The Case for Lean: Presenting Status

Jun 27, 2016

I’ve found myself advocating for Kanban methodologies as I’ve advised agile teams, and I’m working through my reasoning in the hopes of understanding it better myself. In the first article I talked about program oversight, in the second I talked about team dynamics, and in the third I talked about principals and agents.

This time I want to talk about presenting status to management. I recognize I just lost half of what audience I hadn’t already chased away, but I just could not come up with a way to make that sound more interesting. Still, since we’re stuck with it, we might as well do as good a job as possible, because presenting status poorly is a fast way to get “help” from upper management.

Those of us who use and advocate agile in large organizations can be at a disadvantage at status time. The users of traditional methodology have detailed estimates, based on years of past history, and can identify exactly where they are in their lifecycle (right up until reality intrudes and everyone learns how long the project will really take). Agile practitioners typically don’t have as much past history, and agile teams are self-organizing, so my team doesn’t do things exactly like those other teams anyway. Plus, we try to plan as we go, so often we only have a vague idea of what we’ll be working in a year’s time. (This, as contrasted with traditional methodology, where we have a very clear and very wrong idea of what we’ll be working in a year’s time.)

Now, add to that the fact that agile practitioners have invented brand new terms for everything that management thought it understood. We’re telling management that we’re partially complete with a feature. We mean something very specific by that term, but management probably doesn’t know that. We tell them we had consistent velocity for the last four sprints, and they want to know how to increase the velocity so the work will be done faster.

And on top of all this, we show them our agile board, with “To Do”, “In Progress” and “Done”. We know that there are a bunch of things in the backlog that don’t show up in “To Do”, because they’re not in the current sprint. We also know that while a story is “In Progress”, we’re doing a bunch of things listed in the completion criteria for that story. Unfortunately, none of that is conveyed with our agile board, which makes it painful to try and use for most status presentations. So instead, we show them our sprint burndown, which has this nice straight plan line on it. If we’re lucky, our progress line looks like a staircase reasonably close to the plan line. More likely, the progress line stays the same for a week, during which time management panics, only to drop like a stone in a single day because three different people finished the stories they were working. By this point, either management doesn’t trust our status, or worse, they think that by panicking they actually helped the situation.

In my organization, as in many others, we have more and more managers who are savvy about agile and understand what the chart is showing. But it still seems to me that this kind of status presentation is needlessly exciting to both sides. This is one of the reasons I’ve started advocating Kanban as a methodology. First, on the status board, it’s more common to see multiple columns, showing states like “Coding” or “Testing” that are actually meaningful to management. (This is possible on a sprint board, but since in a sprint methodology we only take credit for a story when it’s done, showing more columns is rare.)

Second, the kind of measurements that Kanban recommends are necessarily longer-term. Kanban is primarily measuring “flow”: the time it takes a business requirement to go from ready to be implemented to delivered to the customer. Not only is this more intuitive to a manager, it’s easier to help them understand outliers and the need for more data to build an average. Also, it puts the focus on areas where managers can help, not just “help”. Managers can be useful in removing bottlenecks in process or organization in order to improve flow. That’s a much better use of their time than the daily beating.

As with the other articles I’ve written, I’m not intending to say that sprint-based methodologies are bad or inferior. If they’re working for you, the right answer is to keep them. But if you’re finding that you’re facing the kinds of communication problems I’m mentioning here, it might be worth giving something else a try.