This post is part of a series in which I address Bill Miller’s criticisms of agile. Please read the original post for context. In this post I take on his criticism of the role of documentation in the agile process.
Mr. Miller offers two criticisms of frequent deliveries.
The first criticism is this:
Agile proponents promote frequent releases from “a couple of weeks to a couple of months.†Most customers will not adopt such rapid changes. It costs time and money to deploy and train people on any new software.
He’s absolutely right. But nobody says that you have to actually deliver to the customer for full deployment at the end of each agile iteration. Rather, it’s the principle that you should always have fully functional code.
I’ve been working on a new product that we’re developing first for a particular customer. At the ends of he first few sprints, we indeed had working code, but since we were at the very beginning of the project, that code wasn’t yet very interesting to the customer, so we did not release it to them.
Since then, we’ve offered the code every sprint, but we have processes established where the customer first installs our code in their test server so that the sponsors of our project at the customer can try it out. But the customer chooses whether or not to actually deploy each sprint’s code to the production server.
Mr. Miller’s second criticism of frequent deliveries is as follows:
Further some features require long lead times to assemble, making them impossible to deliver in a short interval. It’s like saying no matter what size building you give a team to build, they can build it in a month.
Building construction is not a good comparison to agile since the requirements for a building rarely change significantly (as I understand the process) once construction has begun. This stability allows you to first lay the foundation, then build the frame, then put in the plumbing, etc.
But if we do use this metaphor, here’s how you would build a building using agile: in the first iteration, you lay the foundation. No getting around that. At the end of the first sprint, you have a ‘functional’ foundation, but the customer doesn’t really care about that, so you don’t deliver it to them.
But at this point is where agile differs. In the second sprint, you don’t build the entire frame; rather, build as much of the entire first floor as possible. If you don’t have time to build the entire floor, then you build half of it and put in a wall to the unfinished section, cap off some plumbing lines, etc. At the end of this sprint, the customer could move into the finished section, or at least go into it, see that toilets flush, the doors are square, etc.
In the next sprint, you finish the first floor, and at some point, you put a door in the wall to join the two sections of the first floor, connect up the plumbing to the finished plumbing, etc.