It is true… development teams don’t like me as Scrum Master. They blame me, they tell me it is my fault, they tell stakeholders that Ralph the Scrum Master said it was not good enough. Probably making the stakeholders think: “Who is that guy to decide if it is good enough?”
Why do they don’t like me? Because after one sprint of hard work, I am the one who tells them that they are not allowed to show the results of their hard work to the product owner and stakeholders. It is me who is so black and white. It is me as a Scrum Master who doesn’t understand that they really worked hard and even did some overtime!
Sometimes the product owner or some of the stakeholders ask me “Ralph, but why not, this seems so unfair?”
OK, let me explain why sometimes I am a horrific Scrum Master in the eyes of the development teams.
We all know these projects where the team reports 80% of the work as done, and when the software/framework is done, we can do everything we need to do, and even more. OK… sounds good, so let’s just wait until that final 20% gets done. For some reason, however, that last 20% of the work will then start taking 80% of the project time.
What will happen when a development team shows work done during the sprint that is not really done? Maybe they even say, it is not completely done. Trust me, when stakeholders leave the room, they will remember the software that has been shown during the demo. They will forget that small footnote, it is not done yet. So the impression is, the project is on track, everything was done.
The team will still need to finish the items that they showed during the sprint review (not sprint demo!) The work that is not done could pile up, and it will take a few days in the next sprint before they can start working on the new sprint goal. With a bit of bad luck, this will get worse over time, and also influence the velocity.
The most important reason I forbid teams to show work that is not done at the end of the sprint, there is no learning! No reason to improve! Scrum is for me all about making things visible, being transparent, and inspecting and adapting. If we don’t show to each other that we don’t have items done, why improve?
Let me tell you about a few recent examples, where I coached teams and made them have a bad day because of this.
One team committed to two items in one sprint. They estimated the items to be around 40 points. The team believed they were able to make around 80-100 points in a two-week sprint. I told them upfront, guys it could be smart to split up those items. Either the team was too stubborn or I did not explain myself clearly. The day of the sprint review came and I asked hey guys, what are you gonna show during the sprint review? Those two items? Are they done? Yeah, almost, 90%… Nope, you are not gonna show them. I used my veto and forbid it. The team was upset and blamed me explicitly during the sprint review. Fine, no problem for me. Guess what happened in the next refinement session… they split all big stories up into small stories.
A second case. One team had a big dependence on a visual designer. However, this person was overloaded with work and also reported ill a few days during the sprint. The team said we can show and report it done during the sprint review. The only thing we need to do is to do the styling, but we can explain this and do it next week. Well sorry again team, but you are not gonna show these items. They are not done. I would like you to report why it is not done, though, because of your dependency on the visual designer. You should make the organization aware of this problem, by mentioning it during the sprint review, and the impact, it will get attention. There was a second team who reported the same issue. The result was that the management team looked into, and started to get some extra project funding together to get an additional visual designer.
To make this all work, make sure you have a good Definition Of Done. The Definition of Done is used to decide if an increment or backlog item is done. In a very transparent way, the Scrum team should know what the Definition Of Done (DoD) is. As Scrum Master, you can refer to the DoD and not just because “I say so.”
I hear you thinking, Ralph, Scrum is all about inspecting and adapt, and you throw away this opportunity. True, I throw away THIS opportunity, but the moment I tell the team no you are not gonna show it, I also ask them to schedule a meeting with the Product Owner asap to show the progress to him. Furthermore, I advise them to have regular meetings between the Product Owner and team members to discuss progress. The sprint review can and should be no surprise for the product owner.
What do you think, do teams don’t like me for a good reason?
These are great points! Would like to hear what is your experience what metrics managment find most useful and accurate in forecasting project outcome vs expenditure?
I think why your development team may not like you is it’s your job to coach the team and unfortunately that means you are not on the team.
A coach (scrum master) for scrum should not be considered equivalent to that of a coach in a sport, but closer to a life coach or a speech coach. As a life coach I think you’d be considered be pretty unhelpful if you’re simply telling the person how to live instead of helping them discover what will be the most beneficial.
The team may find putting more effort in splitting tickets is where they’re best at or working with the design to come up with smaller expectations in the beginning of a new feature. They also may end up doing everything you think could help.
I think it would be better to point out problems caused in other parts of the organization, and likely for the product owner, and see what the team comes up with rather than using your veto, like you’re the team president, to stop them from making a mistake.