Is this Scrum implementation really too formal?
I am a Scrum Master in a team composed of people who had not previously worked with Scrum. I introduced Scrum to them, and we’ve been working this way for nearly two years. Since we are a distributed team (only myself and one developer work on site), we use an MS Teams group for team communication (PO, SM, Devs). As we agreed the Product Owner uses this group to communicate he needs to change the scope of the sprint, usually adding an urgent request. The developers then assess whether adding a new urgent requirement to the sprint threatens the sprint goal, and whether there is a need to renegotiate the sprint scope. They also size the new PBI and, if necessary, let the PO know they need additional explanations on the item.
A similar process (also on the MS Teams group) occurs when developers have free capacity during the sprint and are ready to pull additional items from the Product Backlog.
Some people say that this way of working is too formal - developers complain they cannot start working on any item from PB they want and PO complains developers does not start working on new item immediately — in my opinion, this approach is a way of ensuring transparency. Am I right?
in my opinion, this approach is a way of ensuring transparency. Am I right?
Follow that smell a bit further. You know the team. In your opinion, is there something they might be trying to hide?
I don’t believe they’re trying to hide anything it’s more likely they unintentionally surprise each other. My concern is to make sure everyone stays aligned, especially due to our distributed setup.
You're on the right track. Your approach supports transparency, respects the Sprint Goal, and ensures collaboration between the PO and Developers when mid Sprint changes occur or capacity opens up.
It may feel formal to some, but structure isn’t the enemy. Lack of clarity and shared understanding is. I see many distributed teams using MS Teams or Slack to coordinate work so it sounds like a practical adaptation, not overkill.
If frustrations are surfacing, bring them to the Sprint Retrospective. Scrum encourages continuous improvement, not rigid rules or chaos.
I faced a similar situation. The Scrum Teams needed to self-manage and plan two-week sprints, but the Support Manager frequently wanted to insert “urgent” tickets mid-sprint—often items that had sat in the backlog for months until they escalated (just saying, and that a discussion on it's own :-)).
The teams agreed to allow one (sometimes a couple) swap per sprint: a planned sprint backlog item could be replaced with an urgent support ticket, ideally one not yet started. The team was quite flexible, and personally I think this worked well and gave the Support Team enough room to act on critical escalations.
Developers complain they cannot start working on any item from the PB they want, and the PO complains developers do not start working on new items immediately."
I would classify this as a separate issue. In the case described above, the Product Owner also wanted to dictate to the team which items to work on, using urgency as a justification to keep traditional control to dictate and assign tasks into the team. In your case this is where you, as the Scrum Master, can step in and advise the Product Owner, while also helping the team stay focused on what matters for the sprint. (Possible formulating the Sprint Goal might help here.) Having a flexible team to take on urgent Support tickets, does not implicitly imply the PO can take a controlling role in task assignment.
We had a similar issue. When our management wanted to insert urgent items into a current sprint, our PO and the team discussed and decided how to manage that. We tried to replace a low priority, not yet started sprint backlog item(s) with the urgent one. So far this worked well for us.