agile - Agile and Scrum Blog

Agile Transformation Metrics

It’s very common that people ask me how they shall measure the success of their Agile transformation. It’s a hard question because there is no meaningful metrics unless you know why you decided to start the agile transformation at the first place at all. Agile is not your goal, it’s just a way how to achieve some of your more strategic goals i.e. address complexity better, be more change responsive, shorten time to market, be more flexible, … And once you know why you are starting your agile journey, then those reasons are exactly the metrics you are going to measure at the organizational level. All are business-oriented and value-driven (outcome), so there is no velocity, no story points as those are focusing on output.

If you want to have a fast culture check on how far you have moved towards the agile mindset, you may look into how many experiments the teams are running, what are their actions from the retrospectives, and how they help them to deliver more value, how likely your teams take failure as learning vs. blaming opportunity, how close are they to customers, and how they collaborate vs. work individually or in silos. As a follow-up, you can have a look to your positions (are they rather broad supporting cross-functional teams than detail task-oriented), recruiting (are we hiring for approach and personality over the hard skills), performance review (team-oriented based on peer feedback over the individual), goals and objectives (team-based focused on purpose and outcome over tactical and individual KPIs focused on output), … and I can continue.

Looking to technical practices, you can check how your software teams implemented Extreme Programming practices i.e. Continuous Integration (even one-minute old code is old code), TDD – Test Driven Development (and overall attest automation), if they use pair programming or mob-programming to collaborate, having strong Definition of Done, focusing on one story at a time, and are ready for Continuous Delivery.

All over Agile is about team collaboration, customer-centered value-driven way of working, and short feedback loops. The rest are just practices, processes, and tools which might support your journey or not. The most important is not what exactly you are measuring, but what you are going to change based on that metric. If the metrics is helping you to improve and change your way of working, it’s a good metric. Measuring something just so you have it, or so you can draw a chart is a waste of your time.

Scaling Success

Companies are not scaling Agile or Scrum, they are scaling success. At our agile journey, we were often wondering how to start, what practices, tools, and processes shall we use. What I learned on my journey is that we don’t need another method. None of these are silver bullets anyway. They are all great for the beginning to change the way you work and to change the mindset. But the most important part of your journey is success. Can you share a success story? Using your own language, describing how your own environment changed, showing the impact the different ways of working created? If yes, people start picking up and trying to achieve a similar impact. The most successful agile transformations I’ve seen started exactly like it. With a small team experimenting with practices, and sharing the impact with others and depending on the starting point, sharing the various different success stories, i.e. 5 times less bugs reported by customers, 3 times more value delivered by the given time (which is not the same as more functionality but quite the opposite), significantly faster time to market, higher motivation and engagement score, more innovations which result in higher customer satisfaction, … the impact varies depending on the environment. For us a few years back it was higher flexibility, faster learning, and higher customer satisfaction.

Sharing success is not anything new in change management. It’s one of the Eight steps for successful change by John Kotter which for some reason are still not widely known in an agile community, so I thought I remind you about them here:

Create a sense of urgency – Unless you know why you are changing the way you work (to be more agile, Scrum, or Kanban), then don’t do it. Neither Agile, Scrum, or Kanban is your goal. They are just ‘walking sticks’ helping you on your journey to success. You need to have a higher purpose defined which will be stronger than their individual goals and therefore unify people.
Build a guiding coalition – You can never change the organization alone. You need to find supporters (agile enthusiasts in this case) who will create a team that will help you change the system. So, at the minimum two additional people who are true agile believers, as three are the smallest team possible. The rest will join you in seeing the results.
Form a strategic vision & initiatives – Sometimes having a purpose is not enough as people don’t see a way how to get there and the whole change is too abstract. That’s a space where frameworks, methods, and practices are useful.
Enlist a volunteer army – Finally, it’s a time to make it bigger. Make it a movement, not just another project. Get buy-in from larger crowds. Get them involved. Again, if you skip some of the previous steps, there is no way it’s going to scale.
Enable action by removing barriers – Now, once you have the energy by your side, you need to help it and remove barriers (hierarchy, silos, detailed positions, individual KPIs, … ), otherwise, all the initial enthusiasm is gone before you realize it.
Generate short-term wins – Show the success early and often, make it visible to everyone. Share stories talk about improvements, celebrate even small steps. Success is a strong engine for change. Accelerate, multiply success. Without it, any change will die.
Sustain acceleration – You can celebrate, but you can’t stop pushing after the first win, being too satisfied with your progress. There is always a better way. Find another challenge, discover a better way of working until the vision of the new way of working defined by the original purpose becomes true.
Institute change – Finally by creating connections between the new way of working and success you keep the change stick. It’s the final glue that prevents the environment from flowing back to the old way of working again.

Agile is a change, and without driving it as a change you can hardly be successful. So don’t forget the define how success looks like, celebrate it, and make it better over time.

Journal of Business Agility – Emergence

Recently I received a nice magazine in my mailbox, the Journal of Business Agility – Emergence. If you are looking for stories from different organizations, inspiration from agile leaders, I would recommend you to subscribe to it. Businesses Agility Institute is known for high-quality content conferences, and the Emergence magazine is a good example of very good curated content. So what caught my attention from this first issue of the magazine?

Budget planning: Prioritization – Capacity – Funding

I start with the first article where Jardena London shares her insights about Budget planning. It’s so much close to what I experienced as a Director running a software organization. “Stop talking about budget and capacity until you prioritize the outcomes you want across the organization. Even the high-level strategic goals need to be put in order.” So many organizations are unable to focus and try to push more things without a conversation about priorities. Once ordering is done “Start by planning capacity by teams, it’s way easier than planning for individuals. You may find that your current team structure no longer serves the needs of your portfolio, so you’ll have to tweak it, maybe add/ remove team.” On my journey, I learned that working with teams is so much easier than trying to plan everything with individuals. From the organizational perspective, working with individuals is too detailed and all different irregularities made it too fuzzy and unpredictable. I can also relate to this note: “Don’t plan out the year, plan the now.” In the current VUCA world, the yearly planning cycles feels outdated and unrealistic. I still remember when we went away from estimations and how enlightening it was. However, when I speak about it now, many people are almost freaking out. How can you plan your capacity without it, they ask. “When we estimate hours, we miss all kinds of variables like task switching cost, administrative time, and buffer time. We spend energy trying to get more precision in the output than we have accuracy for in the input.” Instead, in an agile environment, we focus on forecasting how much teams can produce in a short iteration. “With the same number of people, capacity can change over time. Improvements to capability and technology can impact capacity. Capacity is great for forecasting and planning.” But it’s still a concept very hard to accept not only by finance departments but also by the teams. Finally, “Once you have prioritized and planned capacity, and you’re ready to go, allocate funding. This is the very last thing we do, allowing money to be free and flexible as long as possible.” Agile is about flexibility and the ability to be change responsive. “Decoupling prioritization, capacity and funding can breathe new life into budget planning, alleviating the difficulty for employees and improving outcomes for the organization.”

Fact Sheet: The State of Business Agility in 2020

For those who like facts, numbers, and charts, there is a summary of the State of Business Agility report. “In 2020 we saw a significant increase in business agility globally. Compared to last year, we have seen more organizations commencing their business agility journey, and those on the journey report greater progress.” It’s no surprise for me, as I’m getting the same message from organizations, but it’s still good to have it confirmed with data. And it’s also no surprise that “Leadership continues to be the common theme amongst all transformational challenges.” I can see that in most of the organizations. Boards and executives are struggling with a core understanding of agility beyond practices, processes, and frameworks. Their experience with business agility is still very limited. The good news is, that there are many inspirational stories and use-cases covering every spectrum of organizational function, but still looking for an agile organization is a tough job. When I was writing my new book The Agile Leader: Leveraging the Power of Influence I was bringing in some of those pioneers to share their insights in a short story. We need more stories about the successful agile. We need more insights from their journeys. That’s the only way how to make business agility more accessible for leaders and organizations. If you are looking for three tips where to start, the report brings you three tips: “Organizations who reported higher ratings in these three characteristics also report higher overall business agility and associated benefits: 1. Encouraging a culture of learning and experimentation, 2. funding business outcomes rather than specific work outputs or projects, and 3. aligning work to customer-centric value streams.” Very true. Experiment, learn from feedback and deliver value. Looks very simple, but it’s unfortunately very hard to do in some organizations.

The agile journey of Scrum Alliance

I was watching the Scrum Alliance journey for several years, and I’m very proud of how they changed and the experiments they were courageous to take. Living the Scrum values is never simple, and being agile is a journey. “The Scrum Alliance revolution – beginning with reflection, continuing through a complete rebuild of the organization’s working methods, and ending in a revitalization of public perception.” That’s easy to be said, but hard to be done. “Before the self-organization process, Scrum Alliance had multiple departments with multiple part-time scrum teams. Afterward, the structure had been simplified to six cross-functional and cross-departmental scrum teams.” Once the change was implemented as a trainer I could see immediate value to be created every sprint. How interesting change from all the years before, where value delivery was much slower. “By changing the internal structures of Scrum Alliance, Melissa and Howard had also changed attitudes, operational standards, and revitalized the ethos of the entire organization.” It’s great to read about successes but equally important is to read about things that didn’t go so smoothly. Being agile is a journey and this article is showing the journey with all the transparency and honesty. “Most importantly, Melissa and Howard have built an organization that strives every day to practice what it preaches and embody the values and principles of Business Agility” and that’s something you don’t see every day.

And there is more…

Stories from leaders, experiences shared by practitioners. That’s all that we currently need on our agile journey as a society. Agile is not anymore a different project management method. For long ago it left the basement where the IT department was closed. It’s changing the way how organizations operate, and how they do their business. The topics of Agile Organization, Agile Leadership, Agile HR, Agile Finance, and Business Agility are everywhere. There are schools applying agile values and principles, there are governments changing their way of working. Agile is everywhere. The new generation is different, they don’t want to be told what to do, they are asking for higher flexibility and autonomy, they require freedom to choose from where they are going to work and how they deliver the value. Some organizations already figured it out and started accommodating the change. Others are picking up. “The intention of business agility is to create an organization best able to serve its customer, no matter what the future brings.” That last part – no matter what the future brings – is in my mind the most important. Imagine an organization that is flexible and fast responsive, so it is ready for any situation. What else could you wish for succeeding in the VUCA world, right?

Subscribe for Emergence Journal and get a 10% discount using “agileprague” promo code.

Top 10 Agile conferences to attend in 2021

Every year I speak at many conferences and based on my experience I recommend some places to go for inspiration. 2020 was a weird year with almost every conference canceled or transferred to virtual space and there is a risk 2021 might be the same. But no matter if you are virtual or not, we still need to get some inspiration and interaction from similarly minded people. So here is my list of Top 10 Agile conferences to attend in 2021. It’s not my intention to cover them all, I’m sharing places where I like to return. Inspiring places with interaction, high energy, and great speakers.

Agile 100 is one of the most interesting virtual events bringing a series of talks from agile space focusing on a mix of innovations, products, teams, organizations, and culture topics. It’s a monthly event combining 30 min talks and 20min interview with the speakers. Even if you can’t join all the events in a series, join at least a few at agile100.com. The 2021 series starts on Friday, Feb 12, 2021
Business Agility Institute organizes several high-quality content conferences every year focusing on stories from executives, thought leaders, and practitioners on their agile journey. TED-style talks are followed by facilitated deep-dive conversations where participants can digest the experience and learn from each other. This year I would recommend you to join the virtual Business Agility Global Summit on Mar, 22-26, 2021.
ICR Agile is a great event organized by the local Iowa community, I really loved the first year, so I recommend you to join the second year of ICR Agile Conference (Cedar Rapids, IA, USA) on February 25, 2021
LeSS Conference is this time planned in Prague (nice city 🙂 ) and the organizers are still hoping they can organize this gathering of LeSS practitioners face-to-face. Reserve 16-17 September 2021 for LeSS in Prague.
Another tip is a 12-hour virtual conference with active networking, great vibes, small groups, and international Agile leaders talks called Beyond Agile Israel on January 31, 2021.
XPDays Benelux has a date for 25-26th November 2021, Parc Alvisse in Luxembourg. Let’s see if they are able to organize this highly collaborative event. Don’t expect any talks, this conference is more about workshops and interaction.
Agile Coaching Retreat is not a typical conference, but it’s a great place to network and get inspiration from other agile coaches and practitioners. The 2021 Agile Coaching Retreat is planned for Lisbon/Sintra, Portugal on June 17-19,2021.
AgileTestingDays is another great event happening for many years in Potsdam, Germany. Join Europe’s greaTEST Agile Testing Festival on Nov 15-18, 2021. There are always great speakers and a friendly atmosphere.
Agile Manifesto 20th Anniversary is calling all agilists to celebrate the 20th Anniversary of the Agile Manifesto streaming live from Snowbird, Utah from the Aspen Room where it all happened. You can’t miss this event.
Finally, if you want to experience something different, join Regional Scrum Gathering Tokyo. It’s organized by an enthusiastic agile community in Japan. The purpose is to provide a “Ba” (place) where practitioners share ideas among Scrum practitioners having a great diversity. Regional Gatherings provides a unique experience and even if you don’t speak Japanese, there are some talks in English and other translated. Join the local community on January 6-8, 2021.

The selection is based on my personal preference and experiences from those events.

Other conferences to consider this year:

Regional Scrum Gathering Belgrade 2021, 7-8 October 2021, Belgrade, Serbia.

There are many great events that didn’t make it to this list, so please share your suggestions with us and we add them to the following list.

Appreciation

It’s the end of the year, and that’s always a good time to reflect back. So how about if you do a very different retrospective this time, and instead of focusing on improvements talk about some great things which happened this year. What did you change which helped you to be a better team? What made you happy? What do you appreciate about your colleagues?

You can say it directly, print the cards, use the images in a Mural template where people can fill them in, or design your own cards. It’s not about the form, nor tool. It’s raising the positivity of the space, showing others your appreciation. Great teams do that regularly. Great organizations do that across the teams and departments. You might be one of them, and this suggestion would feel like nothing new. However, too many organizations are busy to stop for appreciation. They need to deliver, work faster, achieve the goals. If that feels like your environment, break your habits, and introduce more positivity, more appreciation. Not only before the end of the year but regularly. It will bring the results soon.

Failing Fast

To my huge surprise, I realized that the concept of failing fast and learning from failure is difficult for some people to accept. They always feel the frustration when I say that ScrumMaster needs to feel comfortable to let the team fail so they can learn. I wrote about it here a few times, so you most likely know it, but the goal of a ScrumMaster is to make teams self-organized. They are not their assistant nor their mothers (as it might end by being dependent on a ScrumMaster), they are not their managers (the team is self-organized, fully responsible for their decisions), ScrumMaster is a coach, facilitator, helping the team to take ownership and realize they can solve most of their problems by themselves. And with every decision you take, there is a responsibility going hand in hand, and risk that you might fail. It is OK to fail if you learn from it. So ScrumMasters are not responsible for preventing failure, but for making sure the team will learn from it and figure out how are they going to work differently next time, so it will never happen again. And that’s very different from what the project managers have in their job description. And here is why – Project Manager is responsible for making decisions, ScrumMasters is not. It’s either the Development team (for how are they going to organize themselves to maximize the value towards the Sprint Goal), or Product Owner (for maximizing the value, prioritizing the backlog, and achieving the overall product success including the return on investment).

Agile is about safety to experiment and learning from feedback. In the VUVCA world, you never know what is the right functionality which will multiply the value and success. You need to inspect and adapt. Learn from failures. Be ready to respond to changes and be flexible to shift the direction based on feedback. Scrum has it all. Short Sprints which make it safe to fail, Retrospectives which ensure fast learning, Sprint Reviews which create a platform for frequent customer feedback, and Product Owners who take care of maximizing value and return on investment. It’s one thing to read it, and another to live it. What happens in your body if you hear “Your Sprint just failed.” Is it closer to the panic and looking for who to blame or is it closer to being curious and excited to search for improvements? It’s a simple question that indicates the level of agility. Failure is a good thing. All you need to do is learn from it.

New Scrum Guide

There was a new version of ScrumGuide published last week. And I have to say that I mostly like it. It’s lighter, less prescriptive, and simple. Here are a few differences.

#1 – Scrum Guide 2020 is Simple and Clear

Scrum Guide 2020 is clearer. Finally, there is a sentence that is easy to read, and that describes what Scrum is:

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

A Product Owner orders the work for a complex problem into a Product Backlog.

The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

Repeat

Scrum is simple.

Yes, Scrum is simple and so the Scum Guide. It’s easy to read and understand. With this version, we got rid of many long and complicated phrases full of details. For example, one of my favorite changes in this space is that daily Scrum finally not suggesting the three questions but recommend that people “can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal…” Isn’t that awesome? After all those years of individual status meetings where people were reporting to someone what they did. It’s finally gone!

#2 – Focusing on the Mindset

I like the fact that the new Scrum Guide stresses the three empirical pillars of transparency, inspection, and adaptation and explains what are they about. The five values of Commitment, Focus, Openness, Respect, and Courage are clearly defined there now as well. It focuses on people’s behavior, over the processes and practices.

I also like the new Scrum Guide to remind us about the primary need for Agile and Scrum in complex and unpredictable environments: “In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.” All over, if you know what needs to be done, can plan it, then all you need to focus on is how fast are you going to deliver it. In such a world all different estimation techniques, velocity, burn-down, and burn-up charts are considered useful. Unlike Scrum, which builds on empiricism and inspects and adapts the plans on the way.

#3 – Scrum Team Focus

The biggest change seems to be that we don’t have “Development Team”, ScrumMaster, and Product Owner but “Developers”, ScrumMaster, and Product Owner forming a Scrum Team together. It looks like a big change, but it’s rather cosmetic as they all have to collaborate and self-organize (or self-manage if you like) to maximize value towards the Sprint and Product Goal. So, no real change there, we’ve just finally got rid of the very typical dysfunction where the Product Owner was like an enemy and the team was delivering to the Product Owner only. Now there is no such mentality in the Scrum team, they are in it together, responsible for all product-related activities. They are a team in the first place, a team that is cross-functional so can deliver end-to-end value together. ‘Developers’ is a poor name, as most people somehow read it as software developers but it’s more like a product workers. They are still the people who create working product increment every Sprint, while Product Owner focuses on maximizing the value and ScrumMaster on improving teams and organizations.

I also like the new Scrum Guide to make the scaling approach clearer than before: “If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.”

#4 – Product Goal, Sprint Goal, and Increment

Finally, the last change is the new language about Product Goal (new) and Sprint Goal (improved), and Increment (clarified). All over the Scrum Guide is catching up with the industry and adding a Product Goal as an artifact. It also provides a definition of a product, which is much broader than many organizations think: “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract.” Product Goal is a long-term objective for the scrum team – a vision. Sprint Goal gives meaning to each sprint and defines the value we are focusing on now. The increment is a useful output. Well done, verified, and delivering value towards the Sprint Goal. Simple and straightforward. Finally, there is a much better language about the Definition of Done: “The moment a Product Backlog item meets the Definition of Done, an Increment is born.” It’s almost like a poem.

All over, I really like the new version. It doesn’t change much from what I was teaching and using, just brings a more clear and crisp definition of Scrum as I know it.

Barriers of Agility

In most of the surveys about barriers of agility in organizations, you learn that the top three places are culture, structure, and leadership. There is no surprise. Organizations were designed for a different world where you can analyze the situation, plan what you are going to do, cascade the goals through the organization, and deliver it accordingly with minimum change requests, simply for the predictable world. The problem is that in the last decades the world has become less predictable and changes were more frequent, the VUCA challenges overtake our everyday life reality and the organizations realized they are too slow to respond. Like dinosaurs thousands of years ago. Change is inevitable. Analyzing, planning, and following the plan is not an option anymore.

Innovations, creativity, and flexibility are new norm and organizations which can create environments where teams are self-organized, collaborate on maximizing the business value, and co-creating the organizational goals are taking over positions in the Fortune 100 list. Most of the big corporations are still in the cage of the old-world reality. They optimize for speed. But speed is not that important asset anymore as going fast in the wrong direction doesn’t lead anywhere. Instead, we need flexible environments optimized for creativity. Thinking about flexibility, the organizational structure needs to change to allow it. Departments focused on competences or components, not business value, is meaningless. They kill creativity. Hierarchy keeps responsibility by the managers and prevents people from taking ownership and decide themselves. Again, it kills creativity.

Culturally the traditional organizations are leaning towards competing over collaborating, and controlling over creating. The practices of detailed positions, reward systems, performance reviews, and individual goals and objectives are keeping the organizations in competing and controlling quadrants.

Finally, the leadership needs to change significantly. Traditional organizations were expecting leaders to be Experts or Achievers. Agile organizations need Catalysts. They need leaders who are visionary, purpose-driven, are able to see the business and organizations from different perspectives. They enhance collaboration and are good at building teams and networks. They search for win-win solutions, are good coaches, and helping others to grow. They support running experiments and use failure as learning.

All over we can say that Agile Organization needs different leaders, cultures, and structures. You don’t have to start with changing all of them at once, but sooner or later such change is inevitable. The fewer barriers you give agility on the way, the more likely the frameworks, methods, and practices make a difference and help you to be successful in the VUCA world.

Autonomy

Autonomy is a topic that is in my mind for a while. How come that in some environments it’s so simple to let it grow and some others are so much struggling with it. The more I think about it, the more I feel it’s about trust or fear of losing position, power, or comfort. And environments with no trust are not places where agile is much successful. In order to allow autonomy in even a small group as a development team, the trust must be there. I’ve seen the companies which were struggling to allow teams to choose their own name. “What if they choose something offending?” Like really? Now if you deal with such low trust, there is no way Scrum can work. I’ve seen organizations where they track when people are in the office and have so many restrictions that their computers become useless. “What if they don’t work and play games? Or not coming to work?” Isn’t that funny? The more restrictions you create, the more time people spend on breaking them or the more demotivated they are. Neither will help you to create successful products.

“Trust is prerequisite, transparency enabler, and purpose of the driving force for autonomy.”

Building trust takes time. Start small, don’t be afraid to be vulnerable. Ask yourself what is the worth thing which can happen. Ask what are those people around you scared and how can you help them to feel more confident. The second ingredient in the mix is transparency. Being transparent about what needs to be done, what the success looks like, and what are the things we want to avoid is crucial. People learn by doing. Be transparent with the feedback. Perfection is not useful, it’s all about learning from small failures. Finally, the third ingredient in the mix is a purpose. Autonomy without a purpose only creates chaos. The higher the autonomy, the stronger the purpose needs to be to glue it together. To give everyone the same goal, belonging, identity, the reason for why they are there.

Imagine a kid’s camp. The Red group is defending the castle, the Blues are trying the take it over. Kids are naturally forming small autonomous teams, making their own decisions on the fly. They share information as they move forward. They don’t need any detailed instructions, any KPIs, any manager to give them process. All they have is a strong purpose. Your organization is not any different. Trust is a prerequisite, transparency enabler, and purpose of the driving force for autonomy. Building such an environment requires a portion of agile leadership.

ScrumMaster Mind

Great ScrumMasters are patient, can give space and dedicate their time to help other people grow. They are servant leaders and Catalysts. It sounds simple and not conflicting at first look, however, the real disconnect people feel at first, when they came across the role, is often about their ability to let things go. As a ScrumMaster, you are not responsible for the delivery. As a ScrumMaster, you need to let them fail. As a ScrumMaster, you can’t make a decision for them. “But I need to make sure they deliver the Sprint!” people often say with fear in their eyes. “I need to make sure they are efficient!”, “I need to tell them … ”. Not that quite. Being a ScrumMaster is a very different role than being a Project Manager. They actually can’t be more different from each other. Project Managers are responsible for delivery, they shall manage, make decisions. ScrumMasters are coaches, they help other people to grow. They are facilitators, help the conversation to flow, but don’t interfere with the content. The team is responsible for delivery, the team is responsible for organizing themselves, and the team is also responsible for improving their way of working. ScrumMaster can help them, but not push them. The ultimate goal of the ScrumMaster is to do nothing – or if you wish to build great self-organizing teams.

For example, imagine a team, which is super confident that they are going to finish all the parts they planned for that Sprint. In the middle of the Sprint, you can see from the board that they are not in the middle of the work, not even close. They started many items but didn’t finish much. It seems to you that they are not well organized, abandoning problematic tasks and not collaborating. What are you going to do? When I ask this question at the classes, most people feel a strong need to guide the team, tell them how they shall organize, and when we talk about the fact that as a ScrumMasters they have no power to decide for them, they are very uncomfortable. “But I have to make sure they deliver it”, they say. “I can’t let it go, what my manager would think?”. And it’s very hard for them to accept the fact they can’t push them. They can try their best to coach the team and show them what can possibly happen, but if they are still confident and don’t see that as a risk, eventually you need to let it go and let them fail. Failing one Sprint is not a problem. At the end of each sprint, there is a Retrospective and that’s the time where you can help them reflect on what just happened and come up with action steps on what are we going to the differently next time, so this will never happen again. ScrumMasters are not responsible for Sprint delivery (the team is), ScrumMasters are not responsible for the product delivery (that’s Product Owners job), but they are responsible for making the team self-organized and improving. It’s not that hard as it looks. Try to let things go next time, failure is a good thing. Fail fast, learn fast.