Velocity in the Enterprise, Part 5

Before we start talking about an alternative to velocity, let’s take a moment to recap the last few posts in this series… I’ve basically stated that velocity only works in certain circumstances and in certain types of organizational structures. For velocity to work as advertised… first, the organization has to be totally feature driven. Every team has to work on a complete end-to-end slice of user functionality. Second, the teams have to be totally nested underneath the project in a many-to-one relationship. If teams are supporting multiple projects, team level velocity isn’t meaningful at the project level.

What’s interesting is that most companies have a really hard time achieving this ideal structure even within the technology organization. At this point, we haven’t even considered the parts of the business outside of product development. What about sales… what about marketing… what about accounts receivable? In some form or fashion… these guys are responsible for getting the value out of the system too. Are these guys going to be nested underneath the project team hierarchy as well? I doubt it. So when we start looking at the enterprise value stream… velocity is almost a non-starter. The answer I believe lies in thinking about the collection of teams required to deliver a value feature much in the same way we look at the individuals on a single team. Let me explain.

A team is a collection of people necessary to deliver an end-to-end feature. You might have several developers… a BA… a tester or two… a customer… maybe an agile PM or a ScrumMaster. The team considers one or two small features at a time… they collectively negotiate the requirement and decide how the feature is going to be constructed. The team breaks the feature into tasks and the tasks are completed by the individual team members. They collaborate… they self-organize… they work together to make sure that all the parts come together in the form of a cohesive whole. The cohesive whole is then reviewed by the customer and accepted by the business.

The team always works on the highest priority features with the goal being to get to done as fast as possible. The team values finishing one feature before they start a new one. Team members help each other and balance the work because each team member has skills outside their primary area of specialization. There is an implicit understanding that there has to be some design before you can code… some code before you can test… some test before you deploy. Some of the steps are handled sequentially… some are handled in parallel. The team handles all that sequencing because the unit of work is small enough that they can handle it.

The measure of progress isn’t activity… it isn’t tasks on a plan… it is completed features.

Now… let’s build on the core concept of a small team working to deliver a discrete feature and explore how it could be applied to a team of teams working together to deliver a small project. The collection of teams is analogous to a collection of individuals… the small project is analogous to a single user story… releases are analogous to sprints… user stories are analogous to tasks. The teams get together at the beginning of a release to collaborate on the one or two small projects that they can deliver in the next three months or so… they break the project into user stories that are assigned to teams. Teams then deliver their individual pieces and work together to integrate those pieces into an integrated whole. The whole is accepted by the business and released to an external customer.

In this example we haven’t done away with velocity all together… each team can track its own individual velocity to help measure throughput and get more predictable. In this case though… the only meaningful velocity is the velocity of small projects that make their way through the overall system. Just like tasks and activity don’t measure progress at the team level… from a project perspective… team velocity is useful but not a measure of real project performance. The rate of delivery of small independent projects is the metric we really care about.

Hopefully this is all making sense so far. We haven’t solved the entire problem but this should give us a solid baseline for the next few posts. Hang in there… we’ll get through all this eventually ;-)