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
Top comments (8)
Where I work we were doing Scrum up until a few days ago. Now, we are just trying to deliver features as soon as possible and things seems to have got out of control.
We are a team of multiple areas, we have mainframe devs, SOAP/REST services devs and the one I find myself, front-end devs.
Do you think that focusing on a single feature (page in this case), could help us and, how do I explain it's benefits to my superiors?
Oh man, I'm not qualified to answer that question.
Imagine that software development is like flying a modern jet. You've got hundreds of dials, knobs, and switches in the cockpit. And depending on what you're trying to get the jet to do, you would set those dials, knobs, and switches to different settings. The correct setting of any particular knob for landing might destroy the plane if you use that setting in the event of an engine fire. Context is important.
I have no idea what your company is trying to achieve or even what kind of jet they are flying (to continue the analogy). I just wrote a blog post that pointed out a particular knob and tried to describe what turning it might do to the profitability of a hypothetical company. It's up to you (or the senior people in your company) to figure out the best setting for that knob and all the other knobs for your company to achieve its goals.
Best of luck.
Thanks for your insight, it really helps. I'll talk to my team about this. I don't think we'll change the way we're working at this point, but maybe, we can improve some aspects becoming more productive.
You're welcome.
Maybe for future posts. I'm curious about your ops infrastructure, and how much it costs per deployment or a ballpark of what it cost the company to automate deployments, and what things still have to be done manually. It seems like many companies do simultaneous feature development in order to minimize costs and risks of deployment. Risks can include outage due to mistakes, customers upset at things changing too frequently (depends on the app), data migration. Costs might include dev/ops time, versioning, documentation, integration testing, etc. In an ideal world most of the costly things would be automated, but doing this also costs time to develop. And afterwards, some manual work still often remains. Thanks for the post!
You are asking about economically optimal batch sizes. I covered a specific case of this in my post: Optimal pull request size. The graph in the linked post is directly applicable to your question.
You need to find your economically optimal outcome, which is a balance between the cost of waiting to deploy some set of features (holding cost including cost of delay) and the cost of a single deployment (transaction cost).
In my workplace we can deploy our code in about 2 minutes. But I can imagine deployments that are very expensive. For example manually reprogramming all the nuclear weapons in the US arsenal would likely cost hundreds of millions of dollars. Vastly different transaction costs effect the economically optimal batch size.
I can profitably push code updates into production several times per hour but the US military might calculate that their optimal deployment schedule for nuclear weapons software updates is once every 5 years.
However, if the US military found a critical error in their nuclear weapon software, the cost of delay would shoot up, and then their economically optimal release time might be today even if they deployed yesterday. And even if it cost them billions of dollars to redeploy. Does that make sense?
Thanks for the question. I'm planning more advanced cost of delay posts including a post on optimal batch sizes. But I wanted to start with an easy one and work up to the harder cases.
At my company, the cost of a deployment is in the ballpark of $3 million.
I look on with envy at Google Chrome and their release channels. Stable (3 weeks per release), Beta (weekly), Dev (weekly), Canary (daily), Waterfall (per check-in), Last Known Good (tagged from waterfall).
I think Chrome's cost of deployment has been streamlined to the point that it costs pennies to deploy. Now that is an agile feather in their cap!
I can't help but wonder how much it cost Google to develop the continuous delivery process they now enjoy.