Article summary
I’ve spent the last year working on a long-running client project that is ending. Typically, these custom software projects have a short ramp-down phase where we focus on preparing documentation and handing off the project. But this project was a little different.
Knowledge Transfer After Multiple Years
My team found ourselves with ample time to ensure the client team was well-equipped to continue development without our help. After our client told us the main focus for the last three months of our four-year engagement was knowledge transfer, we knew we needed a plan to handle it.
We ended up splitting our knowledge transfer phase into two chunks of work: defining a knowledge transfer backlog and working through that backlog. In this first of two posts, I’ll walk through how we approached defining the backlog. In part two, I’ll share some creative formats that made the knowledge transfer work engaging for both our team and the client developers.
Defining the Backlog
Throughout the engagement, 20 different Atoms worked on the project and built several applications in different tech stacks. Despite spending the last year focusing on leveling up the client team, we still had a huge breadth of information we needed to cover to make sure the whole team was up to speed.
We knew we needed to create a prioritized backlog of knowledge transfer work. We did this to stay organized and on track in the long term and ensure we didn’t miss anything important. So, We took an iterative approach to creating the backlog.
Brainstorm.
First, we used a Miro board to jot down ideas about areas in the codebase where we thought the client team lacked experience or where documentation was missing. Part of the ask from the client was to make sure the entire team was familiar with the entire project, so we had to think about which areas of the code might only be familiar to one or two of the developers on the client side.
We happened to do this brainstorming not long after some new team members had been onboarded, so we had a lot of awareness at that point of where the onboarding documentation was lacking. We decided to consider the onboarding documentation as being in-scope for our knowledge transfer, so we wrote those items down as well.
Categorize.
Once we had a list of ideas, we used the labeling feature in Miro to create some broad categories. We went through several iterations on the labels. However, these were the ones we eventually found to be most helpful.
- AO Only – areas where only the Atomic Object team members had experience.
- Documentation – any items related to writing docs.
- Workshop – areas where we knew documentation wouldn’t be enough and would require workshops with the client developers.
We also added some T-shirt sizing labels (i.e., S, M, L, XL) to each item to help get a feel for how long the knowledge transfer work would take.
Refine and prioritize.
Next, we had to tackle refining each item into actionable steps. We added acceptance criteria and an implementation hypothesis on each Miro card for documentation updates and miscellaneous project maintenance items.
For the workshop items, we jotted down a quick list of things the workshop should cover and some ideas for the format.
We also ordered the cards by priority. The highest priority items were those with the “AO Only” label. The lowest priority items were those that at least one client developer had experience with.
Present to the client.
After we refined and ordered the backlog, we met with the client team leads to present the backlog. Our goal with this meeting was to make sure our priorities matched what they expected and to see if we’d missed any areas.
The client leads were happy with the list we had put together and had just a few suggestions for other knowledge transfer workshops.
Move to the project backlog.
At this point, we had an approved backlog of work we could move into Azure DevOps to track alongside our normal development tasks. We created a knowledge transfer epic with features for the broad work areas and added backlog items for each task we had refined, other than the workshops.
Next Steps
This work all took place over about two weeks. Refining the tasks was the most time-consuming part of the process, but we found that it made the execution phase go really well — just like a well-defined user story makes development tasks go smoothly.
The next step was to pull in knowledge transfer tasks to each sprint until the end of the engagement. We sketched out a rough plan in our Miro board for distributing the knowledge transfer tasks across the upcoming sprints. This was especially helpful for tracking the workshops since we had to account for both running the workshops and the planning that would be needed ahead of each one.
Stay tuned for part two, where I’ll share more about the workshops and how we made them fun!