When Agile Projects Go Bad

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.

No way!

You mean when a good idea is elevated to an inflexible ideology, it can become a bad idea? This has never, ever happened before. :)

SHOCKA

Bad management leads to bad results, no matter the methodology.

Extremist Programming

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:

Fair enough. I just don't defend the tried and broken ones, like many do.

Re:

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?

Late

Re:

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:

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

Uhm...

Alistair who ??

Re:

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 :)

Kent Brock - s/ro/e - Kent Beck

Hello, McFly! It's Kent Beck, not Brock.

Re:

Meh, it's Clark Kent, you insensitive clod!

Name misspelled

That should be "Kent Beck" in the summary, not "Brock".

Cockburn?

Cockburn has seen this in action.

I have personally experienced cockburn and assure you will become "become inflexible and intolerant".

Buzzword Boredom

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:

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:

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 "

Out of context

Cockburn has seen this in action.

Did anyone else giggle like an 8th grader when they read this?

Lots of ragging on Agile here

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:

no, i think agile programming is what everyone does by default when there is no thought about what one is doing or why

Re:

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

Re:

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.

All development processes have cult following

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

There isn't one of them that doesn't have individuals that follow the processes blindly.

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 t

Re:

list the steps from requirements gathering right through to production deployment.

That would not be agile :-)

You guys were using Scrum the wrong way

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.