Gaining wisdom
We can learn and get wiser as we gain knowledge of the profession. Getting wiser can happen by itself, with active learning, constant work, and passion. We can also boost learning and, by doing so, get to the goal of being wiser faster. And the wiser we are, the more we see that we understood less than we initially thought. So, we need to learn some more. Learning never stops. In this section, we will understand this in the context of pair programming.
Improving the system
We can also use pair programming sessions to improve parts of the system. It's a similar approach to advancing our knowledge, but in this case, we are talking about specific parts of the system.
Especially in complex systems, there are people who know it very well; that is, specialists in the domain, logic, and particularities of that part of the system. Usually, if you are a specialist, everyone comes to you to ask questions. But you may also have other things to do – other tasks or parts of the system that you need to take care of. That is when you become a bottleneck for the whole system. The team, coach, manager, or anyone else will need to observe this situation and come up with a plan to pass their knowledge to a few other people. A good practice is to have at least three very knowledgeable people on a specific part of the system. This helps if you want to optimize your development for a fast flow, fast feedback type of development.
When it comes to passing knowledge to a part of the system, we can talk about programmers, testers, analysts, ops, security, or any other role in the team. So, pair programming can be a tool to make pairs such as programmer-analyst, programmer-tester, and so on. We can also extend the whole pair programming approach and lose the programming part. We could have two analysts, for example, pair up in the same way: expert-beginner. But if we are talking about experts and beginners on that particular part of the system, their overall experience wouldn't need to be that important.
Once we've removed these knowledge bottlenecks, we can start thinking about improving the system. Pair programming, or plain pairing, will help the team deliver faster, with some initial time well-invested for the long-term future of our product.
Staff liquidity
This practical approach to advance knowledge, where the most knowledgeable individual would teach others who are less knowledgeable, rather than performing the most difficult tasks, has a name: staff liquidity. The concept of staff liquidity was introduced by Chris Matts during an article back in 2013 (a link for this has been provided in the Further reading section).
Chris Matts explains that there are four levels of knowledge anyone can have for a particular skill or part of the system:
- 0 – "I know nothing!"
- 1 – "I can run it."
- 2 – "I can tweak it or bug fix it."
- 3 – "I can redesign or refactor it." / "I OWN it!"
Here are the steps we follow to implement this in our organization:
- We need to make a list of skills we need to have (for example, Java, JavaScript, unit testing, continuous integration, and so on) and a list of system parts that we need to know (for example, frontend, backend, database, and so on).
- We must then list the names of all the team members, one after another. We use the 0-3 marking system to mark the current situation, in a matrix form.
- Finally, we need to make sure we have at least three people at level 3 for each line in the matrix. How do we get there? Via learning sessions with pair programming. Budget the time needed for learning and get pairing!
Of course, staff liquidity goes beyond pair programming, but we will only focus on how suited it is for boosting pair programming's extensive usage. You can use staff liquidity in any aspect of the organization where you need to improve a team member's skills, alleviate bottlenecks, increase time to market, or accelerate feedback cycles.
In this section, we looked at some ways to get wiser, and we looked at systemic thinking for advancing learning. Staff liquidity is a very powerful concept that needs to be in every senior professional's toolkit. We can be so much more efficient, and deliver so much more quality, just by organizing ourselves better. And as a bonus, our environment's spirits and morale increases a lot. Next, we'll study how we can conquer complexities in our development systems.
