I've found it useful to borrow another idea from manufacturing planning when it comes to understanding concepts and questions like, how big should an iteration be? The concept has two elements transfer batches and process batches.
A process batch is a batch of work that is done by a person, team or system. Process batches are grouped for efficiency or for reasons of other constraints, such as the size of a physical machine, or natural conditions such as hours of daylight. For example, if you ran a bakery, a process batch would be the number of loafs of bread that you can bake in the oven in a single batch. As I described last week, every batch has a setup and a cleanup cost. Process batches tend to be optimized for efficient use of resources, communication, costs or effort expended such as efficiency of time on task and time in motion.
A transfer batch is a batch that gets transferred down the value chain and passes to another set of workers or to the ultimate customer. Transfer batches are often bigger, that is several process batches make up a transfer batch. If you were in the bakery business then a transfer batch is the quantity of loaves you can load on to a truck to deliver to the grocery stores. Transfer batches tend to be optimized for the costs incurred by the next stage in the value chain or the customer. For example, the customer may need to train a sales organization or a help desk operation.
When I worked at the big phone company a big concern for us the cost of training the thousands of people in the retail stores and the thousands more who answered the phone when customers pressed *2 on their phone for assistance.
Other aspects can come in to play. For example, do you have to take your web site down to do an upgrade? Will there be an outage? Is your business seasonal and you only want to take upgrades and new functions at certain times of year? This latter concern mean that the transaction costs vary at different times of year.
The transaction costs associated with a transfer batch can mean that transfer batches have to be significantly bigger than process batches. Often many times bigger. In Feature Driven Development, the process batch is the Chief Programmer Work Package, and the transfer batch is a Release (or sometimes a Feature Set). Process batches are never bigger than 2 weeks worth of work. Transfer batches are seldom smaller than 3 months worth of work. The customer often can't take delivery more frequently.
In much of the agile literature that talks about iteration size, there is no separation of the ideas of a process batch from a transfer batch. They are assumed to be the same. At the same time, there is no discussion about the transaction costs associated with the batch. We get advice like iterations should be one week, or two weeks, or four weeks, or even three weeks. None of this comes with any consideration of the transaction costs associated with process efficiency or delivery (transfer) efficiency. The reality is that iteration and release size will be different for every domain and potentially for every customer. It is a situationally specific problem.
What are the transfer batches and process batches in your process? Can you identify the transaction costs associated with them? Are they optimal? Could you reasonably make the batches smaller? Can you work to reduce the transaction costs? Technorati tag: Agile, David+Anderson, FDD
