Sunday, November 11, 2012

How switching the Scrum Master and developer perspective enlarged my scope


Background

After being Scrum Master for the last 4 years, in my recent project I had the opportunity to work as a developer again. This post will describe my new insights and learnings from this journey. 

When you're stuck, seek a new perspective.(image: Joselito Tagarao, license: Creative Commons)

Why it was possible

  • A special constellation allowed me to become a developer again. Another team member took the Scrum Master role and I had the chance to develop again
  • We will not switch the roles back in this team again (causing irritations) - so it's really a kind of an extraordinary situation and no recommendation to do so for the Scrum Master ;-)


My key take-aways

  • I found even more impediments that developers have to fight with everyday and that were neither found nor addressed with the Scrum Master;Me (because the Scrum Master is not forced to work with it daily and developers got used to it) - some examples:
    • Slow building times and getting used to it
    • Slow test execution times and getting used to it
    • Monitors and screen resolution and a simple way to improve productivity
    • Appointments scattered through the days, preventing flow states
    • Estimations anchored by the end date
  • As a Scrum Master I need to invest more time to investigate the development processes, following every single step in building software to find waste in the process
  • As already often described within Scrum - being a Scrum Master and developer at the same time is not a good choice. 
  • I saw the Scrum Master role from the developers perspective and discover ed my picture in the mirror - Did I like it? For sure I found ways to be a better Scrum Master!

Suggestions for Scrum Masters

  • Get involved, daily - instead of waiting for your team to ask and raise impediments - anticipate by joining steps your team members take:
    • watch pair programming sessions to learn and see what could still be improved
    • join the discussions (even small ones) to learn where the handovers are and how it works
    • analyze all interruptions
      • building times
      • waiting for the environment (for committing code, executing tests, doing roundtrips)
      • task switching behaviour (forced by mails, meetings, bad shared work, silly development processes)
  • Ask more if your gut feeling says - I don't get it why we are doing it this way? 
  • Don't work as Scrum Master and developer at the same time. A team needs a strong Scrum Master and a strong developer. If you combine both roles - both won't be strong and one role will loose. (I'll share my experience with doing this in one of my next posts)


Can you help me with the following questions?


Can a Scrum Master get impediment blindness? How do you prevent it in your environments?


From many discussions I still have the feeling that many Scrum Masters work as developers in their team? Can you share this experience? Why do you think it is like this?