I’m going to indulge myself by having a nice old fashioned rant. The topic of choice is “Agile”. A few experiences and conversations of the recent past have compelled me to write something on this topic. So here goes nothing Smile

I’ve recently come across a quite senior person with an obscenely large number of years of experience during which time he has been involved in very large projects (think multi million pound) for very large organisations (think the likes of British Airways). He hasn’t ever worked in an Agile atmosphere. Now there’s nothing wrong in never having worked in an agile manner. However this individual has some very strong opinions about agile. In brief, his view seems to be that agile means “letting groups of people do their own thing and the hoping all of it holds together”. And he is in a role where he spreads his knowledge to many many others. It appears that other people seem to have a similar viewpoint – agile has no discipline or process. It means “winging” it as you go along. It’s about not thinking and just doing. Seriously, where do people get these ideas? I find it quite remarkable that such FUD exists in 2011.

Agile, in many ways, is far more strict than all that CMMI waterfall-y nonsense of years past. Yes, there are many flavours but to say there’s no process to it is ridiculous. Those who practice TDD, CI, Continuous Delivery would all know about the rigour involved. I’ll just take TDD as a sample. If you’re doing strict TDD, you won’t be writing a single line of production code without a failing unit test. Think about the waterfall equivalent. Would you have test plans and “signed off” test cases that would achieve the same level of coverage? Probably not. You would be coding away at your hearts content only for weird errors to be found during the “testing” phase – at which point recovery may already be too difficult as a bunch of other things have been built in the mean time. In this case, who’s doing the “winging” and “hoping” it works.

The more there is a necessity of “hope”, the less agile you are. This is because you would be actively identifying problem points and bringing the pain forward – so that when it comes to deploying, integrating or whatever, you’re already prepared. You won’t have to “hope”. Yes, there’ll always be the unexpected and weird tangential cases. But an agile team will learn from that and cater for it the next time around. And they will do so immediately. They won’t wait for some board to approve some document put together by a non-coding architect who never really understood the problem as he was so far away from it.

Sure there are “agile” teams out there who do a lot of hoping and praying. Are they really agile? Or are they doing some sort of iterative development and calling it agile? Which brings me to the second part of my rant.

There seems to be another group that claim to be agile and think that because of that, there needs to be no planning at all. Even if there’s a train-wreck on the horizon that everybody can see coming, they seem to say “we’ll tackle the problem when we get there”. Just coz your agile doesn’t mean you don’t think? You’ve all got heads, right? Sure, you don’t design everything left right and centre before starting development but you at least need to think about the problems you’re likely to face or the common exceptional situation you need to cover. If you don’t, you’ll be in a constant state of flux, with more and more churn creeping up. And churn is waste. Agile looks to eliminate waste. Hence this is not agile.

Agile doesn’t mean that all you need to do is use a board of sorts and make things up as you go along. It represents a set of practices that can help improve quality, reduce waste and speed up delivery. It is more about adhering to the practices in order to achieve those benefits. If all you’re doing is adhering to the physically visible elements while your codebase is, and will remain, a stinking pile of shite and you have more and more waste coz nobody knows what they’re building then whatever it is – it’s not agile. It’s not about the board or Ninject or MVC or NUnit or SVN or TFS or Git. Focus too long on less important issues and you’ll quickly find yourself spending hours, days and weeks concerned with stuff that doesn’t really matter. It’s like trying to treat a headache induced from brain cancer with paracetamol. Are you focusing on processes and tools more than individuals and interactions? Sure, processes and tools are important but if all you’re interested in are “agile” processes and tools, surely you’ve lost a beat somewhere.

Yes – and I keep hearing this over and over – the agile manifesto says “Responding to Change”. And it’s very important. Detailed plans are seldom followed. But responding to change doesn’t mean blindly building something without thinking. It means being able to respond to change. If you go too fast without any planning at all, don’t stop to improve your design as you go along and keep doing it over and over again in the name of “Agile”, then you will soon find yourself in a monstrous ball of mud, ironically incapable of responding to the slightest change requested. Whether you have a Scrum board, Kanban flow thingy or whatever, and even if you have your daily 15 minutes going on an hour stand up meetings (where some people have the privilege of sitting!) – if you don’t have sustainable pace for the long run, then whatever you are, you’re not agile.

Every time I see people with these two views about agile, my immediate reaction is to say “That’s not Agile. I call that Fragile”.