Oh Agile, why do we hate thee so much?
If you ever did a search for the terms: “Agile sucks, I hate Agile, Agile fails, Why Agile doesn’t Work,” etc… you’ll find yourself in an internet flame war against Agile. Click a couple links and you’ll find people from all walks of life flaming Agile. From developers, project managers, and even executive level folk.
So, why the backlash? What’s the problem?
Simply put. I believe there isn’t enough writing around case studies, or white papers on how Agile has succeeded. You hear a lot about agile theory, or new ideas around agile methodology (which it isn’t, by the way).
Agile is all about helping the customer. Finding the value where it can be found. In one sense, Agile is the method or process of helping people.
Knowing the ins-and-outs of Agile, Scrum, DSDM, Crystal, TDD, blah, blah is great and all. Hey man, let’s see those case studies where it’s actually worked! My commitment next year is to only submit talks to Agile conferences around case studies. I plan on writing more about case studies here… or on another blog… … but I think I found the answer: Agile White Papers and Case Studies. Check it out!
Maybe we’ve been agilizing everything too much. Let me see where it’s worked. Sing me a song pianoman. Tell me a story.
Ken 'classmaker' Ritchie (2)
Karol McCloskey (1)
Hey Peter,
Here’s a link to the story about my first XP project in 2001-2002: http://c2.com/cgi/wiki?IrrsProject
Let me check with some former clients about any success stories that they could share.
Dave…
Great! Have them go to: http://agilescout.com/agile-case-studies/
Putting together a post for it tomorrow.
Before there was formal thing known as “Agile” people talked about how Waterfall did/did not work. So the fact that there are people saying the same about Agile (or anything else) should be no surprise.
I’m always interested in what did or did no “work” and why people feel it did or did not “work” for them. Some things may “work” for some people even if only part of that thing gets applied very well while others may feel it does not “work” unless every aspect of it (as they see it) gets implemented and “works.”
So people try some set of things that they believe defines Agile for them. They may or may not implement them well (surprise) and they declare that the high level term “works” or does not. I happen to think Waterfall “works” if you accept its assumptions about how to make it work and what constitutes “working.” But there is certainly a way to approach Waterfall in a most dysfunctional fashion.
Well, some of those same dysfunctions (which people may attribute to a history of Waterfall use), will exist and be part of many Agile implementation efforts.
I like what I first heard from Ken Schwaber about how Scrum, for example, not “fixing” anything, just making it very clear what the organization must commit to addressing if they want to be more successful. If you address and fix those things, Agile will likely “work.” If you do not, it likely won’t.
But you could have fixed many of them under Waterfall and made Waterfall “work” (at least better), too.
I don’t think we need more case studies or success stories. They are red herrings. Telling people at company Z that Agile will work for them because it worked at companies W, X and Y is misleading, and essentially, a lie—meaning that you have no better idea of whether it will work or not at company Z no matter how many case studies you can pull out of your hat.
Being Agile means implementing a set of philosophically sound, human-centric principles in a context-sensitive way which will be different /every time/. Case studies do not help—but they may hinder, as both consultant and management try to force-fit a new team/group/division/organization into someone else’s way of doing things. It fails… and that’s when we hear the cries of “Agile doesn’t work”.
So, no, we don’t need more proof, we need more faith, more trust, and, let’s face it, a lot more down-to-earth common sense to remind us that /doing the same broken thing over and over again/ just does not work. Y’know?
Tobias! Thanks for commenting man! Oh, the contrarian
I would think, though, that there are certain things, that you can take from case studies and say “hey, this may just work here… the environment is the same… etc etc.” not to take it full bore… but to take bits and pieces of Case Studies and try them out.
… though to be honest, as I re-read your comment… i do heartily agree with you. sometimes… it’s more about faith and trust over ‘proof.’ …. sometimes again… it’s those that write example case studies that help us learn about what (has and possibly can) work… right?
what would happen if no one wrote anything… at all?
I like what Tobias says because I have been exposed to case study publication for at least 30 years. Many of these really are motivated by promoting a product/service more than delving into what does and does not work.
To meet Peter’s goal of seeing what has worked and has not for others, I’d prefer reports focused more on specific practices, how they were implemented (in some detail) and what people found were the pros and cons of how they did the implementation.
There is no question, after a decade, that the Agile Values, Principles and practices “work”; however, making them work, by understanding what they are trying to get at, is the issue.
When Tobias says we need “more faith, more trust,” I’d agree, in spirit. I do think, though, that one can look at what an Agile approach fundamentally asks be done, and rather easily determine how it all makes sense and certainly can work. But if the willingness to make more than superficial change isn’t present Agile will not “work” any more than any other improvement idea.
Always enjoy your commentary Scott. Well said.
It will be interesting to see what all the total submissions will look like. The point… here, is to try to accumulate “examples of success.” – We can nit-pick about what made them successful… but a purview into those examples… I think that would be valuable!
Firstly, let’s remember where we might be if Kent Beck and Jeff Sutherland had waited for proof
Secondly… okay, case studies can have some value, certainly to the people writing them, as a way to consolidate their learning, but also perhaps to others. As Scott says, if the focus can be on pros and cons of specific practices it may forge a better understanding of those practices. Also, a focus on failure as a learning tool in the way J. B. Rainsberger has often talked about would be beneficial.
My objection here is believing that more case studies will lead to better Agile. It won’t. I actually believe it will lead to worse Agile as people try to fit their implementation to someone else’s model — look at the disastrous legacy of the awful Nokia Scrum Test if you want a reminder of such folly.
Perhaps case studies can be studies of joy rather than studies of process improvement and money-making. That may drive the deeper kind of change many of us are seeking.
I retired on April 1, 2008 about 5 weeks before my 35th birthday using Lean/Agile principles to redesign my lifestyle. Does that count?
Sorry… 5 weeks before my 34th birthday.
WOw… looks like I may need to retire this year then if that’s the special year to do it!
Your life must be miserable.
Do you have links to what the executives hated about agile? Would be an interesting read.
I agree with the need for success stories — of course — since I posted a request for success and failure stories on my blog as well.
10 years out of the gate, we should have some examples of success.
Engineering is not a faith based endeavor; what would have happened if Kent etc had waited for proof?
For one thing the industry would have been saved from the whole XP distraction; XP was a fad, the proof of which is self evident in the job postings and google trends for XP. Only a very few postings ask for extreme programming compared to anything else. Go search you favorite jobsite or aggregator (indeed.com) if you don’t believe me.
To me scrum is no different. Surely after 10 years of hot air, people should be skeptical at the lack of success stories.
Show me the proof Mr Pianoman!
Jordan
> XP was a fad…
No, XP was the foundation for almost all good engineering practices today. That people no longer call it XP is testimony to its credibility and success —and to the integrity of its founders. I hope Scrum achieves the same anonymity—very soon. The prevalence of the Scrum brand-name is destructive to the successful application of its principles.
XP was the foundation for a successful faith based marketing campaign which was copied by Scrum.
XP is so dead, that many of the original XP Prophets have switched over to selling Scrum.
The fact that they no longer call it XP is not a testament to it’s success; it’s a testament that out of all the XP practices, the only one with significant uptake was Unit Testing.
XP did not invent Unit Testing. It did make it popular though. Onsite customer? Nada. Pair Programming? Nada. Merciless refactoring? Don’t see that much.
Big Test Up Front? Yeah, that got uptake.
Jordan
No, I’m not angry; I’m still unimpressed by Scrum and XP, and I have no qualms in stating so.
I’m not impressed by you and the agile crowd always trying to denigrate and belittle people with their own opinions. Give it a rest.
Speaking of success stories, weren’t you involved in Yahoo’s agile transformation? Occurred about 2005? Looking at their stock price prior to and after that period is quite interesting; Yahoo stock is worth about 1/3 of what is was before their agile transformation.
I guess that might lead you to not be interested in case studies?
Jordan
Actually, I believe a few case studies were written at Yahoo! after I left… They fired me for i) insisting that development practices should be improved (along XP lines…) and ii) for insisting that Scrum wasn’t about process improvement, but management change—culture change.
I’m not sure their case studies benefitted them, or anyone else.
Yahoo!, like many companies before and since, were looking to Scrum as a quick-fix. Which it isn’t, despite how it’s often sold. Seeking only process improvement, faster work, and higher profits with Scrum will not lead to success.
If we need case studies at all, I’d prefer to see failure case studies rather than success stories. We learn from the former, we get smug and complacent with the latter. Sure, Yahoo! was a failure, and sure, I had a part in that. The important thing is to learn. And I did. I can’t speak for Yahoo!
Agile is a cult.
It may be important to learn, but does that need to be at the industries expense?
That is the whole point of this case study exercise; can this or that be taught and absorbed by companies and is it effective?
My personal opinion, is that all of this success stuff boils down to talent. Talent can not be taught. Talent may be able to be nurtured, but the two should not be conflated.
I have more “talent” playing the guitar than some people, but I’m not a very talented guitarist. In return I have to work at it much more than people with real talent. When I work at it, I get a little better, but I’m still not talented.
That is why I’m not a professional guitarist. What we have here is an industry of people telling third rate programmers/managers that they can be excellent through this or that method(ology).
Well, that means the method should in fact be testable to see if it produces useful results, on a SUBSET of the population, before unleashing untested theories on the world and “certifying” people in them.
Additionally, we as an industry need to focus on the people a lot more, that talent is not something that is trainable, that talent is valuable and should be compensated for appropriately.
Too much of what is going on is getting cheap programmers, throwing a methodology at them, and finding out that that doesn’t work (what a surprise).
But many of the consultants and trainers are all too happy putting ranks of also-ran programmers through more and more agile training when what they should do is create an environment where the best people will want to work there, and then they will not need any particular methodology beyond that to increase their chances of success.
Jordan
Back to the idea of case studies…
Personally I’d love to see case studies paired with their theoretical underpinnings.
For example; there were those pair programming case studies (blog posts and research papers) a while back, and several of them discussed both observed behaviour and the theory of why pairing works.
Surely that would be a good way to learn from success.
I would also like to see more case studies. In fact, I’ve often said that even something like a “documentary” would be very useful. I helped bring agile practices to a small software company. Neither myself or anyone on the team had any extensive experience with agile. Seeing some of this in action would have been very helpful. It’s one thing to read about practices, it’s another to actually see them in action. So much can be lost in words. So I don’t think it is so much about saying hey, this worked for company X so it will also work for company Z, but more about saying, hey, this worked for company Z, maybe there are some things you can take from what they did and apply at company X?
In fact, that was the whole reason I submitted an experience report for Agile2011 about our evolution to agile. If you’re interested, you can find the paper at http://www.developmentblock.com/resources/.
Thanks for sharing Matt!
Our very large company (that you all know very well) that shall remain nameless has jumped the shark on Agile/Scrum and is now implementing it in all areas, Basic Algorithm development, Hardware Development, Software Development, Basic Research, you name it. We no longer have Technical Managers we are all put on scrum teams. A huge scrum of scrum will churn to coordinate all our scrum teams and coordinate everything in lock step. Our company with large groups of developers in China, India, France, Germany, Rumania, USA is now committed to this new fad and anyone voicing displeasure is sent to the Ministry of Truth to root out their doubts. We are told it is all the rage and everyone is doing it and they all love it. I learned long ago that when people say things like that to watch out. That is how I avoided destruction in the recent stock, real estate bubbles. So every one is happy.
Our 10 min scrum is over an hour and involves Netmeeting. Our sprint planning is weekly and will take the entire morning and keep you from lunch. Everyone must stay on board and show they are enthusiastic. One team member called into the scrum from the hospital where he had just taken his wife in an emergency to make sure he attended the scrum!
Each day we are asked for each task how many hours we worked, how many more are planned. Why isn’t this task done? This is worse that working in the military filling out time sheets. I am a self directed guy that gets things done and that might not be on a backlog list.
Of course the exodus has begun. As much as I enjoy the luncheons for those departing they are taking their knowledge to our competition. I found time will on a bridge line to the half day agile meeting to update my resume and my linked in page as well.
Of all the crap I have seen: TQL, TQM, ISO9000, CMMI, Six Sigma this one takes the cake.
Dang friend. I am so sorry to hear this. People just don’t know how to tread softly, and implement change slowly… and effectively. Forget calling it agile or whatever.
Hope you land where you want to!
Would you be so kind as to name the company? If they are big believers in it, they shouldn’t mind their name being used.
Jordan
Also, I am sorry to hear your experience. But it isn’t a surprise in fact I blogged about it in April of this year –
http://jordanbortz.wordpress.com/2011/04/09/scrum-as-the-new-command-and-control/
You could always tell the Ministry of Truth that process over people is against the agile manifesto…
Jordan
This is the company, C Unix and the recently deceased Dennis. Yes that Dennis. His office will soon be demolished with building #2 to save Property taxes. No national historic site. No tours buses. Demolished.
In light of the need to co-locate all of the scrum teams that are now going to be the sole organizational entity replacing existing team leaders and managers it seems China and India groups are destined to grow as we are to shrink to oblivion. Co location is key. We in the USA are so yesterday.
OK thanks for the information.
Google for Steve Yegges post Good Agile, Bad Agile. I think he says that foisting unproven methodologies on people should be an HR violation.
See where you can go with it. Has the ministry of truth supplied any evidence that it works?
Myspace received a fatal dose of scrum a few years ago, and yahoo received a near fatal dose in 2005.
Nokia networks I can’t find any information on their stock price but it looks like they are set to fire 17,000 people.
I think the colocation fetish is one of the biggest disadvantages to scrum, along with just about everything else about it I suppose.
But maybe this will wake people up; they’ll be fired from their jobs because they aren’t colocated with the team in the cheapest country they can find.
Basically, given the history, when a company goes big on scrum, it’s a good time to consider shorting it.
Jordan
Oh, also, what happened to all the managers? Were they fired? Or were they retrained/scrumwashed into new positions?
Jordan
They are now people managers or scrum masters. Two bailed just recently, other people are shifting positions. I of course have relied on these people so I can ignore the corporate BS. Now I guess we are all on our own. All the stuff I blind eyed is not coming back to haunt me.
China with the 51/49% joint venture is very encouraged by all this. Cracked flex-Lm licenses and huge China govt money to purchase equipment is a big plus for them. We are in demolition mode, literally, they are growing like the grass. We are in an unfortunate time zone, neither India/China or Europe. We go. Go Agile!
@DaveL
I feel your pain – I’m familiar with that org, and was in that building in Sept. Lot’s of struggles indeed, with a few precious points of light.
It was that group for which I coined the term Millipede Organization – It has a seemingly unlimited supply of its own feet to shoot.
That’s why I think people should consider shorting (the stock) of once great companies that switch to scrum.
It is often the last gasp of a once great company (Myspace, Yahoo, etc…)
It’s like seeing an old guy with a new red sportscar….a sign that they are over the hill and headed for the dustbin
They have run out of ideas and are clinging to what they think is hip and cool
Jordan
We are having agile forced upon us. It’s silly. I spend more time in meetings telling people what i am going to do than actually doing anything. I write highly complex scientific medical imaging software, usually prototyped in matlab before implementing in C++. The idea of “sprinting” through this kind of work, where it can take me weeks to months to work out a complex numerical solution or machine vision problem doesn’t make sense to me. No one ( on my team) can estimate how “big” my story is; they don’t have te experience in the domain. Agile may work for some things, but to me it crates too many meetings, too much talk, and worse, too much electronic paperwork. We are asked to put everything in JIRA- well, until JIRA has a formula editor on par with MS word, entering math formulas that look intelligible is impossible. Agile is a nice concept, but at 27 years in the programming world I’ve seen one fad after another, and this is another. The good parts of it, such as they are will survive, but a lot of this stuff is going into the dumpster and the sooner te better.
Agile and everything you wrote is disgusting, please die.
… eh?
Our company used the Waterfall method for quite a long time, but for the last 3 years we have been indulging in Scrum method.
We cannot imagine how a big and productive company like ours could work in the un-efficient Waterfall method.
We just admire Scrum here: we care to follow every step “by the book” (Ken Schwaber’s excellent book).
Scrum method has also changed our attitude as programmers. We feel no dismay from being involved in software verification duties. On the contrary: we are more willing to doing QA than to actually go deep into the code.
We have a lot of meetings which surely contribute to our feeling as being part of a team. We consult each other before we make even the slightest change in the code.
And indeed, we see the benefits: the software we develop became much more immuned to faults and much less prone to shortcomings. Our customers acknowledge this and sales get higher.
Our concept is that the software we produce is a consolidated huge lump that each modification in one area of it might affect other areas. Working in Scrum prevents these “shocks” and cross-effects. This is why Scrum fits our goals.
Wow, glad to hear that it’s working for you!