Agile has been a popular software development methodology for some time now. I think Agile methodologies typically work quite well for most projects and see this as a generally good thing. That said, how Agile is implemented makes more of a difference than the simple decision to use it.

Unfortunately, I’ve seen Agile implemented poorly more often than I’ve seen it implemented well. Yes, it is true, like any other methodology you can implement it as you see fit and tailor it to fit your needs. Too often, though, I’ve seen it tailored to meet artificial goals of management, and not the team or the project itself.

The typical implementation I’ve seen is “Oh yes, we would like to release code every 2 weeks and do away with lengthy planning, but we’d also like you to estimate how long a feature will take and commit to that estimate.” Often this accompanies flexibility on the part of management feeling they now have flexibility to add in requirements as they see fit, but deny flexibility as to when features are completed. This puts a lot of stress on developers and ignores the tradeoffs that make it possible to be flexible with requirements, spend less time planning, or releasing often.

The other big problem arises when someone decides “We’ll release a new version of the product every x weeks” and sticks to it regardless of the situation. Why is this bad? It ignores the functional aspect of the application. It is easy to say “yeah, we’ll just release whatever we get done”, but it is pretty tricky to actually DO it - even if those in charge of coming up with a roadmap actually do a good job of breaking up functionality into releasable parts (which is pretty uncommon, in my experience).

Imagine you are adding some features to a piece of the application that has already been completed. What happens if you aren’t able to get that done in time for the arbitrarily designated release date? You can branch that part of the code, but what if it also includes important bug fixes or other functionality that needs to be released? In my experience, successfully doing a selective release is a lot harder than it sounds, and a lot of time is eaten up in the process.

So why does this happen?

It is easy to get higher levels of management excited about the benefits of Agile, and so in a sense, it is an easy sell. Too many people to a poor job of selling the reasons you can attain these benefits. Also, bigger shops tend to like to use nice little charts and Excel spreadsheets to measure performance. I don’t know that Agile lends itself to measuring performance this way.

So what you often end up with is some crazy combination of Waterfall and Agile that I like to call “FRagile”. It is a fragile process that encourages developers to cut corners, develop one-off solutions, and abandon good practices in order to meet unreasonable commitments. Instead of focusing on delivering good software, everyone focuses on hitting their numbers. People end up “cooking the books”, so to speak, so management gets often less meaningful numbers anyway.

What needs to happen?

People need to do a better job of educating management about the true cost of Agile. Management needs to become comfortable with having fewer hard metrics and not being able to micromanage the project.

Also, developers need to be trusted. Most Agile methodologies require trust in developers, and a lot of the Waterfall-type policies I see attached to so-called Agile processes smack of complete distrust of developers.

And mostly, people need to quit passing off some completely bastardized amalgamation of Agile and Waterfall as “Agile”.