Is Agile Dead?
Towards the end of 2024, the boss sent an email to all the consultants on the team asking “Is Agile Dead?”
| Ivar |
| Team, |
|
To quote Scott Ambler: “Agile isn’t dead, but the agile gold rush is, and it isn’t coming back.” Scott’s article is well worth reading, if you haven’t already done so: https://www.linkedin.com/pulse/agile-community-shat-bed-scott-ambler-1npwc/ |
|
Another article by Jürgen Apello: “Let’s celebrate twenty-five years of Agile and ten years of “Agile Is Dead” articles. Now, I won’t be one of those heroes trying to keep the brand alive. It’s time to move on.” https://www.linkedin.com/pulse/agile-undead-synthesis-jurgen-appelo-54wne/ |
| Please, let us know your thoughts. Is it time for us to move on, and in that case, what should we do? |
“Agile is Dead” headlines are largely LinkedIn content writers seeking clickbait for their own articles, but people are after all reading them, so there is definitely disquiet with the branded one-size-fits-all promises that did not really solve the client delivery issues. There are organisations that are laying off ScrumMasters and Agile Coaches, Is Agile Dead?
Of course, Agile, or some form of it, is not really dead, it is still very widely used but the gold-rush for “paint by numbers” transformations with inexperienced staff is over. I would go further and say that customers have “soured” to single approach selling as solutions to their problems.
Rather than add more click-bait to the situation, what I felt it needed was some sensible, reasoned thinking that gets beyond the observable symptoms and starts to ask “why?”
This series of posts covers:
- What Is Agility?
- What Has Changed?
- We Just Don’t See The Value
- Won’t AI Save Us?
- What Is The Problem?
Previously we explored What Is Agility? and came to the conclusion that because Agility is a concept Agility cannot die. Agility has not changed, it is what it always was: nimbleness, readiness to move, quickness; so what has changed?
Not Your Father’s Agility
What has changed?
The rules and social formations that you have grown up with might not be the rules and social formations that are in play now, or in the future.
The Industry Is Changing
Many, many1, years ago I worked in the entertainment industry, writing the software for theatres and rock-concerts that control the automated moving light fixtures. When I first started there were lots of little businesses, each with just a handful of employees, creating all the different equipment used by the entertainment industry. Over time there was a gradual accretion; smaller business merging with each other for safety, stability, and protection; larger businesses buying up smaller ones to gain market share. Now, in the present day, unless the company is in a specific niche, most companies are either part of, or owned by, larger conglomerates.
This is not unusual, a Cambrian explosion of new life emerges when a new opportunity opens up. Then over time, the strongest survive by consuming or outcompeting the others. It is a pattern that has been seen time and again. The first viable automated moving lighting fixture2 was created in 1980, 20 years later the accretion and consolidation of the industry was well underway and had mostly settled within the next 10 years.
The Customers Are Changing
In the early days customers are more experimental, willing to try things, to see if they work. As the market matures the expectation is that those things just work. Geoffery Moore describes this in his book Crossing the Chasm about the evolution of technology adoption from Innovators, through Early Adopters, to Early and Late Adopters.
Figure 1: Geoffery Moore’s Technology Adoption Curve
Twenty years ago, shortly after the signing of the Agile Manifesto, those adopting Agility were Innovators. They turned to whoever could help them, often small independent consultants. The scale of the problem was also small, often individual teams of no more than 10-20 people and the leadership was all part of adoption of Agility.
The industry is not where it was twenty years ago, the Innovators and Early Adopters are long gone, the problem now is the Majority in the Mainstream Market. They are not willing to experiment. They do not want to deal with small independent consultants, the volume of people whose behaviours need to be changed is more than a lone consultant can deal with. The majority is not tolerant of failure, it has existing businesses to defend. The leadership just want it to work and, for better or for worse, they would rather not be involved3.
The Consultant Are Changing
I was not there at the beginning of Agile, I’m not a signatory on the Agile Manifesto for Software Development. As it was being signed in February 2001 in Snowbird, Utah, I was sat at a desk in West Ealing, London, writing control software for theatres and rock-concerts. I was part of an Agile team, in the sense that it was nimble, ready to move, quick, but we weren’t following any formal Agile Methods4, we did what small, empowered teams do, we worked out a process for ourselves, Innovators by default.
I was there at the beginning of scaling Agility5. Trying to work out how to get the benefits of Agility when the number of people involved are more than the single Agile team that the original methodologies suggest6. In the beginning we did not know how it would work, even whether it would work, we had to invent it. Through choice, necessity even, we were Innovators, at the beginning of Geoffrey Moore’s technology adoption.
We spread our knowledge to the Early Adopters. Many of them still had the same innovative mentality because they had to work out how it should be applied in their context. Any good customisations or insight worked their way back into the advice.
Fifteen years later, the consultants that were the Innovators and Early Adopters are still out there, but they have been joined by an army of Early or Late Majority consultants. This has shifted the landscape, the question I hear most often is not the “How are we going to make this work?” of the Innovators, but the “Tell us what to do.” of the Majority.
The Market Got What the Market Asked For
The market asked for a silver bullet, not realising that whilst silver bullets are great for killing monsters in horror fiction, they are pretty useless in real life7.
Commoditisation was inevitable, it is what the market wanted. The big management consultancies muscle in, driving out the independent consultants who might have been hoping for a piece of the majorities’ money. The companies in the mainstream majority are often large companies, they don’t want to deal with individual independent consultants, they want to deal with a single consultancy that can provide all of the consultants under one contract. Many independent consultants are consolidating, a necessary step to be able to compete against the big management consultants. The accretion and consolidation happening now is happening 20 to 30 years after the publishing of the manifesto made the idea visible to everyone and started the clock. The timings will always vary slightly, but it is a pattern that has happened repeatedly, it’s the same pattern I saw when working in the Entertainment Industry.
Why do we have Frameworks / Methods?
Could a company that has decades of experience at Formal Project Management pick up the Agile Manifesto and develop their own Agile ways-of-working?
Maybe.
After all, some of the original Agile signatories evolved out of a formal Project Management background, so it is possible, but I suspect these Road To Damascus moments8 are few and far between. Think of how many Project Managers there were in the world at the point when the Agile Software Manifesto was signed, and how many of those actually converged to sign the manifesto? Maybe 1 in 100,0009?
Frameworks should act as a starting point, so that the change happens quicker, with less disruption and less risk.
Figure 2: How Frameworks influence the Satir Change Curve
Adopting Agility is a change to the organisation, it will have an impact on the performance of the organisation. This impact changes over time, initially there will be a performance drop as the organisation has to devote effort to learning about the change and how to enact it. As the change becomes embedded in the organisation performance increases, hopefully to a point where it is better than it was before, otherwise there would not be any point making the change in the first place.
What frameworks and methodologies seek to do is to minimise the initial performance drop by giving you insight and instructions into what to do so that you can get through the learning and adoption stage of the change quicker, and they should provide insight into what good looks like so that organisations can maximise the performance gain. Good is rarely a process to follow, but a state to be atained; how it’s atained is through customising the starting point to allow the organisation to reach the desired state.
Blindly adopting a process can cause great disruption for minimal, or negative, improvement. That’s the scenario that Scott Ambler is railing against…
Why are they failing?
The frameworks aren’t failing, people’s implementations are failing.
Figure 3: Satir Change Curve for a failed implementation
Why are their implementations failing? Because they are being implemented badly. Bad implementations arise because the Framework hasn’t been properly tailored to suit the needs of the business that is adopting Agility. All the processes and frameworks that I have analysed state that they need to be tailored to suit the needs of the business adopting them, so why aren’t the adopters tailoring the frameworks?.
| In the blue corner, at one end of the spectrum, we have Jeff Sutherland’s Scrum@Scale it provides just enough process to manage an organisation top-to-bottom in an Agile fashion, but everything else around it is left for the adopter to work out themselves. Work breakdown, delivery pipelines, customer and stakeholder engagement, budgeting, and finance, it’s all up to you! You do not have to invent it, insight into all these things already exists, but you do have to do the work of piecing it together and ensuring that the parts all fit. The problem is that if organisations don’t know where to look, or don’t have the experience about how things should work and what good looks like, then this can lead to them adopting ways-of-working that aren’t as aligned with Agility as they could be, so ultimately they don’t see the full benefits of Agility. |
| In the red corner, at the other end of the spectrum, we have Dean Leffingwell’s Scaled Agile Framework (SAFe®) it provides a structure to manage an organisation in an Agile fashion, that isn’t dissimilar to Scrum@Scale, and it also provides a full set of processes that are aligned with Agile ways of working that organisations can adopt as a starting point so that they don’t have to work everything out for themselves. Processes that cover work breakdown, delivery pipelines, customer engagement, budgeting and finance, there’s advice for everything. Blindly following the framework does not necessarily engender the behaviour of Inspect & Adapt, even when the framework says you should Inspect & Adapt. The problem is that if organisations adopt the suggested starting points without customising them to suit their needs, then they won’t get the best results, ultimately, they don’t see the full benefits of Agility. |
Ding, ding; Round 1…
No!
That it is a fight between methodologies is a falacy and a distraction to actually helping organisations adopt agility.
It is not that one framework is better than the other, each framework has its own benefits and challenges. The other scaling frameworks10 sit somewhere in between; I picked Scrum@Scale and SAFe because they illustrate the two extremes. Most of the Agile scaling methodologies utilise Scrum-on-Scrum recursively, they have more in common than they do different, it’s just that the methodologists (or more accurately their advocates), highlight the differences to make their methodology stand out. If you look at them carefully then it becomes obvious that the insight from one methodology can be applied in another; you need look carefully at what the methodologist was optimising their methodology for. Jeff Sutherland was optimising for speed of response11, could you apply that advice in a SAFe context? Sure, just line up the daily standups to get impediments from team to exec in under an hour. Nexus is optimising for flatness of Product Hierarchy, could you adopt a flatter hierarchy in SAFe? Sure, do it, it’s actually a good thing! SAFe is optimised for getting large groups of people collaborating together12 through it’s PI Planning events; could you adopt PI Planning in Scrum@Scale or Nexus? Yes, if it would be beneficial to you.
Innovators and Early-Adopters are more likely to want the complete freedom of choice that Scrum@Scale provides because they have the experimental mindset that will allow them to find or evolve their own processes.
The Mainstream Majority is more likely to want the reassurance that there is a set of processes that they can get started with, that are aligned with the Agile ways of working, and will help them to get started on their Agile journey. They lack the ability to sensibly evolve their own processes13 . Exactly what SAFe provides.
Both need customisation, do you prefer to start customising from a blank sheet or from a known “good” point. As an individual you might have a natural inclination towards one end of the spectrum, or the other, but ultimately it’s not about what you want it’s about what is going to be the best approach for the organisation that is transforming to Agility. You will probably have a greater chance of success if you can show how your preferred framework’s highlights can be fitted into the context of the other frameworks, rather than trying to smite them down as the work of some evil devil.
Caveat Emptor
Buyer beware.
What do you want from the transformation?
Do you understand what is involved? As you start to move towards an agile way-of-working, is the organisation ready and willing to accept the changes that will need to be made to adopt agility properly?
Getting agile teams, or teams of agile teams up and running is just the beginning; to allow them to run effectively the processes in the wider organisation are going to need to evolve. Agility will always fail if the rest of the organisation doesn’t want to allow agility to flourish and isn’t willing to support it. The wider organisation needs to understand the impact of adopting agile ways of working and be prepared to change how they work.
Do you have the skills to steer your customisation of your way-of-working? Do your chosen transformation partners have the skills to help you customise your way-of-working to your needs?
Implementations fail when the customisations either aren’t made; or are applied indiscriminately without thought as to whether their appropriate. Different areas of an organisation have different needs; they’re likely to need different customisations.
No consultant is ever going to admit that they can’t help you; that would mean losing the contract. What do you need to ask them to understand whether they really know what they’re talking about? Does their proposed way of tailoring the way-of-working fit with your expectations? Can they demonstrate knowledge of your industry and how the proposed way-of-working could be tailored to your scenario.
Your expectations for Agility should be tempered by your organisation’s own willingness and ability to change
Next
The nature of the industry is changing as it moves through the Technology Adoption curve; in the next post we’ll explore the problems arising as the nature of the customers and their expectations change and We Just Don’t See The Value.
|
#1 Possibly even “lots”, https://discworld.fandom.com/wiki/Troll#Literacy_and_Numeracy. [Return]
#2 The Vari-Lite® was productised after the rock band Genesis put down $1millon in investment. [Return]
#3 Leadership involvement, or lack thereof, is a common failure pattern. It’s a distinct topic in it’s own right. [Return]
#4 I did read The Scrum Guide at the time, but the silly words used made it impenetrable. Sprints, Scrums, what does it all mean? With hindsight, and someone explaining the silly words, I now realise that we were a Scrum team doing 1 week sprints, with a planning meeting around the coffee machine on Monday mornings and daily standups happening in the pub at lunchtimes. [Return]
#5 As a junior line-manager at Nokia I got involved in Agile coaching just as the Agile coaches there had been looking at an interesting picture in the front of a book on Agile Software Requirements by Dean Leffingwell; let’s make that happen they said. I wasn’t at The First PI Planning, that honour goes to Nick or Keith, but I have been teaching Scaled Agile since before Scaled Agile existed. Nobody can quite remember what happened when because we were busy doing it rather than recording it for posterity, and it was happening globally in a fairly decentralised fashion so London didn’t have full visiblity of the detail of what Helsinki, Bangalore or Beijing were doing. [Return]
#6 Smaller will always be easier to manage, the first Rule of my, completely unofficial, Rules for Scaling is Don’t! But, sometimes things are big enough that 10 people isn’t going to be enough to get the work done. [Return]
#7 Working for many businesses might feel like you’re living in a horror movie. Unfortunately the real horror is that you aren’t in a movie, that the horror your experiencing is fact reality, and that silver bullets don’t work in the real world. It’s a people problem, and the fix for people problems is never bullets, it’s to start talking to the people about the problem and persuade them to change. [Return]
#8 The Conversion of Paul the Apostle to Christianity on the road to Damascus. [Return]
#9 I have no evidence to back these numbers up but the numbers don’t need to be precise to illustrate that the chances of an organisation having someone that can evolve Agility out of historic methods is very slim. [Return]
#10 Nexus, LeSS, there may be others I’ve not heard of and I’m happy to add them if they warrant inclusion. [Return]
#11 Jeff Sutherland had been studying the data held in the Standish Groups Chaos Report and perceived a strong correlation between speed of response and success of endeavour; hence optimising his framework for speed of response. [Return]
#12 Dean Leffingwell spotted that there was very little advice on how to get large groups of people to work together in an Agile fashion and a massive target market of big organisations that had large groups of people that needed to work together so he targetted their needs and started providing advice. [Return]
#13” They may still suffer from a “not invented here” mentality; which becomes even more problematic when the organisation doesn’t have the institutionaly knowledge to invent the processes that it’s trying to evolve towards. [Return]
|
Without wanting to fan the flames of more click-bait, I hope the above has provided more insight into: Is Agile Dead?