Top 5 Reasons Agile Project Management Should Never Be Used

Agile DevelopmentThe Agile project management style has taken the coding world by storm for every reason, it seems, except for the wishes of the people actually doing the coding. This method of project management places accountability on talented software developers to a burdensome degree, harnessing them to the fickle whims of clients and management teams that do not know or care about how software is actually built.

Agile’s spreading adoption has not only contributed to flattening the career prospects of software engineers and developers, it has inserted a malignant attitude towards the creative problem-solving side of software development that halts the evolution of the field in general.

Read last week’s blog on “4 Reasons Why You Should Use Agile IT”

These allegations may seem hyperbolic, even misguided, but consider these 5 reasons why Agile project management is a terrible idea:

  1. It Rewards Bad Client Behavior

Agile was originally created as a response to clients who exhibited bad behavior. They would change their project requirements, request constant updates when there weren’t any to show and often welch on contracts after the final product was delivered because it somehow wasn’t up to snuff.

Rather than trying to communicate with clients and help them understand the software development process in more detail, consultancy owners threw up their arms and decided to put on a monthly puppet show for their clients so they could see what was happening. These short-cycle iterations took more effort to assemble than it would require to simply move forward on the project at a logical pace and solve surface-level problems like UI once a decent framework was assembled.

Yet, the puppet shows continue, and they encourage the client to pitch a fit just to get more attention and feel in control. They feel like they are getting more value out of their contract if every whim is heeded, after all.

  1. Senior Developers Get Condescended Too

Checking in should be a process of updating code changes that are helpful to the team or letting them have a grasp on version progress. Instead, developers are being forced to check in “User Stories” just to prove that they still understand what they are programming and what it should do.

This type of practice is perfect for developers who are inexperienced or often fall off task, but for those who should by all rights be able to work more autonomously, this process is demeaning and counterproductive. To paraphrase Erik Meijer’s colorful rant, if you aren’t checking in code, what are you doing?

  1. Daily Stand-Up Meetings Are More Often Than Not a Waste of Time

Is there even any need to elaborate on this? Teams should have a time and a place for delivering input, suggestions or having a productivity “pep talk,” but if they are being forced to meet when there’s really nothing to say, then their time could obviously be better spent coding.

  1. Having a Stable, Early Build Is Not a Measure of Future Success

The biggest problem with User Stories and delivering iterations is that they are a song and dance for clients that actually reveal little about project progress or how usable the end product will be when faced with long-term use.

Many times, a project that looks unsightly to the untrained eye could be like a giant domino setup, where every element needs to be in place before it all comes together. Yes, it could also fall off the rails without tight supervision, but any programmer worth their salt can fool someone into thinking that they are making real progress when it is all superficial. In the meantime, their technical debt swells to monstrous sizes and promises added backend work when the project appeared to be nearly complete.

  1. Agile Project Management’s Marketing Dogma Presents a False Dichotomy

How often have you heard, “Well, it’s better than Waterfall project management!”? This statement implies that developers never have autonomy, so they might as well suffer under Agile as opposed to more authoritarian systems.

…Except these aren’t the only two choices. Dev teams can collaborate with clients and make suggestions, not simply heed their every client whim when they often do not even have clear ideas of what they want.

The bottom line is that Agile purports to solve problems that are not inevitable while creating plenty of its own. Its methodologies resemble a team in crisis mode, but as Michael O. Church puts it, “Agile has no exit strategy.”

Give your dev team the respect they deserve and free them from drinking the Agile marketing Kool-Aid by allowing them to work under a process that sounds good to them, not just marketing gurus who spin drek into gold for a living.

So what’s your stance on Agile IT? Let us know in the comments below, and feel free to shoot us an email if you have lots to contribute on the subject.

Request a live demo

Need help choosing the right business intelligence solution? Izenda’s solutions experts can help.

Follow Izenda on social media for the latest on technology and business intelligence:

Leave a Reply