Over a million developers have joined DZone.

The Case for Lean: Capturing Business Work

In his fifth part of his series, Alan Hohn discusses the role of a product owner and how they often rely on the nebulous "user story" to show progress.

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

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.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

agile approach ,kanban ,product owner ,costs ,estimates

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}