Why Agile might be the biggest blocker to your engineering velocity
When Agile was created, way back when in the year 2000, it represented a revolutionary approach to software development that boosted engineering velocity by giving engineers the autonomy they needed.
But now, with headlines from HBR and Forbes like Have we taken Agile too far? and The End of Agile, it seems fair to say that the Agile revolution has run its course.
If your engineering & product teams are struggling to hit deadlines or if your teams’ backlog feels like an endless list, our experience is that the biggest inhibitor to your engineering velocity might be Agile.
Let’s take a look at how Agile might be slowing you down, why using an industry standard for best practices can be a bad thing, and what you can do to create your own velocity-boosting best practices.
Agile: An Origin Story
Agile was created by software developers, for software developers. It was also created in direct reaction to their frustrations with the pitfalls of Agile’s decades-old predecessor, Waterfall.
Basically, these folks felt Waterfall overly rigid & complicated. Too focused on documentation requirements and too often resulting in products that didn’t respond to change.
Moreover, these pitfalls forced engineers to sweat the details, which made the process of software development a slog and pivoting to handle change a downright PITA.
Agile’s original spirit emphasised individuals & interactions over processes and tools. The idea was, by giving some autonomy back to engineers, they’d be more nimble and able to operate more efficiently.
That spirit of autonomy & flexibility revolutionised software development in a big way. Software development teams all over the world said “buh-bye” to Waterfall and embraced Agile as their new best practice gospel.
The problem with industry standards
Agile’s widespread adoption ultimately mired it in the same pitfalls of Waterfall.
Yes, you’re reading that right: twenty-plus years on, Agile has become the very thing it was intended to replace.
Once Agile superceded Waterfall as the new industry standard, its original spirit of autonomy & flexibility was crushed. Industry leaders treated the word of Agile as gospel, interpreting it so literally that it morphed into a strict set of processes and tools:
“I can’t take this Agile crap any longer,” reads one developer messageboard rant, “It’s lunacy. It has all the hall marks of a religion. A lot of literature, a lot of disciples… and no evidence at all that it works. In fact, as far as I can see, there’s more evidence that it doesn’t work. “
The problem with industry standards is that they’re followed too rigidly. Adhering too closely to a one-size-fits-all set of best practices inevitably slows your team down.
Case Study: Large financial organisation
Let’s take a closer look at how adhering to a rigid set of best practices like Agile impedes engineering velocity.
One of our clients, a large financial organisation, had an engineering team with the unenviable task of managing a highly complicated product that produced price estimates of real estate.
As complicated as this product was, the client’s team of 50 very capable engineers should have been capable of handling it. But, somehow, they were all drowning in endless backlog.
DEPT® dove in to assess the situation. What we found was a team that was mired in an approach to development that didn’t work for them, Agile.
Due to the nature of their product, the client’s engineering team had grown very quickly. The rapid-fire scaling combined with Agile’s emphasis on interaction and iterating in short bursts worked against them:
Every engineer spent most of their day in meetings that were about organisation and bigger picture stuff. With so much of their days booked up, no one was able to get work done.
To solve this problem, we advocated going against traditional Agile dogma and worked with the client to create a new approach to development.
After interviewing every member of the client’s team, we created a set of best practices inspired by the original spirit of Agile but fundamentally different, designed to delegate tasks and mitigate meetings.
Most importantly, the new approach was tailor-made for the client’s team, honed with careful testing to ensure it actually worked.
Creating your own velocity-boosting best practices
Every engineering team is different and has their own unique set of needs when it comes to how they work.
These needs fluctuate over based on size, experience, and the nature of the project that’s being worked on. They even fluctuate over the course of a single project as the team adapts to new challenges.
Within a system that’s constantly in flux, best practices that are too dogmatically imposed become rigid and lose their efficacy. Helping your team find and define their own best practices is the only way to go.
Rather than hire an Agile consultant, start by asking the engineers what’s working and what needs to be improved.