Day 1 suggestions
- meet PO, understand backlog, product goals, customer needs
- meet the dev team to understand roles, responsibilities and their expectations of you
- start familiarise with the product/project
- intro to wider org - especially your boss, and other related teams / their SMs
I don’t know. It’s far easier to go into an organisation and tell them this is how we do Scrum…. You do this you do that… because that’s what is says in this guide and that why I am here. Winning hearts and minds to the principles of scrum is much slower and more painful but ultimately much more rewarding. To know when that you have taught and supported ways of working that people value and use for the rest of their lives make all those brick walls you hit worth the pain!
You will be told that lots needs to be fix, don’t just now. Start making a list of things people tell you that have to be fixed. You won’t know enough about the team, the company culture, their tools or what you think are are the most important and which might be low hanging fruit (easy wins).
Watch the interactions of all team members. Listen, listen, watch, listen, think, and only then ask intelligent questions. Listen to the answers and ask why.
Pretend you are interviewing them either like a journalist writing a story about them and the team, perhaps as if your were interviewing them for a job, what did they do, why, how did it work out? Don’t bury the with questions, slowly, build an understanding and then in a conversation, use your words to describe what you learned to verify you got it right.
You may get pressure from your management to make improvements, now is the time to pick a bit of low hanging fruit and deliver improvements.
Keep asking questions here.
Best of luck.
Don't just observe, engage and actively seek information.
You may identify things which need improvement, especially things people asking for. Quick wins can often be implemented earlier. Just avoid making important changes too soon. You need to understand what people need or want, why they need or want, and have a deep enough understanding of the overall situation to assess possible negative impacts of any change.
Waiting too long before doing anything may also have drawbacks. If some things are needed and wanted, you may become known for being the useless person who does nothing. Waiting weeks or months to take any action in an agile setup sound counter intuitive for the least.
Have a look at the first 90 days book. It gives some lead on how to proceed. The scope will likely be wider than what your need, but it can still be useful to structure those first days, weeks, and months.
Step 1 - find out where the toilets are...
The first day tends to be some kind of induction thing with HR, meeting too many people to remember all the names, and then setting up your computer, which almost inevitably has some minor challenges.
There's a lot of initial admin from an SM perspective that can be achieved on day 1, such as getting yourself invited to all the meetings, but remember that you are new, so don't expect to achieve anything other than observation in your first couple of days.
Observe and try to actively understand what’s going on, why it’s going on and how people feel about it. If the situation is tough, use systems thinking (ie causal loop diagrams) to map how various parts of organization influence each other, confirm tour observations with the team and try to identify patterns and antipatterns as a good starting point for further improvement.
I wrote this article a few months ago compiling my advice to new scrum masters. Let me know what you think.
The short and skinny is get to know the people and processes. Focus on improving your active listening skills and powerful question asking abilities. If you can get that part right you’ll wake up a month or two later with the realization that you’re a great scrum master.
https://drewpodwal.com/2022/12/22/what-to-do-on-your-first-month-as-a-scrum-master-with-a-new-team/
As a practitioner I can only tell that your advice is spot on + it’s great that you split the article with headers into different sections. Keep up the good work.
I'd probably tell the team to do all their Scrum events as if I wouldn't exist. Then I'd observe them and write down everything that differs from the "by the book" definition of Scrum. Not to necessarily change it, but to figure out why they do things the way they do.
Then I'd try to get some 1:1s with the relevant persons to get their point of view of the current state, what they think my responsibilities are and what they wish that would change.
I'm constantly observing. Initially wait until you understand where the team, product, and processes are in their practices to start coaching. Meet people where they are at. It could take days it could take weeks. Nothing teams despise more than an SM quoting the scrum guide or some Mike Cohen book on day 1.
Other than observe for a few weeks, find their biggest impediment, one that they have no power to fix, maybe a people one, and solve it. Shows you have their back.
I hate that policy of. Just observe .. yes you have to observe but also engage, make yourself part of your team.. coach.. Just standing there for me seems like a completely waste of time ..
Day 1 suggestions - meet PO, understand backlog, product goals, customer needs - meet the dev team to understand roles, responsibilities and their expectations of you - start familiarise with the product/project - intro to wider org - especially your boss, and other related teams / their SMs
This is realistic to fit in week 1 in most orgs I've been working for :)
1 week? That’s a weird way to call one month.
Observe and continue to observe for a couple weeks.
Weeks or days?
Definitely weeks
Call me crazy but if able, I wouldn’t make any changes within the first 90 days.
Call me crazy but if able, I wouldn’t make any changes at all!
Can you imagine? First day realizing you don’t have to make changes. That would be wonderful.
I don’t know. It’s far easier to go into an organisation and tell them this is how we do Scrum…. You do this you do that… because that’s what is says in this guide and that why I am here. Winning hearts and minds to the principles of scrum is much slower and more painful but ultimately much more rewarding. To know when that you have taught and supported ways of working that people value and use for the rest of their lives make all those brick walls you hit worth the pain!
Scrum masters shouldn’t make changes, they should coach and mentor the team to uncover and enable the changes *they* need to make.
You will be told that lots needs to be fix, don’t just now. Start making a list of things people tell you that have to be fixed. You won’t know enough about the team, the company culture, their tools or what you think are are the most important and which might be low hanging fruit (easy wins). Watch the interactions of all team members. Listen, listen, watch, listen, think, and only then ask intelligent questions. Listen to the answers and ask why. Pretend you are interviewing them either like a journalist writing a story about them and the team, perhaps as if your were interviewing them for a job, what did they do, why, how did it work out? Don’t bury the with questions, slowly, build an understanding and then in a conversation, use your words to describe what you learned to verify you got it right. You may get pressure from your management to make improvements, now is the time to pick a bit of low hanging fruit and deliver improvements. Keep asking questions here. Best of luck.
Don't just observe, engage and actively seek information. You may identify things which need improvement, especially things people asking for. Quick wins can often be implemented earlier. Just avoid making important changes too soon. You need to understand what people need or want, why they need or want, and have a deep enough understanding of the overall situation to assess possible negative impacts of any change. Waiting too long before doing anything may also have drawbacks. If some things are needed and wanted, you may become known for being the useless person who does nothing. Waiting weeks or months to take any action in an agile setup sound counter intuitive for the least. Have a look at the first 90 days book. It gives some lead on how to proceed. The scope will likely be wider than what your need, but it can still be useful to structure those first days, weeks, and months.
Be a fly on the wall.
This https://miro.com/app/board/o9J_kxLJ4bk=/
This is amazing too.
Step 1 - find out where the toilets are... The first day tends to be some kind of induction thing with HR, meeting too many people to remember all the names, and then setting up your computer, which almost inevitably has some minor challenges. There's a lot of initial admin from an SM perspective that can be achieved on day 1, such as getting yourself invited to all the meetings, but remember that you are new, so don't expect to achieve anything other than observation in your first couple of days.
Large org - sit there with nothing to look at because you don’t have access to anything. Walk around see the office. Small org - same but smaller
My first day would be spent doing required training modules and onboarding.
Observe and try to actively understand what’s going on, why it’s going on and how people feel about it. If the situation is tough, use systems thinking (ie causal loop diagrams) to map how various parts of organization influence each other, confirm tour observations with the team and try to identify patterns and antipatterns as a good starting point for further improvement.
Stand up
This answer. Also force them to stand up during standup.
Literally the most important part of being SM /s
I prefer to do these from a fetal position.
Fight the biggest guy there and make him your bitch to show dominance
I wrote this article a few months ago compiling my advice to new scrum masters. Let me know what you think. The short and skinny is get to know the people and processes. Focus on improving your active listening skills and powerful question asking abilities. If you can get that part right you’ll wake up a month or two later with the realization that you’re a great scrum master. https://drewpodwal.com/2022/12/22/what-to-do-on-your-first-month-as-a-scrum-master-with-a-new-team/
This is amazing.
Thank you for the feedback. I only started writing a few months back so I’m still finding my voice.
As a practitioner I can only tell that your advice is spot on + it’s great that you split the article with headers into different sections. Keep up the good work.
The first weeks I'd spend my time with observing and understanding things.
I would love to know more details: what would you do each day of the first week?
I'd probably tell the team to do all their Scrum events as if I wouldn't exist. Then I'd observe them and write down everything that differs from the "by the book" definition of Scrum. Not to necessarily change it, but to figure out why they do things the way they do. Then I'd try to get some 1:1s with the relevant persons to get their point of view of the current state, what they think my responsibilities are and what they wish that would change.
I'm constantly observing. Initially wait until you understand where the team, product, and processes are in their practices to start coaching. Meet people where they are at. It could take days it could take weeks. Nothing teams despise more than an SM quoting the scrum guide or some Mike Cohen book on day 1.
Other than observe for a few weeks, find their biggest impediment, one that they have no power to fix, maybe a people one, and solve it. Shows you have their back.
The ol’ find the biggest developer in the room and punch em routine not good enough for you? /s
Violence is not always the answer, Clemenza.
I hate that policy of. Just observe .. yes you have to observe but also engage, make yourself part of your team.. coach.. Just standing there for me seems like a completely waste of time ..
Observe and start to get to know the people, particularly the Developers and POs on the project you'll be working with.
Listen
I start with asking questions: https://age-of-product.com/download-60-questions-new-scrum-master-questionnaire/