Caterina invites us to evaluate success in the Scrum Master role by defining and making success measurable. She uses a Continuous Improvement roadmap to solicit feedback from her stakeholders and the team. Using transparency towards her work as a way to create the right conversations in the team, as well as with the stakeholders.
Featured Retrospective Format for the Week: The 5 Why’s, a facilitation guide to helping the team go beyond symptoms
Caterina’s favorite format for Agile Retrospectives is the 5 Why’s retrospective. In this segment, Caterina shares with us her insights on how to facilitate the conversation with the team, and how to avoid some potential pitfalls of that format.
Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today!The Tips from the Trenches – Scrum Master edition audiobook includes hours of audio interviews with SM’s that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!
About Caterina Reinker
Caterina is a social anthropologist and passionate Scrum Master. She regards organizations like villages – or cities – with their own language, institutions, and explicit and many implicit rules. Caterina works and lives in Germany and helps groups of people, big and small, in their agile journey.
Even if Scrum Masters can focus on “working themselves out of a job”, the fact is that not many teams can get to that level, and even the ones that can get there, it’s not easy to find out when is the right time to step back. In this segment, we talk about what it means for a team to be self-sufficient, and how Scrum Masters can evaluate if the team is ready to be given more autonomy.
Featured Retrospective Format for the Week: The 5 Why’s and some caveats when facilitating that format
Shahin starts by sharing a key lesson about making the Retrospectives adjust to the team, and their mood, instead of asking the team to adjust to the Retrospective format we prepared in advance.
In this segment, we talk about the 5 Why’s Retrospective, and some of the caveats we must take into account when facilitating that kind of Retrospectives.
Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today!The Tips from the Trenches – Scrum Master edition audiobook includes hours of audio interviews with SM’s that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!
About Shahin Sheidaei
Shahin Sheidaei is an Agile, Lean and Success Coach,International Speaker, Transformation Expert, and Entrepreneur.
Shahin is a passionate organizational designer focusing on organizational performance, and is also founder and principal coach at Elevate Change Inc.
This is the second of a multi-part series on Agile Retrospectives with David Horowitz who’s the CEO of Retrium, a company that builds tools to help you facilitate remote retrospectives. The links to Retrium’s Retrospectives Academy below are affiliate links, if you prefer to follow a link that takes you to Retrium’s site, but does not give anything back to the podcast, you can. Just follow this link: Retrium.com. On the other hand, if you want to help us grow this podcast, you can follow the links below or this link to Retrium’s Retrospective’s Academy.
In the second instalment of the Agile Retrospectives Masterclass with David Horowitz, we talk about the 5 phases of a successful retrospective, and share tips and ideas for each of those phases to ensure you are prepared and get the team to find and act on breakthrough improvements.
It all starts with a simple check-in: “Set the Stage”, Phase 1 of a successful retrospective
When we start a retrospective, usually at the end of a Sprint, the team member’s minds might be on that last bug they just closed, or the story that didn’t get delivered, or the feedback they just got from stakeholders. The Check-in phase of the retrospectives helps all the team members, and the facilitator to get into the retrospective mood. To forget the open threads that will need to be picked up later, and focus on the question: “How can we do even better in the next Sprint?”
Gathering Data and Generating Insights, the core of an Agile Retrospective
If we want to enable deeper conversations, we need to be aware that the information that is shared will directly affect the quality of the conversations. Therefore, Agile Retrospectives require special attention to the “gathering data” phase. There are many ways to gather data, and some might even happen during the Sprint, instead of during the retrospective.
During the retrospective, however, we will visualize that data and help the team make sense of it.
In this segment, we talk about the timeline exercise, and how to use emotional-queues to help uncover important pieces of information.
When the data is visible and understandable, then the team focuses on finding insights by analyzing the data and generating possible connections and causal links. Here the challenge for a Scrum Master is to prevent the team from jumping too early into solutions before they deeply understand the problem they are trying to solve.
David shares some tips to help prevent the team from discussing solutions before they have a shared understanding of the problem. We talk about The 5 Why’s technique, but there are many more.
Making Retrospectives Impactful: Deciding what to do
Many teams fail in Phase 4, Deciding what to do. But they might fail in quite different ways. For example, some teams might want to commit to too many items at once, while other teams might not commit to any improvement. And finally, the worst problem: those teams that commit to improvements, but work on none of them.
Great teams, understand well how many improvements they can take from a retrospective, and are clear on the commitment, maybe even including the improvement ideas as items on their Sprint backlog.
In this segment, we talk about the ICE method for prioritizing improvement ideas and the importance of brainstorming several solutions before deciding what to do. It’s also important to use methods of consensus generation when there are several options that seem equally valuable. The commitment of each team member to the solution to be tried will directly impact their commitment to the work to be done for that solution.
At the end of the retrospective, our goals are to provide closure, a sense of achievement, and energy for the work ahead.
How can we do that? In this segment, we talk about the “retro on the retro” and the “gif check-out”. Two simple approaches that help the team feel a sense of accomplishment, and also get better at doing future retrospectives.
David Horowitz is the CEO of Retrium, a platform for agile retrospectives that has powered over 100,000 retrospectives from thousands of companies across the world.
Prior to co-founding Retrium, David spent a decade at The World Bank as an engineer turned Agile coach.
He has degrees in Computer Science and Economics from The University of Maryland and a Master’s Degree in Technology Management from The Wharton School of Business.
This is a guest post by Marcus Hammarberg, author of Salvation: The Bungsu Story, How Lean and Kanban saved a small hospital in Indonesia. Twice. And can help you reshape work in your company. (available on Amazon)
This is the fourth and last post on a series by Marcus Hammarberg about how metrics can help engage, motivate and ultimately push a team towards success! (See other blog posts in this series here)
When we first started to work with the Bungsu hospital they were in a devasting situation.
Fast forward 1,5 years and you would see a hospital that was making money every day.
In the end, we turned the hospital from a situation where only the director and her closest staff cared, to a situation where 100 people in the hospital were actively engaged in everyday improvements.
How is this possible? What kind of magic was applied?
Visualizing the right metric
Each morning we showed the result and it was good we had loud cheering among the staff. But for bad days it was mostly silence, head hung low.
I also noticed that the lady that was in charge of gathering the numbers, Ibu Elly (Mrs Elly) the directory secretary, behaved a bit different for days with bad numbers. She was almost reluctant to present them and quickly went over the whole thing.
We had talked about what we wanted to learn about the numbers and I had written “KENAPA” (WHY) beneath the graph. Because I wanted us to learn from the metric we were collecting and visualizing every day.
For example on this graph – can you see something that stands out?
See those regular dips? If you asked “KENAPA” and counted the dates, you could probably figure out that those dips are Sundays… People don’t go to a hospital, as much, on Sundays.
“KENAPA” – what can we learn? Well, we could (and did) try to be more open on Sundays, but pretty soon realized that it would be very costly to keep more staff around and that it was a cultural thing keeping people back.
Until that point, most of the management team understood the KENAPA-question, but it made Ibu Elly feel ashamed for bad days. That troubled me, until one day when she was bustling with joy. We had made an excellent result yesterday: 138 patients served in one day. The first time, above our goal of 134 patients.
As she entered the numbers and headed back to her seat I asked… “Kenapa, Ibu?”
She stopped in her step and turned around with a puzzled look. “No, you don’t understand. It was a good result, sir.”
I did understand that it was a good result but I pressed on. “I know, but why was it good”.
Poor Ibu Elly looked around for support and then back to me with an even more puzzled look. “Well… in the polyclinic, we had 32 patients, and then for the ER we had 12 patients and …” I interrupted her gently.
“I understand all of that. You are showing me the math. But why was it good yesterday?”. At this point, she gave up and just said “I don’t understand” and took her seat.
I felt bad for her but we had an important learning point here, so I pressed the others. “Anyone else knows why it was good yesterday? Kenapa?”.
After a few moments of hesitation, someone offered “Well, yesterday we had three doctors in the polyclinic, rather than our usual two. Dr Paula did an extra day for us.”
“AHA!” I exclaimed, a bit too loud if I’m honest… “So what can we learn?”
We eventually concluded that more doctors probably means more patients. At least that was a hypothesis we could use to run an experiment.
More importantly, with the visualized data and by continuously focusing on learning we found that knowledge nugget. We now had understood the value of asking “WHY” the data behaves as it behaves. And from this point on we viewed the graph differently – it was now a source of learning, regardless of the result.
This is a very actionable tool that you can you use today in your organization to make your visualizations matter to everyone all the time.
The Bungsu Story is a fascinating account of a real-life crisis, and how Agile, Lean and Kanban saved the Hospital from bankruptcy! Twice! Get ready for the journey, it’s going to be a bumpy ride!
This is a guest post by Jeff Campbell, author of Actionable Agile tools (available on Amazon, and direct from the author at bit.ly/aatbook)
Keeping retrospectives impactful and fresh
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.
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.
Prep Work
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.
Here is a link to a google doc with the prep work I have done, to save you some time: https://tinyurl.com/l8loec6
Reducing the complexity
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.
Headings:
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
Discussion: 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.
Product Vision
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.
Conclusions:
The Good:
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.
The Bad:
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.
How to deliver on time and eliminate scope creep
By scoping projects around outcomes and impacts, not requirements!
Get the Product Owner Booklet!
Avoid scope creep!
And learn to scope projects around impacts and outcomes, not requirements!
Get These Valuable Lessons Today!
Down-to-earth, hard-earned Scrum Masters lessons and the Tips from the Trenches e-book table of contents, delivered by email
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Internal Conference
Checklist
Internal Conference
Checklist
Download a detailed How-To to help measure success for your team
Motivate your team with the right metrics, and the right way to visualize and track them. Marcus presents a detailed How-To document based on his experience at The Bungsu Hospital
Download a detailed How-To to help measure success for your team
Read about Visualization and
TRANSFORM
The way your team works
A moving story of how work at the Bungsu Hospital was transformed by a simple tool that you can use to help your team.
Read about Visualization and
TRANSFORM
The way your team works
Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches – Scrum Master edition audiobook includes hours of audio interviews with SM’s that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!
Caterina is a social anthropologist and passionate Scrum Master. She regards organizations like villages – or cities – with their own language, institutions, and explicit and many implicit rules. Caterina works and lives in Germany and helps groups of people, big and small, in their agile journey.
Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! 
Shahin Sheidaei is an Agile, Lean and Success Coach,International Speaker, Transformation Expert, and Entrepreneur.
David Horowitz is the CEO of Retrium, a platform for agile retrospectives that has powered over 100,000 retrospectives from thousands of companies across the world.
Marcus is the author of 
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.
