Velocity in the Enterprise, Part 3

Last post we talked about two criteria that must me met for us to have any chance of establishing an enterprise velocity. First, let’s explore a situation where the teams are not fully nested under the project.

When Project Teams aren’t Nested

Probably the most common example of broken nesting is where the team is responsible for production support in addition to project work. Production support is inherently an unpredictable activity. You never know when your customers are going to call, you never know what is going to be broken, and usually you don’t have much of an idea how long problems are going to take to fix. You can make the case that these items just get added to the backlog and prioritized, but more often than not… these kinds of issues have to be handled right away and worked until they are complete. This happens at the expense of project work.

In general, you allow some amount of time every iteration to deal with this uncertainty, and hope that over time the law of averages works in your favor. Most teams in this situation are not nearly as predictable as they would like to be… or as their customers need them to be. Let’s say you are clipping along at 25 points/iteration and unexpectedly the amount of production support goes up dramatically. Is this a one iteration event? Is this something that we can fix? We just don’t know. The net result is that while overall team performance may be quite stable… the completion of new features is going to become very unstable.

Another example of this phenomenon is when a team is doing work for more than one project. The team’s backlog is made up of features for project A and project B. The Product Owner is balancing the needs of multiple stakeholders and trying to manage the expectations of the business. If the team is not dedicated to a single project at one time… team velocity can be through the roof while the velocity of any given project might be in the toilet. Either way… when you matrix a team across multiple projects, individual team velocity stops being a predictor of project performance.

Team velocity can be great and say absolutely nothing about the performance of either project.

Feature Teams or Component Teams

The component team challenge is probably just a special case of the nesting problem, but since this pattern is so institutionalized, I want to talk about it specifically. Just to level set here… if every team on the project is not working on end-to-end… potentially shippable feature… you probably have some sort of component team structure. Component teams are common in more complex problem domains because many companies are trying to scale by reusing common architectural sub-components. Because the solutions are so big, it is difficult to get the right skills and domain expertise across the entire product. All this leads to teams organized around components.

We might not like it.. but this is out… there and unlikely to change.

From the perspective of each individual team… they have a prioritized product backlog… can get to done-done… and can burn down the backlog iteration over iteration. From the perspective of the enterprise, it takes several teams working in unison to deliver an enterprise class value feature. The Product Owners for these teams are balancing the needs of competing stakeholders… just like in the matrixed project example… but now we have an additional coordination layer to make sure that our teams are working with other teams to sync enterprise level feature sets. We have another example where team level velocity can be excellent while project level performance suffers.

The project is trying to throttle service creation through several teams. When all the services are in place, the project is going to integrate those services into an complete end-to-end feature. How do we normalize the project velocity in this environment? How do we predict the flow of value at the project level. The basic fact is that by rolling up velocity you can’t. You can try to take averages over time but that strategy will fail. Why? Any team at any time can starve the value creation process. You can have 8 teams building great services and one team struggling. That one team will prevent the creation of enterprise value.

Now let’s make things even more complicated. Usually were not just running a single project, we are running a project portfolio. We have several projects that are dependent on the services of these component teams. Now the backlog of each component team is a mixture of features required for multiple projects. In this case… we have a team that is building services for many projects and services have to come together to deliver enterprise features. At anytime in the project… team velocity can be fantastic. We could be stable and improving at the team level and unable to deliver anything at the project level.

Great Teams… Bad Businesses

What’s frustrating is that every team can be doing great agile. They can have a coach, great teamwork, great collaboration, great engineering practices, run great meetings, have outstanding velocity… and the business thinks they are failing. The business doesn’t care about all that stuff… they value delivering end to end features to market as fast as possible. So we have a problem… an impedance mismatch of sorts… between the team and the enterprise. Here is the problem as simply as I can say it… typical Agile scaling assumes a many to one relationship between teams and projects. The reality is… that in many organizations… we are dealing with many to many relationships between teams and projects.

This many to many relationship is what breaks velocity.

So… you have a choice. Either you structure your organization such that velocity works… or you find something else to measure enterprise portfolio performance. Over the next few posts, we’ll explore an alternative to velocity at the enterprise level.