Why Agile Isn’t Working: 3 Fundamental Flaws of Agile

You have adopted the agile methodology but your projects are still over budget and behind the schedule, leaving the team frustrated and unmotivated. The problem is that agile promises many things – scope flexibility, increased value, visibility, adaptability, collaboration… you name it – but is the reality far from the expectations?

You may blame it all on the management style, but what if this is not the problem? What if the problem is in agile? Can it be making things even worse?   

3 Fundamental Flaws of Agile

Unfortunately, the agile methodology often produces results that are completely opposite to the promised benefits. Here are three most destructive agile flaws that every company should be aware of.

Flaw No.1: Quick delivery over quality

One of the agile principles stands for “early and continuous delivery of valuable software.” No doubt, continuous delivery is important for feedback and collaboration between the customer and the team. But focusing on continuous delivery has an adverse effect: developers work without a break just to put something in front of the customer.

The problem with continuous delivery is that the list of defects grows faster than it can be dealt with. As a result, you have a huge defect backlog, and the team has to spend several iterations just to clear it up. And it’s done at the expense of new features.

You get stuck in a vicious cycle when more defects are introduced, backlogs become unmanageable, the team burns out and development becomes ineffective.

Flaw No.2: Development over planning

Another agile principle – “Responding to change over following a plan” – often plays a low-down trick. In theory, developers collaborate with stakeholder and change requirements as the project goes along. But what happens in reality?

Every change – no matter how small or big – has a cost. The problem is that stakeholders often ask to make really big changes late in the project because they believe the agile team can handle it all. But the only way you can handle this is by adding iterations. And here we go in a circle again… The code base is constantly changing, and it becomes harder to fix defects.

The team and the customer become frustrated, the quality and the delivery expectations aren’t met. In this situation, the traditional approach with well-defined requirements and a formal change management process works much more effectively.

Flaw No.3: Collaboration over management

Creating self-organising teams and empowering individuals is definitely a huge plus. The problem is that it doesn’t always come along with responsibility. So when you replace an accountable project manager with captivating (but naive!) myth of self-organisation, it doesn’t often work as expected.

Neither self-organization nor command-control is appropriate for an effective software team. What you need is a balance between directing and delegating. In other words, the key to success is an appropriate level of direction coupled with suitable delegation and trust. The team is satisfied because they are guided in the direction of success but also trusted to make their own choices.

Turning Flaws into Benefits

• Prioritisation: Remember, the goal is to deliver a quality product on time and to budget – so there are always some elements that have to be sacrificed to fulfil the needs of the others.
• Pragmatism: Don’t ever attempted to solve real problems with an abstract approach. Nobody needs a marvellous abstraction that doesn’t work.
• Dynamism: Dynamism is about the ability to change strategies when the current one isn’t working. It doesn’t necessarily have to be agile. Every team is a unique combo of people, personalities and skills. And what works for one team may be a total disaster for another. Experiment and try different approaches that will let you deliver better products.