Get certified - Transform your world of work today

Close

Knowledge Transfer in Sprints

27 July 2017



Knowledge transfer (KT) is a necessary evil in any organization, team, or project. Someone is leaving the company, or changing teams or projects, or there’s some other reason that KT becomes an unavoidable part of a project. Since the IT industry is mostly run by projects, this topic therefore has great relevance.

But many times, due to lack of planning and tracking, KT stands for killing time instead of knowledge transfer. As a result, when the new person finally takes over the responsibility independently, he or she faces many challenges, from communication to technical details. Eventually, this will affect the project pace negatively.

What happens in KT — what do we do and what don’t we do?



Most often, the focus of KT is around technical knowledge transfer. Documentation and hand-holding are given the least importance.

Technical knowledge transfer: In a typical SDLC or ERP implementation process, the design architecture, solution methodologies, integration techniques, code packs, release process, etc., are part of this.

Know the business: The business overview, product overview, important business users, etc., are all topics here. The new person coming in must know about the business, about the products and the key stakeholders with whom he or she might be interacting on regular basis.

Communication strategy: Expertise is necessary, but communication is the key to becoming an effective team player. Every team or organization operates with a specific communication style. A new person probably doesn’t know what it is. So the communication strategy must be part of a KT, and it can focus on:
  • Communication channels
  • Templates and formats for event notifications
  • Mailing distribution lists, SharePoint location for formal communication
  • Escalation matrix (whom should I approach first to escalate)
  • Release formalities (e.g., release on every third Monday of the month)
  • Emails and documents to update or refer to for reference (lessons log, defect log, etc.)
Documentation and hand-holding: Minimal documentation to keep track of the key users, templates, and key data (such as product information, process flow, etc.) should be available for ready reference. Its is a good idea to put the new person on the actual work; the outgoing person can shadow him or her for a certain period to ensure a smooth transition.
 

KT in sprints

Plan the KT in sprints. Track its progress and moderate as necessary. This will ensure the alignment of the KT with the overall plan and increase its effectiveness. The sprint length can vary based on the duration available or complexity of the work.

For ease of discussion, let us assume KT Provider = KTP and KT Recipient = KTR. An approach to KT planning in sprints, following Scrum, can be as follows:

Sprint 1

Sprint goal: Know the business and communication strategy
Knowledge transfer tasks (tentative):
  • Business, product overview/project scope
  • Solutioning overview (core technology, coding standards, functional setup, etc)
  • Key stakeholders/users/consultants/team members
  • Escalation matrix
  • Templates, formats, reference documents
  • Hardware access and related information
Sprint review:
  • KTR may summarize his or her understandings so far.
Sprint retrospective:
  • The effectiveness of the KT will be discussed, e.g., pace, sequencing of topics, etc.


Sprint 2

Sprint goal:
  • Technical knowledge transfer
Tasks (tentative):
  • Technical design in detail
  • Data management architecture
  • Code pack details
  • Product release specifics
  • Technical documents
Sprint review:
  • KTR may demonstrate his or her understanding
Sprint retrospective:
  • Any specific topic that needs a further deep dive


Sprint 3

Sprint goal:
  • KTR starts leading
Tasks (tentative):
  • KTR is introduced to stakeholders by KTP
  • KTR works on the products with supports from the KTP
  • KTR interacts with the users
  • KTR creates reports and communicates the same with the stakeholders
  • KTR conducts meetings (if applicable)


Knowledge transfer is an integral part of a project — and many times unplanned. A poorly executed KT is a non-value–add activity for the project and the team. Many times, a post-KT blame game starts and things are rediscovered, which is merely a waste of time and effort. But a structured KT can put the new person in a comfortable position and hence help keep the project on the right pace, level, and timeline.


 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.5 (6 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe