Commitment should mean something to both parties – that’s how you generate Trust. But it doesn’t mean cast iron guarantees either.
The Problem of Commitment and Best Efforts
There’s lots of negativity about the idea of Commitment out in the Blog and Twitter spheres. Canonical Scrum itself has taken on this view, replacing the concept of a Sprint Commitment with the much broader and lighter Scrum Forecast. One gets the idea that Good People Don’t Ask Good People To Make Commitments.
Reading these pieces, it’s easy to infer that the only possible reading of ‘Commitment’ is as an externally imposed set of unrealistic expectations. That it’s close to a cast iron guarantee of outcomes, reaching which requires the onerous, frequently cited legal standard of
Best Efforts as an absolute obligation that binds the promisor to spending unlimited amounts of money, time, and effort if necessary to fulfil the expectation.
Clearly in a context of high uncertainty — which Software Development of anything beyond trivial always is — this would be unrealistic.
This reading is problematic in another way: Commitment is something that can never be imposed from the outside. I can only commit myself to do something; you can never commit me on my behalf (unless you have my clear proxy to do so, which is often a cause for dispute in relationships. Ask my wife…).
If this reading is accurate, then indeed Commitment would be an unattainable and undesirable approach.
The interesting thing is, while this is the generally accepted view of
Best Efforts, it’s not actually accurate in either UK or US law (YMMV in other jurisdictions). It’s more accurate to understand that Best Efforts should not be overly burdensome nor unrealistic, nor detrimental to the promisor. That said, the Best Efforts standard
has diligence as its essence and is more exacting than the usual contractual duty of good faith … that has honesty and fairness at its core and that is imposed on every party to a contract,”
E. Allan Farnsworth, 2 Farnsworth on Contracts 383–84 (2d ed. 1998)
A Better Commitment
Diligence, honesty, fairness. That doesn’t sound too bad to me. And SAFe®’s view of Commitment is closer to this. It goes something like:
We will diligently work in good faith and to the extent of our capabilities to achieve what we are committing to within all identified constraints. This is because, knowing what we know now, we honestly believe, from our understanding of the request and our experience of similar kinds of work, that it is reasonable and realistic to achieve it.
However, we recognise that we have a high degree of uncertainty, and there are many known, unknown and unknowable unknowns, which together may make that commitment unachievable. Should this happen, or be likely to happen, we will clearly call it out at the earliest opportunity, allowing the maximum timescale to find alternative options. And that has to be 100% acceptable to all parties.
An example might be helpful here.
Imagine that you are remodelling your home, including combining two rooms into one by removing a partition wall. Your builder makes a commitment that the wall will be down and all finished and cleaned by Friday. You’re away during the week (well who would want to live amongst all the dust?), and get back on Friday afternoon. The wall is still there.
Ah, that. say the builders.
On Monday afternoon, we discovered a pipe in the wall that wasn’t on the plans, so our Friday commitment isn’t valid. You’re (quite reasonably) still cross. Not because the wall isn’t down, but that that they didn’t tell you until now.
If they’d told you on Monday, you could have found (or authorised them to find) a plumber to reroute the pipe, and while Friday may still not have been possible, the work would have been a lot further on.
That sounds reasonable to me.
Secondary Meaning: Converting
Might Do into
The other thing that Commitment brings is an explicit agreement to take on the work. To convert from an Option — a thing that might be worked on — to something that will be worked on.
While this isn’t consciously called out in SAFe, it’s clearly implied as a central tenet of PI Planning: the Product Community brings Options in the form of a Feature Backlog, which Planning converts into a set of Commitments to Objectives.
Note also: we’re not committing to a list of features, but to meet the higher level Objectives of the PI, which gives greater optionality in the face of uncertainty.
Trust And Commitment
The principles of self-organising teams (and teams of teams) which management aligns to Purpose without micro-managing the How relies entirely on Trust. All delegation of authority does, from the moment management moves from Telling every last detail into any form of allowing those who are to do the work to have any degree of autonomy.
Trust however isn’t axiomatic and in any relationship needs to be cultivated. It is based on a confidence that when you say you’re going to do a thing, that you will in fact do the thing. That when you tell me that something is possible, I can build a co-ordinated plan on the assumption that you’re right, or if not, I will have enough warning to be able to find a workaround.
Lack of trust is generated from the opposite. I had an infrastructure lead on a program who gave me expectations that were consistently unmet. Every time, they would come back to me with reasons why the work wasn’t completed to the expected quality on anywhere near the expected date. Usually (at best) a day or two before the expected date. I therefore did not trust any date I was ever given for infrastructure, and learned to protect myself and my wider co-ordinated efffort with a 100% contingency margin.
What made this painful was not the absolute amount of time required: it was difficult work in a domain of significant innovation. It was that I could never rely on any date given to me, and I was never given any time to be able to respond to emergent delays: they were always bounced on me at near zero notice.
I therefore did not have that sense of honesty and fairness, that duty of care to the wider program. It always felt like they were optimising for their own local needs, and suboptimising for the higher organisational needs. This made it hard to trust anything they were doing, and forced me to inspect at far more detail than I wanted to. Turns out I was justified in this too…
So when we’re working in a context of high uncertainty, what do we do? Well, it’s back to diligence, honesty and fairness. Let’s have a transparent conversation about knowable risks. You’re using a new product, straight out of the labs? Well, what are the chances it won’t perform as you expect? Pretty high I’d expect, even without being able to predict what the problems might be. So, what’s the contingency plan? Build in enough time to the date you give me to spend effort getting it up and running through all the teething trouble, and then add more time in case that doesn’t work to find a less functional but more reliable alternative.
Either way, have a view long before the date you promise me about whether it’s going to be OK or not, and if not, have enough time to do something about it, rather than simply pushing all your risk up and making the whole program brittle.
In other words, build margin into your commitment
Like The Don says:
F5 Use a regular cadence to limit the accumulation of variance
F6 Provide sufficient capacity margin to enable cadence
F7 Use cadence to make waiting times predictable
What cultivates Trust is consistently making and meeting Commitments. This elevates Commitments to amongst the most important things we can do.
Recommend this post
Latest posts by Martin Burns (see all)
- Christmas Reading: 6 Books That Will Change Your Thinking - December 22, 2017
- Now Is Not The Time for #NoProjects - December 14, 2017
- Speaking at Agile In The City London 2018 - November 27, 2017