In the posts from the last weeks, I discussed the first two steps in adopting data-driven development (see figure below), i.e. modeling feature value and building the necessary infrastructure. Once we have described the value that we expect from a feature and have constructed the infrastructure required to capture the data coming back from the field, the next step is to adopt an iterative development approach.
Traditionally, R&D would get requests for feature from product management and the business side of the company. In response the requested functionality would be built and delivered. R&D was basically a place where you would order things. The reality, as I have discussed in previous blog posts, is that more than 50% of features built in this model are hardly if ever used and constitute waste in development.
When adopting a data-driven development approach, we can address this challenge by building features in multiple slices and measuring, for each slice, if the value that we expected to see indeed is realized. And if this is not the case, it allows the company to abandon the feature or experiment with alternative feature realizations. This causes the effectiveness of development to go up dramatically as investment in non-value adding features is stopped much earlier than in traditional development.
We developed the HYPEX model as a methodological approach to iterative development of feature slices. As shown in the figure below, this model captures several aspects of the data-driven development process that I have been discussing in my blog posts over the last weeks.
The challenge that most companies run into at this stage is that the release cycles of their software is too slow to allow for this process to be employed effectively. This is why the next step in the process to accelerate the feedback loop so that teams get rapid feedback on the performance of the feature slice that they just developed
The basic notion behind all this is that more than half of the R&D efforts in your company are waste. Iterative development of feature slices provides a very effective way to increase the effectiveness of your R&D. So, stop building each feature completely, top-to-bottom, gold plated and including a kitchen sink. Instead slice the feature into small chunks of functionality that can be developed by a few engineers in less than a sprint and use the feedback data to guide the next steps. Feature slicing == good!
To get more insights earlier, sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
