Skip to main content

Velocity in the Enterprise, Part 7

Mike Cottmeyer Chief Executive Officer
Reading: 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!

Next Organizational Myopia?

Comments (6)

  1. Dean Stevens

    Nice series Mike. I did want to point out a common misunderstanding of cycle time. It is often confused with lead time.

    Cycle time, the inverse of velocity, is the cadence. Cycle time is measured as time/units. Both measure the actual cadence.

    Lead time is a duration measure, not a cadence at all.

    They are related by Littles Law.

    Lead Time = WIP / Velocity
    Lead Time = WIP x Cycle Time

    Cycle time is important to the process manager for a lot of reasons including reducing lead time.

    Lead time is what the customer cares about.

    Cycle time can equal lead time but only in perfect flow where WIP is one.

    If we are interested in applying Lean concepts to Agile, using a common vocabulary would be helpful.

  2. Matthias Marschall

    Thanks Mike for that great wrap-up. I really like the idea of spreading the idea of flow throughout the whole enterprise. I've seen to much sub-optiimization e.g. in software development teams. They become agile but the overall system is not able to take any advantage (= business value) out of it because the bottleneck shifts somewhere else where it is not addressed properly.

  3. Jeremy Kriegel

    Great series, Mike. One element that I didn't quite follow was having the kanban board " include columns for the work delivered by each of the individual project teams." Can you elaborate?

  4. Mike Cottmeyer

    Trying hard to do the explaining with words only… no pictures… and that makes it hard. If you think about a requirement moving through its various states at the project level… at the point it is actively being worked, it is being worked possibly by several component teams. Each of the component teams would have a 'column' on the board with a WIP limit. You could only start a new project requirement if there was a sub-team available to do the work.

    Each sub-team would have their own board with their various WIP states and WIP limits and would track the item through its life.

    In short, the project has a board governed by the capacity of the sub-teams. The teams have a board governed by the capacity of people on the team to do the work. Make any more sense?

  5. Jeremy Kriegel

    So does a card split to work in multiple columns at once or does this force a serialization of the process? Do the individual team columns become 'sub-states' of an 'in progress' column?

  6. Mike Cottmeyer

    I suspect that it could be either. I think that in most cases you'd have the card split into multiple columns at one time and allow each team to work in parallel (would have to be some coordination of interfaces and such, but that is another problem). If a required team was at capacity, that would be a constraint that would stop the introduction of new work into the system.


Leave a comment

Your email address will not be published. Required fields are marked *