There is a commonly shown drawing, which came from a great Kniberg post (of course), explaining how every iteration in an agile development method produces something usable, and the capability of it grows over time. Rather than building parts to assemble later, as typically is done in function decomposition and bottom-up building. I reproduced the image here, to introduce the topic better.
Of course, critics answer by saying "well, if I ordered a car, I don't want a scooter or a motorcycle! I want a CAR!!!"
This argument misses the point entirely, but is frequently given as a counterargument. Henrick's point was that in the crossed-out picture, you have to wait until the whole car is constructed before you get any benefit at all.
The point is not that we "wasted time" building intermediate forms, but rather that we began producing value from the start and increased it over time.
Henrick Kniberg is entirely right, yet people keep insisting that you have to drive in a straight line to the target outcome and not build releasable "value drops" along the way if you want to get there, a point debunked by Geepaw Hill in his "Floptimization" posts, which he illustrates thusly:
But let's return to this image:
What I feel is missing is the degree to which agile methods give control to the end-user (or their surrogate in project/product management.
For instance, if you were to build a car as shown in the first image (under the red X) you might miss this opportunity:
What if you built a car for a person who really only wanted a bicycle? An automobile is a well-known solution to a problem of personal transportation. In the right context, it's irreplaceable. On the other hand, many people are happier with a less expensive and restrictive mode of transport.
What if a bicycle was enough, but you were building a chassis and engine, and couldn't deliver the bicycle?
I've been in circumstances where a client said, "This is fine, I don't want the other 50% of the plan." The team became despondent. They'd built in features, functions, and architecture in anticipation of the final system -- things that would be wasted now that the feature ended short of the goal. They considered going into rebellion and building the final car anyway, against the client's wishes and their own managers'.
In a more agile stance, you don't pre-build what you "are going to need later"; you build perfectly for what it does today. This was well explained by all the original XP developers. They referred to their principle as YAGNI (You Aren't Going to Need It). If you don't need some feature or function for the current iteration, you leave it out.
There is another reason not to pre-build to an anticipated solution: the user may end up going in directions you had not considered originally.
This is not a rare occurrence.
Sometimes, a partial version of a planned feature unlocks a whole new customer base that was hitherto unserved. Once market fit is realised, the product takes a different direction; it serves the new market and may not follow the planned trajectory at all.
If the original plan had been followed (the one Kniberg scratched out with a red X), there would have been no chance to spot the new opportunity and grow in a profitable new direction.
Also, any pre-built architecture and non-YAGNI code would create friction, slowing growth in the new area and creating rework for the development teams.
I illustrate the concept this way:
In agile methods, you avoid pre-building. You focus on the work at hand, and build value every iteration. You don't assume an end-target many weeks or months from now. You take many more much smaller steps, each valuable in its own right, and allow the feed back from customers and product managers determine how you will progress. You take Many More Much Smaller Steps in order to enable feedback and decision-making along the way.
Missing these opportunity guts agile methods of their true power to satisfy customers, and leaves you with a risk of building the wrong thing soonest.
Comments
Post a Comment