A scrum master came to me recently telling that he had given up on Scrum and would like to try out using Kanban with his team. As part of a large organization, they are still using Scrum in theory (as that is the common language with other teams) but in practice he realized that it does not fit their current working environment. So this is some kind of “Scrumban” (referring to the excellent book of Corey Ladas), but that is going to be the topic of another blog post.
When we started to discuss yesterday how exactly they would like to start using Kanban, first of all, I was positively surprised how enthusiastic he was, and as a result, how well prepared he was from conceptual point of view on how Kanban should be done. He knew all about value stream analysis, visualization techniques, work-in-progress limits and Cumulative Flow Diagrams.
However, when we arrived to this last point (I mean CFD), he was 1) surprised hearing that it can be done for more than just being able to tell how WIP changes over time (like measuring lead time and cycle time etc.), and 2) wondering what this is good for in general. I think I could explain to him fairly well all stuff about the 1st point, but when we got to the 2nd point, I started to think myself: btw, why is this good for us anyway?
No doubt: being able to tell (mostly to ourselves and to upper management) that Kanban is a good way of increasing the throughput of the system, enhancing the predictability of work flowing through the process and thus improving efficiency overall, is a good thing. However, is it worth the hassle? I mean, to be able to constantly and reliably generate all these statistics, you need tons of data, and some extra effort of processing these data. If I’m thinking about it, this is one of the most hated aspects of Scrum as well: getting on the nerves of everyone to make sure they enter remaining effort per task every day into Jira / Excel / whatever tool used, keep tasks statuses constantly up-to-date etc. Probably in Kanban this administrative effort is smaller, but still, it’s there.
So back to the good parts: do we need this at all? I mean, if we take WIP limits seriously, and slowly but steadily decrease them over time as process efficiency improves and bottlenecks are removed, then increasing throughput and speeding up the flow is given anyway. So the “prove to ourselves” part doesn’t necessarily dictate using metrics. What about management? My experience is, they care ONLY about deadlines and don’t usually give much attention to details of increasing process efficiency. So if hard work is seen and deadlines are (more or less) kept, I wouldn’t say CFDs and such things matter to upper management too much either.
So there are clearly both benefits (but maybe not too large) and costs (but probably also not too high) associated to Kanban metrics. Is it worth the pain? At first, probably yes, for 1) the assumptions above need to be validated so we should give it a try, and 2) over the long term, we are engineers in the end so like to measure things and see our great results in numbers, right? Of course, point 2 is only an illusion. Measuring indefinitely complex and chaotic software engineering efforts with a small set of KPIs is dangerous, we fool ourselves very easily, so be careful :).