I am a new scrum master for my company and we're trying our first few sprints. The dev team has had non-mandatory stand ups for a while which people attend infrequently at best. Now that we're doing actual sprints I've tried to get the sprint team to come to the stand ups but no one will. What do I do?
I don't think telling people to attend meetings is a great pattern.
Explaining to people the benefits of attending & then have them want to attend is a far stronger tactic & more likely to bring the improvements in process that agile offers. Offer insights & info in the meeting that are unavailable elsewhere - treat the session as special & attending the session is a benefit not a chore.
Having said that if the group needs the agile process to work then there is a need to explain that all the agile ceremonies are a package - attend them all or attend none - only people fully involved in the project can remain on the project.
So if you want to be involved in the project you need to attend the planning session, daily standups & other regular events.
There are some people who want a task list, put their headphones on & want no more team involvement. People with a bad attitude will degrade an agile project & cause it to fail. So they either need to be assigned to other projects, retrained to get better engaged or finally encouraged to move on & find a new job.
To misquote Mr Ford, if people think a project will fail or think a project will succeed then they are probably right.
In my experience, the most effective way to implement Agile is to focus on the people who are most excited about it. Team excitement will spread, but there will always be those that are stuck in their ways and refuse to buy in.
Make sure that the team understands that the daily scrum is a great opportunity for the team to coordinate, identify issues as early as possible, help each other, and deliver on a regular basis. This should reduce stress, and as soon as people realize this, the more excited they will be about Agile.
It is also very important to make sure that you have buy-in from management. If you don't have buy-in yet, make sure and spend some time explaining the benefits of a successful Agile implementation. There will come a time where "the train will leave the station," and those who aren't willing to cooperate are detrimental to the team, and may not be a right fit for the team in the first place.
What do I do?
You tell them that the new "real" stand up is mandatory. If people don't show up, explain to them why it is mandatory. If they still don't show up, have their line manager talk to them. It's your job to improve the process and help them along, but it's their line managers job to make sure they do what is asked of them.
Not showing up to a mandatory meeting is just like showing up for work late or not at all. That's not about process, it's about whether this person is willing to work there or not. And that's manager territory.
As with incentivising the adoption of any new thing – make obvious and visible the usefulness of it (go for quick wins).
Make them feel that if they miss it, they will know less than the ones attending. It all depends on your team/project/business configuration really.
Perhaps introduce small agenda items to have the team share really useful information during standups. Make standups a place where some decisions are made by the team, even small ones, internal but affecting everyone?
At my company (software house) we've made Monday and Friday standups a bit longer with additional items on the agenda and it keeps up the engagement. Maybe start with that? It can be celebrating team's successes, 1minute "what I've learned?" type of thing, short general overview of where things are, or anything else that's short and can build up to your Retrospectives?
Imo forcing it or trying to bribe the team to come doesn't do much good. You'll risk having a standup full of grumpy / joking / and/or whining people if you try that.
(Impressed by all the answers that lean on authority and using a stick instead of the carrot, just wow, that's very hostile to a team collaborative environment!)
First you have to ask yourself, what is the purpose of a daily stand-up. It's to make sure that any issues encountered are taken care of and that the project is moving in the right direction. Oh wait, sorry that's the ideal for stand-ups. Usually the stand-up is used for status updates, they're made for the manager to listen to the status from each team member rather than having the stand-up being useful to the team.
If you find yourself having to force the team to do a daily stand-up, then the purpose of the stand-up is for you and you alone, you are not being a team player. The team themselves have to discover the benefits of the daily stand-up and have their own way of doing it. Maybe this means doing a stand-up only twice a week, maybe it means having a quick one just after lunch or right at the end of the day, or maybe it means just no stand-up at all.
If you're interested in monitoring a project, the daily standup is only one tool of many. You can always revert to asking individuals about status and you can ask them directly whether there are blockers or if they need some help.
Your job is to be a coach to the team, not to force them to eat their vegetables and do their daily stand-up. They need to see the benefits and adopt it for themselves; if they don't see the benefits for themselves and only see it as status updates for you, it will never be attended and adopted. This is true of all other SCRUM tools; remember it's made for the team first.
Just going to throw in another idea that may not be as popular, but has worked really well for me in my current situation. My team was good at doing stand-ups, but is mostly remote. After some discussion with the team we realized that doing the standup the way we were doing it (mandatory web meeting/call) each morning was not the most efficient, because:
- A large amount of time was for status
- It's hard to pay attention to statuses over the phone when you are distracted by your work which is still right in front of you.
- It's harder to get people to speak up on the phone to answer questions, which was were the real value of standup is.
I know this is a little different than your situation, but the key point here is the same as yours, the devs weren't seeing as much value in it.
So we broke it down. Our team uses slack to communicate, so we created a standup channel, and every morning each member posts their standup status in the channel. This has to be done before 9:30 am, which is our call time. At first we held the call anyways, just so any questions from the status updates could be asked and answered. After a sprint or two we discovered this was almost never necessary, so we stopped holding the call, although I or any team member can call for it at any time if they feel it's needed.
Why we like it:
- It takes less time. It takes 2 minutes for each dev to write their update, which they can do at their leisure instead of on the spot, and 2 more minutes to read everyone else's.
- If we do end up needing the call, it's much more efficient since all of the updates are out of the way.
- If anyone forgets what someone said, they can at anytime during the day go back and re-read that person's standup.
- It is now very clear that if we do hold the meeting (and by extension any others, because they know now that I do not like holding meetings frivolously) that it's needed, so participation and morale are better.
While this may not be inherently Scrum, I feel it is very Agile and meets the core of what Scrum is trying to do. We arrived at this process by recognizing a problem, bringing it up in Retro, deciding on a solution, implementing it for a sprint, then discussing in retro and tweaking. Not only did it help with standup, as a new scrum master to this team it helped establish the purpose and value of retro.
Bottom line, talk to your team, present the problem and maybe even a possible solution, and then adopt something and go try it. Talk about it in retro, change or tweak, rinse and repeat as necessary. To me, this is the heart of Agile.
In short it looks something like this:
- Everyone on the team will attend a Scrum Training session.
- Sprints will be one week long.
- They will start out by using my definition of "Done".
- All estimates will be exclusively in Story Points.
- We will use a physical Information Radiator.
- Sprint Planning Meetings will be four hours, once per week.
The rules remain in effect until the team has met three criteria:
- A minimum of 240% increase in Velocity
- They have completed three consecutively successful Sprints
- They have identified a good business reason to begin changing rules
You should add a rule like: We daily synchronize the team at the Daily Scrum
Let the team decide they want to execute and commit to the Shock Therapy, if not maybe get a commit from higher-management to convince the team or let them drop Scrum altogether. Sometimes an Ad Hoc process works pretty well, wonder if you really need to change it?
Currently I am the Scrum Master of a team that was educated this way and whom did 1 years of weekly Sprints, I joined the team just after they switched to Sprints of two weeks. They have some of the best Scrum knowledge and practises of all teams I have worked with over the years.
What is always helpful is to talk with every team member individually.
Try to understand why the person doesn't want to attend the meeting and try to explain to him/her why it is important to be there.
If there are particular conflicts, fears or uncertainties, then try to resolve them or follow up with management if problems require it.
The goal is to convince at least 60 - 70 percent of the team to be there.
It doesn't hurt to invite them / remind them if they are not there.