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, in the third I talked about principals
and agents, and in the fourth I talked about presenting status.
Working for a large, project based organization, I’ve done a bit
of work on proposals and estimation, including estimation under
both traditional and agile methodologies. Often these are firm,
fixed price proposals, so it’s important to create the best
possible estimate. Also, our rules strictly require that all
project work be charged to the contract, so we can’t miss any
activities or people. This means thinking about not just
performing the software work on the program, but also all of the
work required to prepare and plan.
Most of the focus in sprint-based agile methodologies like Scrum
is on the Scrum Team, the set of people who perform the work
and deliver the product. This makes sense; the purpose of the
methodology is largely to structure the behavior of that development
team, and the other roles are primarily defined in terms of how
they interact with the Scrum Team.
However, that presents a challenge for organizing an estimate for
a program using agile, especially a large scale program. How much
work will be involved in performing the Product Owner role? How
will we know how well that work is progressing? The primary
measure of progress for the Scrum Team is working software, but
the primary measure of progress for the Product Owner is user
stories that are “ready”, which is a very nebulous concept.
Additionally, while the development work typically has a nice
agile board and sprint burndown chart, most of the time the
Product Owner doesn’t have a clean way to show progress, just a
bunch of stories in the backlog at various stages of doneness.
This separation between defining, prioritizing, and refining user
stories, and performing the work, seems artificial. This is one
of the reasons I really like the concepts that come with a
methodology like Kanban. With Kanban, the whole process flow
is included in the tracking system, no matter what the activity.
If it’s necessary to get customer buy-in and approval before
work can begin on a story, that becomes another column on the
board, and everyone can see how long it takes to get through
A Kanban methodology can also have the welcome effect of shifting
focus for bottlenecks where it belongs. By putting all of the
process on a single board, not just the development work, any
required work before or after development is made more visible,
helping draw attention to program problems like piling up
software that hasn’t yet been integrated with the rest of the
system, or piling up requirements work ahead of the actual
Finally, a Kanban board can make a cross-functional team feel more
like a reality. In a large organization, where there are specialist
systems, software, hardware, and test engineers, the various
disciplines are usually not going to start performing work in
each other disciplines, no matter whether or not they are on the
same agile team. But by working off the same board, at least they
are in the position of being able to visualize each other’s work
and see how what they are doing contributes to the success of
the whole program.
As before, all of this is possible with any methodology, and is quite possible
with a sprint-based methodology like Scrum. To me, the advantage of lean and
Kanban approaches is that they make explicit and visible the full state of a
program in a way that encourages people to make good decisions for improvement
to the process as a whole rather than optimizing for one part of the process.