Oil workers

This article talks about commitment.    Not  commitment as in the thing I might have fled from as a man in my early 30’s clinging to the notion of eternal freedom, but commitment as in one of the Scrum values

In the Scrum Mastery Pathway Community we were trading thoughts on questions a Scrum Master might be asked at interview, and recalling the commitment question at one such event prompted me to explore further what this word should actually mean.

As a Scrum Master you’ll likely hear things such as ” the sprint commitment”

Perhaps something like “How can you help a team to commit to their work ?”

I want to open up what might be for some, a fresh line of thought around the way this word is used.

First is the conflation of the word commitment with the concept of certainty.

“That’s a committed date (and you have no option but to to meet it).  Or “But you’ve committed to it (and now it’s late)”    Ever heard that ?

In these examples, commitment is being conflated with an attempt to predict certainty.   Perhaps wheeling out the word in that way is intended to convey a certain gravity to the situation, or level of control over the future which is saved for special occasions.

To me this sounds like another way of saying – this problem is on you.  In which case, thanks but it doesn’t make your thing any less late, or solve the problem now affecting both of us.

Now sometimes committed does mean non-negotiable

It’s true that a big event, a major product launch or a legal change is usually a ‘committed’ date but even deadlines like that aren’t always as fixed they appear.    For a long time in my training and coaching teams, I was able to cite the Olympics as an example of a totally immovable deadline.   That was until Tokyo 2020  ran in 2021.

Now the forces causing an Olympics deadline to move were way beyond comparison with the forces that make a Scrum team not land the goods on a deadline (I am deliberately not using the word ‘late’), but it’s true that for most teams there is a point beyond which they have no influence to change a date.

So they just have to meet the ‘committed’ date no matter what ?

Well, let’s see. If you’re in product start-up, shipping new product versions and features frequently,  the exploration factor will be high and the absolute commitment of dates for any specific thing, probably low.

Even where Scrum is used for a long term project, each sprint gives the team multiple ways to reach their next stepping stone towards the bigger goal.

The team commit to the sprint goal as an incremental step.   It comes with negotiation, flexibility and discovery, over the element of ‘guarantee’.

That doesn’t mean the commitment is any less strong, but what I’m doing here is trying to de-couple the word commitment from certainty.    I emphasise – not that teams should avoid ‘commitment’ but rather qualify their relationship with it, and really think about what it means.

Commitment Means Committed to the Cause

It means a full effort, a promise to give the goal the best you can find in yourself, in pursuit of reaching it.

In the organisational context, it means a promise for a team to do everything in their power to achieve the goal, and also a promise to escalate and seek help as soon as they feel that achieving the goal is at risk.

That second part of the phrase sometimes takes a hit.     That  promise to escalate and seek help.   Often teams get bogged down, because they feel they have, or have been “committed” and yet they are struggling with something.   That pressure can exacerbate the struggle, lose even more time and cause mistakes or shortcuts.    Remember that escalation route is available, it’s the team’s  request for help route.   If requesting help will increase the chances of achieving the goal, then to do so is part of the commitment too.

But that will only work if the next part of commitment is present.  The part you probably don’t hear about too often, but as a positive disrupting force in the organisation, you might wish to find ways to tactfully promote.    It’s this:  ccommitment is a two-way thing.  It’s not that the teams commit to a goal, and that’s it.  The Leaders, who are typically the folk who have been involved somewhere in requesting the results of that commitment, have a part to play too.

Leaders must match that commitment with their own;   “we as leaders promise to do everything in our power to help you , the team, achieve the goal.   We are as invested in this as you are. Your impediment is our problem”.  That includes the smart blend of keeping out of the way, yet being immediately there with their Leader powers when needed.

That’s a powerful combination, and was one of the inspirations  behind Scrum.  In the New New Product Development Game, Nonaka and Takeuchi tell us of several Japanese companies who basically did what I’ve just described:  These teams were empowered.   They  demonstrated commitment and had the commitment of their leaders to provide what the teams could not provide for themselves.

Those leaders set the teams a goal,  gave them what they said they needed, and then otherwise kept out of the way.  It largely worked.

Being able to empower the teams to commit confidently, and being respected in the organisation so you can have the sometimes brave conversations necessary with the leaders to help create accountability,  are skills which will help make you a great Scrum Master.   Empowering and Respected are two of the aspects of the RE-TRAINED model on which the Scrum Mastery Pathway is built.

I hope that’s given a new view of a word you’ll hear a lot of when working as a Scrum Master.

Some commitments are indeed fixed, immovable things.

Commitment isn’t a guarantee that a goal will be met, but a promise to do everything you can to do so, and to escalate immediately you think the goal’s at risk.

Commitment is a reciprocal thing, matched by leaders and managers on hand to help their teams reach their goal

Next time you hear the word, pay attention to which of these aspects you’re seeing, and which you’re not

Thanks  for reading

This article was originally published by Martin Lambert on the Agile Mastery Institute blog