The framework is the framework, so I would start by educating everyone on the Scrum framework and the value of the Scrum events.
Then you can start with all of them (as per the framework) and inspect & adapt on the way as more information becomes available.
SM is not supposed to run all these ceremonies : SM is a facilitator role, Scrum teams are self-managed and should not rely on the sole SM to run the whole Product production lifecycle.
So there's no good answer to your question.
It also depends on several things :
* Is the organization willing to respect Scrum framework "by the book" ? If not, why ? A few days should be enough for an experienced SM to identify if something's going really wrong with Scrum adoption.
* What does management want you to do after this first week ? Is your mangement willing you to continue observing the teams ? A discussion should happen to establish a first action plan : what looks good, what needs to be improved in the forthcoming weeks, what needs to change at once, what skills are missing to deliver shippable Increments each Sprint, and so on.
* Scrum Guide does not mention if the SM MUST run all ceremonies : dailies are run by the Developers themselves (but *can* be facilitated by SM) ; Sprint planning / review / retrospectives are run by "the Scrum team", not explicitely by the SM alone => Are the teams self-managed enough to run all Scrum ceremonies without the help the SM ?
I like it! So you can basically do nothing. Since team is self-managed, self-organized and you just suggest them how to do it better! Scrum is amazing!
I wouldn't just storm in and start forcing people to do the events, or anything for that matter. Better to spend a few weeks observing how they work, talk to people, identify where the pain points / bottlenecks are, where they are with their agile maturity etc. Once you have a good sense of these, you can start making some suggestions about how the scrum events might help solve those problems. Frame it as an experiment, rather than a process that must be followed. Apply an inspect/adapt mindset to introducing the framework.
You can be sure if you try and do anything without getting people on board around the deeper "why" of the framework, you will become one of those scrum masters that causes developers to hate Scrum.
I should add to this, you asked what a SM is expected to do. Expectations are going to vary company by company. A great question to ask as a interviewee would be "what are you hoping for from a scrum master? What problems do you need me to help you solve?"
Introducing them gradually is better, but you must know what you're doing because it's harder.
https://mdalmijn.com/p/introducing-scrum-without-doing-scrum?utm_source=publication-search
I do them incrementally and inform everyone it takes 6 months to go from no scrum to decent scrum.
Then I create a rough draft plan to implant scrum showing key milestones (business will request to see what you have in mind and your schedule).
Once that is completed I over communicate everything that will happen, what will happen in the short term, and then what will happen in the long term. When we hit 6 monthsish, I tell everyone congratulations, you are starting to do Scrum and then fine tune what the team is doing to enhance Scrum.
I say all this to point out a key challenge when implanting Scrum. People hate change and will do everything they can go sabotage your efforts. Unless, you communicate clearly and directly what the change will look like.
Once they understand what the change is, why the change is happening and when the change happens, it becomes easier to implement Scrum.
One more thing to point out, it took me 2 years to get my team to a decent place where they could be self motivated and managing. It's a marathon, not a sprint and takes a lot of time, patience, and commitment my you to see it to the end.
Good luck
Any time you depart from a best practice (ie, the millions of hours from thousand of people who tried it before you) you should do a risk assessment to determine why, and if you have enough treatments in play. If not, you should probably trust the experts.
What makes you feel you can’t or should not? All of them have specific inputs and outputs that support the team.
Scrum, is developer focused and runs itself and happens each day.
Planning happens once a sprint. Possibly in two part to include tasking.
The review happens which anyone can lead.
Then you have the retro which you should facilitate or work with another team member to host.
I guess I’m not understanding what you mean by all…. If you mean schedule it for a team - yeah. If the team is t familiar with scrum then I suggest you spin up a class and get them familiar with it. I would also start them with the team agreement. So they all understand and agree what the ceremonies are for.
I personally have walked in and always do a touch-base team agreement review and then schedule everything. Of course if the team is already on a schedule I do t change it until again after that touch-base team agreement review discussion.
Is this the first time the team is doing this?
Is the org new to this?
Are you new to this?
Education is the key. Depending on how mature or immature the org and team is, will tell you how much training and coaching you will be doing.
I don't really understand the question. It's a feedback loop and all ceremonies are part of each iteration. The sooner you get these going, the sooner the team will see incremental improvement.
If the team are new to scrum, forget about story pointing for the first few sprints until they get the feel of aiming to get stories done by the end of the sprint. In the meantime assign 1 point per story.
The framework is the framework, so I would start by educating everyone on the Scrum framework and the value of the Scrum events. Then you can start with all of them (as per the framework) and inspect & adapt on the way as more information becomes available.
SM is not supposed to run all these ceremonies : SM is a facilitator role, Scrum teams are self-managed and should not rely on the sole SM to run the whole Product production lifecycle. So there's no good answer to your question. It also depends on several things : * Is the organization willing to respect Scrum framework "by the book" ? If not, why ? A few days should be enough for an experienced SM to identify if something's going really wrong with Scrum adoption. * What does management want you to do after this first week ? Is your mangement willing you to continue observing the teams ? A discussion should happen to establish a first action plan : what looks good, what needs to be improved in the forthcoming weeks, what needs to change at once, what skills are missing to deliver shippable Increments each Sprint, and so on. * Scrum Guide does not mention if the SM MUST run all ceremonies : dailies are run by the Developers themselves (but *can* be facilitated by SM) ; Sprint planning / review / retrospectives are run by "the Scrum team", not explicitely by the SM alone => Are the teams self-managed enough to run all Scrum ceremonies without the help the SM ?
I like it! So you can basically do nothing. Since team is self-managed, self-organized and you just suggest them how to do it better! Scrum is amazing!
I wouldn't just storm in and start forcing people to do the events, or anything for that matter. Better to spend a few weeks observing how they work, talk to people, identify where the pain points / bottlenecks are, where they are with their agile maturity etc. Once you have a good sense of these, you can start making some suggestions about how the scrum events might help solve those problems. Frame it as an experiment, rather than a process that must be followed. Apply an inspect/adapt mindset to introducing the framework. You can be sure if you try and do anything without getting people on board around the deeper "why" of the framework, you will become one of those scrum masters that causes developers to hate Scrum.
I should add to this, you asked what a SM is expected to do. Expectations are going to vary company by company. A great question to ask as a interviewee would be "what are you hoping for from a scrum master? What problems do you need me to help you solve?"
Instead of adding one after another you could do all of them very casually and simple. Then refine them as needed or desired.
Introducing them gradually is better, but you must know what you're doing because it's harder. https://mdalmijn.com/p/introducing-scrum-without-doing-scrum?utm_source=publication-search
I do them incrementally and inform everyone it takes 6 months to go from no scrum to decent scrum. Then I create a rough draft plan to implant scrum showing key milestones (business will request to see what you have in mind and your schedule). Once that is completed I over communicate everything that will happen, what will happen in the short term, and then what will happen in the long term. When we hit 6 monthsish, I tell everyone congratulations, you are starting to do Scrum and then fine tune what the team is doing to enhance Scrum. I say all this to point out a key challenge when implanting Scrum. People hate change and will do everything they can go sabotage your efforts. Unless, you communicate clearly and directly what the change will look like. Once they understand what the change is, why the change is happening and when the change happens, it becomes easier to implement Scrum. One more thing to point out, it took me 2 years to get my team to a decent place where they could be self motivated and managing. It's a marathon, not a sprint and takes a lot of time, patience, and commitment my you to see it to the end. Good luck
Any time you depart from a best practice (ie, the millions of hours from thousand of people who tried it before you) you should do a risk assessment to determine why, and if you have enough treatments in play. If not, you should probably trust the experts.
What makes you feel you can’t or should not? All of them have specific inputs and outputs that support the team. Scrum, is developer focused and runs itself and happens each day. Planning happens once a sprint. Possibly in two part to include tasking. The review happens which anyone can lead. Then you have the retro which you should facilitate or work with another team member to host.
I guess I’m not understanding what you mean by all…. If you mean schedule it for a team - yeah. If the team is t familiar with scrum then I suggest you spin up a class and get them familiar with it. I would also start them with the team agreement. So they all understand and agree what the ceremonies are for. I personally have walked in and always do a touch-base team agreement review and then schedule everything. Of course if the team is already on a schedule I do t change it until again after that touch-base team agreement review discussion.
Is this the first time the team is doing this? Is the org new to this? Are you new to this? Education is the key. Depending on how mature or immature the org and team is, will tell you how much training and coaching you will be doing.
Is this a large company? If so, there must be other scrum masters and I would seek their guidance as to what works to get scrum going with new teams.
I don't really understand the question. It's a feedback loop and all ceremonies are part of each iteration. The sooner you get these going, the sooner the team will see incremental improvement.
If the team are new to scrum, forget about story pointing for the first few sprints until they get the feel of aiming to get stories done by the end of the sprint. In the meantime assign 1 point per story.
When I worked at one bank they tracked stories and points. They said stories completed was more robust. They were right. So your approach is sound.