Velocity in the Enterprise, Part 6

Okay… so the travel marathon starts today. Spent an hour in the Sweetwater Pub in the Atlanta airport earlier this afternoon. Had a nice Sweetwater IPA and a great bowl of 420 Beer Cheese Soup. Very tasty. Got on the plane and the weather was so bad in Boston, they kept us on the ground for extra hour while air traffic control cleared things out for us. So… I did a little writing… took a little nap (the beer made me sleepy)… and then got up and did some more writing. The good news is that Delta bumped me to first class at the last minute… so while I was late getting into Boston… at least I had a big comfy chair. Here is the result of my flight today… if you disagree… I am blaming it on the IPA ;-)

… last post in this series, we discussed that when we have a many-to-many relationship between teams and projects, velocity is not a meaningful metric at the project level. Velocity CAN be used to establish a steady throughput at the team level. Velocity CAN be used to help the team get better. Velocity CAN’T be used to establish the rate of flow of integrated end-to-end stories at the project level. Velocity CAN’T be used to establish the rate of flow of small independent projects at the portfolio level. In other words, the performance of the team IN NO WAY directly implies overall organizational performance at the project level… or at the portfolio level. Period.

Value Streams and Work-in-Process Limits

To get this worked out… we are going to have to take a look outside of some of our typical agile thinking. I want to explore for a moment some of the recent thought leadership around Kanban and see if there is anything we can apply. What new idea is Kanban fundamentally bringing to the table? To me… Kanban’s primary contribution is that it is making the flow of value within the team explicit. We all know that every team has to move a user story from definition, to analysis, to design, to development, and ultimately test and deploy. This doesn’t say anything about who does what, or in what order, it’s just that Kanban elevates these steps, puts them on the board, and helps the team visually track how the features are being delivered.

By setting work-in-process limits on each step in the value creation process, on each column of the board, the team can easily see where there are constraints and bottlenecks limiting their ability to deliver valuable software. We can see when requirements are piling up in front of the developers. We can see when code is piling up in front of QA. We can see when we are building and testing a bunch of stuff that never gets integrated or deployed. Putting a visual control in place allows us to focus our time and attention on identifying and getting better at the parts of the process that are slowing us down.

When I was doing my ‘Noodling on Kanban’ series, I spent an hour or so talking to David Laribee comparing and contrasting the various aspects of Kanban with other agile methodologies. He said one thing that really stuck with me. He said that Kanban respects a reasonable division of labor (David’s words). Scrum leaves the division of labor up to the team… it assumes specializing generalists. It assumes everyone can do everything and we can therefore treat the development process like black box. Kanban allows for the fact that sometimes we don’t have specializing generalists, or at least that everyone doesn’t do everything, and gives us explicit tools to manage how value flows across a series of somewhat independent agents (my words).

Bringing this back to our example… we might find a bottleneck between requirements and dev that tells us we need more developers… or maybe the constraint is with testing and we need more QA folks… or more maybe we need more folks that can deploy the code. We might find that we have a persistent problem with the build servers, or the CI environment, that is preventing us from getting value out of the system. I am not saying that we can’t figure out these things in a self-organizing Scrum team… it’s just the Kanban board helps us visualize it and make it more real. It gives us explicit controls to ‘stop the line’ when we have a problem rather than leaving that up the chance.

Cycle Time

Another aspect of Kanban that is new to the agile community is the idea of cycle time. Cycle time measures the time it takes to bring a new feature all the way from backlog to final delivery. If you look at VersionOne’s implementation of cycle time, the tool can tell you how long (on average) that it takes to complete a single user story, and how that time changes depending on its relative estimate. We might be able to say that an average one point story takes 5-6 days. We might be able to say that an average two point story takes between 11-12 days. If you have cycle time… some folks believe that the iteration boundary becomes meaningless… that velocity becomes meaningless… that the team can get predictable just based on knowing how long it takes us to complete a story of some given size.

There is a bunch of evidence coming from the folks applying these ideas that the approach is working and can actually make the team more effective. To me though… at the team level… it is kinda six in one hand, half a dozen in the other. If the iteration is waste… if you don’t need sprint planning, daily stand-ups, or review meetings… don’t do them. If you don’t need velocity measured at iteration boundaries… use cycle time. But… what if we can’t use velocity because in our environment velocity doesn’t work? Now it’s not a matter of cycle time or velocity… velocity just isn’t an option. Could cycle time provide an alternative?

Cycle time in the Enterprise

What I want to in my next post is extend the Kanban planning metaphor outside the team and see if we can apply the same principles across teams. Just like Kanban supports a reasonable division of labor across individuals with various degrees of specialization… Kanban will also support a reasonable division of labor across the teams that make up our product delivery organization. Rather than thinking about the value stream as being made up of specialists delivering on the steps in the development process, think about the value stream as being made up of the components required to deliver a complete integrated feature back to the business.