This is a small excerpt from The Nature of Software Development. It’s a good reminder of how to think about value, and a blatant ad for the book, if you don’t have a copy already. Do please buy direct from Pragmatic Bookshelf if you can.
Value, by feature
Each feature that we might do adds some value to the product. And each one takes some amount of time to build. We can’t know exactly how valuable, nor exactly how long. But we can still get an excellent sense of what to do.
Suppose the height of the features above is their value, and the width is their cost. Which ones should we build first, and which ones should we defer until later? Pretty clear, isn’t it?
Value growth depends on what we choose to do
Look at the difference in the growth of value if we choose the higher value inexpensive features first and defer lower value costly features until later. And these features only vary by about a factor of three to one. In most products the best ideas are tens of times better than the worst – or more. The results would hardly fit on the page!
Some of those later features look pretty boring. What would happen if we did different, more valuable features, even for some other product?
We might even switch our investment to a new product!
When we begin to ship frequently, with highest value first, a time soon comes when the next features aren’t worth the time and money to create them. This is a good thing. We can often do far better by investing in a new product.
What’s the next product we’d like to do? Who might feel negatively impacted by a product shift? How might we make that shift a good thing for everyone? Can we focus on a portfolio rather than separate products with diminishing returns? Can we show more software, with more value?
Best value comes from small, value-focused features, delivered frequently
OK, we can see that small features could deliver value sooner if we can do them. Let’s think next about managing our project. Will smaller visible results help us manage? How might they get in the way?
What about our teams? Are they organized to work this way? Do they have the people they need, the skills they need, and the help they need? Read on – we’ll talk about all those things.
The main thing to remember is that we get the best results from delivering the software, feature by feature.
Did you enjoy this excerpt? Get the book: The Nature of Software Development. Already have a copy? Perhaps you have ten or a hundred friends and colleagues who need one!