A Scrum Master can wear many hats. Specifically, the Scrum Master can be a coach, a mentor and a teacher. All three roles are necessary at different times in our assignments. How do we know which ones to hold? We discuss that in this episode, where we explore Elena’s definition of success for a Scrum Master.
Featured Retrospective of the Week: What? / So what? / Now what?
Elena found in “Liberating Structures”, a good exercise to help teams reflect on the outcomes, and the necessary changes after a Sprint. In this episode, she shares one facilitation technique that helps facilitate a retrospective even with large teams.
Elena considers herself a lifetime learner (she says, she absolutely loves having “aha!” moments). And she especially enjoys learning together with and from other people: her team and her friends. Elena is curious about everything: people, software craftsmanship and the world around. Elena is also a passionate hiker and a cross-country skier 🙂
When we join a new team, there’s a set of things we should look for in order to know what the team needs help with. In this episode, we talk about what to look out for when joining a team, to ensure that we know what requires our focus. We discuss a set of critical questions every Scrum Master should ask from themselves.
Featured Retrospective Format for the Week: The Speedboat Retrospective
Catrine likes this format because it helps move the conversation from complaining to taking action. Listen in to learn how to apply this format in practice and help the team focus on positive action that brings improvement.
About Catrine Björkegren
Agile coach and scrum master, Catrine has worked with agile for a decade in various areas like education, nuclear waste, government agencies, pharmaceutical and at the Royal Swedish Opera.
She believes that co-location is the key to building teams and that leadership is the key to successful agile transformation.
The hours people put in are a good indicator of the success of the Scrum Master. Are your teams working long hours? Putting in crunch weeks and then laying back for a while? Those are signs that something isn’t working as it should. Scrum and Agile are about sustainable, continuous progress towards our goal.
Featured Retrospective for the Week: What’s going well and how can we make it better?
Starting the retrospective with the team by sharing Kudos (appreciations) can energize and team and get them in the mood to improve their practices. The “what’s going well, and how can we make it better” retrospective format, takes the energy from the Kudos check-in and turns up the good by focusing the teams on how they can continue to build on what’s already working.
About Kristopher Stice-Hall
Is the co-owner of Digital Maelstrom, a consultancy specializing in custom software, DevOps, managed cloud services, and information security. He has been doing Scrum Master work for over 10 years. He has worked with fortune 500 companies to companies less than 15 people. He also has been doing software development for 17 years.
Scrum Master success is not only about the team, but also about the Product Owner. When we want to help Scrum teams, we should check how the interaction with the Product Owner works, and how to help the team and Product Owner collaborate effectively.
Helping Product Owners also means focusing on the business side of our work and defining together the critical business metrics for the PO and team.
Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate.
Featured Retrospective for the Week: Conversations as retrospectives
Sometimes retrospectives are simple moments in time where team members have important conversations with each other. Instead of waiting for a retrospective event, Scrum Masters should encourage those conversations every day. In this episode, we also talk about how to help distributed teams hold regular, even daily retrospectives.
About Varun Maheshwari
Varun is a Scrum Master and agile practitioner in Australia. He believes in “being agile” rather than “doing agile”. For him, Agile frameworks are not the goal, but rather “Delighting customers, Zero Defects, Quick ROI, Better team work, Excellent Quality & Shortest ‘Time to Market’” are some of the possible goals.
Scrum Masters can use their self-check-in every day to assess their progress. In this episode, we talk about questions you can ask yourself to assess your progress and find the areas that are working or need more focus.
Featured Retrospective for the Week: The 5 steps, how to execute them when time is of the essence
The Agile Retrospectives steps that Derby and Larsen shared in Agile Retrospectives can take a while to execute in a retrospective setting. Sometimes we don’t have that much time. In this episode, we discuss how we can implement the standard 5 steps of a retrospective even when time is of the essence and we only have 30 min or less.
About Elena Astilleros
Elena coaches people who hate wasting their time with badly run agile ceremonies, meetings or projects. She gives them tools to get more out of their time while sprinkling in a little enthusiasm and cheerleading. You can find some of her tools in the forthcoming book Invisible Leader.
When working with teams, the team’s metrics should also become the Scrum Master’s metrics. In this episode, we talk about metrics that teams use but can also be important for Scrum Masters to assess their success, and help the teams.
Featured Retrospective Format for the Week: The Hot Air Balloon Retrospective Format
The Hot Air Balloon Retrospective format is a format that helps teams use a metaphor to explore their current problems (ballast) and the things that are working well (heat, wind, etc.) Metaphors help teams get out of their minute task focus and focus more on themselves as a group.
About Eduardo Ribeiro
Eddy is passionate about helping people, teams, and organizations foster a culture of continuous improvement where experimentation and embracing change becomes part of their DNA.
He’s also the author of the Beyond Lean Agile Blog, a Co-Founder of the Lean Coffee Portugal Community, Founder of Agile Online Community and Co-Founder & Director of Startup Grind Porto.
Scrum Masters must pay attention to how Scrum teams adhere to the Sprint Goal, how they collaborate with the Product Owner and other aspects that help teams perform.
In this episode, we talk about 5 different success metrics for Scrum Masters.
Featured Retrospective Format for the Week: The Sailboat Retrospective Format
Scrum Masters usually have multiple retrospective formats in their “back-pocket”. The Sailboat Retrospective format is one that is easy to setup (a flipchart and markers/post-its are enough), and can engage the team in a creative assessment of their ways of working.
About Nedeljko Damnjanovic
Nedeljko is a Scrum Master and a full-stack developer who has been in the IT industry for the better part of the decade. He spent the last 5 years actively working as a Scrum Master with many diverse teams and projects who has helped him understand his role better. One of the core developers of the first VivifyScrum release, he has participated in its development product-wise ever since.
For Scrum Masters, success must include the team’s success. In this episode, we talk about the metrics and the type of feedback we must help teams collect, and how to use that to measure our Scrum Master success as well.
Featured Retrospective Format for the Week: I Like / I Wish and other games
Sometimes Scrum Masters must focus on helping teams feel at home, so that team members can discuss the issues that bother them. In this episode, we talk about how a CEO/CTO can derail a retrospective and what kind of games we can use to help teams focus on improving, even when managers are present in the retrospectives. The retrospective format we talk about is “I Like / I Wish”.
In this segment, we refer to Retromat, a service that helps you choose games/activities and plan your retrospective.
About Henrique Centieiro
Henrique is a Blockchain Product Manager (i.e. dealing with the blockchain related features/user stories of the product). He is passionate about teams and agile, using scrum to manage even his personal tasks.
Ajeet has come to value 4 specific ways to measure his impact as a Scrum Master. In this episode, we review these 4 benchmarks and how he uses them regularly to improve his approach.
Featured Retrospective Format of the Week: Well/Stop/Start retrospective format
In the Well/Stop/Start retrospective format (see a facilitation guide here), we have a simple format that can trigger important conversations. Especially when team members see each other’s contribution to those 3 categories.
This is a format that suits very well teams that are action-oriented, and have a high degress of collaboration already.
About Ajeet Singh
Ajeet is an IT professional with 17 years of delivery experience in application development, system integration and software testing. He’s served as a ScrumMaster for over 3.5 years for the clients of USA, UK and Australian geographies.
We like to keep our retrospectives fresh. We find it helps to reveal things we might not otherwise have found if we alter the format frequently. With this goal in mind, we follow a simple system:
Once a month we use our ”normal” retro format. Everyone in the team is familiar with this, and we can perform them quite quickly, with minimal prep work and explanation required. Basically, effective with very little admin.
Once a month we have our ”experimental” retrospective. A little more set-up time required, but a good opportunity for experimentation and explorations.
This is the story of one such retrospective.
Obviously, you can perform many Agile practices, but not be Agile. However, there are a lot of practices out there and sometimes teams can become focused solely on those that they are currently using, rather than looking at other tools they might bring to bear. This is where the Agile Practices Retrospective comes in.
In preparation for the retrospective, we created cards with various Agile practices as headlines, and a brief explanation of each listed on it. I also color coded them under various categories so they could be more easily identified from afar. Then we simply taped all these cards to a wall in their respective categories. There were about 50 cards in all.
With over 50 cards, there was a lot of information. We split into groups and started categorizing the cards under a new set of headings, it was made clear to all that they were not expected to read all the cards.
Doing (Working Well): Things we are currently doing, and quite happy with the way they currently work.
Doing (Could be better): Things we are currently practicing but could use improvement.
Not doing (By choice): Things we are not currently practicing, but have made a choice not to use in our context.
Not doing (Not tried): Things we are not doing, and have never really tried.
WTF!?!: We have no idea what this is, or what it means.
Deciding what to focus on
We obviously cannot talk about all these things. So, we used dot voting to decide what topics to focus on. Each team member was given 3 ”dots” for each of these types of vote:
We should start and or alter this practice in some way. (Indicated by a dot)
We would like to learn more about this practice. (Indicated by a +)
I also printed out simple list versions of the same information, as I knew it would be hard for everyone to gather around the board when deciding how to use their votes. Despite this, this was still not as successful as we would have hoped. Part of this is because we are actually two teams and our 3 customer representatives, so the whiteboard was too crowded. I feel this would go better with a single team.
Discussions and action points
We had open discussions and tried to create action points/experiments around the topics we had discussed. I will just give a very brief of what we arrived at:
Root Cause Analysis/ 5 Why’s
We even arrived at the fact that without formal tools, we are still quite good at root cause analysis. But perhaps a formal tool might reveal something we would have otherwise been unaware of.
Experiments: 1)Focus on using our discussion time during retrospectives (Generate Insight) to use more formal tools like 5 why’s.
2) When events are added to our timeline at daily stand-ups, then we should also consider doing a more in-depth analysis of those items.
Discussion: We felt that we very likely do have a product vision, and even a fair amount of impact mapping done for that, but this is not communicated to the entire team at a frequent enough rate. Also, we need to get better at following up these things.
Experiments: 1)Make the product vision more concrete and communicate it at a regular interval.
2)Follow the vision and impact map up at a regular interval.
Behaviour Driven Development (BDD):
Discussion: This is a discussion point we wanted to learn more about. So, the discussion was brief. We basically arrived at the fact that it was intriguing and we want to know more.
Experiments: 1)The two team members who know something on the subject will provide some links and a quick intro for everyone else.
2) Some of the team will experiment with these concepts in our ”Brain Day” next week.
This retrospective was reviewed well by the team, everyone generally liked it.
It was a fairly active retrospective, because of all the moving things around and working in teams, so the energy level remained high throughout.
Probably the best aspect of this retrospective was the addition of fresh concepts into the team, the idea to focus on things we wanted to learn more about was a good one. In the future, we would probably recommend only focusing on these things.
There was a fair amount of prep work involved in this one, although I consider it worth the investment, it wasn’t free. Hopefully, a bit cheaper for you, as we have provided the work we have done. Once again: https://tinyurl.com/l8loec6
It was too hard to get an overview with so many items, this may have been due to team size, and might have been possible to mitigate by having the team read the list beforehand.
Despite there being so many items, the list was not even close to exhaustive, and it was hard to leave off some practices that really should have been included.
Jeff is an Agile Coach who considers the discovery of Agile and Lean to be one of the most defining moments of his life and considers helping others to improve their working life not to simply be a job, but a social responsibility. As an Agile Coach, he has worked with driving Agile transformations in organizations both small and large.
Jeff is also involved in the Agile community and is one of the founding members of Gothenburg Sweden’s largest agile community at 1500+ members , and he also organizes the yearly conference www.brewingagile.org.