2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- February 8, 2017
- Collaborate
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.
Previous Post: « Developer on Fire Podcast
Next Post: Success to Standish is Failure in Agile »