When I started my transition journey, it was for a part of a large knowledge transfer of work from ABN Amro to Infosys a decade back. As I have long been associated with knowledge transfers, I observe many mistakes repeated. This blog is to share the essence of my learnings’ and capture the key tenets of successful agile knowledge transition in a product environment. Further this blog is to encapsulate a methodology that will work for knowledge transfer or transition a large body of work.
Traditional way of Transition
During the initial transition, I was quite impressed by the way the knowledge transfer happen. For each phase there were very clear checklists and criteria on when each phase and can start and end. When I look back, I realize that same water fall based approach is adopted for knowledge transfer also
Typical phases for the knowledge transition of support/enhancement
There have been several developments in this area since we created a large scale model and more information can be seen here (https://www.infosys.com/digital/insights/Documents/application-maintenance-support.pdf )
In the past decade of playing various roles in in agile, I have seen multiple types of work being transitioned. Hence, I realized that while we keep talking about agile for developing software, our knowledge transition or transfer part has been slowly evolving.
Seven Tenets of Agile Knowledge Transition Principles
These principles enable a great ecosystem for the knowledge to flow and create a viable alternate for the transition to be successful
1.Knowledge is a continuum and there is learning that continues to happen
Creating a phase based approach makes it a milestone that has to be achieved. There should be an expectation that it’s a journey and continuously learning will happen. This adopts the Kaizen principle
2. Creation of shorter feedback cycles are easier to make course corrections
Shorter outcome driven feedback cycle creates easier to adopt. This is in the same lines of vertical story slicing. Similarly the module that’s taken up can be completed before understanding the next set of modules
3.Knowledge is considered a fluidic asset that depends on the people’s energy and motivation
While people are motivated to understand the new system, inertia comes down. Another way to look at is for the knowledge transfer plan to be owned by the people who are going to take up the work.
4. Knowledge transfer should be looked at for whole team including the publishers and the subscribers
This will reduce the friction within the two teams and common goal orientation is present
5. Publishers and Subscribers would need to work together to create the plan
6. All other members play the role of impediment removers and play no other role
7. Doing the actual work creates better learning than classroom type learning
The below characteristics and the model includes the tips and tricks of making a successful and smooth transition of product knowledge.
Characteristics of a Whole Team Agile Transition
- Create a Transition plan based on sprints: At the beginning of transition all the modules are laid out and similar to a release plan a transition plan is laid out, preferably for a few sprints.
So while creating the transition plan attention must be paid on who are the actors – The main actors are the folks who are learning, say subscribers, and the folks are teachers, providers. Usage of this type of language is easier in technology-based knowledge transition as there is knowledge flow from every angle.
Once we establish the team of subscribers and publishers, there would need to be a team coach who enables the free flow of conversation across the providers and subscribers. Having a single coach, enables the teams to work together towards the same goal
A clear assumption is being made is the availability of the stakeholders and the acceptance from them to make the transition successful.
For example, let’s take an illustrative example of the following system which has a set of modules. Say the entire system needs to be transitioned. What is highlighted would be the sprint 1 goal. With that in mind, stories for the sprint will include technology setup, knowledge of these modules, understanding stakeholders. With this model, the stories, acceptance criteria for the sprint and spring goal will be oriented towards only these modules.
Definition of Done for each sprint will need to be laid out based on the modules.
- Each sprint having a module on knowledge transfer goal: When we say sprint-based transition plan, thinking from a vertical slicing of a module(s). Each module would need knowledge transition, code setup, testing setup, understanding past problems, known issues and future set of stories.
How are the transition sprint ceremonies conducted?
- Transition plan has an Iteration 0: The iteration 0 for a transition plan includes human side of things, creating a pathway for a smooth transition – access, software required, tools needed, tools training and other pre-requisites to have the sprints move smoothly
- Sprint ceremonies: Sprint Review: Review of the previous sprint including showcase of knowledge, roll over stories, showcase of transition metrics, updates of transition plan and what are the focus areas/impediments and focused modules on next sprint. While creating a sprint review, effort by the team on showcasing the knowledge. One of the teams I coached used the aha moments during the learning journey and environments setup automation as a way to demonstrate progress. Another example was to use reverse knowledge transfer to an existing team member could be great ways to showcase knowledge and progress.
Tools like Jira can be used to bring in visibility within each module and there are several ways of creating great graphs using dataplanes for visual representations.
- Sprint Retro: The transition retro is similar to the usual retrospective with focus only on the sprint work. Hence including all the participants who are participating in the transition (both the providers and subscribers) is critical. One of the teams I was coaching did the retro only with subscribers and there was no major change after 2 sprints. Because of this, providers also joined in the third sprint, there were fireworks, long conversations and very uncomfortable silences. After the first retro, once all the emotions were on display, the knowledge started flowing very smoothly. There was a sense of trust that was lacking from the publishers that created the resistance.
Review of Reviews
Just like how we have Scrum of Scrums for cross team collaborations, review of reviews is focused on removing impediments and decisions based on data from the reviews
In the Review of reviews, one of the teams used the below template to measure progress. They used the 6 parameters to weigh themselves on the progress such as Skill Acquisition, TDD, Story Shaping, Technical Acumen, Effective participation and Risk Mitigation. They added additional parameters well after the knowledge transition to measure progress. This encapsulates the knowledge acquisition is a continuum.
While doing these agile transition sprint ceremonies, it would be good to observe the ice that’s thawing within teams. So during the initial sprints, you would observe the change leads would be talking more. As time progresses, different team members would showcase their knowledge as well as share the impediments.
And the change can be observed from which side is sharing. As the original transition plan would be tending more towards the providers and later ones towards the subscribers.
As a coach, I have often coached the providers to take a step back and after the initial sprint. And let the pull come from the subscribers so that the flow of information and the speed can be controlled by the subscribers rather than governed by the providers.
Amount of time for transition
Here there is a need to change in the mindset that’s required when we look at agile transition. First question is always how long does it take.
Amount of time to transition any product would totally depend on a lot of variables and factors. Only thing that’s constant is that the current Business as Usual work will get impacted. How much of impact the business is ready to take would be inversely proportional to the amount of time to transition the knowledge.
The transition time is best judged by the teams that are impacted and creating a mutually agreed upon transition plan.
Transition Metrics
Next big question in Agile way of working is how do we measure progress and are we there yet?
Some of the ideas of transition metrics is
- Is the transition going per quarterly plan – RAG indicator
- Impediment list – And who’s working on them
- Stories that are completed by the subscribers
- Applications BAU status
- Balance of BAU work to transfer work
- Definition of Done for the product transition
These 3 dimensions provides clear understanding of the transition from the timing, effectiveness of transition and the current applications supported as well.
Benefits of Agile Better Way of Transition
- Clear visibility to teams and across the companies
- No surprises for anyone and adaptability built in
- Ease of transition
- Well defined metrics that enable to move towards done
Conclusion
Knowledge transfer from one team to another is a very difficult process. As we saw in some of the examples, its highly emotional in some sense and there is a huge disbelief in another end. Knowledge transition in the agile teams need to be looked at in its entirety and finding ways to start delivering work is the easiest way to prove whether the knowledge has smoothly moved from one brain to the other.
All the efforts that we have talked about is only for creating the fastest way for creating valuable work to be delivered and proven.
