I’ve been thinking lately about how agile turned out to be the way we know it today. And the more I think about it, I get more depressed.
You see, agile was supposed to save us all. It was supposed to be the bridge between business and developers. And 10 years after its inception, we should be happy that more than half of the projects are done in agile manner (depending how you interpret the numbers). Agile has crossed the chasm, but not like we imagined it would.
At this point, I feel Agile is declining into what TQM was. A brilliant success in the beginning, and now just a history fact. In a few years, months even, the business side will wake up and say: Agile is snake oil. It doesn’t deliver on its promise (and it doesn’t matter if it’s done wrong). The backlash will be grand.
There is still some light at the end of the tunnel: Regardless of our role in the process, as long as we’re delivering working software, we’re contributing to balance this future backlash. As long as we stick to the original agile ideas, we’re helping agile win a few more hearts.
I hope our collective work will be enough, that results will prevail. But I fear we’re seeing the beginning of the end.
Don’t agree? Cheer me up in the comments!
Reference: 4 Warning Signs that Agile Is Declining from our JCG partner Gil Zilberfeld at the Geek Out of Water blog
Also See: Clean Sweep in Agile
You see, agile was supposed to save us all. It was supposed to be the bridge between business and developers. And 10 years after its inception, we should be happy that more than half of the projects are done in agile manner (depending how you interpret the numbers). Agile has crossed the chasm, but not like we imagined it would.
- Companies are “doing agile”. But they do it the way they implemented processes for the last 200 years: Top-down. First they train the top management. Then they move on to directors. Then to team leads. And at the end, they get to the developers. Remember that “working software” part? It looks like they didn’t read the small print (much like in the waterfall case).
- The business and development divide has grown. Because scrum won, we now have project managers as scrum masters. They don’t know much about software, and that doesn’t help bridge the gap between the two worlds. Developers still look at those scrum master certifications funny (with some reason on their side), and the PMs still don’t understand that in order to get to “working software” you need to persist with actual software development practices. Because if you don’t write tests, or refactor, your team will slow down very quickly. And that will not produce as much “working software” as it said on the side of the box.
- It’s been just 10 years and we’re already looking for the new hotness. We didn’t have enough time to learn or adjust. Agile has now become “boring” and we’re looking to uncover more better ways to develop software. Those things that looked “shiny” a few years ago, like TDD or continuous integration, have lost their shine, and aren’t attractive anymore. Don’t believe me? check out the big conferences – seen these topics lately? Much like good management is dull and repetitive, so are agile development practices. But while we appreciate the old ways, apparently we value the new stuff more (without any good reason).
- We can’t even appear as a united front. We’re bickering inside ourselves. Agile vs kanban, craftsmen vs non-craftsmen – you’re doing it wrong, we hear from every side. And since agile has now become mainstream, it has a lot of money pouring in, and the side (read: consultants and trainers) that shout the loudest get a piece of the pie.
At this point, I feel Agile is declining into what TQM was. A brilliant success in the beginning, and now just a history fact. In a few years, months even, the business side will wake up and say: Agile is snake oil. It doesn’t deliver on its promise (and it doesn’t matter if it’s done wrong). The backlash will be grand.
There is still some light at the end of the tunnel: Regardless of our role in the process, as long as we’re delivering working software, we’re contributing to balance this future backlash. As long as we stick to the original agile ideas, we’re helping agile win a few more hearts.
I hope our collective work will be enough, that results will prevail. But I fear we’re seeing the beginning of the end.
Don’t agree? Cheer me up in the comments!
Reference: 4 Warning Signs that Agile Is Declining from our JCG partner Gil Zilberfeld at the Geek Out of Water blog
Also See: Clean Sweep in Agile
CodeMash had plenty of agile sessions. TDD and CI with Hudson to name a few. I hear what you are saying, but I think it's more along the lines of agile being used wrong by the wrong people, rather than dying. A misunderstanding of sorts. It's hard to stick with it, and if you don't, it's not agile and it's not effective.
ReplyDeleteUnfortunately, I completely agree. Within the last 2 years, the two places I've worked claimed to use a "hybrid" agile approach. Both were large corporations.
ReplyDeleteI had two projects at the first company. The first project everybody was completely clueless how agile actually worked. We're talking post-it notes on whiteboard stuff. The second project, we actually had a certified scrum master. The guy was top-notch, but the "business" people were clueless. Both projects went over budget, failed to ship anything, and generally made the developers working on them go insane and 90% of the team quit after 3 months.
The second company had a better approach, but it was more waterfall then agile. The developers had nicknamed it "agi-fall" as a shot at the people running the project. Fortunately, we had good PM's, good developers, and good architects. We also had a lead PM who basically kept the "sponsors" in their place and said "no" a number of times to unreasonable requests. In the end, we hit the majority of our deadlines, and shipped several versions of our app - a rousing success.
Both places desperately wanted to claim they used Agile Methodology, but if you've worked at places where it's been used and used successfully, you know most of these place are just jumping on the hype - which has really dried up lately. I'd love to tell you Agile is still going strong, but in my experience, it's dying a slow death.
You're right...but isn't that the definition of progress?
ReplyDeleteThat's the "Moneyball" lesson: it's not the absolute things you're doing right in your business, it's what you're doing better than your competitors that really matters. So, as Agile goes mainstream, competition is forced to innovate in the space. And they do. The faster that happens, the better.
Dying or not, agile doesn't solve the problem. We still delivery expensive, or low quality, or no-one-will-use-it software. I think it is time to stop on thinking about proccess and start to think about how to do great software.
ReplyDeleteprocess = how to do, surely?
ReplyDeleteInteresting. My experience in very large financial institutions, for the projects I worked on, has been just the opposite over the last 10 years.
ReplyDeleteIn a recent project, the org was desperate. They had blown huge sums of money on BAs analysing the problem for 6 months trying to come up with a spec. Prior to that they had blow more money on prototypes/waterfall style dev that failed to deliver. My agile team delivered in 3 months. The business are extremely happy, senior IT mgmt openly admit they don't understand how we did it but want to learn.
Another project, complex and nasty, has been successfully running for over 5 years and has been virtually bug free in that time: CI, TDD, ATDD, weekly releases, pairing, direct contact with the business.
Most of the devs around me wouldn't accept working where TDD/ATDD and CI was 'not permitted' - not that they would ask. Most of them are moving from project to project helping teams with their process.
The problem here is perhaps that these XP/agile practices are becoming normal. People don't shout about it, they are too busy doing it.
Interesting. My experience in very large financial institutions, for the projects I worked on, has been just the opposite over the last 10 years.
ReplyDeleteIn a recent project, the org was desperate. They had blown huge sums of money on BAs analysing the problem for 6 months trying to come up with a spec. Prior to that they had blow more money on prototypes/waterfall style dev that failed to deliver. My agile team delivered in 3 months. The business are extremely happy, senior IT mgmt openly admit they don't understand how we did it but want to learn.
Another project, complex and nasty, has been successfully running for over 5 years and has been virtually bug free in that time: CI, TDD, ATDD, weekly releases, pairing, direct contact with the business.
Most of the devs around me wouldn't accept working where TDD/ATDD and CI was 'not permitted' - not that they would ask. Most of them are moving from project to project helping teams with their process.
The problem here is perhaps that these XP/agile practices are becoming normal. People don't shout about it, they are too busy doing it.
So what if it "dies"? Then it'll be just another secret weapon known only to those who practise it. The naysayers can just tell themselves that the agile practitioners are succeeding despite themselves, but who cares what the naysayers think? There's no need to "save" agile development as if it were a threatened ideology. Just leave it to commercial darwinism to sort out the long-term winners from the losers.
ReplyDeleteif you implement agile, it delivers. if you half-implement it, it might half-deliver, or not at all. Scrum says you're either following all the scrum rules, or you're not doing scrum. I have a feeling you have worked in many places that do hybrid, but nowhere that did pure.
ReplyDeleteI am not surprised that you are seeing signs of aging in the AGILE approach. Since the IBM Project Management process that I heard of back in the 1960's, every iteration of IT Delivery PRocess has been touted as the "Be all and End All" to all other processes before and after the one that is getting touted! It's marketing but NOT necessarily permanent TRUTH! I saw we all go back to the future with Software Engineering disciplines of the 70's and 80's and thwart the next "Be All and End All" for something that has some structure, legs, strength, history, PROOF! etc.
ReplyDeleteCheer up. I do agile with my clients and it works great. Among developers I'm seeing healthy discussion of approaches such as scrum vs. kanban, lean software ideas, rapid prototyping, TDD/BDD and the like. I imagine the reason you're perceiving it as in decline is selection bias: when it works well, we don't hear as much about it because it's working. :)
ReplyDeleteBuilding a complex software requires good processes and methodologies in place. Complex software means more resources, more resources requires good coordination so without those processes and methodologies in place you are will be doomed.
ReplyDeleteOf course Agile is dying: it's never lived. All the projects I have worked on that were "agile" have been utter failures, waste of money and resource. Agile is a way to hide delays, then to rename failure as "success", then to redefine crap as "working software". Agile teams are too big, chat too much about irrelevant problems, and don't deliver anything worth in the long run. Would you live in a house that's been built the "agile" way? Would you fly in a plane whose flight control systems have been developed the "agile" way? I have built awesme software in teams of four using waterfall, and crap software in teams of ten doing agile. Guess which experiences I am proud of. And I can already hear the "your team was not doing agile the correct way", which sounds like "religion would be good if people did it the good way, it's just sad that they all do it the bad way".
ReplyDeleteOf course you're going to get the Agile haters to come out with a post like this. Is Agile perfect? No. It reflects how humans think and work. Like humans, it's imperfect. But compared to the old way of working, it's worlds better than the military-like waterfall world and it's far better at fostering real creativity and teamwork. What I don't think we've figured out well yet is how to scale it to very large teams. But that's not an Agile problem, that's a human problem. We're genetically predisposed to work in small teams. Agile does that beautifully.
ReplyDeleteYour comments about it not being the new shiny thing is really a sign of it's success. Becoming mainstream simply isn't sexy. It sounds to me like, now that you've been 'married' for a few years, you're getting that 7 year itch that breaks up so many marriages. "Something new... I need something new". In reality, you don't. Happy marriages consists of people that are willing to take the good and the bad that comes with every partner. It's the same with Agile. Sure, it has a few warts here and there, but how well the relationship works depends on how good you are at ignoring the warts, recognizing the beauty and getting on with your day, every day.
Please go now and read the Agile Manifesto again. Consider it carefully then ask yourself is any part of it is obsolete?
ReplyDeleteSurely this post is linkbait? If you pay lip service to agile, you're not "doing" agile and you fail, then you blame agile. Besides this, you don't "do" agile, it's a value system, it's mostly common sense. If you're not following the common sense written down in the agile manifesto, you can't claim to be agile, anymore than I can claim to be a bird because I flap my arms when I leap from buildings.
ReplyDelete"Agile has now become “boring” and we’re looking to uncover more better ways to develop software. " - isn't this agile? It's actually the FIRST SENTENCE on the website. (http://agilemanifesto.org/)
I applaud people like you who are willing to challenge the status-quo and not be an agile zealot, so thank you. But, please, spend more time learning what it means before posting this kind of thing.
I think to build complex software, you don't need processes and methodologies to tell you how to do something. To build software, complex or not, you have to learn how to build it. And you get it only by experiments and a loop of build, measure and learn.
ReplyDeleteHere, I mean by processes things like Scrum, XP and Waterfall that tell (or suggest) you how to do something. I know that agile methodologies claim to be adaptative. But I think that just it doesn't work. You don't have to get some management framework and adapt it to your culture, project, etc. You have to learn what is the better way to manage that specific project. I think you can do it conducting experimentation over users, revenue, etc. And then adapt when is necessary.
ReplyDeletethanks for the thoughts. the trends du jour always fade.
ReplyDeleteHi, I was going to write a comment yesterday and had so much paragraphs, I just decided to write a post on how agile is evolving: http://t.co/AJn18KQd
ReplyDeleteWhat do you think? Is agile really in decline or is it evolving?
I'm not sure about your though process, but I think you just described a process. :-)
ReplyDeleteIn short processes are guidelines (or rules, depending on where you work). If you described what you said as a guideline, I would say you just described a process.
Mike,
ReplyDeleteI've already met the people who "do" agile. They are "doing" it in their team, and have just management backup to "do" it in their organizations. I've been at an agile conference where a case study for the agile success story left the developers waiting in the wings until they get to join the party.
Don't make a mistake - agile is now the new shiny thing. It's the new sliced bread. It's crossed the chasm, and now everybody wants one. And there's plenty of people ready to fill that need. It's now a business. Not a value system, not any more. You may think that for yourself, but then again I'll bet that Certified Scrum Master paper doesn't account much in your eyes either. So why are many organizations offering it?
By the way, the sentence is very much like the first sentence in the agile manifesto, though not exactly the same. I suggest reading the manifesto again :).
While you don't need a framework, people safer when there's one that's been used before. But people are also lazy, so they don't get to the adoption phase. They just decide it's not for them. Which is a pity.
ReplyDeleteNice description of the state of agile. I've seen agile work in two cases: in small teams, fighting against management. Or when there's both management support and the development teams that have accepted it.
ReplyDeleteI didn't write declining for nothing - it is not stopped dead. If management adopt it, it would work having the right teams in place. Unfortunately, the case of that happening succesfully are not that good.
True, but complexity has gotten us to a point that we found agile methodologies as the solution because of their simplicity. And also true, if your team is not working with proper processes, it will take a lot of resources, training, and not to mention convincing, to get them there.
ReplyDeleteIt is why agile seems like a silver bullet. Unfortunately, it's not as easy as it seems. Fortunately, when it works, it works miracles.
No it's not. For me and obviously for you. And I seem to go back to it whenever I write a post like that, which is something like every month at least.
ReplyDeleteThe question is: How many CTOs that bring agile onboard actually read it? How many scrum masters know it? The "Agile" was confiscated from the Agile Manifesto and placed in the hands of peddlers. As I've commented above (or below) it is no longer a value system, it's a brand, even a product.So it's not obsolete. But it's not "used as intended" either.
Agile hater - never been called that before...
ReplyDeleteAgile better when done well. It crumbles when it doesn't - like you say, it's a human thing.
For agile (in any methodology or process) to work, you need discipline. The successful are disciplined, and will stick with the processes. Most people don't.And they look for the new shiny thing. Why do you think that divorce rates are rising? :)
I feel better already!
ReplyDeleteGil is right. Agile is now used and abused and it no longer looks like the original Agile. In any case, the whole point of Agile was to get more consultancy work, and if you think about it, it's just an offshoot of Waterfall, with just some rituals (by the way, Waterfall is iterative, that's why there are change requests) and some set parameters.
ReplyDeleteFor those that believe that a hammer, saw and blueprints can build a house by themselves, Agile is snake oil. For many of us that start with good teamwork, a focus on quality and doing what's right, Agile is just another tool that can help us build great software. I've seen it many times. For those of you who believe there is a magic tool or process out there that will allow you to mindlessly plod away, you are searching for a pot of gold at the end of the rainbow.
ReplyDeleteI agree with you.
ReplyDeleteDavid Sabine Yes, the agile manifesto is still relevant. But in the eyes of those implementing agile today, they see this equation:
Scrum = Agile
The only problem is that Scrum is not agile. It is a set of best practices that end up confusing people who might like to be agile.
I agree with Gil Zilberfeld but I don't blame the CTOs, they are only buying the product the Agile Alliance is selling. They are consumers, pure and simple. While we might think otherwise, they don't see their jobs as understanding the difference between a CSM and someone who actually knows how to lead a project.
"It’s been just 10 years and we’re already looking for the new hotness " -From an article about how Agile is passe.
ReplyDeleteThis is like when every news program does a story on "Why are the media paying so much attention to [celebrity X]?" Is this some joke about recursion?
The problem is made by a lot of people, like the author herself, mixing up development processes (agile in this case) with development itself. Writing tests (even TDD) and refactoring are parts of the development that can be used in agile development as well as in waterfall, spiral, iterative and incremental models.
ReplyDeleteprovocative - focus... should be on ... "doing what it takes to produce quality software." regardless of methodology
ReplyDeleteThese videos saya it all...
ReplyDeleteEnjoy!
http://www.youtube.com/watch?v=NZyi__N4zBo
http://www.youtube.com/watch?v=nvks70PD0Rs
John