How a Scrum team refused to suffer from commitments made by outsiders
By: Willem-Jan Ageling
Tags: Software Development, Serious Scrum, Scrum, Product Management, Agile

How a Scrum team refused to suffer from commitments made by outsiders

And how the commitments were reversed

“We need to ship this MVP within three Sprints. I am confident that we can do it.”

Bart — the Product Owner — tried to look optimistic and convincing. But Sarah doubted he truly believed it himself.

As the Scrum Master of the team, Sarah asked him: “Where does this come from? We still have many uncertainties. But even without taking these into account, it is all far-fetched. If we look at our historical throughput and at what we still need to do, we are looking at at least 6 Sprints. The chances of finishing within 3 Sprints are close to zero. Unless we decide to be flexible with the scope. Which is normal in complex environments.”

“You don’t know how it works. This date and the functionality are both promised to our most precious customer. We need to do it.”

“I am afraid I do exactly know how this works. The customer applied some pressure and you made a promise that you knew you couldn’t keep.”

“It wasn’t me. My manager Fred made this promise. I can’t reverse it. We would be losing face. But I have all the confidence in the team. They will be able to make it.”

“I also have all the confidence in the team. But I KNOW that they will not deliver the remainder of what is deemed required for the MVP in three Sprints. And many from the team even said so themselves. Also, Fred isn’t allowed to make this call. You have to reverse it. If you don’t inform our customer about what we can do and what we can’t, you will mess it up at the expense of the good name of the team and the good name of the company.”

Bart refused: “It’s too late now. We need to do what we can.”

Then Sarah said: “You have to if the team says they can’t do what was communicated.”

Later that day, Bart and Sarah discussed the issue with the Development Team. The discussion was intense, but Bart couldn’t convince the team to agree with the due date for the set of features called MVP.

“Alright. I guess this is fair. The blame will be with me if we fail, but I am still convinced you all will be able to do it. Let’s just see what happens.”

“I’m sorry, but there’s only one thing you can do”, said Sarah. You need to fix this issue now and I will help you.

By Ian Burt at Flickr

What went wrong?

Several things went completely wrong here:

The team apparently works with fixed requirements, to be delivered over multiple Sprints. This is good old project planning, assuming that the world is this predictable. This is a lesson for Bart, Sarah and the Development Team.

The team apparently fails to deliver a “Done” potentially releasable increment every Sprint. Also this is for the whole Scrum Team.

People from outside the team make promises to customers which they can’t possibly make. Bart and Sarah need to step up to clarify that this is a no-no.

Product Owner Bart does nothing to fend this off. What’s worse: he complies with the promises while this is not his call to make! He needs to be firmer next time.

Bart and Sarah both dropped some balls here. As experienced Scrum practitioners, they both should have recognised that these are all anti-patterns. There’s also the Development Team though. They also let things happen that should be unacceptable in their eyes.

How to repair this?

To fix the situation, Bart and Sarah decided to do the following:

Make the stakeholders aware of the fact that the product environment is complex.

Having established this, make the organization aware that real change is required to work in a complex environment and foster this change.

Emphasise that outcome (value) beats output (deadlines).

Inform the stakeholders that traditional product management isn’t suited to build the product in this type of environment.

Clarify to the stakeholders how Scrum works with empiricism, making decisions on what is known , not on what is assumed.

, not on what is assumed. Establish that only the Development Team can assess what can be accomplished in a Sprint. This is exactly what is brought forward in the Scrum Guide.

Make it crystal clear that both Fred and Bart crossed the line making promises and accepting these promises.

Point out that no-one can assess what can be accomplished beyond the Sprint. Because “In a complex environment, what will happen is unknown” — Scrum Guide 2017

Don’t work with a fixed scope. Instead embrace the fact that new insights can result into changes in the Product Backlog.

Aim to create a “Done” potentially releasable Increment every Sprint. This will most probably satisfy the customer needs more than a MVP on a date far in the future. It gives instant value and something to reflect upon. Something concrete.

And finally: clean up the mess. Be totally transparent and straighten things out with the valued customer.

At this point in time, Bart and Sarah are in the process of fixing the situation. The customer wasn’t happy that the promises made wouldn’t be met. But they are happy to be involved more, attending the Sprint Reviews and seeing actual functionality — and with that actual progress. Plus that they could influence what to do next.

The customer never asked for a fixed set of features on a specific date. Fred had it all wrong there. Instead they wanted to be involved more. And this is what they are now.

Bart initially was afraid that the damage of being this open would be catastrophic. However he soon thanked Sarah for helping him to reverse the situation. He learned a valuable lesson: Scrum requires a different way of working with your stakeholders. Don’t fall back into the old habits. Scrum comes with many great possibilities. Make use of them. Embrace them.