Matthew (Ford) Kern and Miko have both recently written posts on the topic “Agile is Dead”. Matthew relates this to the saturation of agile consulting and the speed of hype cycles. Miko links it to a need to go faster than the approaches embodied in the agile movement and replace agile with DevOps.
Matthew’s first article is simply titled “Agile is Dead” He deliberately takes a controversial (and sarcastic) stance, saying that
Agile Software Development work is dead. If you practice that, you are a doorstop. If you manage that way, you are a boat-anchor. The wave has ended, it is over, and if you went for the head-fake and bought certifications, you wasted some money.
He goes on to explain the “death” in terms of the hype cycle of marketing and management fads and feels that
The meaning (of the brand name "Agile) was lost, the technical merit was diluted, and those looking for technical excellence abandoned the effort, and if not for the efforts of “true believers" it might be history already.
He states that the demise was inevitable and gives a lengthy list of reasons why this is the case, including:
- Agile had a sweet-spot, and a range of inapplicability, but everyone wanted to ignore that.
- I knew it was being hype-marketed, and the facts were secondary.
- There was a sacred mythology, strange terminology, special sacred tools and other weird cult behavior. (For example many Agile practitioners are bullies, and want to browbeat you into agreeing with them. They will attack you or undermine your credibility when you disagree. I was just threatened yesterday 4/28 by one young acolyte.)
- I saw everyone hammering it to fit with much more important corporate controls. Clearly we had suboptimization with development thinking they were the most important part of the ecosystem. In most enterprises they are a minor support function, not the core business, and should be accommodating more important business functions.
He continues to identify elements which he feels can be saved, including iterations, teams, some of the social practices, many of the technical practices.
He concludes with his ideas for what will replace agile in the marketplace, the DevOps wave:
So next comes the DevOps wave. It is the "heir apparent". If you buy software development services at a medium or large scale then someone will be in your office selling you DevOps this year. (When they do, they will say it is better than mere Agile. You have to buy it.) There is still a chance to fix this one:
- We could take a wider focus than last time on enterprise considerations.
- We could integrate corporate controls.
- We could recognize the real reason enterprise software exists, where most of this custom coding happens, and focus on code relevance.
- BiModal IT could fix some of it, if any of these analysts could grasp the full lifecycle and where each method fits for but a moment.
- We could lose the "full stack developer" mythology.
There are also various modified forms of Agile resulting from practical experience and improvement. Maybe someone will make a real marketing effort with one of those.
Miko identifies Continuous Delivery as the successor to agile in the market.
The paradigm of “Continuous Delivery (CD)” seems to be the logical successor to Agile. Continuous Delivery provides an umbrella term that does not specify methodology–and doesn’t require much of a manifesto. Everything you need to know is in the title–you just deliver shippable software in as continuous of a way as possible. This allows a team to pull whichever Agile principles and methods needed in order to achieve that goal. This addresses one of the complaints of Agile, which is that it became a religious movement with gurus–and that these highly paid Agile gurus would come with one-size-fits-all solutions for development teams which were hard to realistically fit to real-world development.
He maintains that we are now squarely in the age of DevOps.
Matthew has a second article which goes deeper into his reasoning and provides statistics and explores the marketplace for DevOps and Agile by looking at job opportunities and salaries.
He concludes
Job data and salaries data show Agile may be at or near market saturation in the IT services sector. DevOps market penetration is expected to increase rapidly in 2016. Decline in Agile services may occur due to the ascendance of DevOps related services. If the next wave is DevOps as assumed, the market currently requires one dominant methodology and tool experience, not ideology.
The demise of agile as an approach and its replacement with something new has been a subject of InfoQ interviews and articles over the last few years. In 2014 Dave Thomas encouraged readers to adopt agility over agile and in 2015 he gave a talk titled “Agile is Dead”. In 2012 Alex Bell identified “Agile Fever” as a deadly risk to organisations.
Community comments
Agile coding
by Roland Heimdahl,
Re: Agile coding
by David Dawson,
team, trust and communication matters
by joyous javadev,
Dev ops is dead, long live (insert buzzword here)
by Florian Sommer,
Re: Dev ops is dead, long live (insert buzzword here)
by Rusi Popov,
Reports are greatly exaggerated
by Andrew Webster,
Agile is overvalued
by Roger Itai,
Re: Agile is overvalued
by Roland Heimdahl,
Agile is not dead but abused, misused and mangled
by Brian Tan,
Agile coding
by Roland Heimdahl,
Your message is awaiting moderation. Thank you for participating in the discussion.
It is great that we finally are leaving the project focus for agile to actully start do develop in an agile way. Most of the agile so far has been about project management, but we still code in monolith, n-layer anti-agile architectures. But does that mean that agile is dead, or expanding?
Re: Agile coding
by David Dawson,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hopefully dead, but the momentum is there that it won't be.
XP had all the good bits of agile, improving the doing of software
The belief portions are, and always were, delusional fluff.
Not all of us code in n-layer systems. Microservices has been around for a while, event systems and streaming data have been around just as long. They give a tremendous flexibility to improve or wreck your app as you see fit.
team, trust and communication matters
by joyous javadev,
Your message is awaiting moderation. Thank you for participating in the discussion.
Building software product has a lot to do with the team and individual resources building it, the trust and communication efforts they put into. More importantly, the methodology used, either Waterfall, Agile, or mix of both; it needs to be evaluated regularly by the team and adjusted to meet the needs of the specific team and the product. Continuous delivery, Build and Deployment Automation are key principles of any successful software engineering project along with continuous process improvement which involves listening to all team members and implementing their ideas and trusting each other to play their role.
Dev ops is dead, long live (insert buzzword here)
by Florian Sommer,
Your message is awaiting moderation. Thank you for participating in the discussion.
How to manage modern IT:
1. Find the newest hype approach towards software development
2. Implement cargo cult
3. Complain that the approach did not work and claim it dead,
then back to step 1 with the newest hype that basically is exactly the same as the one u just claimed dead just that it emerged in a different context so it uses different terminology for the same ideas... don't worry, nobody will recognize because nearly everyone was only implementing cargo cult in step 2...
I agree 100% with the arguments about those bullies and cult behavior and bad marketing, it's just that I would never call those things aligned to an agile mindset. So maybe the term "agile" has a bad name and should die, but not the fundamental, simple idea that emergent strategy is necessary in complex environments and that selforganizing, cross-functional teams are better for this than the bureaucratic processes imposed in some big companies...
Re: Dev ops is dead, long live (insert buzzword here)
by Rusi Popov,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree with you, but I would object the "bureaucratic processes" reference used. How does the self-organizing team learn? It learns by cutting off non necessary practices and procedures and establishing new ones. Establishing a process. The process is a form of learning in the organization. Thus, if the process is a result of the practical needs and experience of the team and the organization, then it must not be referred as the ultimate evil. Treat the individuals, teams and organizations equally and allow them to learn their own way.
Reports are greatly exaggerated
by Andrew Webster,
Your message is awaiting moderation. Thank you for participating in the discussion.
While I wholly agree that "Agile" as a term has been bent way out of shape, Agile as a way of thinking is more necessary than ever.
I've been around more than one "Agile Transformation" at scale, and seen it turn into a bunch of poorly applied practices, attempts to impose structure and methodology, and apparently only applied to engineering. Mostly because it's seen as "something to make the teams more productive" or "we'll get to market quicker". *facepalm*
Which leads to a bunch of people with transformation PTSD justifiably complaining that "Agile doesn't work".
And yet, that is totally missing the point. It's not a case of Agile working or not - Agile is about what works.
Is every organization on the planet doing great work, that their customers deeply appreciate, that their workers are deeply fulfilled by, and that causes no further problems in the world, leaving only a trail of benefit to all?
Nope.
So Agile still is massively relevant, and wow, is there still a long way to go with it.
"We are uncovering better ways of [working] by doing it, and helping other do it". That work is far from finished.
Enough with the "Agile is dead" already.
Agile is overvalued
by Roger Itai,
Your message is awaiting moderation. Thank you for participating in the discussion.
… And, unfortunately, I think the time has proven me right. The word
“agile” has been subverted to the point where it is effectively meaningless,
and what passes for an agile community seems to be largely an arena for
consultants and vendors to hawk services and products.
So I think it is time to retire the word “Agile.”
…We’ve lost the word agile. Let’s try to hang on to agility. Let’s keep it
meaningful, and let’s protect it from those who would take the soul of our
ideas in order to sell it back to us.
—Dave Thomas, Agile Manifesto Signatory,
Re: Agile is overvalued
by Roland Heimdahl,
Your message is awaiting moderation. Thank you for participating in the discussion.
In Sweden the flag as a national symbol to be proud over, was kidnapped by neo-natzi. It was got so bad that you bascially was considerd a racist if you had a flag. Now we have reconqered the meaning of the flag. Maybe giving up on our symbols isn't the best way to stop badness.
Agile is not dead but abused, misused and mangled
by Brian Tan,
Your message is awaiting moderation. Thank you for participating in the discussion.
I have been developing software for more than 10 years.
Been in successful software teams (agile and not) and unsuccessful ones (agile and not). Had good projects, bad projects and some just plain ugly.
My personal opinion and experience, Agile is great for good competent teams that know what they need to do.
But I've seen and participated in failed Agile-based software projects before and in general, I can categorize the reasons for the failures into 3:
Abused:
Agile often is abused to just bully teams into death marches. Undisciplined management that changes requirements at their whims and fancy often use Agile as an excuse to force the impossible. Their common mantra "The project is an Agile project and therefore you must be agile enough to accommodate the changes at the same deadline."
Misused:
Agile can't miraculously save a software that's doomed from the very beginning.
Grossly insufficient time / resources, unrealistic expectations, ridiculous requirements etc. can't be magically fixed by employing any so-called good practices / processes. A spade is a spade, simply slapping an Agile logo on it doesn't increase the chance for success.
Neither can it compensate for bad or incompetent team members or management.
In crux, people can fix Agile, Agile cannot fix people only people can.
Mangled:
Far too often have I heard, we adopt certain Agile practices but we don't do the others. Or the other extreme, we adopt all Agile practices but we had to modify some of them.
The problem doesn't arise from selective adoption of practices or modifications of the practices but from not having a proper understanding of the fundamentals before selection or modifications. Too few experts, too many brainwashed evangelists.
I've seen both sides of the coin, Agile can and do work but only with the right people with the right mentality.