When teams transition from an iteration-based (i.e., Scrum) to a more flow-based (i.e., Kanban) approach to software development, they often face three 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 taught me. Thanks, dude!
In iteration-based approaches to software development, there’s a natural endpoint, a 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 your board:
When I first saw this, I thought it was a prank of some sort, so I asked the team. But “No,” they explained, “when we’ve reached 40 items in the Done column, work starts to back up. And the only way to resolve that bottleneck is that the PO buys us a cake and congratulates us on a job well done.” Simple and quite brilliant. You also reintroduce 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 go 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 despair 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 monotony of just working off 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 sticky. As you take it off, note the date in an 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 kinds of work will take:
- A small task takes between 3-4 days.
- A medium task has during the last 3 months taken around 5.7 days, with 2 outliers off by mostly 10 days.
Things like that. Pretty cool, huh? Stakeholders often value predictability over speed in my experience.
Number of items done / week - with this simple metric, we see our throughput. Are things 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 it 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.