Forget Commitment, Make Reliable Forecasts
There is a widespread confusion about the meaning and the relevance of “commitment” for teams that develop software according to Scrum. “Commitment” is one of the five Scrum values, as introduced in the book “Agile Software Development with Scrum”. However, since 2011 the word does not appear in the Scrum Guide any more, which has not helped to clear up any ambiguity. Plus, there is no really good translation of the word in German, complicating things even more for me in discussions with co-workers in Hamburg.
So, what is commitment and how can it, or an improved version, be a useful concept? And finally, how can this abstract value be brought to life by actual Scrum teams? I believe it is best to replace “commitment” with a more precise term that addresses more issues, and put that to work.
In ye olden times, before the 2011 Scrum Guide, development teams used to commit to a sprint goal or even to a list of user stories. The future is unpredictable, estimates are way off, impediments show up, developers are easily distracted, miscellaneous foreign managers often distract the team, nevertheless the dev team promise really hard to deliver the sprint results the product owner ordered. The scrum master is in place to remove at least some of the issues.
The Agile Manifesto, in contrast, demands that teams be formed by motivated individuals who just give it a go. These individuals already have a basic inclination toward the project goal and sprint goal, and they do not need an additional appeal to their integrity in the fashion of “but you promised!” Also, they are an empowered team and therefore are capable of removing impediments of any kind for the higher purpose of customer value.
A commitment resembles a contract: The dev team promise to deliver a certain service (sprint goal) by a certain date (sprint review meeting). However, there are no provisions in place to reward a successful delivery, or to punish a failed delivery, other than the dev team feeling embarrassed in public when they have nothing to show at the sprint review. Also, only one party is asked to sign it, not both. In fact, Scrum’s commitment is almost, but not entirely different from a contract.
Now that we have had a look at the use of commitment, how is that useful to anyone? Some people seem to believe that, as it is really hard to keep a commitment due to the various slings and arrows of outrageous fortune, it is a wise move to only commit to learning, to adhering to the Scrum process, or to the team, but never to a specific outcome. Most times your commitment will be broken anyway (never mind whether on your account or by adverse circumstances), so pressure will increase, quality will degrade, control will increase, and your team will be in a place they really wanted to avoid.
I disagree and argue that it is rather important to make commitments to outcomes in the general direction of your customers, i.e., to your product owner. Trust is the cornerstone of customer relationship not only in the Agile Manifesto. It is also the foundation of the teamwork pyramid in Lencioni’s book “The five dysfunctions of a team”, and we need to see the dev team plus product owner as one team in order to avoid the biggest risk, namely, of building the wrong product. In order to improve teamwork, you need to build trust, writes C. Avery, and to do that, he advises to repeatedly make small promises and keep them, this way building a track record of reliability, thereby expanding your freedom. Foremost, Avery recommends to only make promises you can definitely meet, because one single failed commitment can ruin the positive effect of a hundred kept promises in an instant and destroy your client’s trust in you.
To me, a forecast you can count on most of the time is good enough, and close enough to a commitment that one can replace the other. When the dev team trust their own ability to execute and the product owner trusts the developers, they should work together smoothly even when the going gets tough, and resolve issues instead of shifting the blame about. Replacing “commitment” with “reliable forecast” works for me.
The obvious opportunity to repeatedly make and keep promises and build trust are sprints and sprint deliverables. This brings us to the question of how a dev team can actually keep their promises regarding sprint outcomes to the client.
Ready, Willing and Able
Meeting a sprint commitment (or better, “reliable forecast”) depends on three aspects that are easily confused:
- The organization must be ready.
- The dev team must be willing to do all they can for a sprint success.
- They must be able to perform all tasks that might turn out to be necessary to reach the sprint goal.
Many authors, including Schwaber in his 2002 book and this more recent article, focus on the organization as the biggest obstacle to sprint success. A team can only commit to a sprint goal when they are empowered to meet it and to blast through any impediments that might occur, even if they hurt feelings and disturb processes in other parts of the organization. The underlying assumption is that the biggest challenge for Scrum teams is a lack of organizational support when they ruthlessly turn towards customer value. If the organization is not ready to accommodate this change in mindset, the team is doomed from the sprint planning meeting on and is better off not entering any kind of commitment.
Now, on toward willingness of the dev team to work as hard as they can (see, e.g., this article). Asking the team for a commitment to the sprint goal may or may not be helpful. Hope is that, in order to meet their promise, the dev team are now a bit more motivated to focus, to remove obstacles, and build the important things first. This way, the chances of achieving the sprint result are supposed to be higher than without commitment. The Agile Manifesto starts out with the assumption that developers are motivated individuals, as discussed above, so there is no need for an additional act of commitment. However, there is the real danger that a lackluster interest in success is a self-fulfilling prophecy, whereas a “play to win”-attitude can help bring success about. The (fictional) Yoda has (fictional) success with his famous “do, not try” approach. But the best way of having the dev team’s full attention on the sprint goal is to grab them by their intrinsic motivation. In Appelo’ Management 3.0 (Chapter 5, “How to energize people”), there is a lot of good advice on how to help people give their best at work. Only one of them is grabbing people by their sense of honor and integrity, by having them make a promise that they are reluctant to break. Asking for commitment is just one of the many ways to increase the willingness of the dev team to deliver.
On to the third aspect of
keeping commitments forecasting reliably, the ability to do so because the dev team have the necessary time, know-how, tools, and supply from upstream stations in the value stream. This is the classic area of team-level impediments and their removal. It is not enough to have a supportive company and a motivated team, they also need to be able to remove all impediments that slow them down. They need to notice them, attack them, and remove them for good. Noticing impediments is a science on its own, but good books have already been written on retrospectives, so this is not the place to dive in further.
Commitment and Sprint Planning
Let me wrap up this inspection of the notion of commitment by suggesting how to use “commitment” or “reliable forecast” in a sprint planning meeting.
The point of a Scrum Master is to address impediments from within and without the team, and to detect looming obstacles on the team’s likely path.
- When the organization is not ready to tackle the work in the sprint, the dev team plus Scrum Master must call out and provide the required infrastructure, helping hands, or authority.
- When the team is not willing to run for the sprint goal, it is necessary to notice that not everyone supports the sprint backlog, and bring possible side-agendas or doubts about the general direction on the table before they blow up in your face during the sprint.
- When the team is not able to deliver, it is important to raise any concerns right away, whether they concern limited availability of team members, know-how, technical unclarity, or any other risk threatening the sprint success.
The idea here is to educate people to act proactively (first habit of Covey) and to assume responsibility for the sprint goal and sprint backlog instead of evading a clear position (Avery).
So, in my role as Scrum Master, I usually ask two questions at the end of the sprint planning meeting: 1. Is this a good plan? 2. Can you do it?
- Look at the taskboard. Given this sprint goal and the stories planned here (and other stuff like the product vision on the wall over there). Do you think this is a sensible plan?
- Look at the table of who is available in this sprint for how long, at the tasks on the taskboard, at our list of impediments next to the taskboard, the recent sprint velocities in this chart here, etc. In light of that, can you do all the things on the board and thereby achieve the sprint goal, or is it wishful thinking?
The first question serves to draw out any discrepancies between individual goals and the team goal, and bring any doubts about the goal to the surface. Through the second question, I want the team to discuss all risks on the way to that goal, including the question of whether they are simply too optimistic.
These two questions work for me to replace the request for this mysterious commitment, which is, as mentioned above, especially awkward to ask for in German. Also, there is no waterfallish smell of a mini-contract, while addressing the questions of whether the organization is ready, and the dev team is willing and able to achieve the sprint goal.
The sprint may still fail, but I believe that this is the best way to get a forecast that is mostly reliable.
- Mike Beedle/Ken Schwaber, Agile Software Development with Scrum (2002)
- Ken Schwaber/Jeff Sutherland, Scrum Guide (2013)
- Agile Manifesto (2001)
- Patrick Lencioni, The Five Dysfunctions of a Team (2002)
- Christopher M. Avery, Teamwork is an Individual Skill (2001)
- Jurgen Appelo, Management 3.0. Leading Agile Developers, Developing Agile Leaders (2010)
- Another way of testing commitment is described in this article.