Baseball player swinging at a pitch

Sometimes having a DH makes sense!

We began discussing the concept of staff liquidity during the re-read of Commitment. Liquidity is a financial concept describing the ease of converting assets into cash. Stocks traded on a major exchange are liquid while stocks in private company traded between friends are far less liquid. Translating the financial concept to software development and maintenance teams, liquidity is a measure of the ease of turning effort into functionality. Staff liquidity is valuable three significant reasons:

Staff liquidity reduces risk. In Waltzing with Bears, Tom DeMarco, and Tim Lister defined five categories of risk.

  • Intrinsic Schedule Flaws
  • Specification Breakdowns
  • Scope Creep
  • Personnel Loss
  • Productivity Variance

Staff liquidity helps the team move people to bottlenecks caused by capacity problems, which reduces three of those risks (schedule flaws, personnel loss, and productivity variance).  For example, a team with a testing capacity problem will tend to fail to deliver or end up delivering partially tested code. When a bottleneck is identified, resources with some testing experience from within the team can be used to increase testing capacity. This is why everyone on a team can’t be purely a specialist (I-shaped person).

Staff liquidity increases productivity. The ability to get work done so that the business or a customer can provide feedback has been shown to  increase both quality and productivity over time. Don Reinertsen in The Principles of Product Development Flow (who was interviewed on SPaMCAST 92) stated at the outset of Chapter 8, “A little rudder early is better than a lot of rudder late.” The faster a team gets feedback, the smaller the impact of any potential change or defect. Staff liquidity prevents teams from getting stuck, delaying the completion of work and getting to a point where feedback can be gathered in production.

Staffing liquidity increases trust. Trust is a multifaceted term; however, one ingredient in trust is doing what you said you would and being able to prove it. Being able to adjust capacity in order to rally to problems or to remove bottlenecks increases a team’s ability to deliver. Additionally, the reduction of systemic risk lowers that amount of tension present in any work environment which increases trust between customers, management, and the team.

As noted in our read of Commitment, staff liquidity is good for everyone. But unless you have the luxury of having constructed a team with T, M and Pi-shaped people, how can you assess staff liquidity? Assessing the capabilities of the team can be as simple as canvassing the team during a retrospective. Ask team members which roles they could handle in a pinch and then ask the remaining team members to provide feedback. This approach requires a significant amount of trust among team members or the feedback will be perfunctory. A second easy mechanism is to actually watch what happens when a team runs into a bottleneck. Just waiting to see what will happen is a bit scary. This is the approach many inexperienced scrum masters and coaches use under the mistaken assumption that urgency will spur people to move outside their comfort zone. Combining the two techniques is actually far more useful. Asking about the breadth and getting team members to public commit to having more than a single specialty plants a seed which urgency can be used to push people into action (a type of anchor bias). Once the team understands each other’s capabilities, have team members with the most options pull their work last and keep a buffer of capacity free to help others.

Staff liquidity is not rocket science; however, it does require that teams and team members spend time understanding their capabilities. Time for introspection on capabilities and capacity must happen before starting an Agile effort and should be revisited during any effort. Real life will provide feedback and experience helps people to grow and change increasing options and staff liquidity.