As a developer, starting your first Scrum Master assignment is not easy. In this story, we hear about how easy it is to stay in the developer mindset in our first Scrum Master job, and what that means for the team and yourself. We discuss how Scrum Masters can learn to step back, even if they “know” what to say.
About Joe Auslander
Joe is into game/experience design and enjoys working with teams to solve unique problems. In the past this has been in areas of ship repair, crew coordination, television production and software delivery. Joe enjoys learning and sharing what he has learned and he particularly loves seeing people succeed.
As Jakub took on the challenging role of being a Scrum Master for 7 teams, he started facing the problems that come with over-committing (as a Scrum Master). The typical running around just to be present at the teams’ meetings started to take its toll. Jakub did not know how to handle that many teams, and that led to a reflection and learning that stayed with him forever: he had turned Scrum into the outcome that he was pushing teams towards, instead of the tool that helps them succeed.
About Jakub Jurkiewicz
Jakub is a kaizen practice lead who participated in his first standup in 2005 and facilitated his first retrospective in 2007. Previously a software developer, team leader, Scrum Master and Agile consultant, Jakub is also, a podcaster and trainer at Agile Coaching Lab. Loves wine, bicycles and his wife (in the reverse order).
The story that John shares with us, starts when Project Management transformations were a thing. He went through a PRINCE2 adoption process, which led to the emergence of the inevitable silos. John started searching for better alternatives and found Extreme Programming, Scrum and Kanban. As he tried to play the servant leader role that comes with Scrum, however, he discovered that there’s a good and a bad way to be a servant leader. Listen in to learn when to stop serving, and when to be a true leader!
About John Albrecht
Agile Person, for the team by the team, used to be a developer. Got into Agile via Extreme Programming (XP), then Kanban, then Scrum. Some of his key ideas are Principles over Practices, #noestimates, love working with teams and organizations, the softer side, finding what they and customers need and what works for them.