Typical Mistake of Product Owners

One of the typical mistakes of Product Owners is, that they still live in the world of requirements. They still believe, they know what needs to be done. Or at least, that their customers know what needs to be done. So, they spend all the effort on gathering requirements, asking “what do you want us to deliver?” and through that they end up with this crappy Backlog, that grows to unlimited sizes. But none of that is true. The world had changed. It’s more unpredictable, is unstable, and complex by nature. I believe it’s a time to be honest and admit that we don’t know what needs to be done. All we know, is what do we want to achieve. But we don’t know how. And that’s a problem in traditional world. Because how can we plan what to do if we don’t know that. So that whole shift brought a lot of frustration to the industry past decade. And organizations were approaching it in the wrong way. They try to estimate better. They try to detail requirements. None of that worked.

So, what’s the solution to this problem? I think the solution is surprisingly simple, but we need to fundamentally change how we organize our business and how we prioritize. We need to look at things in more strategic way. We need to embrace the business agility and start welcoming changes already at the very beginning. The backlog was never meant to be fixed to-do list. Quite the opposite. It was meant to be dynamic and changeable. It was not meant to be full of requirements describing all the possibility details which must be delivered. Instead, the backlog supposed to be a collection of business cases, of small little hypothesis we phrased together to describe the needs of our customers, the pains of the business. And that’s very different from what you usually see in organizations.

So how can a backlog item look like?

Requirement

A detailed description of a functionality to be delivered. Very traditional, works for stable, known environments with no surprises. Usually large but can be split into smaller pieces.

The system shall provide users with an AI-based assistant that analyzes their transaction history and generates personalized financial tips. The assistant must support natural language queries and return responses in under 2 seconds.

The system shall allow users to set monthly spending limits for expense categories (e.g., dining, groceries, entertainment) and shall notify users via in-app alert when 80% of the limit is reached.

User story

If written correctly, it’s a frame for conversation with our users to describe a business case. It’s customer centric, value driven. It’s a good start to address customer’s needs. As a [persona] I want [what] So that [need].

As a Jenny (single mother, budget-conscious),

I want to have control over my monthly spending

so that I can keep my finances safe.

Story map

Like user story, but covering larger functionality, bringing the whole context of the user’s need. Is more consistent and coherent, balancing the customer perspective and the value.

Story: Jenny needs to Improve financial health

Map: Steps/Options/Journey:                        

Connect Accounts Visualize Expenses Recommend Track Progress
Bank API Automatic Categories Tailored Tips Progress Bar
CSV Charts Rules-based Suggestions Gamification
QR Code Manual Tags Benchmark Suggestion Predictive Trends
Compare History Savings Plans Email Reports
Weekly Trends

Impact map

A mind map describing hypothesis in visual form. It’s created around well-defined business product goals to maximize the value towards the goal. It helps you to be very strategic. Business Goal (SMART) → Actor (Who can influence the outcome?) → Impact (How shall the actors behavior change?) → Scope (What can we do to support that change?).

Goal: Help people make better financial decisions: (15% increase in savings or a 20% reduction in non-essential spending)

Actor: Young professionals

Impact: Limit ad-hoc spending

Scope: AI assistant that offers spending alerts and budget tips

Hypothesis

Optimizes for testing assumptions and learning from them. It’s highly adaptive, emphasizing adaptability, and regular feedback. We believe [Functionality] Will result [Outcome] We will have confidence to proceed [Measures].

We believe that providing users with personalized, AI-driven financial insights based on their real-time spending behavior

Will result in a 15% increase in savings or a 20% reduction in non-essential expenses

We will have confidence to proceed if at least 60% of engaged users show measurable improvement in their financial behavior and report feeling more in control of their finances through in-app surveys or usage metrics.

And there is more. However, the more venerable, unpredictable, complex and ambiguous your environment is, the more you need to leverage the flexible and business-oriented techniques further down on my list. Requirements are not successful in unpredictable world. Organizations need more business agility, so forget requirements and try some story mapping, impact mapping, or hypothesis. Business agility is not an option anymore. It’s a necessity.

Top 10 Agile conferences to attend in 2026

Every year I speak at many conferences and based on my experience I recommend some places to go for inspiration. Here is my list of Top 10 Agile conferences to attend in 2026. 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.

  1. AgilePrague Conference is one of the best conferences in Europe. In two days, it creates unique collaborative space. You can expect short talks, afternoon workshops, and inspirational keynotes. Plus, Prague is a great city to visit so you can come early and enjoy the weekend in Prague. Join Agile Prague on Sep 21-22, 2026, Prague, Czech Republic.
  2. Regional Scrum Gathering Tokyo is 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 me and the local community on January 7-9, 2026.
  3. XP Days Benelux is a conference with parallel workshops for experienced audience. This year it’s going to be in Belgium on Nov 26-27, 2026.
  4. Agile Coach Camp Cologne, Germany, Apr 30-May 2, 2026, is a global gathering, it is an open space event over 3 days of creativity, inspiration and co-working on new work-related topics.
  5. AgileDC is a one-day conference with a motto: Of the People, By the People, and For the People. Organized by local community and it has a great atmosphere. Washington DC metro area, Oct 26, 2026.
  6. AgileByExample, Warsaw, Poland, Oct 12-14, 2026, brings three days of intensive, example-driven content featuring global experts and deep dives into strategic agile governance and data-powered decision-making. This is where cutting-edge agile meets real-world application.
  7. Scan Agile is one of my favorite conferences. It’s where the future of Agile takes shape. This year is planned for March 17-18, 2026, in Helsinki, Finland.
  8. Agile Testing Days are almost a festival not a traditional conference. The full week of tutorials, talks, workshops, and networking events is just awesome. Join Testing Days even if you are not a tester. It’s in Potsdam, Germany on Nov 16-19, 2026.
  9. LeSS Conference is from practitioners for practitioners. Since 2016, LeSS Conferences is where LeSS practitioners share their LeSS experience and learn from new experiments. Book your time for October 8-9, 2026, Tokyo, Japan.
  10. Global Agility + Innovation Summit, Washington DC metro area, May 13, 2026, explores the Age of AI, focusing on building AI-powered products to leading in AI-powered environments.

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

Other conferences to consider this year

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.

  • Agile on the Beach is great event to attend and explore the summer in Cornwall, UK on July 2 – 3, 2026.
  • Org Topologies Summit is a single track conference. Expect a curated mix of focused talks, hands-on workshops, engaging simulations, guided group discussions, and practical problem-solving. Mark your calendar for Oct 16, Amsterdam, Netherlands.
  • Additional events: https://agilegatherings.com/

The State of Agility

Recently Business Agility Institute published the new 2025 Business Agility Report and based on the data agile is far from being dead. Quite the opposite – business agility is a good investment. Organizations that increased their business agility in 2025 significantly outperformed their peers in revenue growth. On average, companies with rising agility achieved up to 10.3% revenue growth, compared to 5.1% across all organizations, while those with decreasing business agility lagged behind at just 3.5%.

The data clearly shows that investing in business agility is not only a cultural or operational choice—but a direct driver of measurable business results.

The top challenges to business agility are not about processes or frameworks—they are deeply cultural and systemic. The highest negative impact comes from outdated leadership capabilities, fixed mindsets, and a lack of clear transformation direction, often compounded by transformations that are too limited in scope to create real change. At a moderate level, organizations struggle with resistance to change, unsuitable ways of working, misalignment across leaders and business areas, low decision autonomy, and talent or skill gaps, all intensified by ongoing market disruption. Lower-impact issues, such as poor prioritization and excess WIP, are typically symptoms of these deeper systemic problems rather than root causes.

It’s never too late to start taking Business Agility as a strategic capability. To tackle some weak areas, join our agile leadership program and get my book Agile Leader: Leveraging the Power of Influence.

The Difference Between a Team and a Group of Individuals

It’s easy to assume that a team and a group of individuals are the same thing, but there’s a key difference: intentional collaboration. But there is a fundamental difference. A group of individuals is simply a collection of people working together, often with individual goals and responsibilities. Each person might be working on their own tasks, and while they may share a common purpose, there’s little to no collaboration or interdependence.

On the other hand, a team is a cohesive unit that works together towards a common goal. Teams share knowledge, support each other, and work collaboratively to achieve something greater than the sum of their individual efforts. Team members hold each other accountable, leverage each other’s strengths, and have a collective sense of responsibility.

Teams outperform groups of individuals for several reasons:

Collaboration over competition – Teams thrive on sharing ideas and solving problems together, leading to innovative solutions.

Accountability – Team members depend on each other, which encourages mutual accountability and a stronger commitment to success.

Synergy – Teams combine diverse skills, experiences, and perspectives to tackle challenges more effectively than individuals could on their own.

Teams are essential for fast decision-making, continuous improvement, and delivering high-quality outcomes.

So, let’s have a look. Are you a team or a group of individuals?

Answer the following questions on a scale of 1 to 5 (1 = Not at all, 5 = Always):

    1. Do team members actively collaborate and share ideas?
    2. Are individual contributions aligned towards a common goal?
    3. Is there accountability among team members for the success of the team?
    4. Does the group leverage the diversity of skills within the team?

Scoring:

    • 16–20: You have a strong team! Collaboration, accountability, and shared goals are in place.
    • 11–15: Your group is on the right track but could benefit from more intentional collaboration and alignment.
    • 4–10: You have a group of individuals who may need guidance in forming a more cohesive team.

Fostering teamwork is the key to greater efficiency and success. A true team doesn’t just work together; they grow together.

Agile Teams, Conflicts, and TKI

In the world of agile, conflicts are natural part of the team’s journey towards innovation and efficiency. When teams come together to work towards a common goal, they’re bound to have different ideas and opinions. Facilitation is a great tool to help navigate through healthy conflicts. That’s one reason why having a ScrumMaster is always useful. But here I wrote about this many times already. This time I want to introduce a tool that is not that common, but is very useful to have in your ScrumMaster toolbox. Thomas-Kilmann Conflict Mode Instrument (TKI) is a tool, that helps people understand how they handle conflicts and keep your team productive and happy. It identifies five different conflict-handling modes:

Competing

The Competing mode is in the assertive and uncooperative quadrant. Sometimes, making important decisions without the team’s agreement can damage trust and cause problems. For instance, a Product Owner makes sudden changes without talking to the team, which leads to anger and quality issues. Or a team member pushes their ideas without listening to others, which breaks up the work and creates tension. On the other hand, it’s okay to make quick decisions when you really need to. For example, a Scrum Master can quickly stop a discussion to make sure the team meets a goal, or a developer can say that security is important, even if others are more focused on velocity.

Collaborating

The Collaborating mode is in the assertive and cooperative quadrant. Sometimes, trying to get everyone to agree can slow things down and make teams less efficient. For instance, if you spend too much time brainstorming and trying to please everyone, it can delay decisions and cause a condition called “analysis paralysis.” Or, if you try to include everyone’s opinions, it can expand the scope of the project beyond what’s actually needed. On the other hand, this mode is great for bringing together different perspectives and building consensus when a team works together to make sure technical decisions align with business goals. This can improve product delivery and customer satisfaction, or when developers and the Product Owner collaborate to make sure user stories are clear and prioritized correctly.

Compromising

The Compromising mode is intermediate in both the assertiveness and cooperativeness quadrants. Sometimes, accepting partial solutions can lead to missed opportunities for achieving the best results. For instance, when the team agrees on a solution that partially satisfies everyone but fails to fully meet important technical or business needs, or when sacrificing test coverage to meet a sprint goal, causing later rework and technical debt. On the other hand, it can be useful for achieving temporary settlements like negotiating a minimal viable feature set with stakeholders to meet release deadlines or splitting time between refactoring and delivering new features to balance technical health and value delivery.

Avoiding

The Avoiding mode is in the unassertive and uncooperative quadrant. Sometimes, ignoring recurring problems can make things worse, and it can hurt how well the team works together. For instance, if the team keeps ignoring the same issues, it can lead to technical debt or if a Scrum Master avoids dealing with conflicts, the team can keep getting stuck. But there are times when it’s okay to ignore small problems or when others on the team are better suited to handle certain conflicts. For example, if there’s a non-essential process debate that can wait until the retrospective, or if a developer with deep expertise can handle a minor technical disagreement without involving the whole team.

Accommodating

Finally the Accommodating mode is in the unassertive and cooperative quadrant. Sometimes, trying to please everyone too much can lead to forgetting about important things like technical and delivery needs. For instance, if a developer keeps agreeing to impossible deadlines to keep everyone happy, it can cause burnout, or the team always puts stakeholder demands first, even if it means ignoring technical debt. On the other hand, sometimes it’s good to keep harmony and relationships in the first place. For example, agreeing to small feature requests to build goodwill with stakeholders or when a senior developer lets a junior team member lead a task to gain experience.

Agile teams are all about teamwork, and it’s important for everyone to know how they usually deal with conflicts and how leaning towards different modes can change the team dynamics. For example, if you have a ScrumMaster who is very strong on Avoiding and Accommodating, they might ignore team issues, fail to remove impediments, and compromising agile principles to keep everyone happy for a while. In a nutshell, they’re not really helping teams and organizations change. Great ScrumMasters need to have a balanced profile with high Collaborating to integrate team insights and fostering consensus, and moderate Competing and Compromising to protect the team, keep agile principles, and navigate trade-offs effectively.

In real life, people have a mix of tendencies. For example, imagine you have a Product Owner who is very strong on Collaborating and Accommodating. He will cooperate well with the customers and build great relationships which is awesome but at the same time, they try to make everyone happy and can’t set a clear direction or make a decision when needed.

So how to start? Encourage team members to take the TKI assessment to gain insights into their default conflict styles. Understanding one’s natural tendencies can help individuals consciously choose the most effective approach in various situations.

After that, I usually run a workshop to discuss the five conflict-handling modes and explore scenarios where each mode might be most effective. Using role-playing helps team members practice switching modes and understand the perspectives of others.

Great Scrum Masters are a great help. They are good at recognizing conflict modes and are able to help teams find the most constructive way to deal with conflicts. They coach individuals to reflect on their tendencies and help them to create a better balance. They’re the ones who make sure everyone feels safe to share their thoughts, and they step in when things start to get too heated.

Why You Shouldn’t Miss Agile Prague Conference 2025

Organizing Agile Prague Conference has always been more than just an event for me—it’s a dream come true. I started this conference 14 years ago with a simple vision: to bring world-class Agile inspiration to Prague and create a space where people from all over the world can connect, learn, and grow together. Every year, I’m honored to welcome some of the most inspiring minds in Agile to share their wisdom, challenge our thinking, and help us move forward—together. It’s not just about talks; it’s about community, energy, and the magic that happens when

If you share that passion—for Agile, for leading meaningful change, or for staying ahead in how we work and collaborate—then Agile Prague Conference 2025 is the place for you this September. Join us and be part of something truly inspiring.

Here’s why this event stands out—and why you should join us in Prague on September 15–16, 2025.

🌍 A Truly Global Agile Gathering

Agile Prague brings together a multinational audience of practitioners, leaders, coaches, and innovators. All sessions are in English, welcoming participants from across Europe, North America, Asia, and beyond. It’s your chance to connect with global peers, share experiences, and build long-lasting professional relationships.

🎤 World-Class Speaker Lineup

This year’s program features inspiring keynotes and talks from some of the most respected voices in the Agile space:

  • Diana Larsen – Thought leader in Agile retrospectives and organizational change

  • Lyssa Adkins – Renowned Agile Coach and author

  • Linda Rising – Agile pioneer and expert in group dynamics

  • Pete Behrens, Danko Kovatch, Pamela Paterson, Pat Guariglia, Petra Skapa, Erez Morabia – And many more!

AgilePrague Conference Speakers

The diversity of perspectives—from leadership and coaching to engineering culture, agility in organizations, and psychological safety—makes this conference incredibly rich in learning.

🧠 Deep Learning & Practical Takeaways

Whether you’re a Scrum Master, Agile Coach, Product Owner, or team lead, the sessions are designed to deliver practical insights you can apply immediately. Real-world case studies, expert advice, and engaging formats like workshops and open spaces ensure you don’t just sit and listen—you learn by doing.

📍 The Magic of Prague

What better place to attend a conference than Prague—a city of historic charm, vibrant culture, and stunning architecture? Agile Prague gives you the perfect excuse to combine professional growth with sightseeing and inspiration. Take a walk through Old Town, cruise the Vltava River, and enjoy world-class cuisine between conference days.

AgilePrague Conference

🎟️ Early Bird Registration Now Open

The Early Bird tickets are available for a limited time, offering great value for an unforgettable Agile experience. And if you’re looking to go even deeper, you can combine the conference with hands-on workshops right after the event—led by global experts like Jurgen De Smet and John Barratt on Sep 17-18.

💡 Don’t Wait – Join Us in Prague!

Agile Prague Conference 2025 is not just another Agile event. It’s a chance to elevate your practice, grow your influence, and connect with a truly global community.

👉 Secure your Early Bird spot now

See you in Prague!

Value of ScrumMasters

ScrumMasters are the most misunderstood role in Agile space. Organizations often take them as assistants of the team, like some expensive administrators. They let them update tasks and schedule meetings, and they believe that’s it. However such work seems to be important from a traditional point of view where we need to allocate tasks to individuals and handle dependencies, in Agile it’s not much needed, because of a regular cadence of events and team ownership and responsibility for their work and the value they deliver. When we accept that ScrumMasters are not here to become team assistants, what are they doing and what is their value to the organization?

The real goal of ScrumMaster is to create self-managing, cross-functional teams, constantly look for improvements, help teams to become better, and eventually hyper-performing. It’s a leadership position. They don’t micromanage what individual team members do, but instead, they create an environment where teams can flourish by facilitating the conversation and collaboration and by coaching them for improvement.

Many ScrumMasters got it and focus on helping their teams to become great. But unfortunately very often they forget that the ‘My Team’ level of the #ScrumMasterWay concept is just the beginning of their journey and can only create a limited impact on the organization. Now don’t take me wrong. It’s a good start. But it’s only a beginning. Once they learn how to build self-managing teams from groups of individuals, and how to make them cross-functional, it’s time for them to shift to the ‘Relationship’ level of the #ScrumMasterWay concept and focus on the broader ecosystem. Help the Product Owners to work differently with their stakeholders and build more value-driven backlogs, create value streams in the organization, initiate the shift from projects to products, work with management on goals that would be more team-oriented over individual-oriented, and introduce some meaningful scaling approach to help the organization to reflect and be better at delivering value for the customers and achieving some real business impact. Because at the end of the day, no one cares if you use Scrum, no one cares which agile scaling framework you implemented. The only thing that matters is if you could help your organization to become more successful, create some impact, and bring a return on investment.

And ScrumMasters who are only active on the ‘My Team’ level of the #ScrumMasterWay concept can only create a limited impact on the organizational business. Working at the ‘My team’ level is more like a kindergarten for ScrumMasters. So grow up, and help your organizations to become successful.

Agile is in the first place about change, so don’t be afraid to change the status quo, don’t be afraid to challenge people. There is a sentence you should never say as a ScrumMaster. “It will never work in this organization”. Everything is possible. If you believe it and you are not afraid to go for it, you’re going to be a great ScrumMaster, and your organization would appreciate what you’re doing. Remember that success scale, not Agile. So stop focusing that much on different practices and start focusing on creating an impact on the organization and helping your organization to see it. And that requires a significant change at the ‘Relationship’ level and eventually, the ‘Entire System’ level of the #ScrumMasterWay concept.

The Power of Continuous Improvement

Very often, people are expecting changes to happen instantly. They are impatient, they want everything now. But changes take time and effort. Change is definitely not a straightforward activity; it never goes as you plan it. In order to succeed with change in your organization, you need to be creative, innovative, and playful. And on top of that, you need to be patient. One of the reasons why I like Scrum, is because it’s incremental and iterative not only in delivering the value to the customers, but also in its own implementation. Step-by-step, you are figuring out what does it mean to be agile for us, how to use Scrum, and how shall we implement the different artifacts and events. There is no cookbook, you need to figure out your own way.

At the beginning, don’t look for any perfection, just start with anything that is good enough. You need to have a team that can deliver at least some sort of limited value. A team that has a chance to become at least a bit cross-functional. A team that over the time can take over the responsibility and ownership and become self-managing. Once you have this starting point, a team willing to give it a shot, all you need is to incrementally inspect and adapt. Small, little iterations. Every iteration, you discover what is working and make it stick; each iteration reveals what needs to be improved and comes up with an actionable step for the next sprint to improve it. It doesn’t have to be a big change, quite the opposite. Small steps work generally much better. This way, they’re safe to try and more likely to happen. They don’t look like they can change the world instantly, but if you look back where you’ve been six months ago, you realize you’ve made a huge step.

Overall, I would say, if you don’t take anything out of the Scrum framework but Retrospectives, do them regularly and make sure they bring incremental changes, you end up at a much better stage than you’ve been before. Being agile is about being adaptive. Be creative and take it one step at a time. Play with the change. An incremental change is the key practice that can make you truly Agile. It’s not about tools. It’s a different way of thinking, and incremental changes are a key part of that new way of thinking and approaching things.

Backlog is not a Linear List

“It’s all about Product Backlog. Product Owner should manage it. Prioritize it. Fill it with User Stories.” Sounds familiar? It’s typical at certain stage of agile transformation to focus on building a Product Backlog. And use Jira for that. You find such linear to-do lists in almost every organization at the beginning of their agile journey. And though Product Backlog is very important tool as it brings clarity and align people around the same business goals, it’s also one of the most misunderstood and misused tools. It often starts with a good intention, Product Owner asking customer what they want. And they, in a good intention, brainstorm all the possible functionalities you can imagine. And the Backlog/scope keeps growing while the time expectations stay the same. That’s very common start of a big disappointment with Agile. “It didn’t help us. It’s not faster!” people say, and they are right. Agile is not the way how to deliver more functionality faster. Quite the opposite. It’s a way how to achieve higher business value faster, and those are two different things.

So, if you want to get more business value, start with the backlog. But this time, you’re not asking what you want to be implemented but instead ask for needs and look for a minimal functionality to be implemented to satisfy those needs. 80% of the value is in 20% of the functionality and that’s exactly what good Product Backlog should identify. The higher value items first, the rest later or never.

Good Product Backlog is co-created in collaboration with customer, stakeholders, and team members. They all need to uncover the business needs. They all need to develop an empathy for the customers. In most of the cases Product Backlog they create together is not a linear list that would fit traditional tools like Jira or Excel, instead very often we use Story Mapping technique to create multidimensional maps, or impact mapping technique to create a mind map, or visualize the product as a tree and prune the branches. Nothing that would look like a linear to do list. All the techniques have one thing in common; they focus on the business value and the customer needs. They don’t describe the solution. The how in Scrum should be uncovered during the Sprint in team collaboration. So, forget on the requirements, stop asking your customers what they want, and instead focus on uncovering their needs and together visualize the value in your Product Backlog.

Getting out of “Dark Scrum”

The only reason I’m still stuck with Scrum is because I’ve experienced it. Over the years I’ve seen it working so great, that I sort of felt in love with the energy well-functioning teams are creating. I love the self-management, I love the value-creation, and the impact the environment has on customers and the overall business results.

But it was not always like that. I didn’t like it at first. I took it as another process. I was angry that I must change. Deeply insight, I was afraid of the change that seems artificial, stupid, and crazy. At first, with my team we didn’t really like what we were requested to do, trying to fake it. Making all the possible mistakes you can imagine. The break point happened when we realized that it’s not about having a backlog, it’s not about standups, it’s not even about having a retrospective. It’s about the ability to take over the responsibility and ownership and do things our way. That Scrum is only a framework that allows you to creatively create outcome. Not just some work but achieve real value customers care about. And more over I realized that there is no need for perfection. By inspecting and adapting we make it work. If it doesn’t work, we improve it and find a way how to be successful. Change is our next day.

So why are organizations so stuck with faking it? Firstly, after that many years, organizations still don’t have people who experienced the real Scrum spirit and energy. They are so stuck in the project management individual way of working that it’s close to impossible to even imagine how things could be different. I used to believe that when we make agile well-known word, people use the common sense, and by inspecting and adapting create their own way of being successful. Instead, I see too much of the “Fake Scrum”, “Grey-processed Scrum”, or even “Dark Scrum”. So, stop saying it will never work here and start finding a way. I eventually had to redefine the goal. I now believe that we, the agile community, need to actively fight the flavors of Dark Scrum. That’s why I wrote the Great ScrumMaster: #ScrumMasterWay and Agile Leader: Leveraging the Power of Influence books. That’s why I teach and coach hundreds of practitioners. To help them to return to the mindset, help organizations to realize what are the principles, and what is this change really about:

  • There is no one way. Stop copy pasting practices, follow the principles.

Create your own way by inspecting and adapting.

  • It’s not about delivery but about achieving value.

Deliver end-to-end value.

  • Don’t hide behind contracts, invite the customer in your team and collaborate.

Create partnerships.  

  • We don’t know what needs to be done, only what needs to be achieved.

Be adaptive.

  • Don’t focus on growing individual skills, build environment for team collaboration.

Relationships maters.

  • Don’t hide things behind tools, roles and processes. Share everything so everyone knows what’s happening.

Crete radical transparency.

  • You don’t need to control everything. Trust the team they can make it together.

Become an Agile Leader.

So if you are wondering how much of “Fake”, “Grey/processed” or “Dark” Scrum you have make an assessment around the following points on a 0-100 scale. If your overall score is 0-30 you’re stuck in traditional management, 31-49 it’s a blend, and it surely feels that way. No that it’s not a start but there is a lot of pain over here and there. Finally, if your overall score is 50-70, congratulations. You are on the journey. It’s not about being ideal but improving along the way. Embrace the Kaizen principles.