In order to assess her success as a Scrum Master, Moana likes to look at the team members’ ability and willingness to take on the responsibility for learning and adapting to the challenges they face. But there are other signs like the team taking responsibility for preparing and hosting their own retrospectives. Finally, we talk about the idea of “swarming” and how teams that implement that approach ends up achieving more.
Featured Retrospective Format for the Week: Lean Coffee
Lean Coffee, a format we referred to in several other episodes, is a good format to help teams explore what is critical for them at that time. Moana describes how this format is a safe format for team members to approach topics that may seem untouchable when using other conversations and retrospective formats. We should also note, that the Lean Coffee format is also very good at helping to discuss the “edge” topics, that could easily be forgotten otherwise.
About Moana Pledger
Mo started her career in education and program management before moving into digital delivery. She’s pretty sure she was a servant-leader before she had even heard the term. Her passion is to build healthy teams and foster the all-important relationship between business and team, which allows a safe space for the magic to happen.
When looking at success for Scrum Masters, measuring improvements on the team, and how they work is usually a big part of the evaluation process. We also look at the outcome of retrospectives and discuss how to measure accountability in the team.
Finally, we discuss an Agile Coach/Scrum Master assessment approach (Agile Coach NPS by Jason Little) that can help Scrum Masters assess their contribution to the team’s success.
Featured Retrospective Format of the Week: If this Sprint was a GIF?
Do you like searching for funny GIFs and memes to share with your colleagues? Well, you can make that part of your next retrospective with this format that Chelsie shares with us.
Chelsie has been working as a Scrum Master in the Greater Boston Area for just over two years. She has experience working with both co-located and distributed teams developing on-premise and SaaS solutions worldwide. She is an avid lover of technology, dogs, and bullet journals, Chelsie loves finding ways to bring Agile outside of the office.
When it comes to Scrum Master success, Ellen likes to look at metrics that indicate if her work is having an impact. She suggests that a simple metric around the quality of the Sprint planning may be enough to assess the success for the Scrum Master.
Featured Retrospective Format for the Week: Cards Against Agility
Ellen developed a game called Cards against Agility based on another popular game. Ellen uses this game as a simple way for the team to blow-off some steam, or as she puts it “trash talk in a fun way”.
About Ellen Santamaria
Ellen is a Scrum Master based in Berlin, and originally from Australia. She completed a Bachelor in Australian and later a Masters in Berlin, Germany where she works.
Ellen is passionate about startups, innovation, social entrepreneurship, new business models, organisational change management, and other topics. She also loves story-based video games, sci-fi, pétanque, and finding new ways of doing things.
When talking about success, we learn that Valeria focuses on evaluating the level of collaboration between team members. Listen in to learn about what collaboration “signs” Valeria looks for, and to learn more about what kind and why conflict might be a good thing in a Scrum team.
Featured Retrospective format for the Week: Playing Jenga, the wooden blocks game
In this segment, we discover how Valeria used a concrete game to help the team practice retrospectives in a short period of time. Through the game, Valeria was able to help the team practice “observation”, and speed up the learning cycle greatly.
Valeria has worked as a Scrum Master for 4 years. She has experience with both Software development and non-software development Agile teams. When asked what she does for a living, Valeria replies: “I build teams!” And she does it by focusing on building relationships first. As Valeria says: “all my teams will tell you that I like talking about the feelings :-)”
From her early start with Extreme Programming to learning how to integrate testing with Continous Delivery, we explore Leena’s story and describe some of the most important lessons she collected about adopting CD/CI.
Read on to learn what were Leena’s main lessons, as well as the main challenges teams face when adopting CD/CI.
Wouter started his Continuous Delivery journey as an Extreme Programmer in his first years of engineering experience. He shares the story of how, as a team, they sat together with the operations department to learn how they developed their software. Thanks to that, they radically changed their build system to export the kind of packages that operations needed. A brilliant story that also illustrates the adage: “Your first customer is the next step in the process!”
Read more to learn why testing is such a key skill and technical area when adopting Continuous Delivery.
Chris started her Continuous Delivery in a small agency, nurturing a build server that nobody cared for. That gave her an insight that is not very common: taking care of the build server was a very practical way to help and care for the team’s success. It was a practical tool that the team needed, but no one was looking after. It was a concrete way to help people.
Read more to find out how trust plays a key role in Continuous Delivery adoption, and to read Chris’ recipe to get your team started with CD.
How do we get started with Continuous Delivery? Manuel suggests that we run a Value Stream Mapping session with all the teams involved in the release process to learn about the “current state” of the release process.
We also review the most common challenges and blocks for teams that are starting to adopt Continuous Delivery.
Read on to learn about the different motivations businesses have to adopt Continuous Delivery, and Manuel’s 3 steps from bi-weekly release to Continuous Delivery.
Morten’s adoption story starts with a team at eBay Denmark. The team had started working in a more continuous mode, but there was a lot of “release friction” as Morten calls it. You are probably familiar with that friction: it takes a long time to release; the site needed to be “closed” for every release; the team would need to come in at night during the weekend, etc.
That’s the reality for many teams. No surprise they prefer to release less often. In this segment, we explore that story, and also the steps the team took to go from “high friction” to “no friction”.
Read more to find out how Dev and Ops are different and why that matters when adopting Continous Delivery.
When Thierry got started, the team had troubles with version control, so he helped the team “commit to trunk”, and after that, it was much easier to adopt continuous integration. The build server quickly evolved into a continuous build pipeline. From there it was a small step to continuous delivery.
Although not all stories are this easy for teams adopting CD, this story provides a striking example of how things that are “hard” for some teams, just become the “natural way” of working for others. What’s preventing your team from working this way?
Read more to find what was Thierry’s most painful lesson about Continous Delivery adoption as well as all the resources he recommends for those wanting to dive deeper into the topic.