When Agile Projects Go Bad 139
blackbearnh writes "CIO Magazine has an article up looking at some of the ways that Agile projects can fail, or Agile can be misapplied in organizations. Some of the issues raised may not be new, but folks might want to pay special attention to these, since the people throwing the stones are two of the original Agile Manifesto signatories, Alistair Cockburn and Kent Brock. From the article: 'Once individuals become familiar with Agile, either through training or practice, they can become inflexible and intolerant of people new to the process. Cockburn has seen this in action. "I'm one of the authors of the manifesto, so if I say something 'weird,' they can't tell me I don't understand Agile. But if someone else — and it doesn't matter how many years of experience they have — says something funny, they get told they don't understand Agile."'" Here's another recent article by the same author on the perils now besetting Agile.
Extremist Programming (Score:5, Interesting)
We've had quite a few people around my workplace promoting extreme programming and (fr)agile software development. It's not going to replace lack of talent, lack of planning, or not knowing what the true costs of things are. I think many people in management have taken in only the parts that they want to hear, and ignored the rest. The results of this kind of misapplication are fairly obvious.
My biggest objection is the lack of credible proof that it actually works any better than the tried an true software methodologies.
Oooh, the irony! (Score:1, Interesting)
XP is probably the most prescriptive of all methodologies I can recall.
If you aren't following all 12 practices, you're not doing XP. It's ironic that the people that want to shy away from CMMI's use of the term 'discipline', requires more of it than any other. Even RUP is more flexible (albeit bloated on an altogether different scale). CMMI is a model, not a standard, but with XP - it's all 'do it our way or you're not doing agile'. If you dear criticize some practices, there's a chorus of fanboys crying 'Blasphemy!'
Personally, I prefer Scrum and Lean development - they really tickle my senses.
Re:Extremist Programming (Score:5, Interesting)
My biggest objection is the lack of credible proof that it actually works any better than the tried an true software methodologies.
But can you provide proof that the "tried and true software methodologies" work?
Our biggest problem in process improvement is that we can't easily measure productivity. If we could, then it would be a walk in the park to determine if one way of doing things was better than another. Instead we can say that project A was successful at meeting its targets while project B was not. Even then management always games the system to claim that their projects were successful. How else would they get promoted?
Lately I've been hearing from a lot of people who claim to agree with agile principles and therefore feel that they must be agile. Whether or not they actually achieve results seems to be secondary. A good example would be, does your team *actually* welcome changing requirements? If not, then I would argue that you aren't agile.
If you read through the agile principles and think to yourself, what would you do to actually achieve this, I hope that people start to realize that becoming agile isn't trivial. In fact, I think many people would argue that it's impossible. Having worked on a couple of teams that were actually agile in this respect, I disagree.
I think scepticism is healthy. But when we're comparing development methodologies it's hard to find ways of comparison. Even though I'm retired from professional programming, if I were to take it up again I wouldn't work in a more traditional setting. Especially one of the XP teams I worked on, while not being particularly exceptional in terms of talent, was one of the most amazing experiences of my career. I highly recommend others to try to get the same feeling. But it is by no means easy.
Scrummed to death (Score:1, Interesting)
Having worked on a Scrum-managed development project for 3 years in a large French/Canadian software house, I am happy to have the opportunity to get it off my chest that Scrum SUCKS the big one!!! and Scrum slowly strangled a decent project over 3 years until death. Finally our company was bought out, and the project was consigned to the trashcan by accountants due to faiure to show any results after such massive investment. Due to the fact that it was a project for a new product, using new development technologies, and with a new team, we were all initially on the learning curve. As required we had to give estimates on how long our tasks would take, blindly. Of course we got it wrong and soon had a massive backlog, and finally we became slaves of this massive backlog. We had many overlapping scrum groups based on vertical and transitional concerns, resulting in seemingly non-stop scrum meetings and backlog meetings. Scrum masters were incapable of passing useful information and alrets between scrum groups, because they had little technical savvy. End result: people just lying about the completion level of their tasks, backlog explosion, lack of coordination, demos not working, a massive drop in morale, massive infighting and politics and blame game, massive quality problems - components not working meant testing was limited, etc. In that 3 years over 50% of the original development team just left the company and so we were slowly sinking into the mud of failure. It was micromanagement gone mad.
But these scrum idiots just kept flogging that dead horse with religious zeal and in the end they blamed everything but themselves. Perhaps the fact that the company spent so much money on having these people trained, they could not admit defeat and stop the madness.
You guys were using Scrum the wrong way (Score:5, Interesting)
Just reading your post shows me that you guys where using scrum the wrong way. Most people don't understand the true purpose of Scrum. We do Scrums every day at 11:30 and they take about a minute ot two per team-member (just did todays and I'm checking on slashdot while adding my new tickets to mantis).
Scrums are stand-up meetings. Everybody stands and keeps his turn short. You say what you where doing since yesterday, what you achieved and what you are going to do today. It's mostly about self-awareness and being able to judge your capacities - it's a mental exercise, not a classic meeting (we have those too, but only like once every 8 weeks).
Agile came out of the need to deal with controll-freaks who didn't do their homework and tend to weigh down things that should be lighweight with to much bureaucracy. Where human interfacing is a key point of your software, Agile is a very good method to handle things. If the pipeline has skilled people at each section, that is. Our company is technology driven with managers that actually wrote code at some point in their career. I'd call our process somewhat agile - we get changes every odd week - and everybody deals with it without a single hitch. ... Coming to think of it, maybe that's why we dominate our market.
Bottom line:
You guys got Scrum and Agile all wrong. Maybe you should've steared clear from the get go.
yes, but here it's funnier (Score:5, Interesting)
Yes, but here it's funnier, since you were supposed to trust it without any proof, and in fact in spite of proof to the contrary, from the start.
Since the topic is agile projects gone bad, you only need to look at the original Chrysler C3 project that became the poster child for XP: from Chrysler's point of view, the project was an abject failure. By the time it was _years_ overdue, it still hadn't delivered a tenth of the promises. At least one of the managers involved as client-representative in that project got stress-related health problems during it. Chrysler not only cancelled the project, but forbade XP. It's something you'd normally call "EPIC FAIL!" as projects go.
But in true CCCP fashion, a failure got redefined into a smashing success, and presented as such in the books. In fact, turned into the poster child for successful XP.
So there we have our answer already: when XP projects go bad, failure gets redefined as a smashing success.
Later studies into, well, how much better _is_ pair programming, actually showed that such a pair is somewhat better than a single programmer for inexperienced freshman year programmers, but barely marginally better than a single programmer when done with experienced programmers. Both cases delivered actually less than the two programmers working separately on different parts of the problem.
Again, it won't stop anyone from still pretending that it's the opposite.
XP also redefined what "bug" is, by pretending that only stuff caught by the client's automated tests are bugs. Hence, if your tests for my "int add(int x, int y)" method only test for x = 2 and y = 3, and the whole method is just a "return 5;", it's not buggy. If you wan it changed, that's a change request, mate.
Hence making possible the claim that XP delivers 100% bug-free code. Now, if you want to redefine what "bug" means, you could do the same for any other methodology, but XP zealots like to ignore that. (I mean, seriously, if "not caught by the acceptance tests" doesn't mean "bug", then Windows 3.0 was 100% bug free too. Dumbly enough it was only tested internally on identical Compaq computers, but it ran flawlessly on those and with the particular software mix used in the test. If it doesn't work on your computer, though, XP would call it a change request.)
So, heh, it's mildly funny to hear the same guys who did that reality redefinition complain about others doing the same.
Seriously, it reminds me of a joke by Vince Ebert, translated loosely from memory: If you think there's a beer in the fridge and go look, that's science. If you think there's a beer in the fridge but don't look, that's religion. And if you look, see there's no beer, and still think there's a beer in the fridge, that's esotheric.
That's what XP is: something that started as a religion, and ended up an esotheric cult.
I'll be the first to say that flexible thinking is great, and that XP even has some good ideas. The point where it fails is that "turning all the knobs to 10", to quote the authors.
Essentially what they do is discovering something like "hey, some salt in a soup tastes nice, and a bit of vinegar makes it even better"... and from there formalizing an ideology in which all soup is done only with salt and vinegar. In fact, by boiling a kilo of salt in 5 litres of vinegar, since that's the turning all knobs to the max point.
Re:Measuring productivity (Score:3, Interesting)
Furthermore, you can't consider a group comprised of people in the top 10% (however you determine that they are) to necessarily perform X amount better than a group that comprises people in the bottom 10%. Supposes your top 10% group contains two genius prima donnas who grow to hate each other? Suppose your bottom set contains a group of jobsworths who don't show much initiative and consequently follow the design plans of the power-hungry one and consequently follow a cohesive and well-delegated plan? How complex is the task? If it's simple code-assembling, an office full of plodders might have little significant disadvantage compared to the creative geniuses. Or if it's highly complex, they might botch the whole job. You can't easily prove the effectiveness of different methodologies and I don't think it's possible at all without significant resource.
But supporting the argument that comparing methodologies can be difficult is not me personally arguing for the effectiveness of "Agile" which I view as some common sense, some ideas that would be bad if applied in the wrong circumstance and a lot of vague principles that should be read to stimulate insights and then forgotten about.
Re:SHOCKA (Score:3, Interesting)
Of course, they probably did, and management probably ignored it because the Agile Consultant had a nice suit and a cool car...
Re:Measuring productivity (Score:5, Interesting)
Because in real life you rarely find enough of the top 10%-ers to do all the work that needs to be done.