Can you really commit to delivering work?

Topic(s)
Audience

Everyone

PST Logo 2 There has been a subtle but targeted change in the wording used as part of Scrum. There has bee a move away from commitment towards forecasting what will be completed. Why is this happening and what does it mean to my team?



There has long been a subtle lack of transparency between the Product Owner and the Development Team that has largely gone unnoticed. In the empirical world that is Software Development it is not possible to commit to delivering anything! This is reminiscence of the institutional fiction that we can indeed give someone a guaranteed delivery date for something that exists in the complex world and thus is impossible for us to estimate. We have been doing it for years and we are still doing it even in Agile. The only saving grace is that our commitment has been for such a small amount of work that we are routinely forgiven and indeed any good Product Owner quickly learns that Commitment is really a guess and can often be a WAG (Wild Assed Guess) at best.

image
Figure: The meaning of commitment

Where are these points in Scrum where commitment has been applied:

  • Daily Scrum

    During the daily Scrum the Development Team get together to review each others previous days commitment and then commit to each other to completing work.

  • Sprint Planning

    During Sprint Planning the Development Team commit to delivering work to the Product Owner at the end of the Sprint.

There are also a number of other commitment points that are implied in Scrum. The Product Owner is probably committing to delivering functionality to the Stakeholders (The Business) and often the Business will then commit to delivering functionality to their Customer. 

And this is where the major problem lies as there are escalating cycles of impact at all levels.

  • An Individual fails in their commitment to the Development Team

  • A Development Team fails in its commitment to the Product Owner

  • A Product Owner fails in their commitment to the Business

  • The Business fails in its commitment to its Customers

If you have “commitment” then others will read that as something that can be relied on and potentiality take a dependency on the timely completion of that work. Once a dependency is taken then it can be a BIG problem if things go south. What if your Sales teams have made commitments to old customers to get them to say and to new customers to get them to change to you?

This is the result of committing to delivering work, so I say again:

Can you really commit to delivering work?

The word “Commitment” smacks too much of the Prescriptive world and not enough of the Predictive. Can we stop diluting a perfectly prescriptive word? Is there a better choice that lives in the Predictive world?

image
Figure: Would you hold a weather presenter to a 10 day forecast?

The new Scrum Guide talks about Forecast instead of the Commitment. This is a subtle and carefully chosen contrast that is intended to result in a more positive open and transparent communication between the key actors in the pantomime that has been Software Development.

image
o_Error-iconFigure: Bad example, “Commitment” implies that we know for sure

 

image
o_Tick-iconFigure: Good example, “Forecast” implies that we don’t know for sure

The result should be higher levels of trust between all parties that should result in less (or at least more well known and specific) dependencies that are of much lower risk. If we make that change we really start thinking in the Agile / Predictive space and some of the old ways will drop by the wayside. Those old ways are the things that get in the way of an Agile adoption, that make us want to drop back into our old comfortable bad habits of Waterfall.

Are you going to make the change from Commitment to Forecast?

If not, let me know why this will not make sense in your organisation!

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Read more

Martin Hinshelwood
For a long time now I have been searching for that perfect domain that epitomised the vision, the why, of what I am trying to achieve with my customers and the industry at large. Now I have found it in http://nkdagility.com
Martin Hinshelwood
At the MVP Summit I was appalled by the number of people who asked questions about new features for supporting hierarchical tasks! I shared a disgusted look with Peter Provost and we had a quick (and I mean really quick) conversation that resulted in this post. it really comes down …
Martin Hinshelwood
In my journey of delivering an immersive Product Development Mentor Program over the last eight weeks, a compelling narrative unfolded that beautifully illustrates the essence and true strength of Scrum. This story, rooted in the practical application of Scrum through Minecraft, unveils the depth of adaptability and resilience that Scrum …
Martin Hinshelwood
The Boards in Azure DevOps are a powerful tool that your teams can leverage to enable transparent visualization of the current state of value delivery.  However, the inclusion of Blocked columns can stealthily erode the very foundations of efficiency these boards are meant to uphold. By obfuscating the state of …