Show cover of The Liberators Network

The Liberators Network

If you're excited about unleashing organizational superpowers, then this is the podcast for you. We talk about Scrum, Liberating Structures, and creating better workplaces. This podcast is created by Christiaan Verwijs and Barry Overeem. Both are Professional Scrum Trainers for and stewards of the Professional Scrum Master II class they created. Aside from their extensive background and experience with Scrum, they are very excited about Liberating Structures and are active members of this worldwide community. We publish a new episode every first Friday of the month.


In-Depth: Are Scrum Masters Sufficiently Focused On Valuable Outcomes?
Are Scrum Masters perhaps too focused on the process, and too little on whether or not that process actually delivers valuable outcomes? How is that for you, as a Scrum Master?This is a hunch based on countless conversations we've had with Scrum Masters, including our own practice as a Scrum Master. But what do the facts say? So we read relevant scientific studies and collected data through a large poll (500+ participants) and data from almost 2.000 Scrum teams. We were also fortunate to use data from a research study by McKinsey and data suggest that Scrum Masters are more effective when they balance a process-based perspective with a value-based perspective. This means that Scrum Masters lead in designing effective Sprint Reviews, drawing in stakeholders, and emphasizing the need for this. I expect that Scrum Masters that stake a strong stance here are more likely to see effective Scrum teams over time. I offer tips on how to do this.Read the transcript here: Diagnose your team with the Scrum Team Survey:https://scrumteamsurvey.orgSupport the show
34:03 3/3/23
How Work On The Scrum Team Survey Taught Us 10 Lessons About Agile
We are creating the Scrum Team Survey to help Scrum teams and Agile teams to diagnose their process. We also give tons of evidence-based feedback. One of the cool things about developing a product ourselves, and with our own money, is that we get to learn (or reaffirm) a lot of valuable lessons about Agile software development. In this episode, we share our 10 biggest lessons. Be prepared for some technical stuff though, as several of these lessons involve architecture, design, and code quality.Read the blog post for this episode here: the Scrum Team Survey here (it's free for individual teams)https://scrumteamsurvey.orgTry the Team Dashboard here: the show
37:45 2/3/23
In-Depth: How Coherence And Cohesion Are Critical To Scrum
Do your Daily Scrums feel like a pointless ritual where everyone just lists what they’ve done yesterday, and what they do will do today? Does Sprint Planning feel like a waste of time because everyone only wants to know what they have to do? And does your Sprint Review consist of team members listing their individual accomplishments? If so, you are probably dealing with a complete lack of coherence and cohesion.This episode is an exploration of scientific insights that help us understand what coherence and cohesion are, and why they are so important. We also explore how these insights create a strong foundation for the Scrum framework. We also translate scientific insights into practical applications, ready for use with your team.Read the transcript here: many do-it-yourself workshops to help your team: the show: the show
22:42 1/6/23
Is Blue-print Thinking Limiting The Potential Of The Agile Community?
Do you start a new Scrum team by explaining the roles, artifacts, and events? Do you rarely consider how to build coalitions and persuade people in power to support your work with Scrum? Are you thinking about the psychological needs of people and how to motivate them to work with Scrum? You may be engaging in a bit too much blueprint thinking.In this episode, we explore how blue-print thinking is too dominant in our profession. There are exceptions. But much of the professional discourse is focused on frameworks, processes, and structure — independent of the messy sociological, political, and psychological realities of organizations. We explore how this bias leads to blind spots. It also explains why so many framework implementations fail. This episode is based on the “Color Theory of Change”, and we think its quite eye-opening if you've never reflected on this before.Find the transcript here: our show at Patreon: the show
30:10 12/2/22
In-Depth: Stable Or Fluid Teams? What Does The Science Say?
Recently, the concept of “fluid teams”, “dynamic reteaming” or “ad-hoc teaming” has gained traction in the Agile community. Although the concept has many different definitions, a characteristic they share is that members move in and out of a team during its lifetime.However, decades of academic research into teams and workgroups have underscored the importance of team stability as a requirement for high performance. Although these studies did not compare stable teams versus fluid teams specifically, the most reliable theories we currently have to understand team development also seem to favor stability over fluidity.In this episode, I explore the research in this area. Considering just how popular the notion of fluid teams has become, I think it is important to weigh the evidence that supports it or contradicts it.Read the transcript of the episode here (including all references): an in-depth post about team cognition: an in-depth post about social cohesion: the show at: the show
31:03 11/4/22
In-Depth: How To Create Better Work Agreements For Your Team
Do high-performing teams communicate more than low-performing teams? 🤔If you think "Yes!", you may want to reconsider. Scientific studies often find the reverse. When researchers compare high-performing teams with low-performing teams, they consistently find that high-performing teams communicate less. This has been observed with flight crews, nuclear plant control crews, and work teams.These teams have not developed telepathy, but they've learned so well what is expected of each other that they don’t need to communicate explicitly for day-to-day coordination. This effectively keeps a lot of their bandwidth open for problem-solving, critical communication, and maintaining focus - and that makes them more effective.There is so much to unpack here. It tells us much about cross-functionality, team cognition, and what it takes to grow high-performing teams. In a very practical sense, I think it shows us how important it is to develop work agreements and mental team models about how to:- Coordinate work- Coordinate the use and application of skills- Coordinate the navigation of conflict- Coordinate psychologically safety (the proper kind)- Coordinate dealing with work pressure and stressRead the transcript of the episode here (including all references): the show at: the show
27:37 10/7/22
In-Depth: What Scientific Research Has To Say About Technical Debt And Code Smells
Why is code quality so often an issue? Why do software teams — despite their best initial intentions — often end up fighting a codebase that is hard to test, resistant to change, and prone to strange bugs?We have many intuitions about this. But we’ve learned the hard way that my intuitions are often wrong. So in this episode, we explore insights from scientific studies that have investigated technical and code smells. We also share evidence-based recommendations on how to write better code. This episode is interesting both for developers and non-developers.And yes, it turns out that several of our intuitions are indeed wrong :DRead the transcript of this episode (it includes the reference)Try the Scrum Team Survey with your teamSupport the show on the show
31:20 9/2/22
Agility And Business Agility Are The Same
There is a growing trend in our industry to distinguish between “Agility” and “Business Agility”. The idea here is that Agile is limited only to teams and to software and that more is needed. Many consultancy firms are now jumping into that gap with additional frameworks and models.This makes no sense to me. I think that this distinction reveals a glaring misunderstanding of the purpose of Agile. More importantly, I think that the distinction between Agility and Business Agility only muddies the waters and distracts leaders away from what it is they should be doing.We take a history tour to visit some of the precursors of Agile and learn what made them different from what came before, and why. With this historical understanding, we then revisit the distinction between business agility and agility to see if it makes sense. We also explore the notion that "Agile is only for teams" and "Agile is only for software".This episode is an opinion piece. You may agree or you may not. Either way, we hope you learn something from it.A transcript is available here (an account for Medium is necessary)Support the show
15:30 11/12/21
10 Powerful Strategies To Break Down Product Backlog Items
Great Scrum Teams know that refinement is one of the best ways to optimize the flow of work and deliver more value to stakeholders. Refinement is the act of breaking down and clarifying work for this and upcoming Sprints. We also know this from our research with 1.200 Scrum Teams; teams that actively refine also release more frequently. And they have more satisfied stakeholders and higher morale.Sounds good! But how? It is often surprisingly hard for teams to break down large chunks of work in such a way that the smaller pieces still deliver value on their own. Often, work is broken down across technical layers (horizontal) instead of functional layers (vertical).In this podcast, we share the 10 strategies that have worked well for us, and the Scrum Teams we've been part of. Each strategy breaks work across functional layers. We give examples for each strategy and explain how they support your team and the Product Owner.  We still actively use them for our work on the Scrum Team Survey too! We apologize for the length. You can easily listen to the episode in parts though.Download the cheatsheet (it is free): the Powerful Questions deck: the original post this podcast is based on: the show
43:18 9/17/21
Why Psychological Safety Improves The Effectiveness Of Your Team
"Professionals don't need psychological safety" is what someone recently told us. Perhaps you are on the fence about the need for psychological safety too. Or you get the point, but always struggle to make it practical. In this podcast, we explore psychological safety from a scientific perspective. And we offer many practical recommendations for what psychological safety looks like in teams and how to develop it. You can also hear some great ideas and suggestions that were generated by our growing community of patrons. Read the transcript here (includes references): many free do-it-yourself workshops to improve psychological safety (among other things): our work too at: the show
18:23 9/3/21
Refinement: The Mise en Place of Great Scrum Teams
Does refinement in your team feel like a slog? Do developers go there with lead in their shoes? Many Scrum Teams struggle with refinement, and understandably so. Yet, in many ways, this is where some of the most important work happens. And some of the hardest work. In this episode, we offer a reflection on the purpose of refinement. And we offer recommendations to make the process more enjoyable and effective — many of which originate from a discussion we had with experienced Scrum Masters on the Discord server that is accessible to our patrons.Check out the transcript here: paper we wrote with Daniel Russo is available here: the free cheatsheet with 10 breakdown strategies here: try this fully prepared do-it-yourself workshop for refinement: the show
15:39 7/16/21
From Largest Potential Product To Smallest Valuable Products
The biggest challenge in Product Development is to distinguish between what the product can become one day, and what it should incrementally become first to validate critical assumptions that clear the way towards that future. This presents a major struggle for Product Owners, customers, users, and developers as they are all inclined to spend most of their time thinking about the “Largest Potential Product” instead of the “Smallest Valuable Product”. In this podcast, Christiaan talks about product discovery, minimum valuable (or viable) products and offers many ideas on how to engage in product discovery.Diagnose (free) how well your Scrum team is discovering their product:https://scrumteamsurvey.orgFind a transcript here (requires a Medium-account): our work: the show
20:06 6/18/21
Why Great (Scrum) Teams Have A Mind Of Their Own
How does "team cognition" make some Scrum teams more effective than others? In this podcast, we explore scientific research into team cognition and mental models. And we translate it into actionable improvements you can make to make your Scrum teams more effective.By the end of the episode, you will have learned:How team cognition is essentially the "mind of a team", with its own memory and perception of the world.What team cognition is and how substantial its influence is on the effectiveness of teams according to large-scale research effortsHow team cognition helps us understand what cross-functionality should look like for Scrum teams.What team cognition looks like for Scrum teams, and what signs tell you whether it's there or not. And if it isn't, what you can do about that.What research in this area tells us about how you can design, support, and encourage teams to develop team cognition and become high-performing.Why frequent changes to team composition are not a good idea if you want to maintain effectiveness, no matter how they are initiated.More resourcesSupport this podcast by becoming a patronRead the transcript here (a medium account is, unfortunately, necessary until it is published)Try the Scrum Team SurveyBarry Overeem and I created three do-it-yourself workshops (#1, #2, and #3) to help your team create shared goals.ReferencesButler, A. C., Chapman, J. E., Forman, E. M., & Beck, A. T. (2006). The empirical status of cognitive-behavioral therapy: a review of meta-analyses. Clinical psychology review, 26(1), 17–31.Cannon‐Bowers, J. A., & Salas, E. (2001). Reflections on shared cognition. Journal of Organizational Behavior: The International Journal of Industrial, Occupational and Organizational Psychology and Behavior, 22(2), 195–202.DeChurch, L. A., & Mesmer-Magnus, J. R. (2010). The cognitive underpinnings of effective teamwork: a meta-analysis. Journal of applied psychology, 95(1), 32.Kearney, E., Gebert, D., & Voelpel, S. C. (2009). When and how diversity benefits teams: The importance of team members’ need for cognition. Academy of Management journal, 52(3), 581–598.Kozlowski, S. W., & Ilgen, D. R. (2006). Enhancing the effectiveness of work groups and teams. Psychological science in the public interest, 7(3), 77–124.Mathieu, J. E., Heffner, T. S., Goodwin, G. F., Salas, E., & Cannon-Bowers, J. A. (2000). The influence of shared mental models on team process and performance. Journal of applied psychology, 85(2), 273.Stout, R. J., Cannon-Bowers, J. A., & Salas, E. (2017). The role of shared mental models in developing team situational awareness: Implications for training. Naval Air Warfare Center Training Systems Division.Tolin, D.Support the show
20:55 5/14/21
Five Tips Every Starting Scrum Master Should Know
When we started as #ScrumMaster, the thing that scared us the most was how to translate those lofty ideals into actual down-to-earth behavior. While it sounded great that #Scrum is about #empiricism”, we had no idea what that should look like with our teams, how we should behave to support that and how flexible we could be with the framework of Scrum.In this episode of our #podcast, we collected five practical insights that we think every starting Scrum Master should know, and that are inspired by mistakes I made over the years. If anything, we wish we would’ve realized these when we started. For this episode, we also asked our growing community of experienced Scrum practitioners on Discord for help.A transcript for this episode is available here (Medium account required, unfortunately):Here are some helpful exercise materials for starting Scrum TeamsWe designed a bunch of do-it-yourself workshops to start Scrum Master communities in your own area or organizationEnjoy!Support the show
15:52 4/23/21
How To Remain Productive While Working From Home In A Pandemic (with Daniel Russo)
Even when we don't want to admit it, the Covid-19 pandemic changed how we work. Even after the pandemic ends, it is likely that many Scrum Teams will continue to work from home. Or at least, more often than before the pandemic hit.What is the impact of working from home on productivity and personal well-being? How can organizations support it well? And what can Scrum Masters do? We invited Daniel Russo, assistant professor in the Department of Computer Science from the University of Aalborg to talk about his research that was funded by the Carlsberg foundation. During the pandemic, he and three colleagues had a unique opportunity to follow a group of developers during the early months of the pandemic. Their research gives us compelling insights into how working from home impacts productivity and well-being - often in surprising ways. It also gives us a handle on what we can do to support developers that work from home during pandemics, and hopefully also outside of pandemics.Read the entire study online here: the show
30:02 4/3/21
“That’s Impossible!”: Self-Limiting Beliefs in Scrum and how to deal with them as a Scrum Master
This episode is all about what is impossible when you work with Scrum. Deliver a new and working version of the product every Sprint? Impossible! Give a Product Owner mandate over how to spend the product budget? Impossible! Have only one Product Owner for several Scrum Teams? Impossible!But is it really impossible? In this episode we look at how self-limiting beliefs can impede potential improvements. And how those beliefs tend to spread in organizations. At the same time, we offer you an alternative approach to investigate with your team where these beliefs came from. Or which decisions were made somewhere in the past that makes it seem impossible today.Enjoy!A transcript of this episode is available here.Support the show
11:39 3/26/21
So, When Will It Be Done? And How Much Will It Cost?
This episode is all about that dreaded question: "When is it done and what will it cost?". Its also one of the most natural questions for customers and managers to ask. After all, they're either investing their own money or they will be held accountable when the product fails to return on its investment.So what can you do? In this episode, we draw from personal experience and what - after many experiments - worked for us. Will you play along in "risk management theater"? Or will you offer your customers and other stakeholders an approach that has unique benefits that they don't otherwise have? The blogpost this episode is based on can be found here (a Medium account is required): older - and admittedly rougher - version of the post is also available here: can also support at the show
12:50 3/12/21
What Shipping Fast Looks Like In Healthy Scrum
We often talk about how "Zombie Scrum" lacks frequently releases. Teams are not shipping fast. And while people often easily recognize this in their own team, what does it actually look like on the other side?In this episode, we take a close look at shipping fast. Why is it important? And how can it be turned into the competitive advantage - or asset - that it really is? We also offer some of the strategies that healthy Scrum Teams use to make releases as effortless as possible, and reduce the stress and pressure that often accompanies "big bang releases".This episode draws from material in the Zombie Scrum Survival Guide. Get your copy here:https://zombiescrum.orgYou can also find a whole bunch of do-it-yourself workshops (some free, some for a small price) to improve your Scrum here: the show
22:38 2/22/21
Five Types Of Value
The Scrum framework exists to deliver value to stakeholders sooner. Sounds good, right? But when is something “valuable”? For something that seems so central to Scrum, it is remarkably hard for many Scrum Teams to determine what the value of the work on their Product Backlog actually us.In this episode, we offer a more fine-grained approach to understand what “value” means to your product and the items on your Product Backlog, and to start a conversation around that with your team and its stakeholders.You can read a transcript for this episode here.Or download a (free) poster of the five types here (PDF).Or get a fully-prepared string of Liberating Structures to start a conversation around value, and the five types of value, with your team and stakeholders.Support the show
22:35 2/5/21
How To Involve Your Stakeholders
How do you know that you're actually delivering value to your stakeholders? That you're responsive to their needs? And that the quality of your work is what they expect?This episode is all about value and stakeholders. We introduce a new feature for the Scrum Team Survey that allows team invite their stakeholders for their perspective. And we share a great way to involve your stakeholders in the creation of product strategies.Support the show
41:59 1/29/21
On Continuous Improvement And Agile Transformations
In today's episode, we make the connection between the Scrum Framework and continuous improvement. Few Scrum Teams start from a position where everything works smoothly. Often, you initially don't know very well who your stakeholders are, you don't have access to them or you can't release as frequently as you'd want to. So there's a lot to improve and to learn. And if that doesn't happen, you're bound to get stuck in deep Zombie Scrum.At the same time we see many organizations engage in "Agile Transitions" that promise to change from one state (e.g. waterfall-based development) to another (e.g. Agile) in a short amount of time. But an exploration of organizations that have undergone such transitions shows that stakeholders are still not involved, releases still happen very infrequently and little value is delivered to stakeholders.So we draw from two helpful perspectives - organizational learning by Chris Argyris and the force field model by Kurt Lewin - to understand how continuous improvement is vitally important to effective Scrum - and change in general - and unlikely to be rushed on by "Agile Transitions" and "mindset changes".We apologize for the sound quality here and there. The gain of our microphone was a bit too high, which means that there are a few cracks here and there. The good news is that we've learned to reduce the gain now for the next recording :)Support the show
17:56 1/21/21
A Conversation About The Zombie Scrum Survival Guide
Paul Klipp and Justyna Pindel recently reviewed our new book "The Zombie Scrum Survival Guide". They also graciously invited us to talk about our book with them. The ensuing conversation was so nice, that we asked them if we could also publish it as part of our podcast.So here it is :) In it, we talk about how we've seen Zombie Scrum happen around us, how we wrote the book to help Scrum Teams and how our industry sometimes contributes to Zombie Scrum because it is so strongly focused on certificates.Follow the Agile Book Club here: your copy of the book here:https://zombiescrum.orgOr diagnose your team for free here:https://survey.zombiescrum.orgSupport the show
68:03 1/8/21
How Group Dynamics Explain How We Often Create Our Own Resistance
We often talk about "resistance", and how to overcome it in others. But ironically, we often create resistance ourselves.In this episode of our podcast, Christiaan shares one of his biggest lessons about change and resistance. With this in mind, we also explore how group dynamics helps us explain how we can easily create and amplify resistance through our own behavior.If you like this podcast, and our content, please consider supporting us: the show
11:41 1/2/21
Self-Organization As A Survival Skill (And How Self-Managing Teams Get You There)
In today's episode, we talk about self-management and self-organization. How are those concepts related. And why are incredibly both valuable and important, even now that the Scrum Guide changed its language to emphasize "self-managing Scrum Teams" instead of "self-organizing Scrum Teams"?Coincidentally, we dedicated a chapter in our book - the Zombie Scrum Survival Guide - to self-organization and self-management. In it, we make the case that the Scrum Guide always meant "self-managing" in the first place, and how those self-managing Scrum Teams enable self-organization on a larger level (the department, the organization).In this episode, we give examples of what self-management and self-organization looks like. And more importantly, how self-managing Scrum Teams act as a crowbar to increase agility and responsiveness by driving self-organization on the level of the organization.This episode features a part of one of the chapters from our book. You can get it at your favorite bookstore, or directly from us.Support the show
17:45 12/18/20
What Makes A Developer Culture: A Personal Story
"Without good developers, Scrum is lipstick on a pig". Yet, a quick look on blogs, LinkedIn and popular podcasts makes it obvious that more attention goes to Scrum Masters, Product Owners and coaches than to developers. Why is that?In this episode, we share a personal story about a what contributes to a "Developer Culture". This is a culture where software craftmanship is celebrated, and developers work hard to increase quality and their skills. Without this, it will be very hard to work empirically and overcome tough technical challenges that you're likely to face.We explore eight factors that seem to contribute to a successful developer culture, at least based on our experience. If anything, it may inspire you with ideas for things to try or ways to create a similar culture in your organization.This episode is based on this blogpost (which also contains the pictures): can support the show on Patreon: the show
33:03 12/11/20
What 4 Key Changes To The Scrum Guide Tell Us About Scrum
Are you excited about the new Scrum Guide? We certainly are, if only because every version makes it more clear what Scrum is really about — which is also our mission.In this episode, we take a look at the four most significant changes and why they were made. While it is tempting to talk about all the nitty-gritty linguistic changes, we believe it is more helpful to understand the underlying patterns and how they reinforce what Scrum has always been about.You can find a transcript of this episode here: new Scrum Guide is available (as always) at:https://scrumguides.orgYou can download our updated Scrum Framework poster here: the show
18:59 11/20/20
About "Purpose to Practice"
It is easy to start new initiatives. And much harder to make them endure. Whether or it is a new team, a new community, or a new product, how do you create a foundation to build on?Thankfully, the Liberating Structure "Purpose to Practice" is of great help here as it gives groups five essential elements to focus on: purpose, principles, participants, structure, and practices.We've frequently used Purpose to Practice (P2P) to start new teams, communities of Scrum Masters, change initiatives, and even entire organizations. In this episode, we share how we've used P2P in our work, specifically for our growing community of patrons, and how you can use it in your own work.Read a blog post we wrote about Purpose to Practice here: try this prepared string for a Purpose-to-Practice with your team.Or download a free PDF canvas for Purpose to Practice.And we happily invite you to join our growing community of patrons and work with us to refine our Purpose to Practice together: the show
31:05 11/13/20
Organizational Learning; Why Single-Loop Learning Isn't Enough In Scrum
At its core, Scrum is a framework for learning. But learning is hard when what you learn remains superficial and never challenges existing rules and beliefs. In this episode, we talk about the foundational work by theorist Chris Argyris on organizational learning. He developed a model for organizational learning that distinguishes between single- and double-loop learning. Where single-loop learning concerns itself with correcting mistakes in the actions that you take, double-loop learning takes it several steps deeper and challenges why you're even taking those actions. In our own work, we recognize that Scrum doesn't work when there is only single-loop learning. For example, many Scrum Teams struggle to find the best way to estimate their work and experiment with story points, t-shirt sizing, or functional points. But the deeper question is; why are we estimating work that we know is inherently unpredictable? What existing beliefs are making us estimate our work, that we should revisit and change?The Liberating Structure "Myth Turning" is all about double-loop learning: developed a deck of Powerful Questions to help you challenge existing beliefs: the show
32:33 11/13/20
Don't Scale Up. Scale Your Product Down!
"How is it a good idea to mirror this complexity in the product with complexity in the group of people that develop this product?"Scaling Scrum is seriously hard, right? How do you work with many teams on one product? How many Product Owners should you have for one large product? How can many teams deliver a "Done" Increment every Sprint? How do you manage the increasing number of dependencies between teams? Honestly, we believe that -  in most cases -  scaling Scrum is tantamount to solving the wrong problem. And we say that irrespective of the framework you use, Nexus, LeSS, or SAFe: Scaling Scrum is a contradiction.In this episode of our podcast, we explain why. And we offer you five strategies to avoid scaling.Support the show
19:08 10/30/20
Why Zombie Scrum Teams Struggle To Improve Continuously
Few teams start from a position where the Scrum Framework works like a charm from the start. Scrum is radically different from the way that teams have built products and worked with stakeholders in the past. Scrum Teams usually need to improve in many different areas, and overcome many barriers, in order to reach their goals of higher customer satisfaction. Unfortunately, we’ve found that many Scrum Teams struggle to improve at all. And that easily leads to Zombie Scrum: something that may look like Scrum from a distance but lacks the beating heart. In this episode, we address one common reason for this: a lack of tangible improvements.Read a transcript of this episode here: about 15% Solutions can be found here: can pre-order the Zombie Scrum Survival Guide here:https://zombiescrum.orgSupport the show
15:23 10/23/20