Introducing Staff Liquidity (1 of n)

This is the first of a few blog posts on Staff Liquidity.

Liquidity is a term used in financial markets to describe one aspect of the health of a particulary market or stock. A liquid market is one in which there are active buyers and sellers looking to do business. An illiquid market is one where there are either no buyer, no sellers or no buyers or sellers.

The liquidity of a market is normally expressed in terms of the spread between what people are prepared to pay (bids) and what they are prepared to sell for (offers). This is the bid-offer spread. The bid offer spread of a market or stock is an emergent property of the market or stock based on how long the broker thinks they will have to the stock before they can unwind their position. The time taken to unwind a a stock is determined by the number of active buyer and sellers (and the size of trade they will do). The other factor driving the bid offer spread is the volatility of the stock. A volatile stock with few buyers and sellers will have a high bid-offer spread. A stable stock with lots of buyers and sellers will have a narrow bid offer spread. A bid or offer is really an option to buy or sell a stock.

The Bid-Offer spread cannot be used as a measure of liquidity in software development. “Time to unwind a position” is useful as a outcome metric to measure the health of a software development team, however it is not much use as a diagnostic metric or a means to manage the liquidity of a team. So far, the best way I’ve discovered to manage liquidity is to consider the number of options in the system*. This is done quite simply by the team creating a skills matrix.

The team create a simple skills matrix. Along one side, are all the tasks that need to be done on the system, and along the other are the names of the people in the team. The members of the team then score themselves as follows:

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!”

The team can use the matrix to make sure that they can cover the application development under their responsibility. They can ensure that there are a minimum of three people who can perform each task (at level 3). If there are only two, they may introduce a policy of not allowing both to go on holiday at the same time. If there is only one or zero, they know they have a key man dependency. Key man dependencies impact the team’s time to value as they cannot move forward if that person is not available. At the stand up, the team can use the matrix to ensure that they address their key man dependencies.

There are a number of points to consider when using a skills matrix:

• The tasks are not necessarily “skills”. It is normal that they refer to a part of the system. e.g. Feeds, Payables and Receivables rather than C++, Java, SQL. In order to do “Payable”, a team member might need a knowledge of C++ and Java.
• The tasks may be very very small such as run a build script which only takes 5 minutes. If the team has to wait a week for the person to run it, it has taken a week even though the run time was only 5 minutes. If there is only one person who can do that task, the team might list it until it is no longer a problem.
• People who have moved internally to other teams can be included in the skills matrix provided there is an agreement in place for them to come back and help the team.
• Sometimes people overstate their ability. If someone says they are a “3”, ask them to do the next piece of work in that area to test their ability.
• Sometimes people understate their ability because they do not want to do it. This is actually a good thing as both ability and willing are needed to ensure a task gets done. It helps prevent the situation where someone leaves the team because they keep being assigned to work they do not want to do. It can act as a forcing function for other people to learn.
• From experience, updating the matrix every two months gives a chance to see development. A month is not quite enough.

* Footnote: Some people in the Kanban Community have suggested that liquidity can be managed by measuring the number of transactions in the system. There are a couple of problems with that approach. First, the approach manages transaction volume rather than liquidity. Second, the “Liquidity” metric is easily gamed by breaking tasks into smaller and smaller items. Third, it does not systematically look at the whole system. Fourth, the team may be working on tasks in one area of the system and areas of the system could be unworkable or illiquid. Fifth, the metric does not indicate the inclination of the team towards certain work and hides the fact that team members may not want to do the work.