Monthly Archives: November 2013

Introducing Staff Liquidity (2 of n)

Staff Liquidity is about managing the number of options in your system. You want to maintain as many options so that you can respond to changes in demand. Once we realise that we want to create/maintain as many options as possible in our system, it affects the way we make decisions. (Author’s note: When I say “you”, I’m referring to the team as a whole).

In the past I’ve seen many development teams that have one or more Bob’s on the team. Bob is the one who knows (some part of) the system inside out. Whenever you allocate work, Bobs is the only person who can do certain things and as a result, he is always fully loaded at two hundred percent utilisation. Bob spends his entire time on the constraint for the project. Whenever a problem/issue/production issue/etc. occurs, Bob is the only one who can work on it. Whenever Bob is working on a production issue, etc. the projects slips behind a day at a time. Some Bob’s enjoy the attention, some don’t and they leave. Allocating Bob to work first is the most effective way of destroying options on a project. On a skills matrix, Bob would be the only “3” for one or more task. The rest of the team are only along for the ride as only Bob(s) can do the real work.

Every time you allocate someone to an item of work, you effectively remove them from the skills matrix. Once you see it like that, you realise the best way to allocate work is to start with the people with the fewest options first. You give them work they can do with the support of an expert. You then do the same for the rest of the team until you get to Bob. Ideally, you do not allocate Bob to anything. Bob becomes the expert who pairs with other team members. Bob coaches others in his part of the system. Bob is instantly available in the event of a crisis without impacting the time to value.

When Bob investigates a production issue, he should do so with another member of the team. As soon as they work out what needs to be done and the other team member is able to finish it alone, Bob becomes available again thus ensuring the team has the maximum number of options to address the next crisis.

Sadly its not too uncommon to discover an entire team of Bobs. Everyone on the team is the only person with a “3” for a part of the system. Once they understand what they are doing, the team should self organise to become Not(Bob)


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.