Employee turnover is a harsh reality of any workplace. Your team is in a good place, your velocity is gaining momentum with each new sprint, and then suddenly your star developer turns in his resignation. If yours is like most workplaces, over the next two weeks you will be doing everything you can to extract as much knowledge out of him as possible and extend it to other members of the team. Your velocity will take a hit as people are pulled away into learning sessions, and then a deeper hit when the rest of the team realizes they asked one question too few as their teammate walks out the door. You will be faced with another velocity dive when a new hire joins, and suddenly your team is being pulled away to try to bring that person up to speed. This can feel like somebody came up to your Scrum team and hit the reset button, wiping away all that positive momentum. This is every ScrumMaster's worst nightmare.
So how do you prevent this? Well, employee retention is really nothing you can control. Your team members will
leave at some point; it's the nature of the business. What you can focus on is easing that transition so as to lessen the negative effects it can have on your team and velocity. Losing a pair of coding hands is one thing, but losing the knowledge behind those hands is another. This is why an effective knowledge management system (KMS) is vital to your team's success.
A strong KMS, balanced with Scrum, can improve your velocity and prevent the negative effects of team-member turnover. The problem is that many think the Agile Manifesto actively pushes away this theory with its "Working software over comprehensive documentation" clause. I would agree that documentation is of little use here. But it's only in a perfect world that our employees stay forever and our projects are relatively simple. In reality, for complex projects there must be some kind of system in place to retain knowledge and documentation in order to prevent turnover-related failures.
Finding the right balance between a strong KMS and an effective Scrum development cycle is not a trivial task. Your team might struggle at first with the idea that, even in an Agile environment, they suddenly need to be documenting architecture or code functions. "Isn't the whole purpose of Agile to stop documenting and just produce working stuff?" they might say. The answer, of course, is no. Agile does not mandate that employees stop
documenting things, as many would believe. It simply states that we should emphasize working code over
documentation. It does not dictate that we should stop documenting altogether. The trick is to stop looking at the old way of documenting, and start looking for ways to blend it into Scrum.
- Don't use wikis. Wikis are difficult to work with. It takes forever to write them, forever to read them, and forever to extract the information that you actually want out of them. It's difficult to edit a wiki due to its size and style. Wikis should be used for historical things that rarely change, not living code. They simply require too much maintenance.
- Don't tie documentation to Done criteria. You should never tell your team that in order for a story to be "done," they must also have documented it. This is how you get bad documentation and frustrated team members.
- Do motivate the team to come up with their own solution first. The team might not see the benefit of a strong KMS; they may need some convincing. Give them clear goals, just like any user story, and see whether they can create a solution on their own. If they can't, suggest some of the techniques listed below.
- Do promote KMS as a tool, not a chore. Team members hate chores, but they tend to like tools. It is not helpful to lead with the goal of "Saving knowledge so that when they leave, the ship doesn't sink." That doesn't motivate anyone to properly document. Instead, treat KMS as a tool to help the entire team better share knowledge with each other to increase their velocity.
As with all things in life, there is no silver bullet for implementing the perfect KMS every time. You might have to try one thing, then iterate toward another (this is Agile, after all). You might choose a hybrid of a couple of techniques, or settle on one that is a good fit for your team. When looking for a strong KMS, keep in mind the following user stories to help you find the best fit:
- As a developer, I want to find out whether there is an answer to my question in ten seconds or less.
- As a developer, I want to understand the answer to my question within 30 seconds or less.
- As a developer, I want to type an answer in 60 seconds or less.
No, these aren't perfect user stories, but you can see a clear overall theme: Developers want things fast. They Google it, and if they don't find it on the first page, they likely give up. This is why wikis are a bad idea; they fail almost every one of the user stories above. They require developers to read through long documents, not knowing if they even contain the answer. Creating a system that can give quick answers and also allow your team to create answers rapidly is key in a strong KMS. Here are some commonly used techniques to help you build your own.
StackOverflow is the gold standard of programming questions. Why? Because it's simple. Ask a question — get an answer. Programmers use this site more than anything else because it is easy to find what they are looking for, and they can extract the answer quickly. Many companies have sprung up in the past few years that offer their own, locally hosted site that is a clone of Stack Overflow for your company. Companies such as Atlassian
, and others have created these tools that are easy to deploy and can help your team create an effective KMS.
This is a popular technique already in practice at a lot of software companies. When developers finish a key software component, they give a presentation with an overview of what they did, explaining it to the rest of the team. These talks are informal and serve to simply keep the Scrum team notified of any big changes so that everyone is on the same page. You should record these or, at the very least, save the slide decks to use as references or to give to new hires.
is a popular Agile technique already used in a lot of software companies around the world. The basic premise is that you always have two programmers working on a piece of code at one time. This prevents you from creating knowledge silos and instead spreads the knowledge across the team. If a team member should be rotated or leave the company, you would still have someone with virtually the same knowledge to help fill in the gaps the team member might leave behind.
As with any change, you are likely to get some resistance at first. I have found that a popular resistor is the my-code-is-perfect person. This person believes they don't need to document because they rigorously adhere to Clean Code guidelines. "Just by reading my code, you should be able to tell what it does. I don't need to document," they complain. The problem here is who the you
is in this user story. Is it a senior developer? A manager? A junior developer? Creating code that is perfectly
readable, I would argue, is impossible. Your next hire might be an intern in his first year of coding — or a senior engineer. These examples might seem extreme, and you don't need to plan for every worst-case scenario. However, if your architecture is homegrown and custom to your product, it is likely that a new hire (even an experienced one) will take a long time to get acquainted if there is no documentation to help them.
Overall, an effective KMS is something no Scrum team should be without. Even without the threat of turnover, it can help your team members learn from one another faster to create more constructive growth. While some naysayers may look at a KMS as something Scrum can do without, the evidence is clearly there to show that the advantages surely outweigh the disadvantages.