In my formative years, I had a Labrador/Whippet cross called Barclay. We did almost everything together. If I were digging a hole in the garden, he would be there snuffling around it. If I were reading a book, he’d lie on my legs until I got pins and needles. When my family went for walks in the forest, he would scout ahead and race back to check on us, running ten times as far as we walked in his excited loops.
One of the best things about dogs is that you can talk to them when times are tough. They are great listeners and understand you when no one else does.
If I were to get another dog, companionship would be my top reason. There are many other reasons to own a dog, but for me? That’s the top one.
Now imagine I went to the rescue center and asked to see their dogs, but they wanted me to take home a cheetah, because it’s much faster than a dog. That’s what I hear when an organization says they are adopting AI with a myopic focus on speed.
Speed Is Not The Goal: Speed Was Never The Goal
We’ve been here before. We should all lament how the Agile movement withered to a dried husk that only offered “speed”. Speed was never the goal. The primary reason to increase your throughput is to get feedback earlier. When you find out your amazing new feature doesn’t excite your users, you can stop working on it right away.
You throw away far less when you can stop a bad idea early, and you get to move on to a better idea straight away. Nobody should be trying to build software with the most features and the fastest rate of change. When you have too many features and things are constantly changing to accommodate the ever-expanding list of stuff your software does, people start to hate what you built.
Microsoft Word is the most powerful and full-featured word processor available today, yet nobody uses it anymore. They are using Google Docs, which has far fewer features. That means the features Google selected must be more compelling, or that fewer features make the software easier to use. In reality, it’s a combination of many small factors like these. Sometimes one really compelling feature eclipses all others, and the ease of collaborating on a Google Doc in a web browser might have been just that.
If you’d asked someone twenty years ago, they would have told you Microsoft Word had an unbreakable hold on its category, but now it has 3.9% of the market, compared to Google Docs’ 9.6% (source: 6sense). If you believe this market shift is solely a question of pricing, you’re probably working for the kind of organization that wants straight-line speed, because you’ve already stopped believing in the idea of creating software that users value.
Adopting AI For Speed Lacks Credibility
Software leaders have a track record, and that should be considered when they announce they are adopting AI for straight-line speed. Very often, you’ll find that over the past decade or two, they have announced an Agile Transformation for straight-line speed, adopted DevOps for straight-line speed, and started a platform initiative for straight-line speed.
The fact that they have burned through all these initiatives without achieving significant results is a strong indication that they don’t want speed as much as they claim. Sure, they want to slap a “DORA Elite Performance” badge on their work history. Still, they don’t have a genuine reason to go faster, because they aren’t interested in that fundamental outcome from shipping more often: feedback.
Any leader who has put their teams through the mangle this many times in the name of speed and who now says AI will be the thing that finally brings it is deluded.
The Feedback Metronome
When you want the feedback more than the speed, you’ll let the feedback loop set the pace of the whole software delivery process. Setting the pace to this beat gives you crucial space to process that feedback and do the one thing Agile wants you to do, which is change direction quickly.
Organizations and teams that use feedback as the metronome, setting the rhythm for the whole orchestra, are likely to seek out and eliminate work that disrupts the beat. They design teams to complete the work with minimal (and well-designed) dependencies. They streamline change approvals. They make sure the team can decide when to push the button to deploy their software and that they can observe what happens when they do.
The DORA model, with its generative culture, transformational leadership, lean product management, and continuous delivery process, wasn’t created by accident. This is the result of decades of work. Teams applying these concepts have speed, but that’s not why they adopt the culture and practices. They want frequent high-quality feedback so they can discover what really needs to be built.
This Is What Team Elite Did
Team Elite was a software team in a large healthcare company. The organization provided software for patient management and emergency triage. When it comes to safety-critical industries, this was software that really could mean life or death.
They shipped their patient management system once every six months, and the testing cycle for their decision support system was two weeks, plus another two weeks if they found a problem. Repeat until a version passes!
Despite this history, we managed to run a program of work for six months that created a deployable software version every three hours. We were following a set of very strong technical practices, but what we removed was likely more important than what we added. However, there’s a balance that came from adding specification by example with executable specifications and removing bureaucratic checking stages that were slower and less effective.
When it comes to outcomes, a crucial deal with a new healthcare provider required a decision management API to integrate into their website. We delivered a working API safely in two weeks and went live on a contract valued at $1.8 million ($2.5 million in today’s money).
If your organization hasn’t reviewed the route to production and made similar changes, nothing will deliver the speed you claim you want. You’ll introduce AI, just as you introduced Scrum, DevOps, and Platform Engineering, and it will make zero difference, just as before.
The most important thing you could do right now is map the flow of value, especially from code commit to production deployment, and start fixing the parts that are broken. There is no secret to what needs to change. Dave Farley and Jez Humble gave away the magic in their book “Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation”.
Why Are You Adopting AI?
Before today, you might have said you were adopting AI to speed things up. If you’re serious about software, I hope you’ll adjust your answer and make it clear to those around you that frequent feedback and decision agility are high on your list of priorities.
Teams that have already solved the throughput/stability trade-off through practices like Continuous Delivery will be less attracted to speed. They are more likely to seek more valuable opportunities. I wanted to close by suggesting a couple of these.
Small teams are better. We have compromised on this because we need things sooner than a very small team can manage. We might double the team size even though we know it won’t halve the time it takes. The COCOMO model had a complex calculation for this diminishing return, though Fred Brooks said it more memorably. Adding people to a late project makes it later.
As a result, most software teams that understand the complexity of communication and coordination fall into the 6-12 team-member range. The famous two-pizza team. But it’s not an ideal team size; it’s too large. It has simply been a pragmatic way to balance several factors. With AI, we should look at one-pizza teams, and even a smaller pizza.
Small teams with high autonomy working on a loosely coupled component could be the power move to unlock the value of AI-assisted software development.
My final suggestion is that, rather than building the same software faster, AI may let your teams build more ambitious software. You could tackle that globalization work you’ve always lacked the courage to start. You might have a feature idea that has always been impossible to get sufficient clarity on, where an AI prototype would allow an exploration you couldn’t attempt before.
In any case, start with a more aggressive improvement to your software delivery process and deployment pipelines. Make sure you’re joining up the feedback loop and that you use it like a metronome to set the rhythm. Once you’ve done these, you will seek something more imaginative than “speed” from your AI adoption.
The post AI won’t speed up software delivery — nothing has