A friend of mine sent me a link to this article in Inc. magazine by Adam Fridman: The Massive Downside of Agile Software Development. Since I’ve been doing Agile software development now for twelve or thirteen years, I was eager to learn about this massive downside.
Here’s what he has to say, in five points.
1. Less predictability.
For some software deliverables, developers cannot quantify the full extent of required efforts. This is especially true in the beginning of the development life cycle on larger products. Teams new to the agile methodology fear these unknowns. This fear drives frustration, poor practices, and often poor decisions. The more regimented, waterfall process makes it easy to quantify the effort, time, and cost of delivering the final product.
For all software deliverables, developers cannot quantify the full extent of required efforts. This is because every time a developer builds something, it’s the first time he’s ever built it. (If it weren’t the first time, he’d just use what he built the first time instead of doing it over.) If he is very experienced with similar things, he might have an idea how long it will take him; but he’ll still run into unfamiliar issues that will require unanticipated effort.
What the more regimented, waterfall process makes it easy to do is lie about the effort, time, and cost of delivering the final product, and maintain the illusion until nearly the end of the project, which is where all the make-or-break emergencies are. Anyone who estimates that a software project will reach a specified scope in eighteen months is just making stuff up, whether he realizes it or not. Heck, the team I just rolled off made capacity estimates every two weeks for almost a year, and hit it right on the nose only once. And that time it was probably accidental.
If a collection of actual boots-in-the-trenches developers in the middle of a project can’t give accurate estimates for two weeks in the future, then a project manager isn’t going to be able to give accurate estimates for eighteen months in the future before anybody really knows what the project will involve.
However, we were able to give data–real historical data about the past, not blithe fantasies about the future–on those discrepancies to our product owners every two weeks. Agile teams are no more able to make long-range predictions than waterfall teams are: but at least they’re honest about it.
2. More time and commitment.
Testers, customers, and developers must constantly interact with each other. This involves numerous face-to-face conversations, as they are the best form of communication. All involved in the project must have close cooperation. Daily users need to be available for prompt testing and sign off on each phase so developers can mark it off as complete before moving on to the next feature. This might ensure the product meets user expectations, but is onerous and time-consuming. This demands more time and energy of everyone involved.
3. Greater demands on developers and clients.
These principles require close collaboration and extensive user involvement. Though it is an engaging and rewarding system, it demands a big commitment for the entirety of the project to ensure success. Clients must go through training to aid in product development. Any lack of client participation will impact software quality and success. It also reflects poorly on the development company.
I think these are both good points. You should only expend real effort on software projects you want to succeed. The ones you don’t care about, you shouldn’t waste the testers’ or customers’ time on.
Or the developers’, either.
4. Lack of necessary documentation.
Because requirements for software are clarified just in time for development, documentation is less detailed. This means that when new members join the team, they do not know the details about certain features or how they need to perform. This creates misunderstandings and difficulties.
Have you ever been a new member joining a development team? Me too. Have you been a new member joining a development team that has its codebase documented? Me too. Have you ever gotten any information out of that documentation that you were confident enough in to use without having to ask somebody else on the team whether it was obsolete or not? Me either.
Comprehensively documenting an emerging system on paper is a losing proposition that turns into a money pit and a useless effort. Comprehensively documenting a nonexistent system on paper is even worse.
You know what kind of documentation of an emerging system isn’t useless? Properly written automated tests, that’s what kind. First, they’re written not in prose that has to be translated in an error-prone operation to technical concepts in the reader’s head, but in the same code that’s used to represent those technical concepts in the codebase the reader will be dealing with. Second, they’re always up to date, never obsolete: they have to be, or they’ll fail.
And if you want new members to come up to speed quickly, don’t give them technical documentation–even clearly written, up-to-the-minute technical documentation. Instead, pair them with experienced team members who will let them drive. That’s the fastest way for them to learn what’s going on: much, much faster than reading technical documentation–or even automated tests, for that matter.
Can’t spare the time to pair? Deadline too close? Need everyone on his own computer to improve velocity? Well, first, you don’t understand pairing; but that’s a separate issue. Here’s the point: your new guy is going to be pestering your old guys one way or another, whether he’s trying to find out which parts of the technical docs are obsolete or whether he’s officially pairing with them. Pairing is much faster.
5. Project easily falls off track.
This method requires very little planning to get started, and assumes the consumer’s needs are ever changing. With so little to go on, you can see how this could limit the agile model. Then, if a consumer’s feedback or communications are not clear, a developer might focus on the wrong areas of development. It also has the potential for scope creep, and an ever-changing product becomes an ever-lasting one.
Is the implication here that the waterfall model handles this situation better?
In a properly-run Agile project, there is no predetermined track to fall off. The project goes where the customers take it, and the most valuable work is always done first. If the communications are not clear, the discrepancy shows up immediately and is instantly corrected. There is no scope creep in an Agile project, by definition: we call it “customer satisfaction” instead.
Since the most valuable things are done first, the product is finished when either A) the money runs out, or B) the business value of the next most valuable feature is less than what the developers would cost to develop it.
On the other hand, if the customers continue to point out more business value that can be exploited by further development, that’s a good thing, not a bad thing. The customers are happier, the company’s market share increases, and the developers continue to have interesting work to do.
Now, the fact that I disagree with much of what Mr. Fridman says in his article should not be taken to mean that I don’t think Agile has no downside. I think it has at least two major problems; but Mr. Fridman’s article didn’t mention either of them.