2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns – Half-Day Sessions
2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- April 10, 2019 ( 2 comments )
- Build in Small Batches
In my last blog post, called Measure Customer Value of Features, I discuss the importance of seeing the value of features from the customer’s perspective. But there is another perspective that the customer can sometimes have that is also important for us to see–the cost of not delivering a feature.
Sometimes we’re in time-critical situations where we’re trying to beat our competition and get a feature out before they do, or we’re trying to address a new market that’s exploding. The longer we delay, the less opportunity we have.
Time-critical situations like this can be very hard for a business to evaluate because there are opportunity costs and production costs. Markets are fickle, and being the first to market can make all the difference in some markets. This isn’t always true, and in many markets, being the highest quality, even if you’re not the first to market, can give you the edge that allows you to ultimately dominate that market.
Opportunity cost can be real and, in some situations, measurable. Under these situations, I find that measuring these opportunity costs can be helpful to management in making decisions.
Ironically, the one cost I often find managers not noticing is their highest fixed cost, which is the cost of the team itself. If you have a team of 24 developers in your organization and their average annual salary is somewhere on the order of $100,000 for the sake of discussion. With benefits and overhead and all the other costs related to having an employee, you probably are spending $200,000 a year on that employee, which for a group of 24 developers, is about $100,000 a week, every week, or about five million dollars a year. What’s your burn rate?
The question is, are we creating at least that much value? Ideally, we would like to create ten times that value from the work we’re doing. Running a development team is expensive, but losing opportunities can be far more expensive for many teams. A few years ago, I was working with a client, and they saw an opportunity to modify some of their systems and capture a new market. The following year one of the developers told me that they made over $100 million by introducing just that one new product over that last year.
In some situations, measuring the cost of not delivering a feature can greatly impact the decisions management makes about what features to build next. This is important because the metrics that we track should be used to influence our decisions.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, called Seven Strategies for Seven Strategies for Measuring Software Development.
{2 Comments }
Previous Post: « Measure Customer Value of Features
Next Post: Measure Efficiency of Feedback Loops »
This directly relates to Don Reinertsen’s economic principle
E3: The Principle of Quantified Cost of Delay: If you only quantify one thing, quantify the cost of delay. (p.31)
From his book Principles of Development Flow (with 175 principles)…
Excellent point! Thank you.