Agility Might Have Been Waiting for AI

I’ve worked on AI-adjacent scaling and agility challenges quite a bit over the last couple of years and that’s shifting into AI adoption in product/engineering organizations and the wider business more recently. I’ve noticed that there’s a lot in common.

Many of the patterns that I developed, used, and avoided for improving development lifecycles and how companies work over the years are very applicable when trying to shift organizations from AI ambition to AI-Native operating systems. For example, AI theater caught up very quickly to something that took a decade in the agile world to happen. AI is much faster about everything.

I often say that I’m a plumber. Not because that’s maybe the profitable future for us knowledge workers when AGI is here, but no. I found myself over the years, whether it was in the Israeli Air Force back in the nineties, or leading engineering teams and building engineering systems, or over the last almost twenty years at this point helping leaders improve flow in their engineering pipelines and eventually outside of engineering in marketing, sales, throughout the organization. It’s like plumbing. Sometimes things are stuck, sometimes there’s a bottleneck, sometimes there’s a very ugly mess on the floor that you need to clean up. Whatever the context, I come and help organizations, and I do that much better than I do real plumbing.

My clients at Gillette don’t like it when I talk about the “bleeding edge” that much. Go figure. But that’s what I’ve been doing. Applying patterns, practices, frameworks, on new frontiers. Whether that was agile, flow, kanban, outcome thinking, evidence-based management.

Using agile techniques to design and launch award-winning razors at Gillette.

Helping an AI Biotech startup accelerate the velocity of research, discovery and commercialization of therapeutic viruses by organizing people in AI/ML, the wet lab to work better together towards aligned outcomes.

Advancing a multi-portfolio technology organization and the business around it from the early stages of a software factory towards becoming a truly product-native organization.

This willingness to try innovative approaches on new frontiers is very different from what was happening elsewhere in the industry. While I was working with these organizations, a lot of other companies were on a transformation fueled by FOMO and the industrial complex itself.

I was helping organizations tackle expensive problems or explore a very lucrative opportunity.

I often come in when organizations realize that there IS an expensive problem or opportunity they need to ACTUALLY work differently to solve for / leverage. It’s when they realize that the activity theater that the FOMO transformation creates isn’t enough.

That’s why when leaders pull me in to discuss how to shift from Tokenmaxxing to transformation I get a strong deja-vu sense.

When you’re trying to shift from activity to impact, one of the most useful perspectives is visualizing flow and looking for bottlenecks.

It’s a key tool I’ve been using as an organizational plumber.

For example, when working on optimizing the throughput of a product group at a large tech firm back around 2010 we used this end to end flow visualization technique to identify a gap in capacity between the development organization, the developers that were building features, and the testing organization.

One of the early insights that we had, once we modeled and showed this information on cumulative flow diagrams, was that this gap is happening, and it doesn’t make sense to focus too much on improving the development throughput. It makes more sense to focus on the bottleneck, which is the testing. Not necessarily getting testers to work harder. Subordinating the whole way we were working to the bottleneck. Figuring out how to reduce the overhead of testing (e.g. through automation, or easier to access more stable product APIs, improving the testing approach/architecture).

Organizations adopting agentic software development lifecycles (AI DLCs) are seeing that their bottleneck isn’t coding anymore (in some cases, it wasn’t the bottleneck even before adopting AI in coding).

Thinking of looking for bottlenecks and orienting your work around these bottlenecks, rather than focusing on the local optimum of a certain function, is a very useful engineering organization optimization technique that is as relevant these days as it was back in 2010.

It’s so hard to measure the impact of what we’re doing that we’re tempted by these vanity metrics for the activity. We’re tempted to measure lines of code, hours worked, planned versus done, how many tokens people use, how many people here are using their Claude Code or Copilot or Slack AI, how many days a week do they use the things. And how many agents can you run? How many agents are you running in parallel? The more agents you run, the more bragging rights you have, right? That’s easy to measure.

It’s harder to measure the output that you’re creating, but it’s possible. It’s possible to measure how many features are you creating, how many articles are you publishing, how many skills are you creating, how many podcasts are you publishing.

It’s much harder to measure impact. It’s much harder for a product team, or an internal team that’s supporting the organization, to understand what impact are we making in general, and even harder, each small thing that we do, what’s the impact of that thing.

Because it’s so hard to measure, we often measure the output and the activity.

And once we allow ourselves to measure and focus on activity, we are at risk of falling into activity theater. That’s true in case of Agile - where a whole industry focused on activities such as ceremonies, sticky notes, writing stories. And it’s true for AI.

A lot of my work with organizations in recent years has been on saving organizations from activity theater by orienting around expensive problems/opportunities and figuring out effective outcome-oriented metrics that matter to align them on the journey from activity to impact.

In the AI world it’s the same sort of challenge, especially for organizations that are still stuck in an activity theater operating system.

How can you assign an effective /goal to an agent when you don’t have an outcome-oriented value architecture even amongst your human employees? It’s fascinating how the race towards being AI-native is surfacing so many of the gaps I’ve been focused on helping organizations close for more than a decade.

When you can’t rally people around a purpose or a mission, you turn to mandates and governance. I’ve seen the damage that the agile police has done in too many enterprises (I often come in to rebuild agility from its ruins). And the same mandates are being inflicted on people to get them moving towards AI.

If you CAN frame a transformative reality, you can replace mandates by inviting people. Appeal to their intrinsic motivation. People are motivated by autonomy, or you could say agency, by mastering something, and by being connected to the purpose.

It can be useful to think about AI as a product that people can choose to use to get their job done better. Which shifts the role of AI leadership/enablement as well. From policing to shaping AI as a product people will choose to use, will want to keep using, and will miss if it goes away.

I find that a lot of the work I’m doing with product organizations on shifting from being an activity theater or even a feature factory to becoming product-native transfers very neatly into creating AI capabilities that enable an AI-native organization.

We’ve built most companies around the fact that our ability to build and deliver products/technology is a bottleneck that can’t keep up so we need to protect it. The whole design of Agile ways of working creates stability and predictability. But what happens if the bottleneck moves?

First of all, we need to rethink our ways of working.

But more interestingly, we need to rethink the potential of what we can do with products/technology.

The product/tech bottleneck forced us to be very reasonable. To continuously make tough tradeoffs. What if we didn’t have to be reasonable?

Unreasonable Hospitality describes what happens when you break through the chains of the reasonable.

What could unreasonable agility, achieved through agentic software development lifecycles look like? What business transformation could it unlock?

In a sense, real agility might have been waiting for AI. Real agility might be the ultimate AI Impact. And in parallel, agility and product thinking are crucial for navigating the disruptive journey towards becoming AI-native.

Agility isn’t going anywhere. Not in my head, and not in my work. It is the “Powered by Intel” inside the AI-Native organization. As well as the ultimate outcome of being AI-Native. So, no, pivoting from Scaling w/ Agility to Scaling AI isn’t jumping on a bandwagon. It is realizing how important and valuable the lessons from years of helping organizations scale agility to tackle expensive problems or lucrative opportunities are for turning AI ambition to impact.

Want to dive deeper? Listen to my conversation with Philip Morgan about the relationship between AI, agility, and how I’m shifting my business around it.