Scrum proposes an empirical approach to software development and invites us to focus first on delivered value instead of delivered quantity. Despite that, we notice that even after several years of practice, few teams succeed in actually applying this empirical approach. They stay well anchored in linear thinking that guides their decisions and actions, often unconsciously or even insidiously. Among other things, this linear thinking brings them to associate success to delivering the projected scope within the allotted time and planned budget.
Thus, too few Scrum teams succeed in having an open, constructive and lucid dialogue about choices to make and actions to take to optimize the created value and technical integrity of the developed solution. This polarity is complex and difficult to manage.
But what about success?
The product’s success, and thereby the success of the Scrum team, are measured according to the value of this product. In a Scrum team, the Product Owner is ultimately responsible for the product’s success.
The Product Owner has an important role, especially as the carrier of the vision to guide the team toward delivering increments that materialize value in the wisest way. In other words, he guides and motivates the development team to make sure the work done creates the greatest possible return on investment.
In parallel, the Product Owner keeps an eye on the potential for innovation (in our mind it is not often enough understood and present). That is why he encourages the team to develop the product in a perspective of sustainable effort and awareness of the intrinsic quality.
For us, an experienced Product Owner also contributes by his presence and his actions to creating a challenging environment where everyone’s well-being is central. Furthermore, thanks to him, this environment is also a source of creativity, innovation and productivity.
One moment! I think the important thing is to deliver what was planned, is it not? Should the Product Owner not be interested first in his team’s development speed?
This is indeed the usual perspective on the question… and it is a sign that predictive and linear thinking are still at play. It pushes us to make speed predictions to ensure that we will deliver everything that was planned, without exceeding the budget. In short, the usual success criteria.
The empirical perspective at the base of Agility recognizes the complex nature of software development and is more about having a speculative approach. Incidentally, Jim Highsmith suggests not to plan, but rather to speculate (see his post Don’t Plan, Speculate).
Empirical or speculative perspectives are all fun and games, but a manager needs to have certainties.
Uncertainty naturally brings discomfort, it is a fact. In this regard, this is a good occasion to suggest that you read the following blog post: An Agile manager opening his heart…
However, delivered quantity does not necessarily mean created value. Nor does it mean value created at the right moment. If you want to read more about velocity, we suggest you read our colleague Tremeur’s blog posts: Velocity, a measure that is false! and Velocity, a measure that is useful!
In the long run, it is also important to adopt a quality perspective to preserve the ability to innovate and adapt quickly. A quality perspective also adds to satisfaction, and even pride, about the work accomplished. We have the conviction that it can contribute to durable well-being for the whole team.
We also believe that some of the things hampering the adoption of a vision centred on value more than delivered quantity (by the development team, the Product Owner or the Scrum Master) are the metaphors that the Scrum teams use to represent and manage their products and actions.
What are these metaphors?
The usual metaphor, used by numerous Agile teams and on which are built most digital Agile product management tools, articulates around the Post-it® and the index card.
The card is seen as a work unit, whether it represents a desired feature of the product or a development activity described in the sprint backlog. It is more rarely perceived as a potential for value to be explored, validated and exploited.
What other metaphor are you proposing?
In front of the findings, observations and feelings mentioned above, we have been looking with other colleagues for a metaphor that would naturally guide the teams toward integrating empirical and speculative thinking. A metaphor that would also enable us to easily get rid of mental models that are well anchored and restrictive.
Let’s look at the Scrum team like an oil prospecting business. It manages in parallel several drilling sites for which it has different expectations of results. Exploiting several drilling sites allows the team to avoid being stuck with a single site that could end up being dry. It is a way for the business to control the risk and optimize the results by investing its energy and resources wisely. It recognizes the speculative and unpredictable nature of its activity.
What could be the result of applying this on a daily basis?
A feature is a bit like an oil well. Its potential value on the market is speculative. Its real value is measured once the software is delivered, in other words, once the well is exploited and the oil sold.
During the sprint planning, the Scrum team defines a drilling mission (i.e. the sprint objective), which foresees the exploitation of several wells (i.e. the selected product backlog items).
Contrary to the assumptions of linear thinking, it is possible for the mission to be a commercial success without exploiting the intended wells. It is also possible that exploiting these wells will not result in the expected success. In other words, mission success and achievement of the drilling objectives initially planned do not necessarily go together.
During the sprint, the development team meets every day for the daily Scrum in order to check in on the mission’s progression and plan the day’s drilling tasks. To do that, the team members ask the following questions:
- What are the drilling results (achievements) and how much oil have we found during the previous day (value)?
- What is our drilling plan for the day and how is it contributing to the mission (value)?
- What blockers do we have that are jeopardizing the drilling mission?
The team needs to stay alert and open to the possibility of revising its drilling plan at any time during the sprint if it discovers better ways of reaching the mission’s objectives.
Here are a few questions we suggest that are able to guide the team to an optimized redefinition of its drilling plan:
- What is our progression regarding the drilling mission’s objectives?
- What should we do to maximize the drilling mission’s chances of success?
- What is missing for that well to be exploitable?
- Should we stop drilling this well, exploitable or not?
The sprint review is the occasion for the Scrum team to assess the wells drilled during the sprint and the value that is now exploitable. It takes into account any change in the business context to decide the relevance of pursuing drilling activities and potential objectives of the coming missions.
Here are a few questions that the Scrum team asks in this regard :
- Is there an opportunity to be exploited immediately?
- What have we learned about the nature of the soil during this sprint?
- How should we adapt our coming drilling plans to create the greatest possible value in the future?
- What are the future scenarios that we think plausible? Unlikely? Very probable?
- Should we continue to fund new digs?
This speculative approach strongly contrasts with the more naive linear approach which simply consists of comparing the drilled wells with the initial plan, leading to little learning and adaptation.
We hope that we have succeeded in providing a perspective that invites to reflection and richer and more inclusive dialogue (more useful) that you can put forward concretely in your teams.
For Product Owners, we hope that this blog post will incite you to adopt a perspective centered on created value more than delivered quantity. For Scrum Masters, we hope we gave you tools to create space for conversation about value. Finally, for development team members, we hope that you will adopt a constructive and contributing posture during conversations with the Product Owner and that you will not stay in a position of resignation or opposition like we often see.