Why Agile Isn't Working: Bringing Common Sense to Agile Principles

Agile promises many things, but the reality in the field is often very far from the expectations. Is it agile we need--or an agile way of thinking?

By Lajos Moczar
Tue, June 04, 2013

CIO — Much of agile's success is due to the fact that it "sells" so well by promising solutions to perennial IT concerns: projects that run over budget and time, lack of team effectiveness, lack of true collaboration, poor product quality and dissatisfied customers.

I've been involved in a number of agile projects from all perspectives, as a team member, leader architect and overall responsible manager. I've concluded that agile has not only failed like other fad methodologies before it but, in fact, is making things worse in IT. Yes, there are certain occasions when agile does work, particularly for proof of concept (POC) work involving already well-integrated teams, but I'm talking about 80 percent of projects here.

3 Ways the Agile Methodology Is Flawed

The agile methodology produces the opposite of the promised effects. There are many reasons for this, but I'll focus on are the three most destructive agile principles, which I've renamed (shown in bold below).

The first, delivery over quality recasts the agile principle of "early and continuous delivery of valuable software." Yes, early visibility is an important tool for customer collaboration. What is dangerous, though, is that focusing on continuous delivery has the effect of creating an unmanageable defect backlog while developers work to put something in front of the customer.

Counterpoints: Who Says Agile Development Can't Be Faster? and 3 Ways to Be More Agile With Software Shipping Decisions

In most agile projects I've been involved with, the defect list has grown faster than it can be dealt with. On one medium-sized project, a huge defect backlog had developed over the previous 18 months and required a full-time role just to manage it. We routinely needed groups of iterations devoted solely to trying to clear the backlog. Not only did that come at the expense of new features, but it naturally introduced new defects—which were just thrown back onto the same endless pile of things to be fixed.

Obviously, large defect backlogs are nothing new in projects, but what is new is that agile promotes the practice of ignoring defects. This leads to unmanageable backlogs and, eventually, to ineffective development. I've watched developers, initially caught up in the excitement of collaboration euphoria, end up psychologically worn down by the perpetual defect list to the point of burnout. Agile projects are responsible for burning out many a good developer, which is far from the agile promise that projects "should be able to maintain a constant pace indefinitely."

The second flaw, development over planning, hits the agile principle of "responding to change over following a plan." In theory, developers code while collaborating with stakeholders to define, refine and change requirements as the projects goes along. The methodology, however, does not distinguish between big and small changes.

Continue Reading

Our Commenting Policies