Velocity in the Enterprise, Part 4

Lot’s of companies are finding out about velocity the hard way. There are many, many contexts where velocity just can’t be used effectively to measure enterprise throughput. These companies are doing some interesting things with velocity in an attempt to compensate for organizational structures that are just not setup to be really agile. These organizations start tracking individual velocity… they start mapping points to hours… they start planning sprints in advance… they start mapping dependencies to try to get some level of predictability. They start doing predictive, plan-driven project management under the guise of agile.

These organizations might be delivering software incrementally… which of course is better than one big-bang delivery at the end… but they are not able to really inspect and adapt… they are not able to do lightweight planning… they are not able to do lightweight artifacts. They are not able to keep the cost of change low… and we know that when the cost of change is isn’t low… we get resistant to change… and being resistant to change is the antithesis of agile. So… it is a pretty interesting dilemma… and we need an answer.

We want to be able to use velocity at the enterprise level, but at the end of the day… our projects and portfolios… our teams and our organizations are not setup properly to be able to make velocity a meaningful measurement. Recognizing the problem is the first step toward defining some meaningful alternatives… the next step is defining some meaningful alternatives ;-). No matter what we come up with… we have to accept the fact that much of what we are reading in the agile literature is not going to work without some sort of measured, planned adaptation. Scrum (by the book) isn’t going to work unless you can transform your organization overnight… and in most companies… that probably isn’t going to happen. Here are a few approaches I have used with varying degrees of success:

Only Build Software with 6-8 People

Believe it or not… this is the answer that lots of people come up with. Why bother to solve the scaling problem at all? Let’s just have small teams take over the world of software development. Let’s never build anything big or enterprise class. Sure… small always makes things easier… but it is definitely going to limit the size of the problems we’ll be able to solve. And somehow this just feels like we are punting on the problem. Maybe we just forget about the rest of the organization and get really good delivering what we can control? We just pretend we are small when the enterprise around us is really big. That works great until you realize your team is doing awesome but the enterprise can’t deliver anything of value. Any guarantee that your team won’t be the ones to go at the next round of layoffs?

Totally Restructure the Organization

We could tell the leadership of our organizations that we have to move to a nested feature team model. For that model to work… we need to get to a place where we have total test coverage, true shared code ownership, we’d have to be comfortable that any developer could touch any part of the system, and we’d have to let go of any sense of having a unifying architectural vision. After all… Enterprise Class Systems Architecture just emerges… right? We’d need to have a solid commitment to building teams around specializing generalist and trust that no solution would ever require any meaningfully specific domain knowledge to build out the product. Everybody gets to do everything.

It wouldn’t be trivial, but I think you might be able to pull off this approach transforming a 50-60 person organization. I maintain though… at some size… at some level of scale… taking the nested feature team approach is going to become unmanageable.

Combine Velocity and Traditional Project Planning

This is a more honest approach than trying to force velocity to work when the conditions necessary for it to work are not in place. Rather than bend velocity into something it isn’t by mapping points to hours… or tracking velocity at the individual level… go ahead and concede that enterprise velocity just isn’t going to work in your company. I would rather see a project manager use high-level Gantt charts at the portfolio level and use velocity and burn-down at the team level. The teams can use velocity to forecast and make higher level project commitments.

The project schedule is created by the project manager using team-based velocity data. The key is to update the project schedule… iteration over iteration… as the team builds and learns about the emerging product. The schedule becomes a high-level roadmap that governs where we all need to be and when. Just like an high-level architectural vision can guide and constrain the solution, the high-level project schedule will guide and constrain our iteration objectives. At the end of the day… it is really never the Gantt chart that is the problem anyway… it’s the attitude that the Gantt chart is Gospel that causes problems. Used appropriately and at the right level of abstraction… the Gantt chart can be an okay tool for solving this enterprise integration problem.

Abandon Velocity all Together (Almost)

The solution is going to take more than a few paragraphs to explain… but I want to touch on a few high level ideas before we wrap. The answer to the velocity problem is going to be found by looking outside the boundaries of traditional agile approaches and building in some of the principles and practices that seem to be just outside mainstream agile. We are going to need Lean… we are going to need Kanban… we are going to need the Theory of Constraints. We are going to need to think differently about how we select and approve project and how we are going to build our project portfolios. We are going to have to make smaller bets and build systems in smaller chunks. We need to start focusing on the flow of value that LEAVES the organization rather than the “value” we create INSIDE the organization.

We’ll explore some of these ideas over the next couple of posts.