Blame Scrum: Part 1

Do any of these situations sound familiar:

• You need to tell a stakeholder that they can’t introduce a change into the process.
• Team members are being approached by stakeholders who want a small, new feature added immediately “just this once.”
• Team members insist they talk often enough and don’t really need a daily scrum every day.
• Someone questions the need to get product backlog items done by the end of the sprint.
• Management won’t assign and empower a product owner but instead wants the team to take direction from five “product owners.”
• Some big boss wants to borrow two people for a special project.

Scrum Masters are often put in the position of having to argue with a boss or other powerful person within the organization in cases like these. So saying no in these situations can be difficult.

 

When you have a hard message to deliver (like telling a stakeholder the team can’t slip in a change “just this once”), a good way to deliver the message is by blaming the process.

 

When someone asks for something that goes against the values of agile, which your team is trying to live by, simply say something like:

 

I wish we could do that. But we’re using a new process and it says we can’t. And since we’re new to the process, we’ve all agreed that we’d do it by the book until we’ve done it enough that we know what changes to the process are appropriate to make.

 

By blaming the process, you shift the target of someone’s frustration from you to the process itself. If the person accepts the premise of following a process by the book until the team has sufficient experience, the person has to accept the conclusion.

 

In addition to advising Scrum Masters to respond this way, I’ve also had good success over the years having team members deliver the same message.

 

For example, if a team member is asked to immediately add an unplanned feature, no matter how valuable (or not) it might seem, the team member can respond, “Wow. That’s a brilliant idea, and I’d love to get started on it. But our process says that I can’t without being told to do so by our Scrum Master and/or product owner. And we’ve agreed to follow that process to the letter for a bit. So, I can add it to our product backlog for you. But you’ll need to get one of them to tell me to stop what I’m working on and switch to this.”

 

This is a much easier message to deliver than expecting a developer to deliver an outright “no” message to the stakeholder.

 

And, stated this way, it’s also a good thing for the product. Blaming the process will either redirect a conversation toward a Scrum Master or product owner or it will force the requestor to be frustrated with the process rather than an individual team member.

 

And that will help you succeed with agile,

 

Mike