And how you can use it as a powerful tool in your stakeholder collaboration.

Earlier this week: This Tuesday starts like many previous ones. Emily and her team finished the Daily Scrum and are walking back to their workplace with a fresh cup of coffee. At that moment they hear a familiar voice behind them. It is John, the Product Owner of the team. He‘s’ a little flushed, and he even appears a little out of breath.

“Guys, girls, good to see you. I have to ask you something. That new piece of software we talked about last month, you are 100% sure it will be completely finished in 4 sprints, Right! The business really needs it because the marketing campaign is planned to start first of October“

Emily and her colleagues look at each other and then she responds,

“Well, John, as you know, that was the estimate we made based on the knowledge we had back then. Given what we have come across in the recent sprints on unsuspected surprises and extra complexity, we can not promise that. This can’t be a surprise to you IMO. We’ve communicated that in our last sprint review too“ “Oh my god, this can’t be true..”, John exclaims. “We have to deliver these features completely and on time otherwise we’re screwed!”

Recognizable? Probably! People like certainty. They ask for estimates and make plans based on those estimates. Yet, estimates have been misused for decades by a lot of managers who then hold the team accountable as if they were the actual deadline.

As a counter-reaction, you now see that teams no longer want to make any estimates or predictions. (see for example the emergence of #NoEstimates) Although understandable, because teams don’t want to be accountable for unachievable expectations. There is of course a need for predictability from a business point of view. This predictability is needed to provide a degree of certainty in business operations and, in my opinion, Scrum is not at all opposed to that.

“ Scrum employs an iterative, incremental approach to optimize predictability and to control risk.” — The Scrum Guide 2020

“Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month.” — The Scrum Guide 2020

It’s not by accident that Scrum Teams commonly measure their velocity. They want more predictability. If velocity is used to increase transparency to stakeholders, and as a way for the team to inspect and adapt, then it can certainly offer value for a Scrum Team.

It is much more interesting to see why the business wants to achieve predictability by asking for estimates (read, “deadlines”) from teams. What is the root cause of that pressure on issuing estimates in order to enforce predictability?

If you don’t give those Scrum Teams a deadline, they just do what they feel like. — A manager I worked with -

Last year around this time: After the presentation from the division director about the new organisational structure, William and Jenna are walking out of the room.

As they move to the door at the back of the line, William whispers to her: “Well, if you have to believe director Davis, those IT people will soon be able to decide for themselves how they deliver functionalities that ensure that we achieve our campaign results.” Jenna rolls her eyes for a moment, “yes, pffffff, like if those nerds understand how things are going in the real world where we earn our bucks!”. “and what amazed me even more, is that they are now setting up John as a” Product Owner “. I understood that role has to translate all our wishes and prioritise them to those teams. John !!!, that guy has never made any sense since he has been working here.“ Exactly, William agreed ”Well, it’s all fine by me if he wants to do that running up and down from us to IT, as long as I get my bonus at the end of the year “

This is something I still see happening more often. Management decides to set up Scrum Teams. Roles and names are displayed in an Excel file, we organise a kick-off to ‘motivate’ everybody and….. Feedy, Fidey, Fodey, Fum!! Everyone should work as described in the Scrum Guide. It would seem clear to me that implementing new organizational control in this way will always fail. For people like William and Jenna, that failure probably becomes a self-fulfilling prophecy.

Scrum is Lightweight; Simple to understand; Difficult to master.

By simply setting up a few Scrum Teams at the IT department, appointing a few liaisons with a sticker “Product Owner” on their chest and following the events without changing the environment wherein this new way of working has to fit, you will not get there.

The stakeholders should also adapt to the new way of working. This requires involvement, commitment, and transparent communication throughout the organisation. Often that is one of the most difficult parts to do in an organisational change. If that doesn’t happen, however, the business will continue to watch from the sidelines suspiciously and shout out deadlines (disguised in requests for estimations).

The other way around, the resistance from the teams to the issuing of estimations will only increase. In this case, there is a lack of confidence at the core. In such an environment, the phrases from the Scrum Guide I mentioned earlier on predictability will be used as a goal in itself. The business will point to it and say, “you really wanted to work Scrum? Well then, be predictable!“ The team will often say, ” We can only be predictable if you show up at the events, we can discuss exactly what you want and come up with your expectations on time “ The business will use the estimates as deadlines and the team will start over-estimating to build in enough slack. Something that will help nobody!

Conversely, if all stakeholders are involved and committed and there are good substantive personal discussions and attunements, this also requires something from the team. They will therefore have to be able to start coming up with increasingly better expectations on which further business operations can be coordinated. That does not need to be as difficult as it might seem at first glance. In just starting by collectively maintaining the discipline of all Scrum events, and using them for their intended purpose (inspect, adapt, communicate, improve), then step by step, sprint after sprint, the knowledge of the matter will grow for all those involved. As a result, the estimations and thus predictability will become a means for the team to achieve the goal of delivering valuable outcomes to the user. The secret sauce for this achievement? Trust! Trust each other and trust that together you get the job DONE.

In this way, I believe that the subject of predictability, in a badly collaborating environment, can be looked at as a goal in itself and even become a toxic subject to further increase the communication gap. While being predictable as a team in a well-collaborating environment is a powerful tool to increase trust and add value to the joined organisational goals.

So predictability can be a powerful tool to drive collaboration and trust. Just keep in mind that “predictability” itself is not more than that, a tool, a means to an end. Because in the end, what matters most, is not if a team predictably deliver what was “promised” but rather if the customer sees value in what was delivered. You could deliver all you promised and still have an angry customer. You could also deliver less and have a delighted customer :)

p.s. Do you want to give a kickstart to clear mutual expectations? Then consider trying this exercise with your team “What I Need From You”

Acknowledgements for inspiration: Dave Rooney, John Lafleur, Norberto Herz.