Friday Philosophy – Why doesn’t Agile work? September 16, 2011

I’m going say right here at the start that I like much of what is in Agile, for many, many years I’ve used aspects of Rapid Application Development {which Agile seems to have borrowed extensively from} to great success. However, after my post last week on database design, many of the comments were quite negative about Agile – and I had not even mentioned it in my post!

To nail my flag to the post though, I have not seen an Agile-managed project yet that gave me confidence that Agile itself was really helping to produce a better product, a product more quickly and most certainly not a final system that was going to be easy to maintain. Bring up the topic of Agile with other experienced IT people and I would estimate 90% of the feedback is negative.

That last point about ongoing maintenance of the system is the killer one for me. On the last few projects I have been on where the culture was Agile-fixated I just constantly had this little voice in my head going:

“How is anyone going to know why you did that in six months? You’ve just bolted that onto the side of the design like a kludge and it really is a kludge. When you just said in the standup meeting that we will address that issue ‘later’, is that the same “later” that accounts for the other half-dozen issues that seem to have been forgotten?”.

From what I can determine after the fact, that voice turns out to be reason screaming out against insanity. A major reason Agile fails is that it is implemented in a way that has no consideration for post-implementation.

Agile, as it is often implemented, is all about a headlong rush to get the job done super-quick. Ignore all distractions, work harder, be completely focused and be smarter. It really does seem to be the attitude by those who impose Agile that by being Agile your staff will magically come up with more innovative solutions and will adapt to any change in requirements just because they work under an agile methodology. Go Agile, increase their IQ by 10 points and their work capacity by 25%. Well, it doesn’t work like that. Some people can in fact think on their feet and pull solutions out of thin air, but they can do that irrespective of the methodology. People who are more completer-finishers, who need a while to change direction but boy do they produce good stuff, have you just demoralized and hamstrung them?Agile does not suit the way all people work and to succeed those people it does not suit need to be considered.

The other thing that seems to be a constant theme under Agile is utterly knackered {sorry, UK slang, knackered means tired, worn out and a bit broken} staff. Every scrum is a mad panic to shove it all out of the door and people stop doing other things to cope. Like helping outside the group or keeping an eye on that dodgy process they just adopted as it needed doing. Agile fails when it is used to beat up team. Also, I believe Agile fails when those ‘distractions’ are ignored by everyone and work that does not fall neatly into a scrum is not done.

I suppose it does not help that my role has usually been one that is more Production Support than development and Agile is incompatible with production support. Take the idea of the scrum, where you have x days to analyse, plan, design, unit test and integrate the 6 things you will do in this round. On average I only spend 50% of my time dealing with urgent production issues, so I get allocated several tasks. Guess what, if I end up spending 75% of my time that week on urgent production issues, and urgent production issues have to take priority, I can screw up the scrum all on my own. No, I can’t pass my tasks onto others in the team as (a) they are all fully assigned to their tasks and (b) passing over a task takes extra time. Agile fails when it is used for the wrong teams and work type.

I’ve come to the conclusion that on most projects Agile has some beneficial impact in getting tasks done, as it forces people to justify what they have done each and every day, encourages communication and gives the developers a reason to ignore anything else that could be distracting them as it is not in the scrum. Probably any methodology would help with all of that.

My final issue with Agile is the idiot fanatics. At one customer site I spent a while at, they had an Agile Coach come around to help the team to become more agile. I thought this was a little odd as this team was actually doing a reasonable job with Agile, they had increased productivity and had managed to avoid the worst of the potential negative impacts. This man came along and patronisingly told us we were doing OK, but it was hard for us to raise our game like this, we just needed help to see the core values of Agile and, once we did, once we really believed in it, productivity would go up 500% {That is a direct quote, he actually said “productivity will go up by 500%”}. He was sparkly-eyed and animated and full of the granite confidence of the seriously self-deluded. I think he managed to put back the benefits of Agile by 50%, such was the level of “inspiration” he gave us. Agile fails when it is implemented like a religion. It’s just a methodolgy guys.

I find it all quite depressing as I strongly suspect that, if you had a good team in a positive environment, doing a focused job, Agile could reap great rewards. I’m assured by some of my friends that this is the case. {update – it took my good friend Mike less than an hour to chime in with a comment. I think I hit a nerve}.

Like this:

Related

Everytime I see an “agile is pants” reference my blood boils, I get the same reaction to the similar often heard comment of “we’ve got Oracle but its very slow”.

I spent 2 years working on several projects that were delivered following an agile approach and in all cases they delivered something that the usual in-house waterfall approach would have failed to do, either due to time, costs, risks etc

At the same time however I have seen several agile projects fail miserably because either the team , the stakeholders or management just didn’t ‘get’ agile.

Once you ‘get’ agile and understand the benefits then you are sold on the approach and wonder why you’d work any other way but on the downside you need to make sure everyone is aware of the ramifications and requirements.

I’ve also come in to contact with the agile ‘fanatics’ who as you say do see it as something akin to a religion with almost utopian potential but that’s a conversation for another day.

The problems you highlight are down to a number of problems associated with ownership, resourcing and skills, all of which would and do occur in a more usual waterfal environment, a bad agile project is as you point out one that just bodges something.

I’ll start writing my “Why agile is brilliant but doesnt work” book over the weekend or alternatively post something lengthier here, I may even finally start my blog with an agile article.

I know that the Agile practices I describe in my paper have immensely improved my company’s productivity and work quality (and my personal productivity and work quality as well). Generally, when I drill into the “Agile doesn’t work” conversations with people, what I find out is people aren’t talking about a disciplined Agile approach at all; they’re just misappropriating the term “agile” as a synonym for “sloppy.” I’m in sincere agreement that sloppy doesn’t work.

I’m going to do a quick reply before I have read your case (I’m downloading it as I type). I predict that the reason Agile works for you is two-fold. No, three fold.:
– You control your work environment and it is a logical and well structured environment. {You came up with Method R and you came up with Oracle Flexible Architecture, you understand structure}.
– Intelligence is used in how you implement Agile. You use the bits that work for your situation and you understand what needs to come along with Agile to make it all work.
– Your staff are significantly better than average.

Implicit in my prediction are core reasons why I think Agiile fails in many other situations. I think it is undeniable that Agile fails in more situations where it is used than it works. Now in some of those situations, nothing would work – the organisation is fundamentally flawed, they are looking to Agile to magically solve more cronic issues and it simply won’t. In other situations, I think Agile is put into place on top of a currently weak development effort and without considering how you still get the best out of your staff, even those for whom Agile is not natural. You have three choices in that situation.
– Start off with staff who have the inate ability to cope with Agile
– Sacrifice the staff that don’t fit
– Soften Agile for those staff or re-use them outside of Agile.
As I say in my original post, there are some people who produce brilliant stuff, but only in stable and controlled environments. Others thrive on challenge and chaos. You will get a lot, lot more out of the former staff in the much derided waterfall methodology.

By preference I like to work with a Rapid Evolutionary Development methodology, which is a lot closer to Agile than Waterfall, but in the real world I see Agile just not delivering and it bugs the hell out of me.

Key issue for you and I’ve seen it, is that some organisations use agile to just hack and coble as a means to bypass overly bureaucractic processes, this is not agile, this is just hacking.

In these cases someone is just paying lip service to agile, there are no excuses for any less focus on quality, testing, design etc than you would expect on any other project, I’ve probably experienced more testing on agile projects than under any other methodology.

We both have experience of RED working but I distincly remember other teams that just didnt get it, agile is no different.

Haven’t read Cary’s post but in my experience we had a collocated team of core dedicated (little if any demands from elsewhere) with multi skills, opne minds and working in as transparent a way as possible.

My parallel for this is coming across people who tell me and I hear this far too often ‘Oracle is slow’ when what they mean is that they haven’t been able to design a suitable solution, they havent collected stats, haven’t created the necessary indexes etc but its much easier for them to blame Oracle instead.

Hope this Friday’s topic is good, last few have been very though provoking.

You are spot on, one of the issues is the avoidance of bureaucracy. It is not the only one though. You really should download Cary’s paper, you will see that you both share a lot of thoughts and opinions. And yes, RED is something I want to bring up in the follow-up post I’ve been struggling to write all evening! My fundamental aim is, knowing Agile (RED, XP) can work, what causes it to not and how fixable is that.

I’m not sure what this Friday’s Philosophy will be, I think maybe I ought to try a different general area of discussion. And boy do I need to get back to those technical posts on IOTs.

“Once you ‘get’ agile and understand the benefits then you are sold on the approach and wonder why you’d work any other way”. This is the attitude that boils my blood. I was working with several people who had this “Agile is always right” fervour and they screamed blue murder if anyone dared criticise the religion.

If your project has a fixed deadline and a fixed requirement/scope, it is NOT agile. This is often the case when complying with some government or similar regulation. It is also the case for most projects where funding is agreed based on the promise of a deliverable. You may benefit from using tools like SCRUM and sprints, but it doesn’t fit the ‘prime directive’ of Agile.

If you need long term planning, eg to get the input of particular resources who aren’t readily available or are expensive, you need an approach that includes long term plans. Business specialists, testing environments…

Agile CAN work. Waterfall CAN work. Some projects can be delivered with either, some projects will only work under one approach.