The Case for Lean: Capturing Business Work

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 about team dynamics, in the third about principals and agents, and in the fourth 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 that process.

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

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. This includes the poor product owner, whose work is finished before most agile boards start.