The Scrum master role (advanced)

So let’s start from the basics. As we all know the Scrum books mainly describe the role of a Scrum master as:
- Facilitator / host / organizer
- Impediments remover / support

…And as we all know (again) nowadays there are two major types of Scrum masters hired in the development industry. The first one, we may call Scrum 'masteloper', is part of the team as a developer and contribute directly to the development of stories/tasks. And usually the person is struggling to find the balance between development and Scrum activities. The other type of Scrum master, I also consider part of the team, might not be a developer or should not contribute (often) directly to burning down stories/tasks and is dedicated entirely to coaching, training, supporting, negotiating and running the process as smoothly as possible for everyone.

It’s been a while and, after assuming both roles for different teams, I am now fully convinced that a team could only fully benefit from a Scrum master when his/hers responsibilities are closer to the second type of a role, described above. A Scrum masteloper is simply too busy and too logically oriented to contribute well in all the communication activities, and easily could lose focus on the big picture.

On the other end a full time Scrum master, dedicated only to Scrum activities could pace well, organize well, communicate better and even bring joy and fun to the team. But above all this person would be able to lead the team if leading is within his/hers personal abilities and characteristics. For example, here is a list of what I perceive and do as a Scrum master for my team of software developers:

* The typical stuff any Scrum masteloper will do

• Organizing and facilitating the Scrum ceremonies and process
• Supporting the tools and the stories/tasks organization (e.g. Jira, Trello, the sticky notes and the physical board)
• Keep a list of impediments and resolve or supporting the team in resolving them

* And beyond

• I am persistently negotiating to help different parties (PO, team, stakeholders, clients, management) get to consensus and stay on track
• Clearly communicating the good and bad news (on a daily basis) inside and outside of the team
• Keep myself informed about the importance and priorities of the items in and outside of the Sprint (it’s simply not enough to just look at the backlog – you need to talk to people… a lot)
• I lead and guide the team to reprioritize and commit to deliveries on a daily basis. Developing sophisticated software requires a lot of ongoing effort in discovering risks, issues and sometimes benefits. How we react and handle them on a daily basis is crucial. (Sprint planning can’t identify and predict everything)
• Keep everybody focused on the big picture – the important stuff. It is crucial as most of the developers tend to lose the big picture focus, doing the mundane stuff
• Coach and train the team members so everybody could grow to their best and beyond :)
• Speed the support and consulting provided or received for/by different teams/clients. I just find enough time to talk to other teams, clients and stakeholders. And it’s invaluable to support the Product owner in deciding priorities or even by taking ownership of a client’s issue until full resolution
• Keep the management well informed about the good and the bad within the team. No blame and shame here – only glory :), transparency and real picture. When we are victorious we celebrate together, when we fail we face the consequences together again – but the management team need to be fully aware of what’s going on
• Responsible for the fun and joy within the team. Scrum is meant to be fun… at least more fun than any other software development framework/methodology. I keep the folks spirit high, for example by revealing a funny collage of the last sprint effort I photo-shopped a day before the retrospective or by presenting a useful topic in a funny way
• Keep myself informed of the innovations in the Agile world, my team could benefit from 
• Coaching the guys and spreading the good practices in a specific way that would fit into our particular environment
• You could even see me doing some Project documentation… but that’s more on the PM part :), and only if needed