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.

Comments

No way!

[Anonymous Coward]

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

[kevination]

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

Re:SHOCKA

[Nelson]

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.

Name misspelled

[mdm42]

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

Project steps

[Anonymous Coward]

I constantly see so many adhoc dev teams operate with almost no formal processes and I would be very interested to see a basic list of steps that you perform to manage your project from the start to production deployment.

At the moment the most common methods for small teams seems to be the following

    - Customer asks for a change to some software, website etc
    - Programmer may do basic class designs
    - Progrmmer codes the changes
    - Pushed into staging envrionment
    - Customer gives ok
    - Pushed into production

I would be very keen to hear from people who have very clean, clear well defined processes to list the steps from requirements gathering right through to production deployment.

Buzzword Boredom

[Anonymous Coward]

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:Buzzword Boredom

[famebait]

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:Extremist Programming

[Anonymous Coward]

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:Lots of ragging on Agile here

[RobinH]

Whenever I've used agile with the right people, it was a breeze getting the job done.

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

Agile as a defense mechanism

[Jahf]

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 willing to give a little to get a LOT (they wanted projects to miraculously start to "just work" as one put it) but wanted to have the process be open. Development wanted ANYTHING to shelter them from the hell they had been going through.

Both parties were going into Agile for the wrong reasons. They both thought they were the right reasons.

By the time I got fed up and left we had everyone calling our process "Agile" because we did scrum meetings, but all the processes behind the scenes had reverted back to waterfall at the core. And when I would tell management -or- development that they were doing things for the wrong reason. I tried to avoid saying "you don't understand Agile" so that I wouldn't get defense mechanisms raised and funny part was the more I avoided using that phrase the more they would toss it back in my face (both sides). We had multiple meetings, even bringing in outside consultants, and the meetings always ended with them agreeing to the points brought up but then a week or a month later caving back to their old ways (this was a shop that was VERY entrenched in old ways, having done web services for financial companies for well over a decade).

The point here being ... it isn't always just management that doesn't "get" Agile. Sometimes the devs don't "get" it either (and very often the middle group of PMs has plenty of "wtf" left as well). Agile isn't a defense mechanism that allows you to block people from giving you work or to let you work on only the things you find interesting. And if -neither- side wants to be Agile for the right reasons it will fail hard and fast.

PS. Me? I went back to being a Sales Engineer / Field PM for companies in other timezones ... however the company I went to DOES do Agile and does it WELL. My scrum master time left me with a bad taste for ever doing it again and I will -never- try to lead a transition to Agile, but it was nice to see my opinions on processes and reasons work. I had convinced myself when I left the scrum master gig that -I- didn't "get" Agile ... but I did ... the company just did not -want- the changes required. Only the benefits.

Re:You guys were using Scrum the wrong way

[winomonkey]

I love it when a person uses their own non-standard definition of a word to tell everyone else that they are wrong and have quite simply missed the point. While qbertino is quite right to say that there is a stand-up meeting portion of scrum (frequently called a "daily scrum"), it is not the entirety of the scrum process. A quick look to wikipedia shows that perhaps there is a better definition out there than qbert believes.

Our team uses some of the artifacts of scrum - the daily meetings, burndowns, backlogs, but we fall into the "scrum in name and not in spirit" category of many others. The team has a tendency to push back against any definition and any documentation. Cowboyisms overpower agile engineering practices a little too often, which is a dangerous thing.

I am also curious what company you work for ... I know a lot of "technology driven companies" that let the tech of the day drive their agenda, which is not always where your customers want to be. It is always good to find a company out there that can live an agile life while playing with the latest and greatest technology AND be top of their market segment.

Bottom line;
What has worked for you and your team does not always work for all other teams, nor does it mean that you get to redefine the definition of scrum for all other folks out there. That is the big problem - people making grand and dogmatic statements about how things work or do not work. Finding something that works for you is more important than finding something that works for somebody else.