Psychological safety has been claimed to impact greatly the productivity and well being of teams. Building trust is how we reach psychological safety, but trust is a touchy topic for teams. Scrum Masters try to build trust between team members, with stakeholders, with other teams, with the Product Owner. Trust maybe one of the critical ingredients that allows collaboration to emerge. But how do we build trust? How do we learn what works, and what doesn’t when building trust?
Tim Ottinger shares his learning in this BONUS episode on trust, with a very practical approach, just like we like it here on the podcast.
Does your company need estimation? Listen to Erwin’s take. He’s a CEO. He should know.
Erwin has his own company and invests his own money in that company. For him, #NoEstimates solves a clear problem: too much time wasted estimating, instead of producing.
He challenges us to investigate how much money and time we already invest in that process, and then to measure the benefits. Are we getting enough return on the time and money we invest on estimation?
We learn about Erwin’s story of adoption. How he started with gradually larger projects, even at larger clients, and what he learned about the dynamics that push companies to make larger and larger decisions. Those larger decisions look like they require estimates, but why aren’t we questioning the need to make large decisions (large batch)?
Can we apply Agile ideas to the definition and execution of Strategy for our businesses? Trent Hone, award winning Naval historian, Karl Scotland, Agile Strategy pioneer, and Henri Mårtensson, long time author on the topic of business strategy got together to discuss just that.
Al Shalloway is a veteran of the software industry, and one of the early adopters of Agile. His company NetObjectives has even been podcasting on the Agile space way before Agile was popular. NetObjectives started their Lean And Agile Straight Talk Podcast way back in 2006, and you can still find many of their episodes on iTunes.
Business Value, the forgotten goal
In this episode we start by talking about the concept of “Business Value”, which is often forgotten in favor of some process goal like “adopt agile”. One can ask: what is the value of adopting Agile if we end up going bust?
But it is not so easy to define business value. In this episode we explore what might be the meaning or definition of business value in our organizations. We also discuss how we can help our teams focus on impact, not just more features delivered. And we end up talking about the need to have a process that adapts to many different organizations. Al talks about FLEX, a model NetObjectives developed after working with many organizations and understanding what is not working today when we try to scale Agile.
Developing an Agile model for organizations of many sizes
Al and his team have been around for a while. They have used XP, Scrum, Kanban, SAFe, Lean and more recently FLEX. From that varied experience, Al has learned a lot that he applies today in his company. From the insight that Scrum can only succeed if we take care of the people, to how SAFe is more appropriate to certain organizations, to the idea that management has to be an integral part of any transformation or Agile adoption. We talk about the Art of Action by Bungay, the orientation of management (hint: not top-down or bottom-up!), and double-loop learning. Double-loop learning is an essential part of transformation and actionable learning. We also refer to the New New Product Development Game, and other work by Nonaka, which informed the creation of Scrum.
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.
Luca, who’s coached at the fast paced environment of the Ferrari F1 team surely knows what “speed” and “time-to-market” mean in the extreme cases. However, independently of all of that pressure Luca has been able to develop his coaching approach without focusing on pushing, forcing or manipulating people to do “the right thing”. How did he do that? We discuss his career and his learnings in this special episode about coaching.
Luca, just like all of us, tried to help people that did not want help, but that only led to his frustration as a professional and very little results. So he embarked on a journey to become a more effective coach. One of the key lessons Luca shares is about the commitment that is expected from the coach, as well as the team or individuals in the team.
Establish commitment and check often
As coaches, we need to ensure that we have the commitment of the people involved or risk failure and frustration. Luca shares his approach for how we can reach a mutual commitment with the people we work with in a way that supports their goals as well as the role we play as coaches and Scrum Masters.
Beyond the agreement between coach and team, we also need to learn to become better Scrum Masters. Luca shares his insights and the actions he took to learn to become a better Scrum Master and coach over his career. One simple tip he shares is: learn to facilitate key ceremonies in the process. The better you are at facilitating the ceremonies, the better the results will be with the team.
The information we need to learn our craft
On top of the work we must do to learn the facilitation role, we must strive to learn and improve ourselves at all times. For that we share in this episode several sources of knowledge and tools that can help us understand better organizations and people we work with. In short, if we are not improving on a regular basis, we are regressing in our knowledge.
Some of the knowledge areas we discuss in this episode are:
The challenges we must be aware of in an Agile adoption
As change agents, we face many challenges, and Luca shares the most common ones he has faced in his career. From the negotiated agreement on the role of the Scrum Master or coach (e.g using the GROW model as a basis for those conversations) to the support network we need to establish to support our work and the continued adoption (e.g. using the communities of practice pattern).
Do we need a Scrum Master when the team is working well?
The final question we tackle is: when is our job done? Luca shares a pattern from his previous employer (ThoughtWorks) that covers aspects that support the team in their efforts, but is not a Scrum Master role. We discuss the “Iteration Manager” role and what that might mean for Scrum Masters that want to continue to work with a team that has reached a certain maturity level.
About Luca Minudel
Luca Minudel is a Lean-Agile Coach & Trainer with 14 years of experience in Lean/Agile and 20+ in professional software delivery. He is passionate about agility, lean, complexity science, and collaboration.
He contributed to the adoption of lean and agile practices at Ferrari’s F1 racing team. For ThoughtWorks he has delivered training, coaching, assessments and organisational transformations in top-tier organisations in Europe and the United States. He worked as Head of Agility in 4Finance and he is working as coach for a top bank in Canary Wharf.
Luca is founder and CEO at SmHarter.com, a company that helps organisations turn their way of working into their competitive advantage.
In this Bonus episode we have Diana Larsen, and James Shore, both authors of acclaimed books about Agile. They join us to talk about their model called Agile Fluency Model™. We talk about how the model emerged.
One of the premises of the model is that teams find proficiency in different aspects of their work. Some teams focus on Value delivery, others focus on improving their technical skills, etc. And although all of these approaches are valuable, they are also different. And we need to understand where we are, as well as what phase best corresponds to the needs of the teams and organizations we work with.
The different phases of team fluency are called “zones”, as in a Bus route. This is because all zones are possible destinations, but there is a certain sequence to the progression. Diana and James discovered this after a long process of learning and experimenting with the teams they’ve worked with. The model reflects their experience, and has been validated by many other Agile Coaches that have seen similar patterns of development for their teams. The Agile Fluency Model is a collection of patterns that teams experience over time, and given their specific focus.
The model is also a useful tool for our retrospectives in the form of a “diagnostics” tool that the core team has put together to help us understand where each of our team is according to the model.
Many will no doubt tempted to call the Agile Fluency Model a “maturity model”, but Diana and James point out that each of the phases of the model has its own maturity dimension, and a team can be very mature in any of the phases if that suits their business context. Maturity is a cross-cutting concern for all phases of the model.
There’s also a very cool story of how the model was invented. Interested? Then listen in on our conversation about the Agile Fluency Model.
When you are ready to know more, follow the links below:
Diana Larsen joins us today from Portland, Oregon. Diana leads the practice area for Agile software development, team leadership, and Agile evolutions at FutureWorks Consulting. Diana is co-author of Agile Retrospectives: Making Good Teams Great; Liftoff: Start and Sustain Successful Agile Teams; Five Rules for Accelerated Learning; and co-originator of the Agile Fluency™ model.