To Increase Technical Agility, Focus on Feature Cycle Time

Organizations that try to adopt Agile methods are often disappointed. They invest a lot of energy standing up a framework such as SAFe, or they bring in a lot of Agile coaches, create Scrum Master and Product Owner roles, and then it seems like things are different, but really kind of the same: the time between product releases might drop from six months to three, but getting below that seems impossible—making A/B testing infeasible; and product quality seems to actually suffer.

We have seen this picture many times, and we know exactly what the obstacles are: and they have nothing to do with SAFe, or Scrum. They have everything to do with focusing on the wrong things.

If you don’t focus on the right things, then everything else that you do will have little impact: it will be noise.

Unfortunately, a lot of what Agile coaches are taught—and therefore teach—is wrong. Early Agile narratives stuck within the community, and a lot of coaches do not have the breadth of experience to discern what actually works from what does not work.

If you don’t focus on the right things, then everything else that you do will have little impact.

To know what works, you really have to be in a role of accountability for awhile, so that you understand a manager’s perspective. It also helps to have sales experience, because that teaches you to think like a customer. Having mostly Agile coaching experience will not suffice: it is like someone who has never actually used math teaching it. That sounds so nonsensical, but that is often what we do when we bring in Agile coaches who have never had delivery let alone P&L accountability themselves.

And so it is not a surprise that what is often taught in the name of agility is not right, and focuses on the wrong things.

The Most Powerful Driver

If you want to change behavior, there is no substitute for measuring something and calling attention to it; and in my experience, the most powerful behavioral driver is the time that it takes to deliver a complete working feature or set of related features to actual product users.

This is important: I am not talking about what Agile coaches often refer to as story cycle time. The problem with that metric is that Agile stories are often not a complete feature. We would like them to be, but it is often not feasible, because products are complex, and it is often not possible for one team to create an entire feature by itself.

Consider the example of a machine manufacturer whose products contain control units running software, written in C, which sends “telemetric” data back to a data center, where that data is streamed to big data analytical tools written in Java, which then populate databases, which are then read by Web and mobile apps written in Javascript. It is a rare team that can implement an entire feature that requires changes to all those components, and so real world features often require that the feature be split up into separate bite-sized “stories” that individual teams can complete.

Without technical agility, you will never have business agility.

But a story is not a full feature, and so it does not get deployed by itself: to be deployed, one has to wait for  all the related stories to be completed, and then integration tested. And that is where things usually slow to a crawl.

So measuring how long it takes to complete stories—the team “cycle time”—tells you almost nothing about how long it takes to bring new features to the users, which is what you really care about to be able to do A/B testing and ultimately have business agility.

But if you start measuring feature cycle time, better thought of as feature lead time, then you daylight the slowness of the integration and deployment. By daylighting that slowness, people start to look into what is wrong: the bottlenecks, and there are many.

There are many inherent bottlenecks to be able to integration test and deploy complete features, and solving that is not easy; but the place to start is to shine a light on it. Because unless you remove those bottlenecks, you will never have technical agility; and without technical agility, you will never have business agility.