Kanban metrics made easy - the other kind of pirate metrics.

You may have heard of pirate-metrics in the realm of startups and customer behavior because Acquisition, Activation, Retention, Revenue and Referral gives us the acronym AARRR! which to some sounds somewhat piratey.

But that is not the kind of pirate metrics we’re talking about here. This is about a simple, quick and easy way to gather flow-data by just ‘carving a mark in the tally for every prize won [or in this case: For every day spent].’

The basic idea – as presented for example by Benjamin Mitchell in his Talk at the LKCE 2012, see slide 31 – is to just mark cards with a “tag” for each day that it spends in a certain column. For extremely narrow cadences this timeframe might be even smaller (e.g. half days). Basically it just means you

1. assign “signs” to the columns (e.g. R = Ready, A = Acceptance test definition, S = Story Preparation, I = Implementation, P = Post processing) (remember to put the 'signs' on the board as well so that everybody can look up the meaning of the tags immediately) and

2. at defined intervals have somebody go over the board and 'tag' all cards according to their current column.

3. Use the information gathered by this in Kaizen events, retrospectives and the standup meeting.

Sample pirate tags

Sample of pirate tags created in half-day intervals on a (hypothetical and hopefully unrealistic) story card, that spent half a day in ready, one day (two half days) in the definition of acceptance criteria, half a day in story preparation, half a day in implementation and two-and-a-half days in post-processing.

Just a thought: Perhaps you don't need fancy software after all,to start getting quantitative feedback on your work...

till next time
  Michael Mahlberg

Yes, you do need a “Dashboard” (a.k.a. Andon - Board)

And no, I don‘t like the terms “Project Dashboard”, “Lean Dashboard” or “Agile Dashboard”. I do like the concept of the andon-boards

But what is a(n agile) dashboard, and why do you need it?

Speed is nothing without control

Most lean and agile approaches include some kind of feedback mechanism to enable informed decisions. In Scrum for example some information is fed back into the loop in the sprint planning as the capacity for the next sprint. In flow based approaches the feedback is often build into the work organization. When a kanban approach to process control is in place it can at least be found in the capacity of the stations (a.k.a. WIP-Limits per column).

This may be enough for a while, but it is not enough for the long run.

How often is an autopilot ‘on course’?

Actually not much at all - if it would be possible to set the course once and then ‘just let go’ you wouldn’t need an autopilot. The main reason to have an autopilot is to counteract the little deviations off the course caused by internal or external disturbances. So the autopilot constantly correct to the target, but the target is only reached for very short periods of time.

You’ve got to know that you’re off course to make adjustments

To be able to auto-correct your course, you have to know wether you’re on or off course. And that is what a dashboard can tell you. By making the actual ‘course’ visible as early as possible. On a dashboard. That is updated as soon as the information is available. And this is where an automated dashboard can come in handy.

What should go on the dashboard?

Whatever you’re aiming for!

• You want to spend a certain amount of your capacity on a specific project? Then the actually spent time per project has to go on the dashboard.
  
• You want to increase the test coverage? Then the current test coverage has to be displayed.
  
• You want to spend at least x% of your time on improvements? Then the time spent on diferent types of work has to go on the dash.
• etc.

So, how do you navigate your project?

’till next time
  Michael Mahlberg