These days if you are not Agile you must hide yourself, maybe in a church. When there, you may find people who have pity of you and grant you asylum despite the right having been abolished in 1623.
Before Agile, software projects were failing at the same rate projects meant to build skyscrapers would fail if you insisted to do them only during an earthquake.
Software projects are still jumping in droves off the seaside cliff of impossible deadlines like herds of lemmings. It's because Agile is misunderstood and misused.
I will lead you in a tour through the dump of Agile junk.
But first let's see what two problems Agile wanted to solve and would solve it wasn't for the junk.
Recently we have celebrated 50 years of Man on the Moon.
We got a well-earned pause from work watching Google's doodle recall the entire leisurely stroll the astronauts took from Cape Canaveral to the Sea of Tranquillity and back.
Some of us may have watched the historic video in which Neil Armstrong steps on the moon.
When mission control talks to the astronauts, we notice — if we know in advance — that there are pauses.
It's because signals carrying voices take 2.5 seconds to fly to the Moon and back.
We are talking about going to Mars. When you send a message to Mars, it takes 4 to 24 minutes to get there. The reply takes as much. It makes for a quite frustrating conversation.
Now imagine having a chat with the crew of a spaceship travelling so far from Earth that it takes six months to get an answer.
Before Agile, when you wanted an application built, you did the analysis, you produced a massive book containing it, you gave it to a development team and they disappeared for, say, six months.
After that time they were back with your application.
You discovered that they had understood that they had to build a town. They built it. When they showed it to you, you realised that it wasn't a town you needed, it was a national park.
Six months to waste and now you don't have any money left to restart from scratch.
Unfortunately you were unable to realise that you needed a national park before having seen the town. You had to see it to grasp that it wasn't what you needed.
To imagine something is different from actually seeing it.
People working in manufacturing factories may do a repetitive job. It may be soul-crashing. C.G. Jung may have warned us long ago that human beings can't stand this in the long run.
But nobody can deny that the predictability of factories is why we now enjoy a lot of useful gadgets like the computer I'm now using to write this article.
IBM wanted to create the Factory of Software. They wanted to make software in a factory using the same principles and management practices factories use to make flat-pack furniture.
It would have been wonderful to have a perfectly predictable system to produce software.
You had just to figure out a production metric and then speed up operations to increase productivity.
But software is not flat-pack furniture. When a worker sets out to make furniture, she knows exactly what she is producing, how long it will take and how to deal with any problem.
Software development is not as predictable as manufacturing.
When a worker starts making a piece of flat-pack furniture, he puts some parts together and, at the end of the working day, he leaves the half-finished furniture for the next day. He knows that he is 50% done and the next day he will bring this partial job to its full completion.
When creating an application, a developer starts to write a piece of code and, when she goes home after a day work, she doesn't know if her half-baked piece of code will disappear the next day. It might get to 99% completion and then she might have to scrap it because it couldn't possibly ever work, or she realises that it wasn't what she needed to do.
In software there is no 50% task completion. Either it's 100% or it's zero. The development team can celebrate a task's completion and add it to the heap of completed tasks only if the code works and it's fully tested.
This is not crazy. It's how software development works.
That we are able to figure out in advance what to build is a pipe dream. We don't know what we need to create, the client doesn't know either and we will discover it little by little as we go.
When software development is forced to be predictable, developers churn out applications the client doesn't use because they aren't doing what he needs. Developers may even produce code that has to be completely rewritten because it's of too poor quality.
To fix the Moon effect you need a lot of communication. You have to create an environment where quality and quantity of communication are much more important than knowing when things will be done.
On the one hand you work to make communication more fluid and healthy. On the other you are busy removing obstacles that would hinder communication, one of them being deadlines.
I want to stress the fact that it's not enough to have a lot more communication. The latter has to be two-ways and good quality.
Imagine a client telling developers what she wants, developers producing it and the client playing with it and giving feedback. It may sound good, but it isn't because it's one-way communication. Developers need to ask questions for communication to be two-way.
Another problem happens when the client talks a lot and is willing to answer questions, but he is hostile.
Agile communication is based on trust and cooperation. When these two ingredients are missing, the project is no longer Agile and the probability that it will fail bubbles up.
To deal with projects being unpredictable, Agile lifted the pretence of predictability saving a lot of projects from certain doom.
In the Agile manifesto you find nothing about deadlines.
Agile is not concerned about producing code faster and faster. Rather it focuses on figuring out the right thing to do.
In most cases Agile is badly implemented. Communication is insufficient or unhealthy. A lot of obstacles damage it and there still is strong obsession with time constraints and no mitigation of the risk they pose.
What is agile junk?
It's many ways Agile is implemented that actually make Agile ineffective or even counter-productive.
Allow me to fanfare through them without further ado.
You hire an Agile guru and he tells you that you are supposed to define sprints. They are two-weeks periods of time in which your developers swear they will build a certain list of features. They will code three-four of them out of the heap of features they are supposed to implement along the entire project.
Bonus points if they manage to cram more features in a sprint.
Agile is all about letting go of the predictability constraint that derailed so many projects in the past, and here it is, still at work and more alive than ever.
In the Agile Manifesto there is no concern about predictability. Agile wants you to communicate. Developers build working code first of all because they want to use it as a conversation starter.
Agile gurus discovered that it was much easier to figure out what to do if client and developers could actually use the application, at least part of it.
Do define sprints. They should implement some part of the application that seems to arouse the most questions and doubts. You want to deal first with whatever the application does that is more uncertain.
The team should not obsess on how long it will take to complete a sprint and sprints shouldn't have a fixed duration.
For the project to succeed you have to drop any pretence of predictability and plan for significant variations in the release dates.
If you need to speed things up, drop features that are not essential.
Agile is not interested in productivity metrics.
Don't force your team to burn their brainpower on what is irrelevant, let them concentrate on making communication more fruitful. It's where you really save time.
Don't play poker at work, please.
(...)
(full article: How Agile Junk Will Mess up Your Software Project)