Why some agile projects fail and others succeed
The Great Promise of Agile Productivity
There are many reasons to adopt agile, but the list must start with increased productivity. Businesses exist to make money and agile proponents are quick to cite large increases in productivity when adopting agile. For example, Jeff Sutherland talks about “hyperproductivity” with agile leading to increasing productivity by 800%.
This is an actual image of a business executive that has been promised a 800% increase in productivity:
Does Agile Fail to Deliver?
Yet many, many teams fail to come anywhere close to increasing their productivity by 800%. Even signers of the Agile Manifesto have called agile failed or dead. Those same business leaders who were promised that giant productivity increase now fail to see it.
In my experience coaching teams, I have seen teams struggle with agile. They change how they are working, but sometimes the results don’t come immediately. The executives that were once excited about the promises of agile start to doubt when the results are not coming in.
Often agile will focus on the execution of the agile process itself. Maybe the team is not embracing agile values. Maybe the team is not engaged or is resistant to agile.
But is there something wrong with agile or is there something else going on?
The Hidden Ingredient is the Ability to Release Frequently to Production
Successful agile teams can release software frequently to production. The greater your ability to do this, the more your capacity to delight your customer and deliver value.
Don’t put your software on layaway – Release at least weekly
If you can only release software once a month, you are putting your software on a layaway plan. (Layway plans were purchasing plans where the store kept your item until you paid it off.)
There’s a reason layaway plans don’t exist anymore. Customers want their stuff now. The same goes for software customers. Your customer wants the value now, not in a few months
What industry leaders say
Even if you don’t agree with me, let’s look at what the creators of Scrum and Kanban say.
Jeff Sutherland says,
Any Scrum without working product at the end of a sprint is a failed Scrum. 80% of the scaled Scrum in Silicon Valley is in this category. They are ‘Agile in Name Only.’
If you prefer kanban to scrum, David Anderson also believes in frequent delivery
Dan [Vacanti] suggests that frequent increment releases to production are key. And yes they are! . . . The notion that you reduce (or limit) work-in-process appears at number 2 in my list. You can’t achieve this without being capable of making frequent incremental releases to production.
If both the creators of Scrum and Kanban believe in releases to production, it seems reasonable to call frequent a best practice.
Hidden Ingredient or Just Plain Hard?
The reason frequent delivery is a hidden ingredient is that it is hard. Most teams I have worked with struggle to release working software every sprint. It’s far easier to focus on agile practices without solving the technical and organizational challenges to enable production releases.
What makes it worse is that often process experts assume that you have good software developers and operations people. There’s an underlying belief that if the process is fixed, then the development team will be able to speed up delivery. I have found that assumption to be wrong.
What happens in these situations is that agile process is labeled as a failure while the root cause was actually poor technical execution. Standups and cards will not fix poor coding practices.
That’s why I believe the DevOps movement is important. It’s about developing the ability to release quality software quickly to production. Whether or not you use kanban or Scrum, having this ability is key to becoming productive and delivering high value to your customers. Without this ability, your teams will be destined for mediocre results.