Case: How would you act? Weekly Scrum instead of Daily Scrum
Hi,
Just recently we had a team-building day with the two scrum-teams in our department. Both teams operate slightly different. "Team A" consists out of 8 people (including PO/SM) and has 4~5 Sprint Goals. "Team B" has 6 people (I'm the Scrum Master) and has focus on 1~2 Sprint Goals. During the team-building day Team A suggested a "Weekly Scrum" instead of a "Daily Scrum", reason; we are working on different subjects and don't have to update eachother on a daily basis. I was kind of surprised that they came up with this idea and also the manager(of the two teams) welcoming the idea of experimenting with this.
My idea of a Daily Scrum is that it increases communication between team members. Synchronize efforts, identify (potential) impediments, inspect progress to goal, etc. But it also inproves transparency and gives better adaptability.
After some discussion it was decided to do the experiment for one sprint for both teams. Despite the fact that Team B wanted to hold onto the Daily Scrum.
In my opinion it is the symptoms that are taken care of in Team A, and not the real problem (cause). They don't have focus and have "two teams in one team" working on different subjects. Also this experiment has influence on Team B.
My questions:
How would you act, as a Scrum Master, regarding this experiment? (Imagine you were the SM in Scrum Team A, and when you were SM in Scrum Team B)
Would you allow this to happen?
What would your advise to the manager be?
If you would like to know more, let me know.
Kind Regards,
Joost
Right now, you don't have Scrum Teams. Maybe these teams want to become Scrum Teams, but there's quite a few deviations from what is described in the Scrum Guide. It very well could be that Scrum isn't a good fit for these teams in the context that they are working in, but there's not enough information to know for sure.
Looking at this particular problem, though, I'd start by trying to understand the relationship or dependencies between these two teams. If these teams are working on separate products for separate stakeholders, then it's easier to decouple their practices, regardless of what those practices are. As soon as there are relationships, though, you want to consider how those relationships affect the product and the ways the teams interact with key stakeholders. Knowing these dependencies can also help chart a path forward for these teams in defining their ways of working to see if the teams have to interact with each other at all.
In parallel with that, the biggest problem is not the frequency of synchronization within the team, but how fractured the team is in terms of work. It may not even be a team at all. 8 people working on 4 or 5 goals isn't conducive to working together as a team. It would be useful to understand what binds these 8 people together and how to best organize the people around the work.
I'd be hesitant to support experimentation without specific outcomes to evaluate the experiment against. It does seem like there are bigger impediments to success than how frequently the team gets together and adapts their plan against reality, though, that should be solved first. Those solutions may offer additional guidance on who should be meeting and how frequently they should meet.
Team A" consists out of 8 people (including PO/SM) and has 4~5 Sprint Goals. "Team B" has 6 people (I'm the Scrum Master) and has focus on 1~2 Sprint Goals.
No it hasn't, neither of them have. As you already suspect, what you've described is no focus at all. In Scrum each team should have a genuine focus on one Sprint Goal, each and every Sprint, which makes the selection of work coherent and gives them a reason to work together as a team in the first place.
A good Daily Scrum is 15 minutes out of a busy day for the Developers to stand aside from all of the buzz and ask "where are we now in terms of our progress to the Sprint Goal commitment we have made. Who among us will be doing what over the next 24 hours?"
It's little wonder that the Developers are questioning the value of a Daily Scrum when the Sprint Goal lacks coherence to begin with. That's where you need to start. What significant risk or uncertainty in this complex challenge is worth the Developers working on together, this Sprint, at all?
Scrum is not a project or time management system. It is a framework that helps use empiricism to deliver usable increments of value. What you have described sounds very much like an old fashioned project management situation where each developer is working on one line of the Gantt Chart. It also sounds like a service organization where each developer is working on completely unrelated issues. You may be in a situation where the Scrum framework is not what the teams need to be using. Perhaps you should investigate Kanban as an alternative. It would allow each Developer to pull work into process as they have bandwidth. The goal is to move items from start to finish in the shortest duration as possible and works well with things that are not directly related.