Whatever happened to Agile? Remember when it was the IT word du jour? The focus of our industry seems to have been shifted to other hip terms and topics: social networking, cloud computing, the browser wars, the mobile OS wars, green IT, slow IT, etc. Anyway, since I started this blog only recently, I’m going to pretend it’s still a hot topic and ramble about it a bit.
Having worked almost all of my professional life for outsourcing firms I’ve seen clients fall in love with the concept of agile, but not be truly prepared to deal with it in one or more ways. More often than not, their projects failed in at least one aspect (budget, timeline, product quality) or simply crashed and burned.
Agile is not a silver bullet. Nor is it the source of all evil. It’s just a methodology, and as such it should be used if the project calls for it. If you had to chop down a tree you would not use a screwdriver, but an axe or a saw. Unless you are Chuck Norris, in which case you would probably just glare at the tree and it would fall of its own will.
The IT world is full of stories of Agile projects gone awry, which leaves all parties wondering if Agility is not a cleverly thought out pyramid scheme. Most of those cases started out with an environment that called for a different approach and people unwilling or unable to detect it.
There are a number of factors that must be weighted in order to decide if a project is agile friendly. I can think of the following:
- Budget constraints: If you are about to undertake a project you could opt for agile if all parties agree upon a flexible budget. Fixed cost projects are not agile friendly. When doing outsourcing your client will love the concept of agility, but he will not always be willing to pay for it. The same applies for the internal client (i.e. the business) if you run the IT department of a company.
- Time constraints: Time boxing + agile = train wreck. Just as with budgets, you cannot set a strict deadline on a grassroots agile project. Instead you can wise your client to the fact that he will be able to progressively converge on the end date, with more visibility than that of traditional approaches, but still, it is pretty much impossible to have a clear view of the end line at moment zero.
- Client culture: The older and bigger the company, the more rooted its methods are, and the more difficult it will be to convince them of changing ways. This cultural inertia will probably make them a poor candidate to adopt agile methods. In these cases gradually introducing some agility will work best than going from dinosaur to gazelle in zero seconds.
- Requirements’ stability: The more volatile the requirements of the project, the more justified is using an agile method. The key is to determine a coherent way of measuring volatility. A note: While the previous elements were potential deal breakers on their own, this one is more of a complementary variable. For instance, if a client has no idea of what he wants but still has a fixed date and money, you should steer clear of agile, whereas if culture, money and budget check ok but he has a great requirements specification, you could still opt for doing the gig in an agile manner.
- Project characteristics: No matter what analogies you might have read… Please do not build a bridge using agile methods.
- Client Participation: The whole point behind agile is having the client steer the wheel so the project can deliver business value fast. The client should participate on a regular basis in stand up meetings, or frequent update sessions; alternatively someone on the team could be empowered to act as his proxy. If none of these occur then you might want to consider other options.
- Business value: Will an iterative incremental approach deliver business value faster? This one might be another complementary decision item. If the answer is yes then agile will probably be a better approach, if the answer is no, then you could go either way depending on the other factors.
You should only use agile methods after conducting a positive health check following the above items and / or other factors you consider relevant in order to make an informed decision. Shush the extremists… don’t let anyone pitch you agility is hip, that it’s a unique and sexy lifestyle, the solution to all problems or a recipe for success. This is only helping accumulate failure cases.
An end note and my personal standpoint regarding this: Traditional development as we know it will slowly fade away. At least some lean concepts should be introduced in all methodologies. For instance traditional artifacts mixed with sprints, using an agile analysis stage followed by traditional development, whatever blend suits you. Agile was born for a reason: our collective failure as an industry to deliver what the client wanted (or a very low success ratio at least). That is something that cannot be ignored.
Shuje
On my next post: Why selling adult diapers at airports would be a huge success. Thoughts or comments on agile experiences? Post below or send them to shuje@holoom.com
My grandpa used to say “as you grow older, you get tired of seeing same things over and over”. Probably agile is experiencing what RUP, Spiral, Staged Delivery, Cascade and every single silver-bulletized methodology/process/SDLC has gone through: people realized Brooks is right when he said “there’s no silver bullet”.
Nevertheless, agile has its own peculiarities. First of all, it is not a methodology (if we stick to the definition of a methodology). It looks more like a set of guidelines and practices (specially for requirements management and software development).
The thing is that these practices have been sold in such a pretty package (not without TONS of literature and expensive training courses) and so many companies have used this “methodology” as a selling argument instead of a management technique to achieve projects’ goals, that it is hard to find an impartial voice. Pretty much what happened to Rational and its version of UP.
Hence, and based on my grandpa’s wiseness, my guess is that same thing will happen again and we’ll have to sit and wait for the next silver bullet.
“The force is strong with this one” the emperor would say. You are right. I do not necessarily agree on the “not a methodology” part though. I believe there are a number of companies that have built full methods out of these guidelines and practices.
And you’re right about actual processes and methodologies based on them. Thing is… companies had to “fill the gaps” agile methodologies left. A methodology (like RUP, for instance) doesn’t leave room for that: it says what, how and who does every single step.
However, you and I maybe (maybe!) agree on that fuzzyness of agile methodologies is part of their charm as you can “build” your stuff around their practices.
I think we all agree that today Agile is fashionable on IT matters and “marketing” and “media” have quite responsibility towards this. Companies always need to sell and new products are most likely to be better sold than old ones.
For what I’ve experienced, it has some remarkable benefits and it adapts quite well to this dynamic world what we live in.
I like to think that these methodologies are not casual and that they are the result of the society who creates them. Past methodologies were most strict and rigid, because societies were more like that. Today everything is dynamic, everything changes faster and Agile is a response for that.
Also agree with my colleague writer that the main reason for why Agile was born is for “…our collective failure as an industry…” but its characteristics are reflections of our globalized culture.
Bottom line is, we shouldn’t either over or under estimate Agile. It’s just one more option we have.
Agree! However, I don’t like to call previous stuff “rigid”. In my experience, a well-tailored RUP can be as suitable and “lightweighted” as any scrum project. Most of the time, “rigid” or “heavy” are words agile evangelists use to understate existing methodologies.
The case is not to get confused with a Project Management methodology, sailing it as a Development Methodology (saw that MANY times). Those are two different things. On another point, a good way to learn about Agile is actually to learn about Classical Project Management. Simple, you cannot think about Agile without being aware on the Classical stuff and how to identify the proper scenery for both methodologies. Great post shuje!