There was an interesting email discussion today at a client where I am engaged in a process improvement initiative. The current-state process resembles a hybrid linear plus time-box model, according to the taxonomy of process models I suggested in an earlier post. They do the iterations only for the programming work, and the rest of it is linear. Their goals for improvement are to improve throughout, reduce lead time, increase predictability, and reduce defects.
A portion of the discussion dealt with the size and scope of work items. It occurred to me some of that material might be of general interest, as it reinforces the idea that small is beautiful. Here is a sanitized excerpt from the discussion. Hopefully it will provide at least one real-world example of the value of keeping things small.
In reply to a question about combining features into a single story or splitting the story into multiples, even when this would result in very small stories, I wrote:
In general, I favor breaking things down small. The advantages are:
- Tracking progress — Small work items move forward through the process in a shorter time than larger ones. Moving small work items steadily through to “done” is key to improving throughput.
- Visibility — By tracking smaller pieces we have better visibility into what is happening. Because we are trying to address [several delivery issues], it’s important to be able to see every potential problematic area in the process. What we are looking for as red flags are mainly (a) blocks and (b) back-flows for re-work. If a large chunk of work were delayed or blocked, it would be more difficult to perceive which part of it had caused the problem. All we could see is that the whole story was blocked. That’s not enough information to help us correct [problems]. So we want visibility at a fine level of granularity.
- Flexibility — Small things are easier to reschedule, cancel, and redefine than big things.
- Maintaining continuous flow — If we have a lot of functionality bundled together as a single story, then any problem with any portion of the work will delay delivery of the entire story. When we break the functionality down into very small stories, then a problem with one of them will not delay delivery of the rest of them. This is feasible when the individual small pieces can be tested separately from the whole.
- Feedback — When a small slice of functionality can be tested early in the process, then the team can receive feedback from the test results to avoid promoting defects forward in the process. When testing has to wait for a larger set of functionality to be ready, then the feedback loop is longer and there is a delay before a defect can be corrected. Similarly, when stakeholders have the opportunity to review small chunks of work frequently, they can provide feedback to the team early and often. When stakeholders are asked to review a large amount of functionality all at once, they tend to feel rushed and not pay attention to details.
- Clarity — Functionality like [the functionality we were discussing] is not complicated enough to make this point obvious, but in a more general case it’s helpful to keep distinct bits of functionality separate so that they won’t be inadvertently blended together. Say we had functionality a little less trivial than [the functionality we were discussing], such as calculating premium rates for insurance. The basic algorithm is the same for all types of customers and all locales, but there are so many small differences in taxation, regulations, demographics, risk profiles, etc. that it would be risky to lump it all together as a single story. To do so increases the probability that some important detail will be overlooked or implemented according to the wrong set of rules.
- Morale — As team members and stakeholders see work items moving frequently, they get a sense that they are making progress. This makes them feel good about the work, which in turn helps them do better work, which in turn makes them feel even better, which in turn…you get the picture. When work is defined in large chunks, then a lot of time may pass before any single work item moves ahead. This tends to make people feel as if they are dragging an anchor through a swamp. It has a corresponding impact on morale, which in turn affects the work, which in turn affects morale…
Alistair Cockburn makes an interesting point in his Elephant Carpaccio workshops: When you have a large number of very thin slices of elephant, you also need a large amount of glue to assemble him. There is a point of diminishing returns in slicing stories into ever-thinner slices. The particular story we were talking about today is a case in point. It comprises three very trivial bits of functionality that could be tested independently (and it makes sense to do so, on some level), but they are so very small that the overhead of tracking them as three distinct stories would be excessive. A single programmer (no, they don’t do pair programming there) could complete the whole thing in half an hour. So this would represent too much slicing. Ah, if only too much slicing were the general problem with story sizing industry-wide! Alas, the opposite problem prevails.
It’s difficult for people who are used to working in traditional ways to think of small slices of functionality as meaningful. It’s normal for people think in terms of units of functionality that makes sense in the final production environment; whole features, at a minimum. Since it would not make sense to deploy a tiny subset of a feature to production, people assume it isn’t reasonable (or sometimes, that it isn’t even possible) to subdivide the work into smaller units for purposes of building, testing, and demonstrating increments of the solution. It’s a mindset shift for a lot of people.
This case was no exception. Most of the people in the discussion are very interested in learning how to effect improvement in their process, but there are a few who seem to be stuck in a sort of self-defense mode. One of them insisted that they don’t bundle too much functionality into individual stories, and that they do keep things small; and then she described “small” in a way that sounded “large” to me. Different past experiences, I guess.
There are some things about software development that are easy to understand once you’ve seen or experienced them, and very hard to understand just by reading or hearing about them. The beauty of the small may be one of those things. It is a form of beauty that has numerous facets and nuances.