This article about agile development is filled with very revealing contradictions.
The people quoted in this article, both with an obviously strong vested interest in agile techniques, are trying to convey the idea that agile practices give users the utmost priority, and that work will not stop until users are 100% happy:
Then the developers can go back and refine their work, repeating the process several times until the users are satisfied.
However, the rest of the article shows that users are, in effect, given very little part in the overall process. Here are a few quotes that made me pause:
It’s not important to deliver on time but to deliver something that works
This is an observation that’s hard to reconcile with the idea that you are working to make your users happy. In my experience, nothing makes users happier than delivering on time. And if development reaches a point where the initial deadlines are suddenly put in question, the best way to solve this problem is to ask the users: “We can ship on time, but then we’ll need to cut feature A. What would you like us to do?”.
Another interesting quote is:
While Ford agreed that it’s critical to deliver software that meets users’ needs, he acknowledged that it’s important to be able to predict when a project will be completed. But developers, business analysts and project managers need to work together on this.
Do you notice anything in the last sentence above? The users are nowhere in the picture. They are not part of the loop. This leaves us with a disturbing impression that developers, business analysts and project managers know better what needs to be done and that they will let the users know once they’ve made a decision. This sounds dangerously like Waterfall, which is exactly what we were trying to avoid in the first place.
The article continues with more startling claims, such as:
It’s a bad idea to ask developers how long it’s going to take to do something because it always varies. Every project has different characteristics
Do you know the difference between a good developer and a bad developer? A good developer can give you an estimate of the time needed to complete a task. And the better that developer is, the more accurate their estimate will be. If I ask a developer “How long is it going to take to do this?” and he answers with “It’s very complicated”, I want him off my team.
To determine the length of a project, the project manager gives the user stories to the developers to decide such things as the programming language that will be used, the architecture and the framework. After that, they sit with the business analyst and go over the story cards and rate their complexity on a scale of one to eight.
This part reminds me of a scene in Dead Poets Society, where Robin Williams asks his students to look at a page in their poetry book that is trying to rate poetry on X and Y axes. Williams then tells his students to rip that page because poetry is not about metrics or scales, it’s about art and using one’s expertise and talents to reach a goal.
And the more I think about it, the more this process with cards and business analysts assessing the load of work reminds me of Waterfall. The developer’s know-how and expertise accumulated over the years is thrown out of the window and replaced with vague numbers and concepts that not even the most hardcore agilists agree on.
We don’t need agile consultants and book authors to sell us vague and unproven metrics along with rigid guidelines that your team must embrace without any questions. We need to hear from people who defend agile practices and yet have no financial interest in them. We need good and experienced developers to be recognized as true experts about what constitues good software products and sound engineering practices.
The world has already moved on to something called “agile”. Very few people agree on what it is exactly, but they all accept the fact that it means “not Waterfall”. We don’t need to be convinced of the idea that Waterfall development does not work very well, and that it’s much better to engage in a continuous dialogue with your users to make sure that the right tasks are being performed in timelines that everybody agrees on.
A lot of people are snickering at the kind of agile rhetoric shown in the article I quoted, because while such logorrhea makes for an entertaining read, the last thing we need is being patronized by snake oil salesmen trying to sell us something we already know.
Until agile evangelists catch up and become truly agile, we’ll just keep developing our software with our own, agile ways.