Value deliveries

A 2001 study informs the results of a survey in which 400 software development projects were analyzed over 15 years, at a time when very few projects used Scrum and similar concepts. In none of the analyzed projects were more than 20% of the delivered features used by their users (COHEN et al., 2001).

These numbers show what our experience has already shown us: how ineffective we really are in our work, since most of what we produce does not meet the needs of users.

Under the most traditional scenario, a long list of features to be developed is defined before delivering anything, based on the belief that an extensive and detailed initial requirements analysis will translate into a successful product. In this way, customers or business people decide in advance the details of a product that will be created over the months to come, and any later changes to that definition are not welcome. As such, they are induced to list everything they can imagine at that moment, resulting in great waste. This detrimental practice of defining and detailing the scope before beginning product development is known as BDUF (see the section Scrum is agile in the chapter What is Scrum?)

In another common scenario, the work is done in short cycles and with a flexible and evolving scope, just like we do with Scrum. However, while the product is demonstrated and feedback is given during the course of its development, it will only undergo some sort of real use after a long period of time.

In both scenarios, we make the mistake of defining the product by keeping ourselves away from those who will actually use it, as well as from the use itself. The delivery to users will only occur at the end of the project or after completion of a major phase. In this way, we invest in the work for a long time without getting any return, which is only expected as a result of this delivery. Nevertheless, there is no guarantee that the delivery will actually meet the users’ needs or that it will generate anything close to the expected value.

Use defines the product.

This circular statement that I created and have used in my trainings indicates that it is only when interacting with working parts of the product – and which potentially generate value –, that the user begins to better understand how this product can help them solve their needs. As a consequence, one of the riskiest market practices we can engage in is to detail a large scope and take a long time to offer users something done that they can see, use and only then provide feedback from this delayed use. What we create and deliver to our users is just a hypothesis of something useful to them, and which should therefore be validated or invalidated as soon as possible. In short, use based on what has already been delivered is needed to guide the definition and construction of the product. The longer we delay this possibility of feedback, the greater the potential waste generated with the construction of a product developed under the wrong assumptions.

With the use of Scrum, however, product development occurs in short cycles. In each of these, we implement at least one done increment of this product, defined according to what we believe to be the greatest needs of customers and users at that moment. Each of these increments, added to the previous ones, is a functional product. In this sense, the product is a delivery candidate that receives some feedback from customers and other stakeholders as they see and interact with it in a meeting at the end of each cycle.

However, it is only when we get these working parts of the product into the hands of users that we receive the most valuable feedback from real use of the product. This feedback allows the details of the product to emerge as it develops. That is why we aim to make deliveries to real users early, and often. And when, for example, we make a wrong product decision, the feedback quickly obtained from use creates transparency about the issue and allows for course corrections. In this way the product is continuously defined, and its development work is ordered based on a constantly evolving understanding of the needs to be met, as a result of the use of the product itself.

This process of defining the product based on its use aims to ensure the development of a valuable product.