New SM for Dev teams

Aren’t the key points underpinning the Scrum Master role covered in the Scrum Guide?

Hi Jessica,

There are no "receipts" to that. With my experience working as Scrum Master (and also using JIRA), I'll try to list to you what helped me all these years.

In short words: Learn the theory, follows your heart and do the best to your team "shine"

1 - Read the Scrum Guide, try to get knowledge of the theory

The best way to start os to get knowledge of the theory. If you don't do that and also if your company is not mature in Scrum, you'll end doing a lot of work that is not your role. And this will impact in your team deliveries/qualities.

2 - Events

You'll need to facilitate all Scrum Events (planning, daily, review and retro).

But don't forget, you are not a manager! Don't try to micro-manage it. You are in the team to facilitate and help them to become the best they can do and also removing all kind of impediments, then your team can "shine" :)

3 - Follows your heart

 Put yourself in the skin of the development team. Imagine how you would like the scrum master be and how it will be the best for your team. And do the best for that.

There is no rule more important than another in scrum, you can imagine it as: SM 33,33%, PO 33,33% and Dev 33,33%

But who will deliver the product to you is the dev team, so, do your best to shield it against external factors that will impact in sprint goal.

Imagine in football, you can be like the "coach" that will do the best to the team earns all the soccer matches.

4 - Innovate!

Unfortunately, in my experience, after some time doing the same events, the team gets tired and don't interact much.

They are there with the body but the mind is in somewhere else.

You will see that each team has its own way to cheers up, but in my case:

- Sprint Planning: I got problems in sprint planning that the team didn't want to interact. As I'm the older scrum master in my office I started to coach new scrum masters. I mean, I nominated one analyst as our scrum master (ofc, with approval of my organization) and she started to learn more about scrum, to planning the sprints, to remove impediments from the team. This brought more energy and new ideas to the team.

- Sprint Retrospective: My team never liked the sprint retrospectives (and to be honest it is the event that I like the most, because it is here where the team improves its problems and start to be more mature). They wanted to remove it and the way I was able to do it more interactive was to create a document "Sprin Review". This is a document where we analyze how the sprint was, the historic of the team, etc. And it is really easy to do that using JIRA. I do it like:

1 - Open a search and follows: sprint = XXXX

2 - Extract ALL data to excel (there is an option there)

3 - Paste the values to an excel template (I have it, if you want I can send an example to you, just send an e-mail to me in jhenrique.domiciano@gmail.com)

4 - Adjust a few values

The in this report you'll have:

- General comments;

- Work Ratio;

- Team Progress (what was planned x what was delivered);

- Story Points Deliveries (Historic of the team, helps in sprint planning);

- Average Time (this is particular of our work, maybe it won't if in your team);

- Time wasted because of blockers;

- Burndown Chart;

- Team Profile;

- Fun Retro

I hope I could help you :)

I enjoy focusing on the servant-leadership aspect of the role. By establishing the necessity of you to work for the team and supporting them in the journey of the Scrum Team to become successful and sustain it, you will obtain opportunity to reiterate the value and purpose of each Scrum Event and Artifact.

To me, that's about as 'hands-on' as you should be. As you go through the Events, make it clear what elements are required and which role owns specific activities. Maybe work backwards from the Done Increment and their Definition of Done and Working Agreement? That should lead you down a path of asking questions and reinforcing trust about the intent of those questions.