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