Stakeholder controls Scrum process
I am currently working on a project with a big customer/stakeholder and recently became the Scrum Master of our team. We are a supplier company and work on a crucial project for that customer. One big issue that I see is that the customer decides the content of our sprints. We may propose something, but the customer always has the last word.
This leads to several problems: the official Sprint timeslot is determined by the customer, and the developers don't even take part in the "official" planning. After the planning is done, they get notified about what has been decided on.
It is hard to bring our meetings into a good order. We have the review with the customer in the morning, and after that their planning takes place. I asked the customer to change the timeslots and let the developers plan the Sprint, but they say these are fixed and we cannot do something about it. They also say our Sprint length is fixed because we have to be in sync with other teams in their company.
I am not sure where to put the Retro since we also need to schedule a pre-planning in advance of the customer planning to make sure what they plan goes in the right direction. Also according to the customer, our pre-planning should happen as early as possible.
Our development team is great, and they do good work, but to me it feels very restricting and of course, prevents us from really doing Scrum.
Did you experience similar scenarios where the process was very much controlled by the customer/stakeholder? And do you have any ideas on how to make the best out of this situation?
All thoughts on it are highly appreciated, thanks!
You're right that Scrum isn't being implemented. They're doing something else and can expect different outcomes as a result.
Whatever the current set-up is, are they happy with the outcomes they are getting from it? If so, that's great, and the best thing you can do is to encourage them to stop pretending it's Scrum. After all, the time may come when they actually need the framework, and there is no advantage to be had in sabotaging the organizational understanding of what it is.
I understand your frustration. Projects can often end up being Scrum in name only.
What you can change may depend on contracts and the relationship with the customer. As a Scrum Master, you may not control the process, but you can still advocate for change and explain the benefits of working closer to Scrum.
If you are able to influence things, this is what I would suggest.
Have a Product Owner who represents the customer’s view. The customer provides a prioritised backlog through the PO, but does not plan the Sprint for the team.
During Sprint Planning, the Developers select the work from the Backlog they believe they can complete, and build the Sprint Backlog.
Given your current situation, you may need to work within the current structure for now. I think your pre-planning is a good strategy to align as a team on what is feasible before the customer planning session. After the customer planning, if you not already doing so, bring the team together briefly to give the team space to take ownership of the Sprint Backlog and align on how to deliver.
On Sprint length, some level of synchronisation with the customer may be reasonable. I would not be too strict on this, as organisations often align Sprints along internal processes, and this should not take control away from the team to decide team sprint events. The Scrum recomemdation is to have the retrospective at the end of the sprint, and maybe align the pre-planning around the sprint review.
I completely agree with Ian.
It is not about implementing Scrum correctly, but creating excellent products in a short space of time.
If that's the case, don't change a thing! Just try to optimise the current system.
It's certainly not Scrum, but it may still be effective.
If issues arise during the retrospective or elsewhere that stem from this predefined approach, or if you identify things that would work better with a different approach, that should be the starting point for a discussion rather than just discussing whether Scrum is being implemented correctly.