Sunday, May 20, 2018

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

Sunday, May 06, 2018

Out of the busy-trap: Don’t call your options backlog

When Scrum was young, one of the objectives was to make sure that the development team was able to work on a fixed set of things for 30 days in a row. (At least that what Ken Schwaber and Mike Beedle wrote in one of the original Scrum Books.) And yes, back then it was 30 days.

A little history

Having 30 days without changing requirements seemed like a very long time for the context in which Scrum –todays most widespread approach to agile– was born. Therefore, a couple of elements were introduced to sustain especially that aspect. The sprint and the notion of the backlog as an artifact are two things that play vital roles in making sure that the objectives for the 30 days really stay fixed.

The sprint has a few attributes that make negotiation between business and development much easier - like a duration, a goal and the whole notion of the fixed subset from the product backlog.

The backlog - especially the product backlog, which used to be quite different from the sprint backlog - contains an ordered list of things that the business (which actually is paying for the music) would like to have. But unless it is in the sprint it is not fixed or committed.

Enter: semantic diffusion

Nowadays many people seem to interpret the backlog as a list of all the things that must be done. And I think must should almost always be questioned. Even the word backlog gives the wrong impression about the requirements – if everything turns out right, the 'backlog-items' are not a burden for the dev team but instead they are options to generate value for the whole organization.

The value stream starts way before the sprint-planning(s)

If we look at the whole value chain from idea-conception to delivery, invoicing and payment, it becomes difficult to extend the concept of a sprint to the ever enlarging group of people. Which is fine, because the sprint was never meant for big groups.
Looking at larger groups of people creating value together, it becomes much more feasible to synchronize those groups via independent cadences and optimize the flow through the whole chain. And once we start looking at the artifact formerly known as ‘backlog’ it sometimes shows that, up to a certain point in time, those backlog-items are merely options – so let's treat them like that (as I wrote a couple of weeks ago.

Naming is essential

And since words have effects, why don't we start calling these things by their names? “We have to decide which options we select” set a different tone from “let’s look at how much of our backlog we can master.”

Make your life easier – treat options as options and only committed items as ‘backlog.’ And perhaps after a while you might be able to drop the term backlog altogether.

till next time
  Michael Mahlberg

P.S.: I find it very helpful to keep in mind that even though the Scrum terminology is almost ubiquitous today, there are only very few teams or projects really implementing Scrum. Product teams who have to deal with support issues, project teams who don't have control over the Product, product owners who only have 2 hours per sprint for their team, scrum masters who serve 5 teams at a time – the list goes on and on.
Given these constraints it pays off to review what we want to achieve if we use lean and agile practices and employ those which actually fit the situation.