Should you distrust agile?

Why do some people distrust agile software development? Should you distrust agile software development? How can you possible trust people who say that they will “take your money and deliver something” after a month or so? How can you possible trust people who have a rubber bird as part of their continuous integration process? After my recent post on trust in agile software development, Mike Lehr asked me why people distrust agile software development.

@GregerWikstrand What are the typical reasons for distrusting agile software development, Greger? #agile #software #softwaredevelopment

— Mike Lehr (@MikeLehrOZA) 24 november 2014

Do people distrust agile software development?

To answer Mike’s question of “What are the typical reasons for distrusting agile software development, Greger?” we should first consider, do people distrust agile? For instance, are there people who think agile ruined their lives? Let’s take a look at some of the stakeholders in agile software development. The people who do the work and the people who pay for it.

Do developers distrust agile?

Let’s start with the people who do the work. We could call them developers, testers, software professionals etc. The roles and titles are many and so are the opinions on agile software development. In a poll on Ars Technica, about one-third of the respondents say that they hate Scrum or that they dislike Scrum.

Source: Ars Technica

What is your general opinion on Scrum? 1/3 don’t like it, 1/3 don’t care and 1/3 like it in this poll on Ars Technica.

“I hate scrum. It is a tool to micro manage developers and to kill teams productivity.”

Perhaps it is only lazy developers that hate scrum and agile? Does it mean that you distrust agile if you hate it? I tried searching for “distrust agile” but what I found was not about people who distrusted agile. It was about using a spirit of distrust to improve security and it was about agile teams where the team members distrust each other. Which isn’t a good thing. Teams work better when members trust each other.

Do customers distrust agile?

Many customers have learned to have an attitude of distrust towards software development in general.

But there are other reasons customers could distrust agile software development. For instance, does iterative development and “done” mean that what you see after the first iteration is all you get?

So, maybe people don’t like agile, maybe they hate it. But maybe they don’t distrust agile anymore than they distrust software development in general?

Top reasons why some people distrust agile

A cursory search of the Internet won’t turn up any real evidence that people distrust agile software development. But in my own experience there are many reasons why people do distrust agile. When Mike asked I gave him a little top list.

1. You do it wrong and then you blame the buzzword.
2. Commercial model does not match delivery model => expectations are not met.
3. Many mistake low ceremony for low rigor.
4. They think it’s possible to guarantee on time on scope on budget high quality delivery.

Agile in name only

The first reason for distrust is about using agile as a buzzword but not doing it right. Some call this AINO or “Agile in name only“. If you do it wrong and it doesn’t work but you think you did it right… It’s only natural if you will start distrusting the method.

Misaligned contracts

Another reason for distrusting agile is that the contracts are not aligned to agile. When the contract and the governance mechanisms are misaligned with the actual deliveries and ways-of-working, conflict and distrust can arise.

Low ceremony is not low rigor

As quoted above. Agile really is about micro-management. But unlike normal micro-management it works, because people manage themselves. But agile is not implemented correctly, or if someone does not understand the checks and balances in agile, it might seem like a chaotic and disorganized process. And that is where you can start to distrust agile.

The iron triangle

The iron triangle of project management states that you cannot control scope, cost and quality at the same time. Or add schedule to that and you have the project diamond. As soon as you increase one, you will decrease another. Agile focuses on cost, quality and schedule but allows scope to be variable. That means that you will get something good at a known cost (the team price) at a known date (end of iteration) but you cannot be sure what you actually get. Not knowing what you get is a bit like buying a pig in a poke. And how can you trust that?

Conclusion

While there might be reasons to distrust agile software development there are also reasons to trust it. Knowing why it is sometimes distrusted can help us turn that distrust into trust.

Source: GeminiLaser at DeviantArt | CC BY NC ND 3.0

What does distrust do to us? We need to learn to trust instead.