The development team refuse to split or do the scrum meeting in the morning
As a scrum master, I worked with a growing developpment team from 7 to 15 people. We had discussions about making 2 smaller teams. But the developpment team didn't want to split even if I let them self-organize. I proposed them to try for 2 or 3 sprint and merge again if it isn't better, but they didn't want to try.
I remember some readings of Mike Cohn about the CDE leading change method (Container, Difference, Exchange). As a scrum master, according to CDE, I could change the container by asking the team to split. But can I force the developpment team? It doesn't sound good.
I encountered another situation of this kind with the scrum meeting. I let the team try different schedules for the Scrum meeting and adapt it at retrospective. But during many months, they decided to do it at 5:00 PM. I saw this schedule wasn't efficient and I tried to convince them but they didn't change. After few sprints, I decided to change the scrum meeting schedule to 9:30 AM and explained why.
I don't know if I was right. It looks like a command and control behavior.
I think if I could return to the past, I propose to the developpment team to choose a schedule between 8:00 and 10:30 AM.
What do you think?
I think I'd have forced a split when the team hit 8 or 9 people. I've never known a development team to function efficiently above that size, and as a ScrumMaster I'd fear for the successful application of the Scrum method.
I don't think I would have done anything about when they hold the daily Scrum. Teams can hold a standup at midnight for all I care, if that's what they reckon works best.
Assuring the team is following the Scrum framework is part of the Scrum Master's responsibility. For that reason, I believe it would technically be acceptable.
Daily Scrum Time
Why do you feel 5pm is inefficient? Why does the team disagree? Is it really the time that is problematic?
In both cases, I think you'll be in a better place if you can come to an understanding of why these things are potentially better. Both changes are not guaranteed to be better and should be considered an experiment like any other change.
The team is before any other definition, a part of an organization. The scrum method allow then to self organize, but they are still emplyees and I don't get why they could disagree in split, when this decision comes from the management. If you are not their boss, as a Scrum Master you should have some force to ensure the split happens.
Thank you all for your visions. It help me to think differently.
The first thing I'd do is to try to understand why they don't want to split. Maybe it's something easily fixed? I'd also collect stats on efficiency if at all possible and show the team that the large scrum team size affects efficiency - if that is the case. If the team has strong, valid arguments against splitting AND efficiency is not affected maybe for that particular team splitting isn't necessary.
Daily Scrum Time
Does the time work for the Scrum team? If so, that's all that should matter. It's the Scrum Master's job to ensure that the daily scrum occurs and that the 3 questions are asked, but that's it. The Scum Master doesn't have to attend and shouldn't set the time of the meeting.
I'm not going to add much here I'm afraid, except to agree with others.
Splitting the team is something that you can take into hand as a Scrum master. Of course you are going to need management support here.
For the stand-up it's for the team to see what's best. What a Scrum Master needs to ensure is that it happens, We have teams with strange times (and I'm glad I don't need to be there too often, only when dropping in on other other teams to see how they hold their meetings) but it works for them in a way that forcing what i would think is a good time wouldn't.
If they are not holding the stand-ups - then you need to do something.
So, you've 'allowed' them to self-organize, but you are not happy that they actually do so if it means they don't do what you want them to?
Why was the expansion anyhow? Did the team decide on it?
Have a conversation, understand their reasons, help them figure out good and bad effects of splitting, help them figure where it might help them, don't draw conclusions on their behalf. Help them implement their own solution (not yours) and inspect & adapt and see how they can improve.
Daily Scrum is their meeting. What's wrong with the team having it at the time they want to?
Be careful in thinking you know better that the collective brains of 15 people.
If you resort to command and control in this case, don't you think you'll only create resistance within the team? After all, you're dealing with experts. They know their job, and don't like to be told what to do :)
In general, I would say that a team has to self-organize as much as possible. Also in this case. A Scrum Master is not a manager, but more of a servant leader. If you feel the team is making a wrong decision, all you can do is ask critical questions to try to convince them. If they can't be convinced, the best approach would be to let them experiment. If the experiment fails (flow breaks down, velocity decreases, etc), this is good input for a retrospective. Chances are that the team will eventually go in the right direction. Or maybe it turns out that it was actually the right decision.
Yes, this can be a costly experiment. But I strongly believe that in order to create high performing teams, you have to let the team make mistakes and learn from them. As a Scrum Master, you are responsible for facilitating this learning process by asking critical questions at the right time.
Oups. I didn't saw the last answers. I'm not sure you are still there but thank you all for these.
Daily Scrum : The issue with daily Scrum is that at the morning many team members didn't remembered what they told at the daily meeting of the day before. I agree with Ken Schwaber when he say in the "Agile Project Management With Scrum" book : "The daily scrum is best held first thing in the day so that the first thing team members do on arriving at work is think of what they did the day before what they plan to do today".
As many of you said, I agree the Scrum Master has to convince. He is only an advisor. But when the Scrum Team has to be very efficient in short time, it can be hard to see a team convinced that it is right :
- doing sprint planning meeting too quickly without really making a true plan
- doing Daily scrum at 17 PM
- auto-organising as component teams instead of features team on a multi-teams project
- not keeping the the sprint backlog up to date
Sure, they will probably learn from these mistakes but it could be too late. I think, if the development team is sure to be right, it can stand on his position even if the Scrum Master is very persuasive.
> Daily Scrum : The issue with daily Scrum is that at the morning many team members didn't remembered what they told at the daily meeting of the day before.
If they dont remember what they said they would work, what do they end up doing for the work day? Surely, they are doing *something* right?
Hello. I'm new here. But what if they during the daily scrum meeting said what they have done that day, and then explain what they are planning on doing tomorrow, if they are holding the meeting at 5PM? Just a thought.