The software development pattern / technique / methodology called Agile has very largely supplanted all others in a number of industries, ranging from auto manufacturers to web services.
Very little information is available by which to actually measure it's success objectively. This is primarily because one of Agile's characteristics is that it redefines the meaning of success, making it hard to compare like with like.
I'm well aware that this is a contentious statement. Many people will take delight in explaining to you how Agile has enabled them to create product faster and/or more reliably than they were able to using their previous method, or will point you to thick consultants reports that claim to show some benefit ( usually when assisted by said consultants ).
And yet, whether Agile constitutes an improvement on previous practice depends critically on several factors. It's necessary to compare functionally equivalent products that have been tested to the same standards in order to have any confidence in claims like this, and frequently that information is missing. Using Agile may actually change the nature of your product, the nature of the testing you do, and how you release your product to customers. You may consider your product to be 'better' - but it will be different.
Also frequently missing is cost information - if Agile did indeed deliver better product in time T, did it also cost more to do it, perhaps because you had to use more costly staff or invest more in tooling or training or support ? If senior management became more involved in decision making about Product, that's the type of hidden cost that may not feature in the budget. Overall, the array of variables involved is large and hard to control for.
There is a body of academic work on the topic, but as noted recently here,
"Although an increasing number of organizations are undergoing an Agile transformation, it has been poorly reported with sufficient academic rigor."
But one thing is clear, although it is rarely shouted as loudly as perhaps it should be - Agile claims to be a better way to make software, but it has never claimed to be a cheaper or easier way to make software.
That inference tends to be left as an exercise for the reader. So, very often the reader says 'hey, if projects always deliver working software, and don't overrun, it must be cheaper'. Well, I can't say that isn't true. I don't have the data. But I can't say it is true either. Perhaps Agile simply makes the actual cost clearer, sooner, although that would be a benefit in itself.
As for easier... well, no. Just no 🙂. It's never easy to get complicated things right, and Agile per se will not reduce the overall complexity of your product. It can, if you understand how and work at it diligently, give you a way of developing that complexity gradually and methodically whilst accommodating change and delivering what the customer actually wants, and this is how Agile works to de-risk development.
Parkour is a crazy sport / discipline / philosophy which involves athletic individuals running around some place as fast as they can, leaping over, round or through random obstacles that they may encounter ( I'm sure there are parkour people out there who can offer a more nuanced summary 🙂 ).
At first glance, it seems like a fantastic analogy for Agile. In fact, you could probably lift chunks of the definition offered in the link above and dump them in the Scrum Guide without materially affecting it.
But, I'm going to take a somewhat orthogonal position on this. The key to this position is as follows - Agile is not about doing software fast . Nowhere in the Agile Manifesto is speed of development ( whatever that means ) ever mentioned. Scrum does not refer to it either. But this is a can of worms that deserves a little more thought.
For this question, the most important thing to understand about Agile is that it does not prescribe ( or even describe ) any particular engineering practice. It's focused on how the creation of software is ordered and managed, and on the responsibilities of the various stakeholders, not on how code is written and tested.
So I think it should be clear - it is 'how code is written and tested' that determines how much 'done' code you are going to get in time T, i.e. it is your engineering practice ( and the skill level of your people ) that determines this, not the Agile/Scrum environment in which this work is done.
What Agile does do is it ensures that your code ( however much of it you may have created ) is always of sufficient quality, and is a good match for the requirements and the PO's priorities, whatever they may be at this point in time. The 'agility' of Agile is all about responsiveness to change and embracing change, not about cranking out the maximum possible number of story points in a Sprint ( see my thoughts here on the question of productivity and what it means ).
We can engage in a little thought experiment. Let's assume, for the sake of argument, that we have a project whose requirements, features and priorities are immutable - they will never change. The question is, will Scrum deliver those requirements and features faster ( i.e. in less actual time ) than the same team using a non Agile approach but the same engineering practice ?
Of course, backlog refinement will drop out of the picture, because all priorities are already decided. Less communication will be required with the business/PO. But standups, demos and retrospectives will still use developer time. It's possible that an advantage may come from retrospectives. It's possible that an advantage may come from the focus that sprints can provide. It's possible that an advantage may come from having a Scrum Master dealing with impediments ( although that may represent an extra cost ).
However, I believe it is certainly possible that in the absence of changing requirements and priorities, the benefit of Agile would be very small. It's the practical impossibility of avoiding such change in most circumstances that gives Agile it's reason to exist.
I firmly believe that anyone who has experienced Agile in a variety of different contexts and companies knows full well that it is more 'successful' in some circumstances than in others, and is rarely done in a way that delivers the proverbial whole enchilada. Well, it's certainly not easy. This blog entry is really dedicated to noting some of the ways in which a beautiful idea can be abused 🙂.
There's an endless amount of verbiage out there on this topic, to which I am contributing. Which is perhaps a fact worth contemplating in it's own right. What does it say about 'Agile' that so many people can find so much time to talk about how it can be done wrong or what it means to do it right ? Even governments are in on the act. I'll return to this question when I pontificate on Agile Culture.
If you're at all interested in reading further, I'm going to assume some basic knowledge of Agile. In particular, you should check out the Agile Manifesto as laid down by the founders of the methodology, and the Scrum guide.
However, please note that this blog has no aspirations to be didactic. You will, I hope, notice that my approach to Agile is fundamentally pragmatic, even as I indulge in philosophical debate to clarify the practical interpretation. And this is the essence of my occasional 'anti-Agilista' prods.
I have no problem with people who support Agile enthusiastically. I may even fit in that category myself. I do have a problem with people who support Agile uncritically, and attempt to use the Agile spanner to hammer in nails - not all the problems that organisations have with software creation can be addressed by Agile, and it's important to understand the particulars of every situation.
Should you happen to trip across an observation or idea that illuminates some problem or experience that you have, fantastic, and I disclaim all responsibility for the consequences 🙂 .
© Mark de Roussier 2021, all rights reserved.