Peter and Michael just finished the first half of a book they are writing together on the topic of shifting our attention, and focus from the “product” focused techniques to “people” focused techniques in order to achieve superior performance.
Karin’s book’s title “Moose Heads on the Table” is a reference to a method she describes that helps her work with teams towards self-organization. We start this episode by discussing what that metaphor means, and why it is so critical for teams wanting to self-organize.
Karin refers that it is critical to bring up the hot topics (the Moose heads) and discuss those openly and without judgment. It is not always necessary to have an idea of what a solution would look like, and being open about that with the teams is actually a bonus in the self-organization process!
Being a CEO in a business you don’t know anything about, and succeeding wildly!
This is the third 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.
When we start facilitating retrospectives (I still remember the first ones I facilitated), we are often focused on getting the structure right, and we may forget that we can uncover insights at any time during the retrospective. This module is all about increasing our chances of facilitating a productive and effective retrospective.
Team Norms, a productivity and engagement tool for Scrum Masters
Does Agile apply when managing a company? In this episode, Simon Severino shares his story and his business of taking Agile to the C-Suite of fast-growing companies!
If you follow this podcast, the success of Agile methods is not a news item. It’s clear that Agile has improved greatly our ability to deliver software products to the market. In this episode, however, we look at a different application of Agile ideas. What if we could apply Agile to the methods we use to manage our businesses? That’s where this interview focuses: how Agile changes our approaches to running a business.
Simon is a growth consulting, he works with business leaders to help them improve the performance of their business. He does that using methods that will sound familiar to all Agile product development team members.
Managing your business as if it were an empirical problem, not a planning problem
“Most purpose statements are dry and uninspiring”, that’s how this episode starts. But Stephen goes deeper and explains why that may be the case. We dive into what are the missing aspects in most purpose statements and share some examples of how he’s been able to help organizations go beyond those dry and uninspiring purpose statements.
The three types of purposes we need to take into account
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.
Jeff is also the author of Actionable Agile tools (available on Amazon, and direct from the author at bit.ly/aatbook).
Why does Management resist Agile change?
This is the first question of the episode and one that Scott and Jeff have worked together on for years. Scott shares how his past as a developer has helped him understand the role of management in an Agile organization.
We also talk about how to understand the reaction of managers when employees come to them with gripes, or ideas for changes to implement. We tend to think that when managers don’t do what we ask, they haven’t listened to us. Is that really so?
In this special BONUS episode with Daniel, we cover some of the most serious Product Owner anti-patterns. These are anti-patterns that can severely affect the teams’s ability to deliver, and to focus on value.
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.
And we start with a big myth about the PO role…
Does the Product Owner REALLY own the Product Backlog?
This is the first 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 first installment of the Agile Retrospectives Masterclass with David Horowitz, we talk about the basic setup for a successful retrospective. It all starts with what David calls the triangle of success: People, Process/facilitation, and Follow-through.
How to set up your Agile Retrospectives for success with the right people
Every 4 months, about 8 teams comprised of University students, other students, and partner-company employees start working on a new product idea at the Digital Product School (DPS).
These teams become their own mini-startups, and work to develop, and sell their products in a 3-month accelerated program. They experience hands-on what it is to work in a start-up and to go from a fuzzy idea (the problem space) to a product they can sell in a very short period of time.
This learn-by-doing program helps companies educate their employees in rapid product development methods, and helps students get hands-on experience with product development in a very short period of time.
The most common problems teams face in DPS
The teams that join and complete DPS usually have the same problems all other teams face, but because of the accelerated time-frame, and because the DPS team has seen more than 10 batches already, the problems are obvious! And we can learn a lot from those problems when it comes to the more normal product development we participate in.
The first challenge teams face is that they have a hard time locking down the problem they want to solve. As it happens, they want to solve too many problems, which is a common affliction of many teams and leads to confused and confusing products.
The DPS team expected that it would be hard to convince developers to work with users and do user research. However, it turns out developers actually embrace that work, and the biggest problem is getting the Product Managers (PMs) to make decisions. PMs tend to expect that the “process” will ensure they have a good outcome, and that leads to having a hard time making decisions.
In this segment, we talk about how to help PMs make decisions and the transformation that happens when PMs are faced with the need to make decisions.
The biggest problem in the Developer-PM collaboration
In such an accelerated program (3 months from idea to product), it is natural that the pressure is high at some point. PM’s work needs to include facilitating and motivating the teamwork. Why are we doing certain decisions? What’s the goal of a certain user test? And many more questions come up during the work.
This brings one of the biggest problems in the Developer-PM collaboration: the motivation of the team when under pressure. In this segment, we also talk about the most common anti-patterns developers and PMs fall into when under pressure. There are also some great insights for Scrum Masters about team building and coping with pressure!
Enabling good Developer-PM collaboration
One of the usual sticking points in the Developer-PM collaboration is the fact that these people speak different languages. Many Scrum Masters also experience that when they see PMs and developers fight about estimations, for example.
At DPS, special attention is put into helping PMs understand what developers do and vice-versa. From explaining and using tools that developers use, to helping developers understand Story Maps and other PM tools, the way the DPS team helps developers and PM’s collaborate is especially about helping each other and learning each other’s job and responsibilities.
Why Product Manager and not Product Owner?
At DPS, the team decided early on to call the role of the product person the Product Manager, and not the Product Owner. Why did they do that?
In this segment, we explore a question that most companies adopting Scrum will need to struggle with: what to call the product roles.
The DPS team shares how the idea of “product” is owned by the whole team, and that the product manager role is much more than looking at the backlog or defining priorities, it’s about being responsible for user experience, business, and technology!
This emphasizes the idea of the DPS program: product development is a team sport!
Resources for rapid product development
At the end of the episode, we talk about what resources DPS suggests teams to study, and we list the following books:
DPS is an accelerated product development program in Munich that helps students from University and employees in partner companies experience hands-on what it is to work in a startup. In 3 months they go from idea to a product, and some ideas are brought back to the companies for further development.
About the DPS team
Michi / Michael Stockerl is director of DPS and has worked as a software engineer with several teams in different setups. Before that, he gathered experience in smaller Startups in Munich and Germany’s biggest Q&A platform.
Steffen is a trained journalist, who slipped into product management through Content Management and e-commerce. He worked with Amazon and Haymarket media, did several hundred user interviews and tests, witnessed dozens of teams at DPS, a Digital Product School of the Technical University of Munich in Germany.
Bela is a Software Engineer at DPS. She helps teams with various software and hardware engineering tasks. She was previously also a participant at DPS.
Download the first chapters of the book Shift: From Product to People at: https://bit.ly/shift_book
✋ 
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.
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:
Every 4 months, about 8 teams comprised of University students, other students, and partner-company employees start working on a new product idea at the Digital Product School (DPS).
Steffen 
Bela