When team transition from an iteration-based (i.e. Scrum) to a more flow-based (i.e. Kanban) approach to software development they often stand 3 big risks; no planning, no retrospectives and no celebrations. Which, when you look at it, just leaves work work work.
Exactly - I wouldn’t want that either.
In this post I’ll show you a little trick I picked up to handle the last one; no celebrations. I know I’ve stolen it from somewhere, but for the life of me I cannot remember where. Please enlighten me and I’ll attribute you accordingly. [UPDATE] I picked this thing up from Joakim Sundén (see comments). Yet another thing he has thought me. Thanks dude! In iteration based approaches to software development there’s a natural end point, goal for the current work; the end of the sprint or iteration. That’s one of the really great things about Scrum I think. The little helpful pressure that tells us that we need to get these items done.
But using a more flow based approach such as Kanban there’s nothing to hinder you from accomplishing that. You can have deadlines or Service Level agreements for when the items should be completed to get that on the individual work item level.
I have now introduced the Cake limit in a number of teams I’ve been coaching. It’s really quite simple; just put a Work in Process (WIP) limit on the Done-column of you board:
When I first saw this I thought it was a prank of some sort so I asked
the team. But "No", the explained, "when we've reached 40 items in the
Done column work start to back up. And the only way to resolve that
bottleneck is that the PO buys us a cake and congratulate us on a work
well done."
Simple and quite brilliant. You also re-introduce the all-too-easy
missing celebrations, but based on the number of Done-items.
"But, why 40, you ask."
Well, pick a number that will give you cake at a reasonable interval.
Maybe every 3 weeks or something.
"But, will that not result in smaller tasks and trying to make them
going faster over the board", you continue asking.
Yes, I respond, and we want that. Right?
"But, that is not a really important metric now is it?", there's now
dispair in your voice.
No, not really. It's just for the team celebration, mind you. Just to
get, what's called a nice cadence in our work. To avoid the monotonicity
of just working of the backlog.
### Simple Metrics
For metrics I always start out with some really simple ones. It's easier
to introduce metrics than it is to remove them so be careful.
**Lead time per size group** - as you put the item on the board,
classify them into Small, Medium or Large and write a date on the
stickie. As you take it of, note the date in a Excel-sheet. You now have
the lead time for that work item and can start tracking trends per work
group. Pretty soon you can start making predictions for how long
different kind of work will take:
- A small takes between 3-4 days.
- A medium have during the last 3 months taken around 5.7 days, with 2
ones off by mostly 10 days.
Things like that. Pretty cool, huh? Stakeholders often values
predictability over speed in my experience.
**Number of items done / week** - with this simple metric we see our
throughput. Are stuff coming out in the other end? Do we get anything
done?
Here too the actual number is not that important but the trends are.
Start tracking in a nice diagram and post on the team wall to get good
attention.
Remember - the metrics are there for you to learn from. It's not an
evaluation of you and your qualities, but rather the qualities of the
current process. But without metrics you have no easy way of telling if
you're improving or not.