It’s trendy to say “Agile doesn’t make you faster” with the implication that it’s wrong for a leader to even care about “faster.” You see it all over LinkedIn, for example.
Here’s the problem: Going faster can translate directly into business outcomes.
Getting releases out the door sooner increases the chance of a positive return on investment. Reducing your cycle time from idea to production lets you be more responsive to customers. Spending less time on each thing saves development costs.
These are good things for a leader to want. And we’ve actually seen how adopting an Agile way of working can make you faster.
But it depends on what you mean by “Agile” and by “faster.” Let’s dig into that so you can get the outcomes you’re looking for.
What do you mean by faster?
If faster means a shorter cycle time per feature—less elapsed time from idea to ROI—that’s a reasonable thing to expect from an Agile way of working. Agile aside, we know that if you really want to get something critical done, you pull together a cross-functional team and let them focus on delivering what really matters (the “tiger team” in a “war room”). An Agile approach done well turns that from a move you make during a crisis to an ongoing, sustainable system.
Similarly, if faster means more value per unit of time and cost, that’s a reasonable thing to expect from an Agile way of working. One of the most common benefits we see from focusing work on small slices of customer value and prioritizing the most valuable things first is that teams stop building features no one will actually use. Their effort goes into what matters most. As a result, the flow of value through the team increases. Which is to say, you get the same value faster.
If by faster, you mean more output per person in less time, well, an Agile approach may or may not create that outcome. It depends what slows people down in your system and whether your Agile approach addresses that waste. Quite often, an Agile way of working makes the waste more visible but doesn’t automatically make it go away.
For example, one client we worked with had lengthy debates in the comments of every pull request that developers submitted. Some of the feedback was valuable. Some of the feedback was endless debates about coding styles and personal preferences. Shifting to an Agile approach made this more visible because it became more clear that things weren’t getting done. But it was up to leaders in the organization to find less wasteful ways to achieve the benefits of these pull request discussions. Once they did, productivity per developer naturally went up.
Another common example of Agile making issues visible: Trying to build cross-functional teams who collaborate on increments of value in short timeboxes often makes it visible that an organization has too many initiatives in progress. Agile won’t *make* that organization reduce their work-in-progress. It may, however, reveal the issue and suggest opportunities for improvement.
What do you mean by Agile?
So we see that Agile software development can make software teams faster—for certain definitions of faster. Implied in that, though, is a certain definition of Agile.
If by Agile, you mean having the Scrum meetings and putting work items in Jira, but still having lots of dependencies between teams and work organized around components and tasks, that’s not going to make anything faster. In fact, it might actually slow things down. All those meetings, all that dependency management, all that Jira wrangling…it adds up.
On the other hand, if Agile means truly cross functional teams and well-crafted backlogs that get teams focused on small increments of customer value? That’s a recipe for increased value and shorter cycle times.
Add on solid engineering practices to continuously build quality into your work, and you’ll see things not just get faster, but get faster in a sustainable way.
Reset Around What Matters
We’re seeing more and more teams who are doing things that are broadly recognizable as “Agile,” but they’re not seeing the results they want. Maybe they once had a high-performing team. Maybe they’ve never really experienced high engagement and flow.
Whatever the issue may be, there are good business reasons for delivering value faster and more sustainably.
These teams don’t need basic Agile training. They don’t need to throw away Agile and come up with some hot, new way of working. Nor do they need to be told they’re not doing it right.
They need to reset around what matters. What does success look like in their context? What constraints are getting in the way of achieving that success? And what experiments will move them towards overcoming those constraints and seeing the results they want?
In our Humanizing Work Team Reboot, we help a team or group of teams go from struggling to thriving in a matter of weeks. Contact us to learn more.
Last updated