“I’ve spoken of the shining city all my political life, … in my mind it was a tall, proud city built on rocks stronger than oceans, wind-swept, God-blessed, and teeming with people of all kinds living in harmony and peace; a city with free ports that hummed with commerce and creativity. And if there had to be city walls, the walls had doors and the doors were open to anyone with the will and the heart to get here. That’s how I saw it, and see it still” President Ronald Reagan, Farewell to the Nation, January 11, 1989
Back in 2001 when the word agile appeared it was a manifesto – a set of ideas, the term “agile” also served to group a bunch of tools and techniques which could make software development “better.” More importantly to my mind, it painted a picture of a shining city on a hill we all wanted to live in.
Agile was a place you wanted to go, it was a journey you wanted to make, it offered hope. More important as the tools – sprints, stand-ups, etc. – and approaches – just in time, last responsible moment, test first – were the stories agile people – including myself – told. These were stories of a better world, of that shining city on the hill.
And not unimportantly, in a world of search engines “agile” gave you something to search for. Before agile you could search “make my software development team better” or “software development process improvement” but what you got was a very mixed offering. AltaVista (and the young Google) would suggest links for CMMI, or ISO-9000, or vendor tools to “fix it”, or proper design, or… there was no coherent message. Most of these ideas resolved around senior people making big decisions and then imposing them.
Then along came agile: it offered to involve everyone, everyone made decisions, everyone was happy and we could all go to that shining city on a hill – more than that, we all had an important part to play in building that city.
Today everyone is agile. Nobody is promoting traditional (“waterfall”) working, CMMI, PMI and everyone else has incorporated agile (to some degree). Not being agile is about as popular as leprosy.
But very few of us have reached the shining city on the hill.
Along the way agile has been watered down, in becoming compatible with everything else it is less different, it is less attractive, fewer workers are motivated to take the journey. And as “the powers that be” have found ways to bring control-and-command back to teams (maybe in the name of scaling) fewer people are invited to help build the city.
Ironically, as we (the agile community) has made agile management friendly we have made it less worker friendly. Today senior managers “get agile” and want their organisations to be agile. But those at the code face seem to have less and less motivation. And those in the middle… sometimes they seem to want to change just enough to declare success but no so much that things really change.
For some people agile has become completely discredited – I wrote Why do Dev’s hate agile? last year and I’m presenting it in London next week. Agile isn’t a shining city on a hill, agile is trench warfare.
And Googling “agile” presents a long long list of links with less and less coherence.
Agile won the war. Agile is respectable and everyone is agile now. Big business rush to be agile, Governments want to be agile, blue-chip consultancies will sell you agile.
But agile lost the peace.
While many say they are agile, few software developers live in a shiny city. The place they live in might be better than the place they came from but it doesn’t live up to the dream many of us shared 15 years ago. Agile has become an excuse for failure and a thing to be imposed.
The thing that passes for “agile” today is too often a watered down version of the original dream. Worse still, we don’t have a word to describe that shining city we all want to get to. Russians have an expression for this:
“We wanted the best, it turned out like always.” Viktor Stepanovich Chernomyrdin, Prime Minister Russia, 1998-1999
Me? – I still dream of that shining city on the hill, I still believe agile is the right way to get there, I still wave the flag for agile but more and more I feel the need to explain myself and tell people that the agile I dream of is not the agile they may experience.
Receive these posts by e-mail?
Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”
Pingback: Top articles of the week march 3
LOL. The Manifesto was never so grand as all that. It was never more than individualist geeks who simply wanted to be left alone to write the code they had been asked to write, instead of being held up by endless meetings and interference. To make that argument they reached for this and that and the other high concept. So the origin story never gets old, we’ve all been there. Managers say, “Start coding now, the requirements won’t be ready for months!”, and the devs all grin and say, “OK!” That’s agile, from the beginning, to now, and forever.
So, I kind of agree about “won the war and lost the peace” but look, if you have scrums and meetings and stuff, you are not being left alone. As soon as it’s about teams and coordination – you are not alone, and cannot be left alone, and will never be left alone. So the origin story has been completely lost, for any project that involves two or more people.
The problem with Agile (and the related spinoffs of SCRUM, Kanban, etc.) is that the very first thing you have to accept in Agile is that there’s no such thing as a deadline any further out than one sprint. From a developer perspective this is great, because it aligns with what we’ve been saying for years, and that endless series of missed deadlines prove. From a management perspective, this is entirely unacceptable, everything from budgetting to media campaigns and contract negotiations needs solid deadlines. So, in the name of encouraging adoption and keeping management happy Agile caved, let management keep their deadline security blanket, and threw out THE central tenent of Agile.
Now we’re back to a world where developers are asked to make long term “estimates” that they’re expected to then hit (or else!) but without the thorough designs and documentation that used to be provided as part of Waterfall. Instead we’re given vague “user stories” that never have enough detail to fully implement anything on the first attempt. Agile as practiced by large corporations is literally the worst of everything, all the hopelessly unrealistic deadlines of Waterfall, with the seat of the pants vague requirements and documentation of Agile.
Really I don’t want this to turn into another estimates or no-estimates discussion. There is more to software development and agile than estimates.
Nor do I accept the “no deadline” argument. I absolutely believe teams should work to deadlines. I also insist those deadlines are derived from the business need – and the value that can be realised – rather than the work effort forecasting.
Some of your points are exactly the things I’m thinking about, all I can say is the agile you are experiencing is not my agile.
The “Agile Industry” does whatever everyone else does with a concept. They saw the HUUUGGGEEE $$$ and went for it. The number of Agile consultants & coaches, the number of certifications and Agile Transformation Experts has grown exponentially over the years, with each one telling us we’re doing it wrong.
Some improvements have been made with the Agile DOGMA has grown so large that it actually prevents real world adoption of positive process. I’ve written about my take on this here.
https://onproductmanagement.org/2018/02/25/finally-reached-peak-agile-lean/
There may be an Agile Industry but there is no collective Agile Industry mind let alone strategy.
I’m sure some have done exactly what you say – and can you really blame them? After all, in our capitalist society the market determines what happens. That is imperfect but so much better than the alternative.
There may be people out there who suffer from Agile dogma but I think a far bigger problem is people watering down agile to the point of meaningless.
来看看，因为，总能学到东西！
http://asyncmanifesto.org
I thought it made some good points. The fight is always to keep tools as mechanisms to achieve the end, and not be the end themselves :p
Pingback: Agile won the war but lost the peace – Hacker News Robot
Fantastic post. You grazed by some Buddhist wisdom:
“The shining city on the hill” is a place that gives us peace to think about. Existence as a concious being is unstructured, and lack of structure gives us “existential nausea”, a feeling of anxious directionlessness.
But in any pursuit, whether you are trying to get wealthy, buy the perfect house, find the perfect romantic partner, build the perfect software team: the shining city is a mirage.
Whenever we reach it, we still see our situation still riddled with imperfections. We find problems with our house, our relationship, our software team. The “perfect” that exists in our minds can never exist in reality.
I think it’s fun to have “shining city” goals, it gives life purpose and direction.
But also, the way to everlasting peace & happiness is to find that we all live in a shining city right now. Everything is exactly how it should be. Physical matter follows the laws of physics, humans follow their genetic/environmental disposition. Everything is operating correctly and perfectly.
Part of how we operate is to follow “shining city” goals, so that’s perfect too. It’s fun to be on this journey.
Thanks Scott, I thought I was getting deep, you’ve gone deeper and I can’t disagree
Hi Allan,
Great post – as always!
Funny you should bring this subject up today, as I was thinking in similar terms this morning on my way to work. My take (I still agree with yours though!) on the lost peace is that agile has become the JavaScript of methodology; there are now so many “agile frameworks” around, with new ones popping up like mushrooms every day, and if you’re not using “the right ones”, you are doing agile “the wrong way”.
I want a shining city too, but maybe it doesn’t look exactly like yours, and neither should it. Build the shining city the way you prefer it, customised to your needs, dreams and desires, Do not look at the neighbouring shining city and assume that just because its inhabitants are happy, yours will be too if you build your city the same way.
Cheers!
Yes!
Maybe Sweden helps these thoughts, I drafted this when I was in Sweden a couple of weeks back.
The shining city analogy has been on my mind for a couple of years. As you say, our shining cities don’t need – even shouldn’t – to be the same. Reagan’s shining city is different to Clinton’s is different to erh… Likewise the Swedish dream is different to the British dream which is different to the Japanese dream. But we all dream.
Agile lost the peace because it became an “all about me” movement
Agilist became focused on the details of how it impacts individual developers and lost its connection with the business processes that pay their salary
I’ve seen this over and over again.
“We’re agile so we don’t need to estimate”
“We’re agile so we don’t need to follow the governance rules”
We’re agile so things like CMMI, ISO 12027, DO-178C are no longer applicable, ignoring those a well proven processes for increasing and mantaknty softare integrity and increasing quality
When we moved from “engineering” the solutions to non-trivial software development, to “we want to do ut our way,” agile lost it’s standing with those of us paying for the software.
I work where we apply agile on Software Intensive System os Systems, using CMMI, DO-178C, ISO 12207, and ISO 12588 and SCRUM
At our local MeetUps (in the office of a major Agile development rtool maker) and we from our domain hear whining about “I want it to be about my self actualization” we simple laugh inside.
Self actualization is an interesting one, for my money there is a lot of Milleniam generation thinking in agile – although obviously agile preceded the millennial.
Those entering the workforce now are more likely to want self actualization then in our day, when we entered the workforce it was about paying the bills. But that is the what the modern workforce wants, if they don’t get it from their employers they look for it elsewhere, and maybe they see it in agile. Personally, I hope they do, I think self-actualisation makes them better employees.