In this episode, Daniel emphasizes the importance of collecting data from day one in product development. He discusses how data can help assess the capability of the system in place and create forecasts to assess delivery dates. He mentions the NoEstimates movement and suggests counting the product backlog items that can be finalized in one sprint as a useful metric. Daniel also provides tips for helping teams accept the data, and continuously updating forecasts. He emphasizes the need to work in hypotheses rather than requirements, as it allows for acceptance that they may be wrong. Finally, he notes that data gives us information on how to act and change over time.
Want to Improve Your Change Management Results? Discover the Lean Change Management Approach Today!
As Scrum Master we work with change continuously! Do you have your own change framework that provides the guidance, and queues you need when working with change? The Lean Change Management framework is a fully defined, lean-startup inspired change framework that can be used as the backbone of any change process!You can buy Lean Change Management the book at Amazon. Also available in French, Spanish, German and Portuguese.
About Daniel Westermayr
Daniel is a Kanban Trainer with a knack for all things Lean and Theory of Constraints. He wants to help teams achieve and measure their continuous improvements.
The Great Product Owner: The Customer advocate Product Owner
This Product Owner was very close to the customer, and listened to their needs as well as the struggles they had with the product. Through their work, the PO tried to focus on adding to the backlog stories that would help the customer directly, and would often act as the customer when talking to the team. They were able to focus on prioritization, and prioritized the work for the team. The PO was also able to create clear priorities and have conversations with the team about the 3 V’s: Vision, Value, and Validation.
The Bad Product Owner: The Product Owner that skipped the Sprint Reviews, and what that caused for the Scrum team
The processes we have in place influence the choices, and the focus of the Product Owners. In this segment, we talk about a team and their Product Owner that did not host a Sprint Review. Instead, the PO would focus on reviews with individuals, separate discussion with single stakeholders. However, that meant that other stakeholders would not know what the team had worked on during the Sprint. Furthermore, the team was not involved, and did not have the chance to show, and be proud of what they had accomplished during the Sprint. This was an anti-pattern that Ruta tried to overcome. Listen in to learn how Ruta tackled this anti-pattern.
Are you having trouble helping the team work 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.
About Ruta Hardikar
Ruta has over 8 years experience with Agile, and has taken the roles of Agile Coach, Scrum Master, Release Train Engineer (RTE in SAFe), working with GM Financial.
Diana and I were kicking around a few topics for this episode, and we ended up selecting “Agile and Leadership, friends or foes?” The idea is to talk about how Agile and Leadership play together (or not)
In this episode, we talk with Diana Larsen and Jutta Eckstein about what problems Leaders try to fix with Agile, what challenges they have when they try to adopt Agile, and we will do this with the focus on the Scrum Master role, and what they can do by working with the leaders of the organizations they work within.
Let’s start by defining some of the major challenges we see happening out there.
The 3 biggest challenges on how Agile plays (or not) with Leadership
Some of the challenges we mention in this episode are not new. You are probably familiar with many of them. We talk about how Agile requires us to think about leadership as a distributed responsibility that team members need to take on, which is itself a major challenge for Scrum Masters as they help their teams understand what that means in practice.
We also discuss how important it is to understand that leadership is not simply a “role”, but also something we need to earn, including Scrum Masters.
Finally, we talk about the important role that leaders play for the teams they work with. Specifically in setting the direction that helps the teams adopt quicker processes like Hypothesis-Driven-Development, for example.
How Scrum Masters can cope with these challenges
We then discuss how Scrum Masters can understand, and learn to cope with these challenges. Not surprisingly, Agile Retrospectives come up as a critical tool for Scrum Masters to use when working with teams and their leaders.
Regarding collaboration with leaders, we discuss how Scrum Masters can help teams focus on the right goals, which need to be defined in cooperation with leaders in the organization.
But there’s a second tool we discuss that complements perfectly the work we do with the retrospectives and helps the teams and leaders understand where they can contribute the most: visualization as a way to establish a shared context.
Do Scrum Masters really need to protect the team from their leaders?
Stop me if you have heard this one before. Way back when I was taught that Scrum Masters need to protect the team from interference. Although it made sense to me at the time, with the passing of time, and after collecting more than a decade of experience, I have come to value a different approach.
In this segment, we talk about the need (or not) to protect the team from Leadership interference.
The goal, of course, is to generate a real collaboration between the team and the leaders in the organization.
The key resources on leadership and Scrum by Diana Larsen, Jutta Eckstein and Vasco Duarte
Given that leadership, and the collaboration between teams and leaders is a critical topic for Scrum Masters, we discuss some of the resources (books, podcasts, articles) we’ve found useful and informative on how to tackle that collaboration.
EXTRA BONUS: to get 30% off Barry’s Hypothesis-Driven Development course you can go to www.leanagile.study and use discount code THIRTYCPOFF before the end of December 2017.
Far too many companies act as if Product Development was a shopping trip: they get a list of things to “buy”, typically Features. Then they create documents explaining that shopping list: Roadmaps, Backlogs, PowerPoint presentations, Post-its on walls, you name it. And then they execute. Here’s the thing: if you act as if Product Development is a shopping trip all you will do is spend a lot of money and get lots of Features you don’t really need.
Barry suggests we treat Product Development differently. He calls it Hypothesis-Driven Development (HDD for short) and includes:
Leadership set an outcome (not a task!) Example: how to increase conversion by 10%
Look for observations: where you try to understand what is happening in the product and to the product you develop.
Set a hypothesis to validate ideas: where you make assumptions and write those down as assumptions. Assumptions should be about how to reach the goal set in step 1.
Create simple experiments: actions that drive results, which you will compare with the hypothesis you created in 3.
Gather the data, learn and repeat: the core process is LEARNING. Therefore, spend enough time on this step so that you generate new observations, insights. Then repeat the cycle.
A fundamental shift in product development
Barry claims that HDD is a fundamental shift in product development. The shift is from doing many things, many small changes, and switches to focusing on outcomes, on results to the business. This means that leadership is no longer accountable for the work, but for the outcomes. And this frees the teams to focus on self-organizing to reach those outcomes, instead of following a list of things that others have dictated.
As a result of the shift towards HDD, we stop focusing on big-bang, all-in projects and focus on running smaller experiments that drive the learning that will eventually generate the outcomes we defined. As Barry says in this episode: we go from 1 to 2 experiments per year (projects) to testing many more ideas every month.
But you can’t run that many experiments with the same approach to funding, and management that you used when you ran projects. So we focus on a different management paradigm that Barry explains further. The goal: learn and adapt faster, not produce more features.
As part of that, we need to get familiar with the concept of safe-to-fail experiments that can reliably generate knowledge without causing chaos or confusion in our product development process.
And it all starts with a simple change in product development: define the problem you are trying to fix, not the solution you are trying to create.
If I want to know more about the Hypothesis-Driven Development approach, where should I start?
Barry O’Reilly is a business advisor, entrepreneur, and author who has pioneered the intersection of business model innovation, product development, organizational design, and culture transformation.
Barry works with business leaders and teams from global organizations that seek to invent the future, not fear it. Every day, Barry works with many of the world’s leading companies to break the vicious cycles that spiral businesses toward death by enabling experimentation and learning to unlock the insights required for better decision making and higher performance and results.