strange loops

I’ve recently had a lot of conversations with people who are thinking of iterations as batches. By definition that’s what they are. You sign up for a “batch” of stories, at the beginning of the iteration, and you deliver them by the end of that iteration. However, it is useful to think of requirements (stories) as units of work that flow through the value stream. Here is why I think so.

What is a batch?

“A batch is a group of items that will be processed at once as a single unit”. Items are usually batched to achieve “economies of scale”. This usually means that there are some overhead activities associated with the items in question and it is better to distribute the cost of such activities over a batch of items than to perform such activities for each individual item. A good example is transportation. It is always more economical to transport a whole container full of items than to transport individual items.

You can batch items up at various levels. Coming back to the software world, you could batch requirements (stories) at an iteration level, at a release level or even at a project level if you must. That’s what classic waterfall does, it batches requirements at the project level. But the point is, you need to work on the whole batch at once at each step of the process. Which means you’d prioritize the whole batch, analyse the whole batch, develop the whole batch, test the whole batch and then deploy the whole batch.

So what’s the big problem?

Well, by batching items, you are limiting what you can do with each of them individually because as we discussed you have to process a whole batch at once. So where you could have prioritized, analysed, developed, tested and deployed individual requirements (stories), you can now prioritize, analyze, develop, test and deploy only iterations, releases or entire projects.

Flow

Instead, think about requirements (stories) continuously flowing through the value stream. This way you can assess individual requirements and make sure that only the most valuable make it into the value stream. Then you can analyze, develop, test and deploy these faster because they are small. Now all you need to do is take stock of how your team is doing at regular intervals. This is the time when you would showcase to your client stakeholders, check your throughput for the given time (velocity OR number of stories), have a retrospective, brainstorm technical approach, assess technical debt, etc.

And what about those “economies of scale”?

You do lose out on them to some extent. But here are two points to make you feel better because economies of scale are overrated anyways (at least in context of software development).

Firstly, remember that the more you do of something, the better you get at it. So by doing small parts of the overhead activities, you get better and faster at those activities and they don’t remain such a big cost anymore. For example, take deployment as an overhead activity. The whole process of deploying to production is usually so tedious and time-consuming that you prefer to do it only when you have a sizable “batch” of features to be deployed. But if you start deploying each story to production, you will have to better that tedious process. You will have to automate most of the deployment. You will have to automate most of the testing. After 10-15 stories are deployed this way, the process will not remain tedious anymore.

Secondly, stop thinking of it as extra cost and start thinking about is as the price the business pays for being able to delay decisions and for getting the opportunity to course-correct.

Example:
Let’s say you were developing a feature which was split in 10 stories. After deploying the first 3, which formed the minimum marketable feature (MMF), you saw that your users are not using the feature as expected. You either need to change the approach for the remaining 7 stories OR you need to stop working on that feature altogether because, given the users’ response, other features have become more valuable.

As business, you would have saved some time & money if you had waited for all the 10 stories to be finished and then deployed. But those savings are insignificant compared to first hand user feedback about the feature and the chance to act based on that information.

As the development team, don’t feel bad because your efforts on the first 3 stories were wasted. They weren’t. You invested that time and effort to find out whether that feature works for your business. You already got more than what you bargained for.

So what about iterations?

Have them by all means. But don’t worry about hangover*. Don’t try to sign up and finish a particular set of stories in the same iteration. If you can well and good. But what you are really aiming for is to perform consistent amount of work every iteration.

*So as long as your hangover remains constant you are good. If its increasing, you need to change your approach. For example by signing up for lesser stories.