How do I convince a team to follow the Scrum Guide?

Question

I have recently joined a new team in a new organization that is supposedly using Scrum.

This Sprint, the BA/Scrum Master has decided it would be best to do the planning session for 1 hour on Wednesday morning, and the retrospective on Thursday afternoon for 1 hour. Obviously this is backward. The reasoning behind this decision seems to be that the last retrospective was "too long" (around 2 hours).

I tried to argue the case that we need the retrospective before the planning as there may be improvements/tasks/adaptations that come out of the retro which could affect the planning/capacity. It was decided that if this was the case, that we would have another "mini-planning" session after the retro to re-prioritize.

Can anybody help me construct a suitable and convincing argument to stop this madness?

Answer 1

Choose your battles carefully

You mention you are new to the team and new to the organization. It will take some time before the team fully trusts you and your judgement. If that has already happened then you have more arguing power to support your point of view. If you are still very new, then have patience and wait a while. It's also very important to measure your words when arguing your case. If you used words like "stop this madness", like you used in this question, your message content may have been dismissed and attention only payed to the way you transmitted it. Combine that with the fact that you are new and your opinion may be ignored until you truly become one of the team.

My suggestion would be to let it slide this once. You said what you had to say, you didn't manage to convince them for now, just accept and continue with your work in the new sprint.

Use the next retrospectives

Having the sprint planning and the retrospective reversed can cause waste and it can be inefficient. But there is a difference between "it can" and "it is". Have the meetings as instructed then at the next retrospective raise these two points:

• the retrospective should be for the sprint like a dot is for the end of a sentence. Having planning makes you think and sets a context for a new sprint. Then you go to work on the new sprint and then, the next day, you need to do a context-switching and discuss the old sprint. This is inefficient. To keep with the analogy, you are setting the dot in the middle of a sentence like this.
• let the "mini-planning" extra meeting occur then at the retrospective mention that it caused waste and propose again to have the meetings in their proper order. If the waste doesn't occur, just wait until it does, then raise the issue.

You should then all discuss ways to improve these points at the retrospective, with the obvious choice of switching the meetings. If everyone in the team really wants to improve things, they will do the meetings like described in the Scrum Guide. And like I said, chose your words and your battles carefully. Make it about improvement of the work. You don't want to make it about you being right and them being wrong because if that happens you'll have an event harder time of convincing anyone of anything.

Answer 2

This shouldn't be about following the Scrum Guide or doing Scrum, but effective practices. Scrum is a framework that has been demonstrated as useful for a good number of teams and organizations in a variety of contexts. It's not the only way to build and deliver complex products or services.

In this particular case, the problem appears to be that planning occurs before the retrospective from the previous iteration. I would ask the team that, if they were to make this change, how they intend to incorporate process improvements into their iteration planning process. Even if you aren't using Scrum, there's a reason why the retrospective is at the end of a Sprint, and that's to enable the team to include improvements in their planning and to enable continuous improvement.

As far as the duration of the events goes, a 2-hour retrospective may be on the long side. It depends on how frequently you perform the retrospectives as well as what kind of issues you encountered since the last one that may need deep discussion to understand causes and develop solutions or changes to improve the team's way of working.

The idea of a planning session, a retrospective session, and a replanning session is wasteful. This adds context-switching and takes the team away from the ability to focus on executing on their short-term iteration plan. Effective retrospective and planning sessions would be less wasteful.

Answer 3

The fact that the retrospective seemed to take "too long" suggests either that the team found a lot of room for improvement in what they had done or that they didn't make effective use of the time during the retrospective. If it's the former then that seems to be a strong argument to complete the retrospective before planning. Take a look at the outputs of previous retrospectives and the evidence of how the team adapted their way of working as a result.

Regarding a "mini planning" meeting. If the sprint goal and scope are unaffected then the team ought to be able to add items to the sprint backlog during the sprint without a separate meeting. Adding new tasks to the sprint backlog often happens during the daily scrum. The only real reason for another sprint planning event would be if the team found that some forecast deliverable was not going to be achievable because of some unforeseen difficulty. Again, if that is expected to be the case then maybe that supports the argument for doing the retrospective before planning.

Answer 4

Bogdan has answered this well and to expand on one point, I do feel the argument to flip the two meetings should be based on findings from previous retrospectives. Gather feedback from the team beforehand and collate your reviews and lessons learned from the previous sprint release(s). If the complaint is that the meeting runs for 2 hours, do a mini-meeting and create an agenda that you can stick to which covers the most salient points. Have short-hand notes for earmarked events that you're likely to be questioned on in the next retrospective session. It can then remain brief and stay within relevance.

Answer 5

"Step carefully, padewan ... You're new to this situation." Watch and learn. Don't call it "madness" yet, especially not within their earshot! ("Walls have ears.")

Look for small improvements. Look for people that you can talk with, "off line," with the aim of making your ideas become their ideas.

If you're surrounded by "madness," look for the one thing that seems to be "the most mad," but also "the most improvable in the short term and with small steps." Diplomacy, diplomacy, diplomacy. What do you think would seriously improve that situation, and how can you then make it someone else's idea?

Finally: "The Scrum Guide" is exactly that: "a guide, not holy writ." It contains a bunch of good ideas that have found to work really good in some situations, which may or may not quite be "this one." Your actual implementation of its guidelines might or might not be "by the book," and to me that's okay.