Slashdot Log In
When Agile Projects Go Bad
Posted by
kdawson
on Wed Nov 19, 2008 01:55 AM
from the antonym-of-agile dept.
from the antonym-of-agile dept.
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.
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
No way! (Score:5, Insightful)
SHOCKA (Score:4, Insightful)
Re: (Score:2)
In my experience, bad management coupled with agile programming leads to dramatically worse results, however.
Agile programming requires good management and very experienced engineers to work effectively. Very few organizations have both.
In the several organizations I've been at that have toyed with it, its been a total failure because of that reason -- a failure clear to the engineers involved, and people like myself looking at the mess from the outside, but the management directly involved can't seem to se
Re: (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:SHOCKA (Score:4, Insightful)
I'll agree with that. Bad management, a top notch team and agile can not only lead to worse results but effectively dismantle the team as well. From the rest of my career experience, assembling that "right" team is a very very hard thing to do. I'd trash almost any product if it meant keeping a high quality, high functioning team.
Agile sort of masks management mistakes for a while and creates the illusion that it's not as important, it places emphasis on the team, encourages team responsibility and the breaking point is when the team is so overloaded that they start to fail. A lot of really good teams will absorb that load for a while though, you'll hear some rumblings but the management mistakes will continues to build. When the load starts to break the team, it's way way too late to fix, the team will fracture and break apart.
I don't like the "2.0" moniker, so I won't call it "web 2.0" or whatever but the current generation of top notch software, lead by Apple and the very few similar companies (come to think of it, I can't name one that is truly similar so much as wants to be and pretends to be, except maybe google) is kind of different. You really have one shot to win or lose the customer, the expectations are exceedingly high, and every product has to pretty much be "lights out" from the start. The old MS "fix it in 2.0" doesn't cut it, there can't be much that needs fixing and in 2.0 you need to further raise the bar, not continues to get in to the game. Web services are a bit different in that you have a little bit more room for mistakes, but not much, the web crowd won't use crap while you figure out the "right way." To put together an itunes or an iphone you need excellence throughout the organization, not a razor sharp dev team and a bunch of morons surrounding them playing iterative games to mask their own incompetence. I think as the rest of the industry wakes up to it and realizes what they have to do they'll realize that it is much harder than it was before. You need a very cohesive management team with vision and high standards that is all on the same page and you can't just pick that up at some seminars. If you have that then maybe Agile might work for you.
Parent
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.
Re: (Score:3, Insightful)
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.
as a part of a company that only does things the agile way, we have a saying "you cannot do agile, you can only be agile" in short it is completely dependent on the kind of people you have on your team.
Re: (Score:2)
Fair enough. I just don't defend the tried and broken ones, like many do.
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.
Parent
Re: (Score:2, Redundant)
It also depends on the team members. If one team has people in the top 10%, and the other team has average programmers, the methodology will be mostly irrelevant.
Re: (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
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.
Parent
Re: (Score:2)
It's pretty clear that there's a risk that "we're doing agile!" can be used as a justification or smokescreen when what you're really doing is blindering through and making it up as you go along.
Re: (Score:2)
Uhm... (Score:4, Funny)
Alistair who ??
Re:Uhm... (Score:4, Informative)
Actually, it's pronounced Coburn because he's from Scotland and apparantly that's how they pronounce it there. He starts nearly every talk by explaining how to say it correctly :)
Parent
Kent Brock - s/ro/e - Kent Beck (Score:4, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
And the article is not by Jim Shore, who wrote the linked article at the bottom of the summary. TYPO TYPO TYPO
Name misspelled (Score:2, Insightful)
That should be "Kent Beck" in the summary, not "Brock".
Cockburn? (Score:5, Funny)
Cockburn has seen this in action.
I have personally experienced cockburn and assure you will become "become inflexible and intolerant".
Re: (Score:2)
Buzzword Boredom (Score:4, Insightful)
In my thirty years of design and programming on projects big and small, high level to low, I've seen this crap come and go. It's always more or less the same, and it's always instigated/pushed/proposed by those who cannot code, or those who are looking for something to do besides code.
Re: (Score:2, Insightful)
No, agile really is different from the old methods. And it's not that much about how to code it's about how to run a project, maintain control, and be able to deal with changing requirements.
You still need good coders, it won't magically improve anyone. But you need more than that. There is no lack of failed projects staffed with good coders. If your projects regularly succeed, you are also employing some planning and management skill that is evidently not obvious to everyone.
Re: (Score:2)
Yeah I'm in the middle of a huge truck of agile fail at the moment. Its good for people like me - the sort of contractor who is called in to "save the project" when its too damn late.
People seem to think you can easily refactor a completely broken domain model for a complex system. Requirement capture via user stories is only going to work when you have a clearly defined problem domain and precise terminology. If at 90% into the project timeline you are still having trouble getting questions answered like "
Re: (Score:3, Funny)
Agreed. Despite some successes, generally speaking mostly small or low mid-scale projects, "Agile" is to software engineering what Red Bull Flugtag contraptions are to aviation engineering.
Out of context (Score:2)
Cockburn has seen this in action.
Did anyone else giggle like an 8th grader when they read this?
Lots of ragging on Agile here (Score:3, Informative)
I'm reading lot's of ragging on Agile here. Maybe you guys should actually f*cking read the agile manifesto [agilemanifesto.org]. It's only a few sentences after all. You'll notice that it's actually quite a good thing that tries to rid the software devprocess of bloat and get close to the people for whom software is written.
Whenever I've used agile with the right people, it was a breeze getting the job done. It's basically common-sence systematically applied to software developement in my book.
Re:Lots of ragging on Agile here (Score:4, Insightful)
Well, whenever I've done anything with the "right people", it's always been a breeze. The problem is that those projects are few and far between. The methodology that will eventually work the best is one that takes the wrong people and makes them productive. (Like assembly lines making cars - if you had a bunch of skilled mechanics, they could make a good car, but if all you have is a bunch of high school drop outs, and you want to build good cars, you need an extremely rigid process to make them useful.)
Parent
Re: (Score:2)
If you have programmers in the top 10%, then it's not guaranteed to work. However in the absence of factors like impossible requirements, bad management or personality clashes the odds favour success much more than they would with less capable ones (who aren't immune to those factors either).
Rather, it's "right people" who are rare. Not every project can hire only prog
Re: (Score:3, Funny)
Rather, it's "right people" who are rare. Not every project can hire only programmers that are in the top 10%. There just aren't that many to go around. Maybe as low as 1 in 10, by some estimates...
That can't be right - over 75% of the developers that I've asked rate themselves in the top 10%!
Re: (Score:2)
Next time someone tells you they're in the top 10% compare their code to the Samba, Linux, or Subversion code base; they won't stack up. The problem is that the people who think themselves great aren't reading other peoples code, so they're
Re: (Score:2)
Well, whenever I've done anything with the "right people", it's always been a breeze. The problem is that those projects are few and far between. The methodology that will eventually work the best is one that takes the wrong people and makes them productive. (Like assembly lines making cars - if you had a bunch of skilled mechanics, they could make a good car, but if all you have is a bunch of high school drop outs, and you want to build good cars, you need an extremely rigid process to make them useful.)
Nope. The sooner we getting out of the idea that anyone that wants to be a computer programmer can be one the better. I'm not a musician, I'm tone-deaf, so I don't pretend that I can be a rock star. Why do we spend ages trying to get those people with a talent for coding to help people to whom its just a job and have no talent for it? All it does is generate mediocrity.
Amen (Score:2)
Agile works fine for us. Maybe we don't do it by some 'book', and I have no use for consultants, but what we do WORKS.
And I disagree that you have to have some exact certain people to implement it. Not that you can just take some random collection of developers and send them off to do agile development, but with one or two key people that can actually communicate and teach people how to do what needs to be done it works fine.
I've taken groups of nothing but myself and interns and done it, people with no ind
Agile as a defense mechanism (Score:2, Insightful)
As someone who had the "fun" of becoming a scrum master at a company that was trying (and eventually failed) move off of waterfall I got to be the main Agile advocate with our management.
This company failed from both ends. Developers began to use Agile as a shell to protect them from the problems that were in the old system. That's understandable given how badly they were overworked during deadlines. However what they didn't see was how this poisoned upper management to the entire concept. Management was wi
Yet Another Fad, Misapplied (Score:2)
XP, Scrum, etc. have some good ideas--however, as TFA mentions, they require *thought* to implement well. They are also not new, just re-packaged. Ed Yourdon was talking about interviewing users to find out how the system/process *really* works over 20 years ago. (His "Structured Analysis" [yourdon.com] is an excellent on-line book for learning how to design systems)
However, any method that relies on your team members being in the top 10%/experienced programmers is only going to be useful for a few, high-profile or speci
Re: (Score:2)
no, i think agile programming is what everyone does by default when there is no thought about what one is doing or why
Re:pft (Score:4, Informative)
no, I've done both and they are very different.
If your impression is that agile methods are directionless then you have met poor practitioners or read negatively selective descriptions. It actually quite rigorous, but on other axes than traditional methods. They focus on process and feedback and controlling uncertainty as you go rather than pretending you can plan away uncertainty.
Of course like any buzzword it attracts unwarranted 'namedropping' use, and like any subculture it attracts overzealous idiots who just want to be 'part of it' and look down on others. But that doesn't really say a lot about what it can offer or not.
Parent
Re:pft (Score:5, Informative)
Agreed; Agile is a specific methodology that is quite orderly and efficient.
Too often, though, sloppy managers let the project run wild, zero specs, zero plans, do what you feel like doing how you feel like doing it, the deadline is yesterday, so there's no time to plan anything, the customer is our alpha-tester - and they call it "agile development" because "total brothel development" doesn't have the right ring in the name. And people who see such projects really believe this is what Agile is all about.
Parent
Re: (Score:2)
I'd never heard of "total brothel development". Is it related to this? [everything2.com]
Or perhaps you literally translated from the French, who use "bordel" to mean "Hmm, this situation is somewhat less than optimal, isn't it?"
Re: (Score:2)
1) Traditional - get everything working, time and money are flexible(to a degree)
2) Agile - Hit our deadline, how much needs to be working can be changed as we go along(to a degree)
Even the approaches by the customers aren't the same
All development processes have cult following (Score:2)
There isn't one of them that doesn't have individuals that follow the processes blindly.
I think this is the point of TFA, you need to think about what you are doing and never assume that you have a silver bullet.
This is actually where XP/Agile have a major advantage over other more formal processes - the Agile processes try not to promote rigid thinking and if applied correctly should be self-correcting or applied in more than just name only (but you would know that if you had read TFA).
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.
Parent
Re: (Score:3, Informative)
usually, at the end of the prototyping phase, management see the product almost marginally working, gets a marketgasm and starts selling it, cutting down the testing and refactoring phase.
with cutting those phases and delivering a rotten product things start to gets awry: the next release cycle, having to be built on bad foundatio
Re: (Score:2)
I see your point, but it's not just a matter of looking at it that way. There have been and are people running around making that exact claim: that XP never produces any bug, in fact it's the only _guaranteed_ way to have a bug-free product. I've occasionally had people throw that exact idiocy at me both in person and here on slashdot. And it's almost invariably based on exactly that redefinition. They can't have a bug, because their whole contract is in the client's automated tests, and the only way to hav
Re: (Score:3, Funny)
list the steps from requirements gathering right through to production deployment.
That would not be agile :-)
Re: (Score:2)
You're missing a stage there where it is reviewed by someone else and accepted or rejected.
I don't understand why more companies don't employee someone to review everyone's patches/commits.
Writers have editors for a reason, so should programmers. Much easier finding the problems on the way in then debugging the problems on the way out.
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.
Parent
Re: (Score:2)
I'd worked that much out before I'd finished the first sentence.