Velocity in the Enterprise, Part 7

Okay… we’ve been going on a while now with this whole Velocity in the Enterprise series. Let’s see if we can get things wrapped up with one final post. Last time around we talked about the idea of extending the Kanban metaphor to the enterprise. Just like agile user stories and teams are extended into agile projects and agile project portfolios… Kanban can be extended past the team to drive the flow of value across multiple teams working in concert to deliver multiple projects. Let’s explore this a little further… starting with the team… then considering the project… and then looking at the project portfolio. We’ll wrap by looking at cycle time and the role of management in enabling the organization to deliver.

The Kanban Team

We’ve already talked a bit about the Kanban team explicitly defining the states associated with getting a user story from backlog to done. These states are represented on a board… work in process limits are set for each state… and the stories move from state to state until they are accepted by the customer. When work gets backed up at any one process step… either due to an impediment or a constrained resource… the team has to deal with the underlying issue in order to get back to work delivering value. The work in process limits ensure that intermediate work-products get finished before new work comes into the system.

The Kanban Project

Now imagine a project that involves several agile teams all working toward a common set of requirements. Remember… our scenario here is that these teams are in some way dependent on each other to deliver an end to end feature. When teams must work together, it is important that one team not get too far ahead of the others before value gets delivered from the entire system. Imagine that the overall project has a Kanban board… one where the steps required to deliver the value feature include not only the normal design, develop, and test activities… but also include columns for the work delivered by each of the individual project teams.

The teams themselves limit the number of user stories they can have in play before and end-to-end feature is delivered on behalf of the overall project. Likewise, the project limits the number of value stories that can be in play at any one time. Let’s be explicit… this can create a scenario where some teams may have to stop work while other teams on the project catch up. This forces the system to deal with the team that is going too slow before they can move forward. We need to focus our resources on speeding up the constraint rather than building inventory of partially competed value features.

The Kanban Portfolio

So… we have suggested that teams limit the number of user stories that can be in play at any one time. We have also suggested that projects limit the number of value features that can be in play at any one time. In a Kanban portfolio… we introduce the idea that the organization limits the number of projects that can be at play at any one time. The Kanban board for projects might have columns like initiation, iteration 0, release planning, execution, and deploy… each with their own work in process limits. These limits inherently result in fewer projects active across the organization… forcing the PMO to get projects finished before new projects can be started. Projects can’t be started unless there are sufficient resources available to actually finish.

Cycle Time instead of Velocity

If we look at each level of the organization having only a limited number of work items (user stories, value stories, or projects) that can be in play at any one time… understanding that we are going to intentionally slow down some teams to speed the performance of others… velocity isn’t going to be our ultimate measure of throughput. What we are going to start measuring… the metric we are really going to care about… is the amount of time it takes to get any single work item through the system. The team will have a cycle time… the project will have a cycle time… and the portfolio will have a cycle time. The question isn’t how we can increase velocity… the question is how we can decrease the amount of time it takes us to deliver value back to the business.

Managing to the Constraint

Now we have a system that is laser focused on the delivery of value… not just at the team level… but across the entire project portfolio. No one team can get too far building user stories before they have to aggregate into a value story. No single project can go on too long with insufficient resources before it gets stopped in its tracks. The portfolio cannot keep approving projects that the organization does not have the capability to deliver. As managers, our role becomes understanding the flow of value across our organizations… understanding where that value is constrained… and redeploying people or teams to do the work that is most likely to actually speed up our ability to produce working software. Only by applying people and money to those areas that are slowing us down can we really get better at delivering faster.

In closing…

Okay… I think we have hit all the major points I wanted to address with this series. We’ve talked about where velocity works and in what kinds of organizations it is an effective measure. We’ve also explored where velocity doesn’t work and where it can’t be used as a measure of overall enterprise performance. With some of the Kanban, cycle time, work-in-process limit discussions, we’ve proposed an alternative to velocity that will help us measure our overall ability to deliver value.

I am concerned that we still have a problem in that this whole Lean, value stream analysis… this whole manage to the constraint idea is a pretty drastic shift in thinking about how to manage teams and projects. It really asks us to take a whole new approach to planning and delivery in our organizations. The more I think about it… I want to do one more post… an epilogue if you will… to maybe bridge some of this thinking with conventional wisdom to see if we can make a compromise that is easier to understand and implement. Either way… this is not the end of the conversation around this. I sincerely believe that Lean is the secret to scaling agile in the enterprise… but you know… we have to make this stuff simple and easy to understand.

Thanks for hanging in with me as I explored these ideas. As always… open to your feedback!