Good software is never complete. There are always new features to add, support tickets to address, and more code to write. If a software solution is good, it’ll likely outlive the tenure of most of the developers on the project. A successful project must plan on people rotating on and off the project. To accommodate developers rolling off, a team must put processes in place to foster continuous knowledge transfer. Removing knowledge silos allows for smooth transitions and long-term project success. Here are a few practices my team has put in place to support continuous knowledge transfer.
Pair Programming
Pairing with another developer while writing code is a natural way to transfer knowledge between developers. When developers pair, both learn how the other looks at problems, and how to realize solutions to those problems in code. Team practices and domain terminology through a pair’s communications ensure that the knowledge of the codebase is properly spread across the team.
Pull Requests
Reviewing code should be an exercise of knowledge transfer. A reviewer should not just be looking for missing test cases or potential bugs. Pull requests provide an opportunity for another developer to learn about a section of the codebase they may not be as familiar with. A team should make sure every developer is involved in the review process to maximize the surface area of exposure for developers.
Developer Show ’n Tell
A team should get together regularly to show off some of the work they’ve done over the past few weeks. On my team, we’ve established a weekly “Show ’n Tell” session. In these sessions, developers will take turns showing off either new tooling they’ve built, foundational work that they’ve started for a new feature epic, or just something they’ve found cool. This time provides not only a time for feedback on ideas from a larger group but also a shared awareness of new areas for the whole team. I recommend doing this on a sprint-by-sprint basis. That keeps the amount of information small and consistently digestible over the lifetime of a project.
Utilizing Artifacts Other Than Code
Code is not the only thing that developers should be regularly creating. Artifacts such as written documentation, diagrams, or RFCs allow the team to clearly communicate and broadly share higher-level decisions. But it’s not enough just to create the artifacts and reference them when someone else ramps into the project. These artifacts need to be integrated into the everyday development process. Documentation should be referred to when creating requirements for stories. The team should consult architectural diagrams when discussing potential changes. These artifacts can contain a wealth of information, and keeping them top of mind for the whole team allows for this knowledge to freely transfer to the whole team.
Closing Thoughts
Of course, there are always more ways to transfer knowledge on a team. These are a few successful practices that have stood out on my team. But what’s important is keeping knowledge transfer a priority for a development team. How that knowledge transfer works in practice for another team might look very different. What is important is that a team should break down knowledge silos, act transparently, and solve problems together as a team, not just individually.