Propagate Knowledge
There is a huge amount of professional wisdom in software development. These are things that we have never bothered to write down but are standards nonetheless.
This general knowledge is communicated through individual interactions as well as the code we write, so it’s really important that we have high quality interactions within the team and that we do frequent code reviews.
Pairing and mobbing are two practices that support the propagation of knowledge across a team. I find that information spreads like wildfire on teams that pair and it spreads even faster in a mob. It often turns out that the information spread is the most important information the team needs. This includes programming standards and practices as well as a range of conventions.
We want to support collective code ownership so that any developer can go to any part of the code and work on it, but in order to do this we have to adopt common coding conventions and practices. This adoption can’t take place among just one or a few of the team members but rather must propagate across the whole team.
We also don’t want to be developing specialists who are the only people that know a particular technology or part of the code. We don’t want the company to become dependent on one or a few individuals. It’s safer to spread this knowledge around so there is no one person who holds all the knowledge for a particular piece of a system. The “hero” mentality on a non-Agile project, where someone specializes and is responsible for just one section of the code, could quickly become a liability. If those individuals, who were the only ones with critical knowledge of a certain part of the system, went on vacation or left the company then there would be big problems.
Some people think that having specialized knowledge equates to job security but it doesn’t. If the knowledge you possess and only you possess is important, you’ll find that your managers are reluctant to send you on vacation and you might quickly find that you “owe your soul to the company store.”
Just a few decades ago, in the midst of the Industrial Revolution, job security meant having specialized knowledge, knowledge that no one else had that gave you a competitive advantage and kept your manager from letting you go during cutbacks.
But in today’s Agile world job security is not about having and holding on to specialized knowledge. It’s just the opposite. It’s about sharing knowledge and propagating information across the team. The most highly valued team members are the ones who help others and support the team in being the best they can be.
It was great to see you at AgileOpen Northwest last week, and to also see how mob programming has taken off since I first saw it at AONW 3 years ago. When you say that information spreads like wildfire in a team, and faster in a mob, I'm hearing you speak about many different kinds of information: programming patterns or "tricks", domain knowledge, application knowledge, and process knowledge. Last week, I noticed what some folks might call "The 100th Monkey Phenomenon". If you're skeptical about that phenomenon, call it a tipping point. We've advanced the state of our practices to a level that sharing is a requirement. Shared knowledge. Shared code. Shared practices. Shared values. Code is no longer complete when it passes the tests and is accepted by the user. The rest of the team must know what's going on in the shared code base that they're doing CI/CD with. Anything less is collective cognitive debt, or collaborative knowledge debt, or tribal knowledge deficit.