Front End Developer transition to Scrum Master (Part 1/2)

I’m a UI Developer for a large company. Day to day my job involves developing new features, fixing bugs, writing unit tests, doing usability testing, doing demos of our system, attending meetings and some Photoshop work. I’ve been working for close to 3 years now in the big bad world and so far so good. I used to work in a smaller company where there was less work which served me well and ten 9 months ago I changed to where I currently am.

 

We work in an agile environment so 3 week sprints, sprint planning and sprint retro sessions, daily stand ups, quickly adapting to change, little documentation, regular communication and all that good stuff. So the team has a good knowledge of Scrum and agile. Since the team was formed we have not had a permanent Scrum Master working full time in that role. We have had acting scrum master who spend 50% of the time on the job and we recently had a temporary 100% Scrum Master on the most recent project which seems to have made a big difference. But now he’s gone.

 

So recently I have transitioned over to this new project which is cool because it uses SASS which I always enjoy working with and it is all over the place and I always enjoy a challenge. However just as I was getting stuck into the code I was asked to stand in as the 100% Scrum Master for the team!  It would be until they have found a permanent Scrum Master (probably 2 months or so). I took a day to think about it. I said yes the following morning.

 

Scrum Master is a career track that I have considered in the past. I worked for about 6 months as a 50% project manager in my last company which falls under the same realm of responsibilities. The way I see it I can’t be hurt. It’s not a permanent offer and people are aware it’s not what I was employed to work as. It’s more a favour to the team and also an opportunity for me to try it out full time. If I don’t like it? Cool, back to being a UI Developer armed with the knowledge that this career track is not for me! If I do like it, maybe there can be some conversations about further training and opportunities that can take place.

 

I have asked some Scrum Masers collocated near me a lot of questions and I’ve condensed the answers into the list below of qualities and skills a Scrum Master must have. I know the internet is heaving with this type of information but I prefer getting it from the horses mouth. I gathered information from various Scrum Maters in my office (one of whom also used to be a web developer) and compiled it into the following list of points:

 

  1. It’s the fun part of being a project manager
  2. You decide what work needs to be done and who is best placed to do it but you don’t do the actual work on the product
  3. If doing a course do the scrum.org course because it’s internationally recognised. It covers all Agile – Extreme Programming, Agile etc. It costs about €300 for the course and €30 for reading materials.
  4. Qualities needed are: Thick skinned, Empathetic, Balls (sometimes you need to tell your boss or someone else to do their job)
  5. Day to day the things you do are
    1. Decision making without having to do the actual work
    2. Facilitating Scrum Ceremonies
    3. Keeping time
    4. Following the Agile rules
    5. Dealing with arguments
    6. Conflict resolution
    7. Say yes/no to product owners
    8. Include everyone e.g. if someone isn’t talking encourage them to speak conversely if someone is dominating shut them down
    9. Lots of calls
    10. Lots of emails
    11. Lots of meetings and sync ups
  6. A lot of people don’t know what you do as in what specifically are a Scrum Master duties
  7. There’s huge demand right now (at the time of writing)
  8. It’s future proofed because everywhere is moving to agile
  9. Going from Web Dev to Scrum master is far preferable than Project Manager to Scrum Master because Web Devs understand the technical details
  10. Helping get things unblocked for the team is a big part of the job
  11. Keeping the pace with all ceremonies – knowing when to interject and say ‘we can talk about that after’
  12. Teach the team Agile if they don’t already know or need to improve
  13. You have to poke some people to do their work and you have to hand hold some people also
  14. Manage stakeholders and keep them out of problems they don’t need to be part of
  15. Sprint Daily’s, Planning, Refinement and Retros
  16. Testing changes in the production environment
  17. Occasionally conflict resolution. This will vary depending on the team.
  18. Don’t do this job if you enjoy ‘Delivering/Creating’ a product
  19. You get to work with different people in all sorts of industries.
  20. Calculate team’s velocity
  21. Calculate task complexity
  22. Sometimes there’s low value high volume work e.g. long processes, raising tickets, documenting etc.
  23. Managing the project is quite easy because of all the tools at your disposal but there isn’t tools for managing people and this can be a challenge
  24. Scrum of scrum calls
  25. Timezones can really slow down the scrum process
  26. In terms of salary: Entry level – 35+, Mid level – 55/65, Senior 65-90 (5 years – 50/55)

 

General Tips:

  • Complete small tasks immediately to avoid long lists of to-dos
  • Things don’t go to plan, get used to it
  • Don’t share all information. Think through a situation/problem and form a strategy before sharing information e.g. there’s no point telling stakeholders about a bug if it can be fixed in an hour. It’s best to avoid worrying them and risking an email thread that snowballs and slows down the project.
  • Document everything about the project – any change.
  • Help the team to get information, don’t keep them waiting. Jump on a call with someone and facilitate them being unblocked.
  • Encourage the team to talk more (without time stealing) e.g. if someone isn’t talking or saying little maybe encourage them. They could be too shy to speak but have valuable information to share.
  • Whatever project management tool being used; Slack, Visual Studio Team services etc. encourage all team members to communicate via this tool rather than walking over to them. This allows team members to prioritize their time. It also means every move is documented and can be used as a reference later.
  • Protect team members from the rest of the team. If a team member is maxed out of capacity (no time left or a full scheduled) and is being asked many questions. This team member must not be disturbed if they are working on high value changes. They can voice this themselves or as a Scrum Master you may have to notify the rest of the team.
  • Check emails once in the morning, once in the afternoon and once in the evening. If you check constantly you’ll never get around to your own tasks.
  • Make sure everybody has something to do
  • Handling a blocker: who do I need to talk to, email and jump on a call with to get them unblocked
  • Let team assign themselves stories
  • Facilitating blockers being unblocked – don’t try and figure it out, just facilitate the calls/meetings necessary to have it figured
  • Keep an eye on people’s mood etc. – it’s fine to send an email if someone needs to be left alone. But can’t give special treatment…say it at daily stand up is probably better

 

Keys to the role:

  1. Everyone has something to do and is active
  2. I’m aware of what’s blocking us and getting unblocked as quick as possible
  3. Keep track of blockers
  4. Set up call
  5. Have a general idea of people’s stories
  6. Putting plan in place for if we’re not going to get to stories done
  7. What’s the highest prioritise and reprioritise
  8. Prioritise backlog (should already be prioritised) because sometime it’s not
  9. Stories going into next sprint, they’re prioritised, stories have enough detail,
I start tomorrow…
Links: