Barry Overeem’s Post

Who decides who is part of a team? 🤔 Is this decision completely up to the members themselves, or mostly up to them? Or is it not up to them at all? We call this team composition autonomy. 🔒 Many organizations are still figuring out how to provide such autonomy, given the increasing emphasis on autonomous teams for non-routine work. Our preliminary data from teams participating in Columinity suggest that such autonomy is still very modest: - 45% say they have no autonomy in this area 😥 - 25% say they have little autonomy 🤷♀️ - 10% of teams report high autonomy in this area 🥳 The point of team autonomy is to move decision-making down from a managerial layer and into the teams. Teams that face complex work often have to make many decisions on the fly. So, autonomy makes them faster. Studies also show that autonomy makes work more enjoyable and motivating because it recognizes the human need for freedom and self-direction. From that sense, composition autonomy is important because it allows teams to create the proper conditions (their teammates and their skills) for success. However, as our research shows, few teams can determine their composition. Both teams and managers struggle with this. 🤷♂️ In this post, Christiaan Verwijs dives deeper into team composition autonomy, offers a brief overview of the scientific consensus on this concept, and shares several strategies that worked in our work with teams. 👉 Strategy 1: Involve teams in the selection of new members 👉 Strategy 2: Create transparency around skills and how to develop them 👉 Strategy 3: Agree to delegation levels What is your experience with forming teams? In your experience, who decides the team's composition? What happened because of that?

Topic: Reflect on the empirical pillars of Scrum 🎯 Type: Retrospective format 🤔 Duration: 60 minutes ⏰ In complex work, more is unknown than known. The unknown is discovered by releasing done increments early and often. With these increments, you validate assumptions, learn what is needed, and avoid the risk of spending time and money on the wrong things. As a result, you can deliver value to your stakeholders sooner. When a team uses Scrum to navigate complexity, it's helpful to frequently reflect on the quality of the underlying empirical pillars: transparency, inspection, and adaptation. With the Scrum artifacts, you create transparency as follows: 🎯 Product Goals & Product Backlog = Future 🎯 Sprint Goals & Sprint Backlog = Present 💰 Product Increment & DoD = Past Product Goals and the Product Backlog make visible what the road ahead looks like and—given the knowledge you have today—what work is needed. Sprint Goals and the Sprint Backlog make the current focus and work visible. The Product Increment makes the work visible that has been completed so far and according to what quality standards (DoD). Each Scrum event is an opportunity to inspect and adapt. The Scrum events can only be effective if you have high-quality artifacts that reflect full transparency. As the Scrum Guide nicely describes: - Transparency enables inspection. Inspection without transparency is misleading and wasteful. 🤷♀️ - Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change. 🌀 - Adaptation requires autonomy, motivation, and skills to identify and implement small improvements. ✅ 🤔 How can you improve the artifacts so they'll make the future, present, and past even more clear? 🤔 How can you trigger deeper inspection to uncover the root cause of problems your team faces? 🤔 How can you identify small AND meaningful improvements to ignite a cycle of 'transparency, inspection, and adaptation' instead of transparency, inspection, and ignore'? Why don't you use the next Sprint Retrospective to reflect on these empirical pillars of Scrum? It's probably time well spent.

"Agile Coaches / Scrum Masters should be willing to get fired." 💥 Given recent layoffs of similar roles, I know it's a sensitive statement, but let me explain where it's coming from. 👇 Agile Coaches and Scrum Masters can face various impediments related to value delivery, release frequency, team morale, trust, and psychological safety (amongst others). These impediments are often not resolved because of a lack of management/leadership support. In almost all my (freelance) assignments, I've experienced the expectation towards me of becoming a whistleblower. Teams would share problems they often faced for a long time, but nobody dared to discuss them. Or they didn't know how to address it constructively. They tried, but nothing changed, and over time, people got frustrated and accepted that 'this is just how things work in our organization." 🤷♀️ I've always considered it my responsibility to share my observations with any judgment. "This is what I see, hear, notice, and feel. What do you make of it?" 🤔 Sometimes, these are positive observations, but more often, they are related to teams' persistent impediments. It can trigger a tough conversation when it's not resolved because of a lack of management support, especially if it's a conversation with the manager who hired you in the first place. Is this a reason NOT to share your observations? I don't hope so... I've probably shortened a couple of assignments because of this, but I like to believe it might have planted a seed to improve the situation. 🌱 A pitfall of an Agile Coach or Scrum Master is that you get too attached to your role. You don't address impediments anymore because you fear you might lose your freelance assignment or it might impact your career. I can totally understand it, but I don't believe it's a healthy position. You can't be an effective coach when you're stuck in this 'golden cage' you don't want to lose. So, this is what I mean by saying that an Agile Coach or Scrum Master should be prepared to get fired. What's your take on this? I'm very interested to learn from your personal experiences.

This week, I provided a public Scrum.org PSM II class in Amsterdam. With 18 participants from various countries and organizations, we explored the services a Scrum Master provides to the team, the broader organization, and themselves. I thoroughly enjoyed every minute and loved the many valuable conversations the exercises triggered. ❤️ On the first day, we... ✅ Used Scrum Mythbusters to get a sense of the experience of the group in a playful manner; ✅ Refreshed the key principles and values of Scrum; ✅ Reflected on the misunderstood and preferred stances of a Scrum Master; ✅ Shared ideas on how to navigate conflict in the Scrum team. ✅ Explored the factors that influence Scrum team effectiveness, based on scientific research by Prof. Dr. Daniel Russo and Christiaan Verwijs; ✅ Discussed how a done Increment minimizes risk and increases predictability; ✅ Learned how Product- and Sprint Goals give focus and guidance and help navigate the complexity of product development. On the second day, we... ✅ Explored how management is an integral part of Scrum; ✅ Conducted interviews with Product Owners to clarify their work and purpose; ✅ Identified strategies, experiments, and practices Scrum Masters can use to help Product Owners succeed. ✅ Made undesired behavior visible and decide how to stop it; ✅ Learned how to clearly express essential needs between management and Scrum teams (with WINFY); ✅ Created a shared understanding of the richness of the accountabilities of the Scrum Master and the importance of acting on different levels in the organization ✅ Offered opportunities to give and get help with Troika Consulting ✅ Used a spontaneous Wise Crowds to discuss any remaining challenges PS: I won't schedule any new public classes in the upcoming period. I'll see how I feel about it next year. I will be available to run this class in company. If you're interested, feel free to send me a message.

"Our Agile Coaches don't add any value." 😲 I recently talked to someone whose organization removed all their Agile Coaches. It seemed a drastic move, but in their opinion, the Agile Coaches didn't add any value. I don't know any numbers, but I've recently heard similar stories. It does raise the question: How do you show your value as an Agile Coach? 🤔 Compared to the work of a Project Manager, Product Manager, RTEs, and even Scrum Masters, the role of an Agile Coach quickly becomes vague and abstract. How do you show that you improved collaboration, interaction, and team(s) dynamics? How do you clarify that the team(s) deliver more value? How do you explain that you tweaked the organizational system and removed bottlenecks and dependencies? 🤷♀️ ❌ Don't use maturity models. Growth is not linear and doesn’t happen in discrete phases marked by convenient external characteristics. Reality is far messier than your maturity model 1️⃣ Use "Evidence-Based Management" EBM is an empirical approach that helps organizations use experimentation and rapid feedback to progress toward strategic, intermediate, and immediate goals. Connect your work as an Agile Coach to these goals. Organizations can develop, inspect, and adapt their measurements as they run experiments, continuously using data to gain information and evidence while always keeping sight of their goals. 2️⃣ Try Kanban metrics 😅 Work in Progress: the number of Product Backlog items started but not finished. 🚲 Cycle Time: when work begins on an item and when the item ships. 👴🏻 Work Item Age: the time between when a work item started and the current time. This applies only to items that are still in progress. ✅ Throughput: the number of work items finished per unit of time. ⏰ Lead time is when a stakeholder request enters the backlog and is fulfilled to that stakeholder through a release. 3️⃣ Measure progress with the Agile Team Effectiveness model The Agile Team Effectiveness model - developed by Christiaan Verwijs and Prof. Dr. Daniel Russo - is part of Columinity, a product to help teams improve based on scientific insights. You can diagnose one or many teams, receive extensive feedback, and resolve broader organizational issues. An Agile Coach can use Columinity to offer support where needed, to remove impediments and bottlenecks, and to visualize if teams are improving. This makes your contribution more tangible and helps you explain the value you deliver to the organization. 👉 What (other) recommendations do you have? 👉 How do YOU show your value as an Agile Coach?

New poster: Impromptu Networking 🥳 Impromptu Networking allows a group of any size to form personal connections and share ideas in less than 20 minutes. It invites everyone to participate from the very start and share stories, challenges, or experiences with each other. Not only is it a good way to ‘break the ice,’ but it also cleverly uses the collective brainpower of the group to identify patterns rapidly. We worked with Thea Schukken to capture the steps AND the possibilities in one illustration. We hope you like the result. Use it as inspiration for your sessions! ## Tips: 🚶♂️ Do it standing, with people walking around the room to form pairs. This is not required. Walking around is a great energizer, though; ☀ Take the group outside of the meeting room for a bit of fresh air and a different environment; 🔔 Use bells (e.g., tingsha) to help you shift participants from first, to second, to third rounds; ✅ Ask questions that are open-ended but not too broad or difficult; ❌ Don’t skimp on the rounds. They are short anyway. The power of this format lies in the three conversations that people will be having and what they learn from that; ⏰ We found that 4 minutes per round is usually enough. But if the conversations die down before that, don’t wait until the timebox expires; instead, start a new round. This keeps the energy up. We often decrease the timebox per round (4, 3, 2 minutes); ❓ As a reminder, write down the question(s) on a flip chart. 🤔 Before the first round, give everyone one minute to start thinking. This will allow them to have a productive conversation once they pair up for the first time. 🙋♂️ Raise hands when forming a pair. In a large group, it’s tempting to form a pair with the person standing next to you, which is fine to a certain extent but might result in having the same pairs continuously. We always encourage people to raise their hands before pairing up. This allows everyone to see who still needs to pair up. Another tweak is that we encourage people to point to the person across the room. 👉 👈 Once you’re pointing at each other, you’ve formed a pair; you only need to walk to the other person. This is way more fun and brings back some energy in the group. ## Bonus tip: use "lightweight" facilitation ❌ Don’t strictly timebox 3 rounds of 3 minutes in different pairs; ✔ Do give participants a 10-minute timebox and invite them to self-organize in pairs frequently; ✔ Whenever someone needs a new pair, they simply raise their hand; ✔ Challenge participants to form new pairs at least 3 times, maybe even 5 times! As a facilitator, you manage the overall timebox; the participants manage the shorter ones themselves. A big advantage is that participants don’t feel rushed and pushed. Enjoy running Impromptu Networking! What is your experience with the Liberating Structure?

Topic: Product- and Sprint Goal 🎯 Type: Retrospective format 🤔 Duration: 60 minutes ⏰ A Sprint Goal is a shared goal that a team agrees on at the start of their Sprint. The aim is for a team to challenge and encourage itself to seek collaboration and coherence during that Sprint instead of seeing all its members work on their own tasks. "But how?" you may now wonder. 🤷♀️ Use a Liberating Structure like 1-2-4-ALL, Conversation Cafe, or XxN-Writing to reflect on the following statements: 1️⃣ With complex work, it is important to have a Sprint Goal because... 2️⃣ If a team doesn't have a Sprint Goal, what might happen is... 3️⃣ A reason the team might struggle with defining Sprint Goals is... 4️⃣ A Sprint Goal is connected to the Product Goal by... 5️⃣ If you don't have a Sprint Goal, what happens to the Scrum events is... 6️⃣ The Product Owner, Scrum Master, and Developers can help define shared goals by... 7️⃣ My experience with using Sprint Goals is... While discussing the statements, make sure to include insights like: ✅ In complex work, clear goals guide what needs attention and what doesn't. ✅ Shared goals are the glue that binds individuals into a team by giving them a shared purpose. ✅ Goals give teams focus on what is important during a Sprint while allowing flexibility to adjust course and avoid emerging obstacles as needed. Close the Retrospective by identifying small improvements. Actions to start small and simple are: 👉 As an experiment, start your next iteration with a goal you'd like to achieve and then select the items from the Product Backlog that fit that goal. 👉 Next iteration, your team will politely say 'No' to any non-critical request that doesn't fit the Sprint Goal. 👉 Ask your most important stakeholders what they think the goal of your next iteration should be. If it's too broad, reduce it. What is your experience with using shared goals❓ What recommendations do you have to help a team start improving❓

Update: Already 44 people signed up! 🥳 This means we only have 6 spots available. So, make up your mind if you're interested. I expect to have a fully booked workshop within 2 weeks. ❓What: Liberating Structures Advanced Workshop ❓When: 26/27 June ❓Where: Volkshotel, Amsterdam ❓Who else: Saskia Vermeer-Ooms, Denise Fleck, Matthieu Tournemire, and I form the facilitation team The advanced workshop contains Liberating Structures that aren't part of my standard Immersion Workshop. For example: 1️⃣ "Panarchy" to understand how the system as a whole interacts 2️⃣ "Helping Heuristics" to practice progressive methods to offer help 3️⃣ "Conversation Cafe" to share challenges and ideas 4️⃣ "Improv Prototyping" to playfully develop solutions for chronic challenges 5️⃣ "Min Specs" to identify the absolute essential 6️⃣ "What I Need From You" to make clear requests for help 7️⃣ "Wise Crowds" to tap the wisdom of the whole group 8️⃣ "Simple Ethnography" to record actual behaviors of users in the field 9️⃣ "Social Network Webbing" to map informal connections and to decide how to strengthen the network to achieve the purpose 🔟 "Generative Relationships STAR" to visualize the performance of a group We'll also include unofficial structures like Myth Turning, Tiny Demons 👿, and Talking With Pixies. As a bonus, we used the concept of Strategy Knotworking as its foundation. Strategy Knotworking is a coherent set of Liberating Structures that aims to involve and engage everyone in developing and evolving sustainable strategies. Why join our workshop❓ 💤 We'll keep you from dozing off during two high-energy days. No boring PowerPoint! 🤔 We'll host an online retrospective 6 - 8 weeks afterward. Joining is optional but an excellent opportunity to catch up with the participants again and share your progress. 🛠 Receive a digital version of all the material we use during the workshop. This means a digital copy of all the posters, exercises, and all other material. 🌎 Previous workshops contained 25 - 75 participants from ±10 different countries. This alone offers a tremendous opportunity to learn from many different cultures and organizations. 🌀 Experience how to use Liberating Structures in person, but we'll also share all our lessons learned on how to use the structures online! 🆓 The day before the 2-day workshop, we'll facilitate a 3-hour session focused on the basics of Liberating Structures. Use it as a refresher, a warming-up session, or to gain the necessary knowledge and experience if you're new to Liberating Structures. 🚀 And much more :) Sounds interesting? Sign up here: https://bit.ly/448Obvk

The Fragility of Agile Transformations 💥 I've experienced multiple so-called Agile transformations at small and large organizations. An interesting pattern I noticed is how fragile these transformations are. Even in organizations with 1000+ employees, which have invested years (and lots of 💰) in training everyone, things seemed to collapse when only a few people left the company. Often, the people who initiated the transformation in the first place. When reflecting on my experiences, here's what comes to mind... The most successful Agile transformations I've experienced were connected to something tangible, such as developing a mission-critical product involving the entire organization. Everyone understood why more agility was needed, so everyone tried to make it happen. In short, there was a shared sense of urgency and a clear goal. 🎯 The tricky part happened when the product was released. Everyone celebrated, and many people often moved on to a new endeavor (outside the company). This is when you can see if the spaghetti sticks on the wall. It's not necessarily a failure if it doesn't stick, but you must be prepared. Organizations evolve in (Eco-) cycles. That's why I have an issue with the concept of 'Agile Transformations' in the first place. It assumes completion. Organizations are never complete; they continuously evolve and change. 🌀 To make the spaghetti stick to the wall, the organization's influencers (for lack of a better term) should talk WITH employees about why increased agility matters, not only TO employees. There's a difference. Define the purpose and develop experiments, practices, and strategies as a shared effort. People will only fully embrace a new way of working when they have been involved in shaping it. No matter how compelling and inspiring your vision on Agile transformation is, it won't stick if you don't involve employees in making it their own. Remove all the Agile language and help people understand how it will change (and improve) their daily work lives. If you wonder how to scale this conversation in a 1000+ organization, check #LiberatingStructures 😎 What’s your experience with the fragility of Agile transformations or with the (false?) idea of an Agile transformation in general? What recommendations do you have to make them stick?

Customers 👇 Account Manager 👇 Product Owner 👇 Developers This was the flow the customer's voice needed to go through to eventually reach the Developers. Its Account Manager was highly frustrated because he continuously talked with angry customers, Product Owners, and Developers. The customer was angry because: 😩The software was full of bugs 😩 Releasing improvements was very slow The Developers were angry because: 😡 They were under lots of pressure 😡 Teams had dependencies, which made releasing difficult 😡 Customers wanted new features, so there wasn't time for bug-fixing 😤 The Product Owners were angry because they had a limited mandate to make meaningful (product) decisions. And everyone was venting their frustrations towards the Account Manager. I felt sorry with him. He was in a shitty situation. 💩 So, my question was: "Why not directly have the Developers talk with the customers? Try to create shared understanding." One of the worries was that this would escalate the situation, piss the Developers off, and have them leave the company... "If I would tell the Developers the same things the customers tell me... Oh boy..." I was so surprised by this answer that an immediate response didn't come to mind. But my facial expression probably said enough. 🤯 Obviously, this situation didn't emerge overnight. It probably slowly evolved within the organization and wasn't addressed early on, so it could spread further. Given that it's a software company, finding a solution is critical, though. Imagine you are assigned as the coach (Scrum Master/Agile Coach) for these teams. What would you do? How would you handle this situation? 🤔 PS: this is based on a real-life situation...