Simultaneous feature development is a common but often economically sub-optimal software development practice. In this post, I'm going to look at the financial implications of simultaneous feature development and show you what you can do instead to achieve better outcomes.

What is simultaneous feature development?

Simultaneous feature development is a common software development practice where a team works on more than one feature at the same time. For example, if you are doing scrum, you'll pull a bunch of stories into your sprint. And everyone is more or less happy if you complete all your stories by the end of the sprint. Your team has no limits on work in progress. So you work on whatever's convenient.

Teams engage in simultaneous feature development to keep everyone on the team busy all the time, which is the incorrect variable to optimize.

Why should you care about simultaneous feature development?

The problem with simultaneous feature development is that by working on multiple features at the same time, you are delaying the delivery of every feature. And if those features increase revenue or decrease costs, you are costing your company profit. So, your team might be hitting all its velocity targets, quality targets, and getting the most important work into your sprints and still be missing out on substantial profit opportunities.

Of course your team might have very good reasons to develop features in parallel. You might have a large team and it just doesn't make sense to have 50 people working exclusively on a 200 line feature. Alternatively, you might have a deadline for delivering a whole basket of functionality and the only way you can meet that deadline is by working in parallel.

How you can improve your outcomes by using cost of delay

You can't dogmatically apply a "no simultaneous feature development" rule. You need to calculate your cost of delay and choose the path that makes the most financial sense.

An example

Suppose you are starting a new four week sprint and you have 4 features to complete. Each feature will take one week to develop. And you lose $5,000 every week you delay the launch of each feature--this is the cost of delay.

Here's the financial impact if you develop all your features simultaneously and deploy them at the end of the sprint.

And here's the financial impact if you develop your features sequentially and deploy them as soon as they are done.

You can have a huge impact on the profitability of your project just by making a simple change to the way you schedule your work. In this scenario, you can decrease the cost of delay by 37.5%! ((50K - 80K)/80K = 37.5%)

Do you see how huge this is? You don't need to work any harder, hire more people, or learn functional programming. All you have to do is schedule your features to minimize cost of delay.

Key insight: waiting has a cost attached to it. If your feature takes 50 hours of developer time to complete but it spends several months waiting in various queues before it is finally delivered to your customers, the true cost of that feature could be many multiples of the 50 hours of programmer wages. Most businesses are focused on that 50 hours of programmer time and making sure all their people are running a very high utilization rates. But they are completely blind to the potentially tens of thousands of dollars they lost because the feature took months to deliver when it could have been delivered in days.

Wrapping up

I was completely blind to this huge opportunity to increase profitability until I learned about cost of delay. We were happy if we worked on high priority tasks in our sprints and met our velocity targets. But we were definitely leaving a lot of money on the table. We would frequently allow stories to linger in multiple sprints if they happened to fail multiple code reviews. Those stories could block whole features for weeks on end. But it never occurred to us that we were bleeding money.

Calculating cost of delay and using it to schedule our work required us to make some adjustments but it is so worth the effort. I'll expand on these ideas and show you more complicated examples in follow-up posts. Stay tuned.

Additional cost of delay resources

You might find the following cost of delay resources helpful:

• excellent website with a great three minute explainer video
• book: "The Principles of Product Development Flow: Second Generation Lean Product Development" (Donald Reinertsen) Chapter 2
• book: "Essential Scrum: A Practical Guide to the Most Popular Agile Process" (Kenneth S. Rubin) Chapter 16
• video of a talk by Donald Reinertsen on product development