The Phenomenon of Prevalence Induced Concept Change

In organizational change, people may respond to improvements in unexpected ways - even though things are getting better, they may be under the impression that things are getting worse - and they may even have data to back up their claims! So, how do you get out of the dilemma of having to justify improvement without starting a theoretical debate detached from what people see, hear and feel?
In this post, we will take a peek at a typical case of Prevalence-Induced Concept Change (PICC) and how to address it in a constructive manner.

What is Prevalence Induced Concept Change?

"Prevalence induced concept change" (PICC) occurs when the frequency of events changes, leading people to modify their definition of what constitutes a problem. This shift in criteria means that as major problems become less common, minor topics start to gain more attention and are perceived as more significant than they actually are - or in reverse!

We will take a common example connected to "Agile Transformation" to illustrate our case - although you may encounter PICC in many forms and shapes.

Transitioning from Classic Project Management

In Classic Project Management, we have our ways of doing things, and everyone knows that nobody's perfect, so there are always some concerns. But, we have arranged ourselves with them, understand them, and how to manage them.

Classic Project Management

• Long-Term Schedules - Projects span several months, with a final delivery date set well in advance. The impact of missing a timeline tends to be massive, and a slippage in schedules requires serious management attention.
• Delayed Feedback - The first feedback comes on "Release Day," and the events on that day tend to be overwhelming due to the sheer volume and severity of problems that went undiscovered during the project.
• Hidden Issues - Problems remain undiscovered until late in the process, making them costly and difficult to address.

And now let us contrast that with a more modern approach.

Modern Delivery Approaches:

• Rapid Cycles - Large projects are divided into short cycles, with intermediate evaluation points.
• Frequent Feedback - Developers receive timely feedback on completed work in small batches.
• High Transparency - Problems are identified and addressed quickly, promoting continuous improvement.

This leads to many follow-up questions: First, how do we even work in a way that we can collect feedback faster - and second, what do we do when we get "bad feedback?" Especially in organizations where Continuous Improvement is not systematized in project management, the question "what do we do with the feedback" can lead to a quagmire of followup concerns that can completely derail a team if not properly addressed.

The Impact of PICC

An organizations advancing from classic project management to a more modern delivery approach may have stakeholders fall for PICC and misinterpret the nature and frequency of what's going on:

• Buffer sizes - By slicing a large project into a sequential set of deliverables, the project gets more checkpoints, and each of them gains a small buffer. So a buffer overrun on one of them is not even an issue - the main timeline is not even in danger when a day of buffer has been consumed! However, a buffer overrun may lead managers to overreact who are used to a buffer overrun always requiring management intervention.
• Higher Expectations - With frequent deliverables, stakeholders have more time to focus on individual deliverables, so they will pay more attention to minor issues they would never have noticed in a project where it was normal that half the scope was unusable upon delivery.
• Perceived Underperformance - A successful product review will always elicit improvement potential, and the constant appearance and high volume of new issues can be misconstrued as underperformance by a management that's used to every report being a quality flaw.

Preventing Misconceptions Caused by PICC

To prevent the misconceptions caused by PICC and ensure that successful improvements are recognized as such, it is essential to create transparency and educate stakeholders of what's actually going on:

Define the Benchmark

Highlight Changes - Frequent evaluations in modern delivery make more issues visible - but also lead to quicker resolutions and thus, better outcomes.

Differentiate Categories - Clarify that the issues reported now are generally smaller and require lower fixing efforts, unlike the severe and late-discovered issues in classic project management that often led to minor issues not even getting addressed at all!

Create Transparency

Provide Objectivity - Agree on severity levels early, and categorize issues accordingly, illustrating, for example, that whereas before, people were simply accepting showstoppers, they are now arguing about button colors.

Analyse trends - Use trend analysis to show how severity classes and quantities shift over time, demonstrating that the measurement is subtly changing.

Manage Expectations

Frame Feedback - Highlight that the feedback is now on a different level than before, and that the purpose of that feedback has also changed.

Correlate Action - Show how feedback is now differently correlated with action, and that the time between highlighting an issue and getting a fix is improving.

Conclusion

Prevalence induced concept change (PICC) can significantly impact how stakeholders perceive the success of teams. Hence, understanding that PICC is happening is a key instrument in managing change and expectations effectively. Be aware of the situation, create objectivity and transparency, then manage expectations to move beyond category errors, misconceptions and perceived deterioration.

10 Signs your Management is Hurting your Teams

Sometimes, we're dealing with bad management. And sometimes, we're dealing with management that's actually good, but may look bad. How can you decide whether your management is helping or hurting your team? With that, let's take a look at "10 Signs your Management is Hurting your Teams."

Lack of Accountability

Great managers lead by example in owning up a situation and focus everyone on constructive ways forward. They "stop the buck" and change the discussion from fault to solution. But some managers see every problem as caused by their teams, and regardless of what happens - they will always find a way to frame things so that failure is never their problem. Those who never see how their own behaviour contributed to a situation will make their teams risk-averse and reduce the desire to be innovative. A boss taking credit for wins and exposing their subordinates for failures will eventually find themselves surrounded only by people who can't find better alternatives.

Intransparency

One of the core challenges of management is to filter information: Teams need to focus on doing their work, they don't have time to sit in meetings or read emails all day. Good managers do what they can to minimize the mental load of their teams while still letting them know what's going on. However, many managers do it wrong - they keep team members in the dark about important decisions and information that will affect their ability to succeed. Such a lack of transparency leads to uncertainty and speculation, and ultimately, failure. And teams who are content with not understanding how to make a difference - won't.

Poor communication

Good managers always provide clear expectations, updates, and feedback to their teams. Lack of clarity regarding any of these, "doing the best we can" may not equal "doing what we should be doing," which in turn leads to poor outcomes - and frustration on both ends. While it's arguable whether it's worse to provide vague, or potentially even mutually conflicting, information to the teams or no information at all, managers are always multiplicators of performance - and with bad communication, they can singlehandedly devastate an entire organization!

Unrealistic Expectations

It's great to let people know that you trust them to achieve great things. But a manager who sets the bar too high without providing the necessary support and resources pushes their own people over the cliff. Simply expecting the impossible sets up teams to fail. Repeatedly doing this can lead team members to burnout and drives them to the job portals.

Siding Against the Team

When complaints come in, whether from customers or other departments, a good manager would always first try to learn what has happened, and listen to both sides of the story. Even when the going gets tough, they would be their teams' heat shield, ensuring people can constructively focus on improving the situation. Bad managers choose to take sides against their team, even before understanding what has happened. When the very person who is supposed to lead the team to success is constantly sending the signal that the team is not good enough, people will first choose to collect CYA evidence, and eventually seek someone else to work for. Team cohesion and the organization's ability to deliver erode.

Favoritism

Good managers look at the value of outcomes. Great results should be attributed to everyone who contributed, and ideas should be evaluated based on their merit. Great managers count on the Pygmalion Effect - letting their people know they can do great things will drive them to exellence! Favoritism can tear a team apart. When a manager shows a visible preference for some individuals, this breeds resentment and jealousy. Those who aren’t the favorites feel sidelined and unappreciated, can quickly lead to a Golem effect - marginalizing people will make them underperformers!

Micromanagement

Great teams are in control of their work. With an understanding of what's expected, they will find out how to solve problems, and deliver outstanding results. Bad managers, however, often fail to articulate what they expect and are unable to connect operational challenges with their (unspoken) expectations. Instead, they check into the small details and turn molehills into mountains. They want to know who is doing what when instead of asking how things are going. This kills creativity and morale. Especially those employees who know full well what needs to be done will find themselves so appalled by the constant checks and controls that they'll prefer to put their remaining energy into finding their next career move.

Ignoring Feedback

Feedback is a gift for those who know how to appreciate it. It's sometimes just a small thing that enable a manager to help their teams do much better. Great managers are not only actively asking for feedback - they're picking up cues and hunches and turn them into action. Terrible managers ignore feedback even when it is actively provided - the worst kind even finding ways to dismiss the outcomes of explicitly institutionalized feedback processes. In doing so, they implicitly tell their teams that nothing will change and that getting a better working environment is easier achieved by job hopping than by talking. Those whom such a manager is left with will eventually have learned not to care when things go wrong.

Unsupportiveness

Great managers aren't great by their own ability - they're great because they have great teams behind them, composed of great people doing great things. But greatness isn't something static. It evolves over time, and is always measured relative to the challenges. Hence, great managers continuously invest into the professional growth of their teams. They actively provide opportunities for training and career advancement to give their teams the necessary edge. Poor managers use the talent they have, and squeeze their people dry like a lemon. When people are falling behind, they get discarded like useless chaff. Individuals who have seen this pattern before will have learned to jump ship while there's time.

Lack of Appreciation

Recognition serves as a catalyst for growth - so great managers will take the opportunity to give credit where it's due, and celebrate noteworthy successes. Without acknowledgement of a job well done, our psyche will eventually come to believe that "it doesn't matter." The worst of managers not only fail to appreciate the hard work and great outcomes of their teams - they will always look for the fly in the ointment and jump upon every inadequacy. Like that, they can drive even the most talented individuals into despair and burnout - or to a competitor.

Closing remarks

We all make mistakes. And managers are as human as anyone else. The occasional glitch is normal, and we shouldn't think too much or too hard about it.

But when any of the points above are a habitual pattern of an individual, or worse: a cultural pattern of the organization - we should have a serious conversation: Does the company want to get the best possible performance from their teams, or are they willing to pay the dividend of poor performance in order to keep counterproductive management behaviours?

Oftentimes, it's ignorance, and then we can work on it. Smart businesses will address the issue and increase their ability to persist on the market. But not all businesses are smart.

If that's the case - draw your own conclusions.

Check your moral compass

In the fantasy world of "Dungeons & Dragons", a character's actions are often defined by their moral compass - a system that categorizes ethical and moral perspectives. As Managers or Agile Coaches, understanding where you and your teams stand on this moral compass can offer valuable insights into team dynamics and individual behaviors, both why you behave the way you do - and what you may need to change about your beliefs and values in order to gain different moral outcomes.

The Moral Compass

The "Moral Compass" has two axes which combine to form nine possible alignments. This quiz is designed to help you discover your alignment within the context of a product development team. Understanding your alignment offers insights into your natural tendencies, decision-making style, and how you might interact with your team.

Before digging in, please realize that the Moral Compass does not pass any judgment on you - much rather, it helps you determine whether there's a gap between where you are and where you want to be.

There is no "right" or "wrong" alignment. The one you get represents you - and it's up to you to determine whether you are happy with that. In the past, I have made >my own considerations and was rather shocked - then happy - where I stood.

Try to answer the questions sincerely, and see where you land. You need to answer all 8 questions to see the result. (we do not store any data - it's 100% safe!)

The Moral Compass Quiz

A team member working on an urgent, critical task is struggling and may fail to deliver on time. What do you do?

I'll skip my daughter's birthday to help them out. Their problem, we'll see tomorrow what happened. I'll ask how they're doing, but will stay uncommitted.

A team member accidentally shares confidential information that could benefit you. What do you do?

Put it into "The Folder." It may come handy later. Report their mistake to our manager and ensure it’s handled correctly. Do nothing: They can handle it.

Your team needs a management decision, but your manager is away. What do you do?

Step in and take charge to keep the team moving. Follow the protocols and wait for the manager's return. Make and own the decision as a team.

Your team has an unrealistic deadline. There is a shortcut, but it violates a governance rule. What do you do?

Take the shortcut to meet the deadline. Stick to the rules, even if it means being late. Weigh the pros and cons before deciding.

A team member is being unfairly criticized during a meeting. How do you respond?

Defend them and let the perpetrator know they are being disrespectful. Interrupt the meeting to stop the criticism immediately. Wait. Afterwards, have private conversations with the critic and the criticized.

The team is divided on the best approach to a problem. What do you propose?

Encourage a balanced discussion while remaining impartial. Play "Thunderdome:" Two ideas in, one idea out. Create a decision proposal and have your manager decide.

A manager insists that you release a dangerously faulty product in order to keep the timeline. What do you do?

Secure your position by satisfying the manager in a way that lets you to deflect blame. Refuse to release the product and use the Whistleblower policy. Consider the request, but weigh the consequences.

You're tasked with institutionalizing a new, unpopular policy that benefits the company but harms people. What do you do?

Enforce the policy strictly and without exception. Implement the policy and work to mitigate its negative effects. Use the policy to your advantage.

Your alignment is: Undetermined.

Conclusion: Interpreting Your Results

Once you complete the quiz, your alignment will be revealed. Here's how you can read the results:

• Lawful Good (LG): You follow the law and act altruistically. You likely prioritize processes and structured approaches while ensuring the well-being of your team.
• Neutral Good (NG): You do good deeds without a strong adherence to law or chaos. You balance flexibility with a focus on positive outcomes for your team.
• Chaotic Good (CG): You act altruistically but value personal freedom over order. You may encourage innovative and unconventional solutions that benefit the team.
• Lawful Neutral (LN): You follow the law or a personal code strictly, without consideration for good or evil. You value consistency and reliability.
• True Neutral (TN): You maintain a balance between all opposing forces. You adapt to various situations, ensuring balance and harmony within the team.
• Chaotic Neutral (CN): You value personal freedom and follow whims without regard for good or evil. You bring creativity and spontaneity.
• Lawful Evil (LE): You use laws and rules in your own favor. Be cautious - this can make you the cause of unproductive conflict!
• Neutral Evil (NE): You do whatever it takes to achieve goals, whatever the cost. This alignment can be problematic with regards to collaboration and trust.
• Chaotic Evil (CE): You act purely out of selfishness, with no regard for laws or other people. This can severely harm team dynamics.

Understanding your alignment can help you identify areas for personal growth and improvement. It can also foster better communication and collaboration within your team by recognizing and respecting different perspectives. Use this knowledge to enhance your effectiveness and to support your team.

I will leave you with three questions to reflect upon:

1. "Why am I like that?"
2. "Do I want to be like that?"
3. "What does this mean for those around me?"

How do we make money?

Understanding how to generate revenue is a critical aspect of running a successful business. The way a business owner approaches the question, "How do we make money?" can reveal a lot about their strategy, priorities, and focus. This seemingly simple question is extremely profound: the answers are crucial to business success. But: how do you ask the question?

Intonation matters

Try emphasizing different words in this simple question: you'll see how various facets of running a business gain the spotlight.

In the table below, you can see how different emphasis leads you to explore how different perspectives influence business decisions and strategies. This analysis helps in pinpointing key areas for improvement and ensuring that the business's efforts are aligned with its financial goals.

Emphasis	Focus	Key Questions
How	Means	What are the specific steps, techniques, or strategies we are using to generate income? Are our current methods effective, or do we need to explore new ones?
Do	Confirmation	Are we actually making money? Can we confirm that our business activities are resulting in revenue? Let's verify our earnings and ensure our efforts are paying off.
We	People	What role does each member of our team play in making money? How does our collective effort contribute to our revenue? Is everyone contributing effectively?
Make	Generation	What activities or products are we creating that generate income? Are we being innovative or productive in ways that increase our revenue? How can we optimize our operations to make more money?
Money	Outcome	How well does our business drive profit? Which of our actitivies are aligned with the creation of profit? How do we ensure the business stays efficient in producing a positive bottom line?

You may find different questions and different answers for yourself. Whatever you discover - be aware that the answers are unique. They define your business. You can not copy these answers from others, nor can we give you the "right" answers.

If you find this exercise inspiring, and haven't had enough: try emphasizing two words and see how that changes your answers.

Conclusion

Dissecting the question "How do we make money?" by emphasizing different words provides valuable insights into the nature of your business.

Each emphasis highlights a different aspect of the business - from the methods and processes employed to the roles of the team members and ultimately, bottom line benefits.

By carefully considering these perspectives, business owners can develop a more comprehensive and effective approach to revenue generation, and also learn where currently, there are gaps between expectation and reality. This nuanced understanding enables them to optimize their strategies, enhance teamwork, and prioritize actions that lead to sustainable financial success.

Remember - the path to a successful business is not just about the end result but about the journey to get there.

The Scrum Master as a Trash Collector

In economics, "waste" can be broadly defined as "anything you must pay money for in order to not have." This expansive definition gives us a fresh lens through which to view the role of the Scrum Master: the trash collector.

With this new stance, we offer a unique perspective for Scrum Masters struggling to articulate their value when asked what they bring to the organization. Take a minute and reflect: when was the last time you asked a trash collector what they brought to your house? If you did that, what would they answer? "I'm getting rid of the trash so your place is clean" - that's what you'd expect! And you're happy with their service when there's no smelly pile of trash piling up.

Organizational trash

What is the "trash" that Scrum Masters should be collecting and disposing of? Here are a few examples:

• Meetings: Reducing unnecessary meetings that waste time, drain energy and break concentration.
• Overhead: Cutting down on administrative tasks that don't contribute to the team's goals.
• Processes: Streamlining or eliminating processes that hinder productivity.
• Effort: Removing redundant work to keep the team focused on what truly matters.
• Delays: Identifying and addressing bottlenecks to ensure smooth project flow.
• Stress: Easing team stress to promote a healthy and productive work environment.

This list is incomplete - ponder by yourself which other forms of trash that might pile up in your organization.

Where does this trash come from?

Just as when you buy a new product, you get the value you were looking for plus some packaging. This packaging is necessary to ensure the product's quality upon arrival. However, once you use the product, the package turns into waste. Most organizations fail to dispose of this waste — they keep it around because they don't even realize it's there and it's waste. Eventually, most dealing with the waste becomes a full-time job, and teams can no longer focus on creating value.

The Scrum Master as a Trash Collector

The more effectively a Scrum Master can take out this "trash," the more valuable they become. A good Scrum Master is identified not by what they add, but by what they remove — making the team's path to success clearer and more efficient.

This perspective also helps clarify the often-asked question of whether the Scrum Master role is temporary. Much like trash disposal, the need to remove waste is ongoing. Believing that "We already had the trash picked up last week, we don't need trash disposal anymore" is shortsighted. Initially, you may not see a problem with a bit of dust and litter scattered about - it's just a matter of time until you're knee deep in the trash and can no longer move!

Summary

The stance of the trash collector underscores the Scrum Master’s commitment to fostering an environment where teams can thrive and focus on delivering value, free from the burdens of organizational trash.

Do Scrum Masters need to be technical?

There's a neverending debate: "Do Scrum Masters need to be technical?" How would I answer this, based on almost two decades of experience?

My answer is a clear "Yes and No."

Accountability

Let's emphasize: Scrum Masters are "accountable for the effectiveness of their team." (Quote: Scrum Guide)
If a team is technically highly competent, a Scrum Master will focus on other areas such as team organization, collaboration with other teams, interaction with management, and optimizing value creation, for example. In this case, no technical skills are required.

In Practice

Scrum Masters, by virtue of their role, aren't technical experts themselves, but must definitely be able to identify technical problems and provide the team with a way forward.

In practice, many teams are far from being as technically mature as one would wish. Code quality is lacking, test automation is an ongoing issue, and many other small problems. Why? It's due to a lack of understanding of technical practices such as Continuous Integration, Refactoring, or Test Driven Design. Primarily, such teams face the problem: "How do I know what I don't know?" If the team recognizes that there's a technical problem hotspot somewhere, it is sufficient for a Scrum Master to work this out precisely with the team and ensure that they receive competent technical coaching and the necessary time for improvement.

That becomes difficult when neither the team members understand their technical situation and competence - nor does their Scrum Master. Then, the team is running head first, full steam ahead into a brick wall - and that will get really uncomfortable:
For the company, which in the worst case becomes long-term incapacitated and in any case loses millions.
Which, in turn, could lead to layoffs for the developers.
And in the middle of it all is a Scrum Master who is accountable for all of this - but completely clueless.
Very unpleasant.

Closing remarks

I've had good and bad experiences with Scrum Masters who have been in technical roles for years, and the positive ones are more numerous. I particularly want to positively highlight the qualification of QA experts who, by profession, are accustomed to questioning everything, uncovering problems, and, if necessary, confronting management.

Hence, I'm confident that having done technical work that helps a Scrum Master succeed is definitely an asset.

"Agile" is not sacred

Some people believe that "Agile" or the ideas propagated by Agile practitioners should not be criticized. They view such criticism as a lack of understanding of Agile or disrespect for Agilists. I disagree. Let's delve deeper into this matter and explore how criticism intersects with science, reasoning, and growth intersect to bring Agile principles to life.

Agile is not a Religion

It's tempting to defend Agile against criticism. But this turns the pragamtic, empirical approach into religious zealotry - We shouldn't hold a Holy Writ or Prophets over observable truth and evidence: Agile is not dogmatic. It thrives on openness, interaction, and an objective dissemination of plausible ideas. Treating it as an unassailable dogma turns this dynamic way of doing the best thing possible into a cultic practice.

The Cult of Dogma

Trying to staunchly defend "Agile" against critique creates a paradox: Agile, by design, thrives on openness, interaction, and the pursuit of better solutions. Turning it into a dogma stifles progress and growth. Dogmastism —whether religious or ideological— resists questioning and dissent. Agile, however, would welcome both.

Agile is Dynamic

"Agile" isn’t etched in stone: it’s living, evolving. Its core values highlight the need for continuous reflection and adaptation. Agile practitioners must embrace critique as a catalyst for growth.

Science and Agile: Kindred Spirits

"Agile" was conceived out of frustration with heavyweight project management methodologies that led to more failure than successes. Its founders sought an alternative that valued interaction, collaboration, flexibility, and responsiveness. That's the opposite of religious dogmas: Agile doesn’t demand unwavering faith. Instead, it encourages empirical experimentation and adaptation.

A place for skepticism

Scientific progress hinges on skepticism, curiosity, and the willingness to challenge prevailing theories. Agile shares this spirit. When practitioners question assumptions, experiment, and learn, they embody the scientific mindset. Agile’s empirical approach encourages us to scrutinize practices, discard what doesn’t work, and refine what does. It’s a departure from dogma, where adherence trumps evidence.

Welcome Valid Critique

An idea or practice that can’t withstand criticism is inherently flawed. Rigorous examination sharpens our tools. When criticism arises, we need to either debunk the critique with evidence or adapt our approach to the criticism. Agile’s resilience lies in its ability to evolve based on valid feedback. It doesn't coincide with flat out rejecting uncomfortable ideas.

Lab conditions

Imagine Agile as a laboratory: a space where hypotheses are tested, results analyzed, and theories refined. Just as scientists revise their models based on feedback and empirical evidence so do Agile practitioners need to do. A laboratory mindset encourages us to embrace critique, learn from failures, and iterate toward excellence.

No Sacred Cows

As long as we stick to our assumptions irrespective of the evidence, we will struggle to produce best possible outcomes.

Letting go of ideas

Metaphorically speaking, Agilists need to wield a cleaver to butcher sacred cows — those unquestioned beliefs or practices that stand between us and excellence. This helps us evolve, learn from mistakes, and refine our approaches.

Being flexible

Agility relies on flexibility, adaptability, and learning. Rigidity stifles growth. By remaining open to change and questioning established norms, we create an environment where innovation thrives.

Scrutiny and Validity

Ideas need to be subject to constant scrutiny. Rigorous examination sharpens our understanding and ensures that only the most reliable concepts are propagated. Emotional reactions or thought stopping hinder progress.

The Crucible of Scrutiny

Agile thrives when subjected to rigorous scrutiny. Just as metals are refined in the crucible, Agile ideas are honed through examination. When we question assumptions, we refine our understanding and discard what doesn't hold up. Scrutiny isn't a threat; it's a catalyst for growth.

Emotional Resilience

Emotions have their place, but they're often a bad advisor when dealing with criticism. It's natural to respond to critique with an emotional reaction that clouds our judgment. Reason, logic and evidence are much more reliable guides when emotions flare.

Constructive Criticism

"Agile" benefits from constructive criticism. Rather than approaching dissent with negativity, we can understand it as a means to foster growth, refine our practices, and elevate our performance.

Avoid Buzzword Bingo

"Agile" arguments often deteriorate into buzzword bingo — where catchphrases replace substance. Avoid jargon and focus on substance: Show me the "better way" with clarity, backed by evidence. Buzzwords won't impress anyone looking for serious answers.

Be Positive

Criticism is not an attack that needs to be defended against. Instead of shutting down the question, let's open up a conversation. By challenging assumptions, we contribute to growth. But likewise: Simply lashing out at something stifles progress. This won't lead to improvement.

Be Reasonable

Ad hominem attacks and Gaslighting have no place in a collaborative environment. Instead, let's engage in thoughtful reasoning. When you disagree, present your case logically. "Agile" thrives upon the respect of differing viewpoints, perceiving uncomfortable questions as invitations to learn.

Summary

Agile isn't a fixed monument; it's a dynamic garden. Water it with constructive criticism, prune away dead branches, and watch it flourish. Let's cultivate growth, learning, and respectful discourse.

Is the Scrum Master an entry-level role?

There's a rise in job postings for "Junior Scrum Master" and even "Scrum Master (Internship)" - and that's problematic.
Without a certain foundation of experience, you can't do justice to this role.

I often read, "How do you become a Scrum Master if it's not for beginners?"
My somewhat cheeky response: "How do you become a medical director if that's not for beginners?"

The seeming hyperbole has a point: These two roles share many similarities. Neither primarily involves the execution of operational tasks - instead, both are accountable for operational effectiveness.

They need to make sure that things are running smooth. That nothing important is overlooked. That when the going get tough, no mistakes are made, and when mistakes are made, that no chain reaction occurs. They need to ensure that problems beyond the competence of others are resolved quickly and effectively. And, of course, they coach and mentor the experts. This requires a strategic overview and an understanding of what's going well, what isn't - and where things are heading. Effective communication. And a lot of experience.
Can we expect all of this from beginners? Hardly.

While Scrum Masters don't do all of this on their own, they support experts, specialists, and leaders in word and deed in order to be effective, optimize, simplify, and solve problems. This requires an understanding of how things work, the success factors, common problems, and typical solutions.

And that was just the internal perspective. From an external perspective, a Scrum Master needs to collaborate with stakeholders such as customers and management. This requires a practical understanding of process management, project management, product management, quality management, management systems, typical business and leadership challenges - and potentially, some basics of labor law and economics.

And still, all of this is only scratching the surface - but this already tells you that the Scrum Master accountability is not for the faint of heart. It requires many competencies that don't come out of nowhere. They require previous experience.

Now, how can you approach becoming a Scrum Master? Simply put: Gain experience in less challenging roles. Prove yourself. Broaden your horizons and grow continuously. Once you have earned the respect of colleagues, leaders, and teams - then you are ready to become a Scrum Master.

I'm aware that I'm setting the bar quite high here. In practice, hardly anyone possesses all these competencies. That's okay. There's always a compromise. But every compromise comes at a cost. Each compromise means that the Scrum Master will be less effective. Once we strip away everything - then we could also use a houseplant as a Scrum Master.
And trust me - you don't want to be a Scrum Master who can be replaced by a houseplant. Because you will be.

Understand Perspectives

Quite often, people jump on a point they disagree with using statements like, "You are wrong," or "You are ignorant ..." While the second has some merit when people literally talk about subjects they are unfamiliar with - the issue we need to talk about is the matter of perspectives. Everyone, regardless how informed, has a perspective based on where they stand. Let us discuss how this understanding helps us build better communication and relationships.

Whenever we interact with others, understanding and appreciating diverse perspectives is crucial for effective communication. Assumptions and assertions as well as our own bias can easily have us miss important points, fail to build agreement, and ultimately result in failure to come up with an effective way forward.

Who is right?

In the pursuit of truth and understanding, we quickly encounter contrasting perspectives. In order to pursue growth and collaboration, we need to acknowledge diverse viewpoints and also successfully navigate conversations to come up with solutions.

Assertive statements like "You are wrong," "You should ..." or a sentence that categorize the person are often hastily thrown into the discourse, with consequences that reach far beyond the statement itself.

This style of communication hinder productive dialogue and pollutes the atmosphere - individuals who get attacked with such statements are less inclined to explore, learn, and collaborate:

Defensive Reactions

Statements asserting that someone is "wrong" or "ignorant" come across as verbal violence and can trigger defensive reactions. People become less open to considering alternative viewpoints and focus more on defending their own position.

Communication Breakdown

Assertive language without considering the other person's perspective may lead to a breakdown in communication. It can create a hostile environment where participants feel attacked rather than engaged in a meaningful discussion.

Strained Relationships

Telling someone what they must think strains interpersonal relationships, as this implies an imbalance of power. Building mutual respect and understanding becomes challenging when communication is characterized by one-sidedness.

Closed-Mindedness

Assertive statements often contribute to a closed-minded atmosphere, where participants are less likely to engage in open-minded exploration of different ideas. Feedback that a perspective is not welcome will hinder the potential for collective learning and growth.

Barriers

When dismissing another person's perspective outright, they are unlikely to consider the perspective of the dismissing person more valid than vice versa. With this default position, dialogue is extremely challenging.

Missed Opportunity for Understanding

Categorical statements may close off opportunities for understanding the nuances of the other's viewpoint. They often assume a binary right-wrong dichotomy, neglecting the possibility that both perspectives can offer valuable insights or even overlaps.

Ten tips to improve your communication

Aggressive language is evitable. Instead of using confrontational language, here are some tips for a more constructive approach:

Express Curiosity

Instead of asserting that someone is wrong, express curiosity about their perspective. Ask open-ended questions to understand their reasoning and the experiences that shape their viewpoint.

Listen Actively

Practice active listening to truly understand the nuances of the other person's perspective. Engage in the conversation by paraphrasing, summarizing, and asking clarifying questions. This demonstrates a genuine interest in their viewpoint.

Adapt and Connect

Be aware of the different cultural backgrounds and adapt your communication style accordingly. This fosters a respectful environment and also promotes effective understanding.

Seek Common Ground

Identify areas of agreement or common ground before delving into differences. This can create a foundation for more constructive discussions.

Acknowledge Agreement

Acknowledge valid points from the other person's perspective. Recognize areas of agreement to build rapport and establishes a foundation for finding common solutions to shared challenges.

Use "I" Statements

Share your own perspective using "I" statements to convey your feelings and thoughts without implying anything about the other person's perspective.

Offer Information

You may believe the other person might benefit from additional information. Consider sharing it in a way that is informative and invokes curiosity. Prescriptive suggestions trigger defensive mechanisms, and these do not advance the conversation.

Be Patient

If your perspective is not immediately understood, exercise patience and elaborate your perspective. Use clear and concise language, provide examples, and repeat your key points to ensure effective communication.

Frame respectfully

Frame disagreements as differences in perspective rather than absolute right or wrong. This allows for a more respectful exchange of ideas.

Stay Constructive

Apply constructivism when you offer feedback. Focus on the specific behaviors or ideas that you want to address. Avoid making personal attacks. This encourages a positive and solution-oriented atmosphere.

Don't worry if you miss out on using these occasionally - it takes a lot of practice, self-awareness and patience to master these.

Conclusion

In the complex landscape of communication, the ability to navigate diverse perspectives is not only a skill but a necessity. By adopting a mindset of curiosity, empathy, and open dialogue, we can transcend the limitations our own biases and beliefs. Avoiding the use of overly assertive language helps us create environments conducive to mutual understanding and collaboration. As we engage in discussions, let us remember that true progress lies not in scoring points by declaring someone "wrong" - but in our collective willingness to explore, and embrace the richness of human experience.

It takes a tremendous amount of courage to open up a controversial perspective when the response might be backlash, personal attacks or outright bullying. Ask yourself: Do you want to be the person who makes it easier, or harder, for others to say what they think? Do you want to be the one who builds bridges, or burns them? Do you want to work towards understanding - or hostility?

With that, I would leave you with the following default stance - whenever someone starts a conversation,

Assume Positive Intent.

10 Signs You're Facing an Agile Fanatic

As "Agile" popularity rose in recent years, so did fanaticism — a rigid adherence to a fixed set of ideas that doesn't embrace the spirit behind them. In this post, we'll delve into ten signs that may indicate a person's journey into Agile has taken a detour into fanaticism. From dogmatism to denialism, we'll unravel the subtle but impactful shifts that can hinder the true essence of Agile and its intended goal: delivering value to customers.
So here we go -

Denialism

Denying the existence of bad Agile practices "because I've never seen that" hints at a lack of awareness and narrow-mindedness.

See also: "Argument from Ignorance."

Tunnel Vision

Rejecting ideas from anyone who isn't a recognized Agile Thought Leader indicates a narrow perspective and a filter that severely restricts opportunities to grow.

See also: "Ad Hominem Fallacy."

Guru Idolatry

A line of reasoning that depends on quotes from Agile gurus, using the name of the gurus as the primary evidence, may not have a point to begin with.

See also: "Argument from Authority."

Manifesto Memorization

Reciting the Agile Manifesto from memory without flexibility in its application reveals an unhelpful focus on form over function.

See also: "Formal Fallacy."

Dogma Defense

When the first reflex is to reject ideas conflicting with "Agile," without entertaining their possible validity, opportunities for improvement are lost.

See also: "Personal Incredulity."

Framework Fundamentalism

Insistence that a "proper" use of an Agile framework is necessary - shows a misunderstanding on the core Agile concept of adaptivity.

See also: "False Dilemma."

"Not Real Agile"

Labeling deviations from a personal interpretation as not "real" Agile betrays unconstructive dogmatism that doesn't encourage finding better ways of working.

See also: "No true Scotsman."

Purity Over Delivery

Prioritizing the "correct" application of "Agile" practices and methods above the delivery of valuable products to customers necessitates reevaluating one's focus.

See also: "Slippery Slope."

Blaming

Immediately responding to challenges or failure by blaming others for incorrectly following Agile practices destroys trust and the opportunity to address the deeper issues.

See also: "Attribution Error."

Elitist Tribalism

Those who separate the world into the categories "Agilists," "Those who can be converted," and "The irredeemable rest," not treating the latter as equals - are dangerous company.

See also: "Othering."

Conclusion

Always remember that Agile is ultimately about suceeding and helping others succeed. Flexibility, collaboration, and continuous improvement lay the foundation for this success. Embrace the principles, resist the notion of dogmatically following ideas or practices. This paves the way for a more resilient, innovative, and ultimately successful Agile journey.

If you spot signs of fanaticism in yourself, reconsider your position. If you spot some signs in those around you - address them. And if someone gets a full Bingo on the list above - do yourself a favor and steer clear.

In Scrum we do ...

"How do you do this in Scrum?" - A common question, and still: not a meaningful question. Why? Let's explore.

Scrum has no prescriptions.

Scrum is but a container, and something that works within Scrum should also work without Scrum. If that's not the case, and something only works because of Scrum - you probably misunderstand Scrum.

Does it make sense?

If something makes sense irrespective of Scrum, you may want to try it. If you believe that it has to be done because of Scrum, but your senses are tingling - they may be right.

Does it work for you?

Whatever "this" is - how are you currently doing it, and does it give you the results you're looking for? If so - why would you want to change it?

A better question

We're currently doing this, and those are the issues we're facing. How could we address these?

Whenever you hear or say, "In Scrum, we do ..." - whatever follows next is either complete and utter nonsense, or has very little to do with Scrum. Most likely, the first.

Agile vs Waterfall - the wrong question

22 years after the "Manifesto for Agile Software Development," the battle for Agile vs. Waterfall still isn't settled - despite many prominent publications, such as a recent HBR article, trying to "settle the debate."

Unfortunately, this debate can't be settled - because it starts with the wrong question. We will take a look at the question that needs to be asked.

Finding the right question

Most authors start with a question that doesn't bring us any closer to a sensible answer, quite often out of ignorance on what "Agile" is.

What "Waterfall" isn't.

Let's examine some definitions you may find floating around.

"Everything that's wrong"

Well, congratulations: with that definition, even adding too much salt to your breakfast eggs is Waterfall. Fun facts - even "Agile" doesn't prevent things from going wrong, and not even "Waterfall" projects always go wrong (would that mean that Waterfall isn't Waterfall because Waterfa ... argh, paradox!)

A sequential, linear approach from idea to completion.

That's crudely based on Winston Royce's paper from the early 70's - but face it: no company actually works like that, and even Royce wasn't suggesting that. Even "Waterfall," in industry common practice, is a continuous, incremental development approach. Just with very big increments, and extremely slow feedback cycles (it's not unrealistic that it could take 2-5 years between when a requirement is defined until people get the thing they actually need.)

A stage-gated approach to product development.

That definition has two fundamental flaws:
First, you can stage-gate "Agile" approaches as well, and before 2006 (i.e. five years after "Agile") - stage gating wasn't even a thing in most enterprises: You can well do non-Agile projects without stage gates.

You can find another, much more comprehensive article on other things that "Waterfall" is not referenced here.

So we're in a bit of a pickle: We can't even find a non-strawman definition of "Waterfall" that would go beyond the completely fictional definition used in Royce's paper for how to not do things.

What "Agile" isn't.

Let's do the same favor to "Agile" and pull out some of the common misleading beliefs floating around:

Scrum is not Agile

Hard to overemphasize this, but there are two core problems with equating Scrum and "Agile."
First, there's a boatload of terrible Scrum out there that not only doesn't qualify as "Agile," it hardly qualifies as professional.

Second, there are many "Agile" approaches out there, and even though Scrum dialects are the most common, quite a lot of agile companies don't use even Scrum.

Inadequate processes, plans, documents, or contracts

This definition of "Agile" only rings true for illiterate people who can't make sense of the statement "While there is value in these things ..." - Agile approaches make use of these things. Any argument against "Agile" referencing to Agile's inability to structure themselves is either a strawman or ill-informed.

Lack of direction or tracking

Humorously, if that's the definition of "Agile," it's not a stretch to say that most large Enterprises are indeed extremely Agile.

On a more serious note: most professional Agile practitioners will emphasize the importance of clear goals, as well as frequently checking progress on these goals.

We're stuck with the same issue: if we use a strawman definition of "Agile," then everything sensible is a better choice - but none of these definitions hold true to the intent of the Manifesto.
The best definition I can come up with today is based on the very first line of the Manifesto itself: "We are discovering better ways of developing software by doing it and helping others do it." My definition, hence, is "The ability to do the right thing right, at the right time." And with that definition, everyone who proposes anything other than "Agile" - would have to argue why it would be preferable to do the wrong thing, do things wrong, or have poor timing: I find that case extremely hard to make.

Note that this definition of "Agile" says nothing about Frameworks, Methods, Roles or any other form of rules. It doesn't even say anything about values, principles or goals. It's so broad and encompassing that the dividing line is only, "Is that right?"

So - if nobody in their right mind would purposefully do something wrong, why is "Agile" even a thing?
And that leads us to ...

The actual choice

After this introduction, we realize that choice isn't Agile versus Waterfall. It's about answering the question how we deal with things going awry. But: why do things go wrong? Let's take Mark Twain's opinion here:

This provides us a powerful reframing of the entire debate: The "things we know for sure that just ain't so" are - unvalidated assumptions. With this framing, we can rephrase the question to:

How are we dealing with assumptions?

The fundamental choice is: do we proceed based on predetermined assumptions, or do we capture evidence to validate our assumptions? And at which point do we do this?

The framing thus stops being the unfortunate false dichotomy of "Agile vs. Waterfall," it turns into:

Which mechanisms do we employ when reality contradicts our assumptions?

A classical plan-driven approach is built on three core assumptions: we are doing the right thing, we know how to do it right, and we can determine the right timing.

A classical "Agile" approach is built on the core assumption that there is uncertainty: we don't know what the right thing is, we could be doing something wrong, and the world doesn't always follow our timing. The concept is the "VUCA World."

These approaches are both extremes, and in practice, there's always a form of compromise:

• We can start with a hypothesis of what's the right thing, and when it turns out that it isn't, we need to change what we do.
• We can define how we do things, and we have to change that plan when it no longer works.
• We can schedule when we do what, and when we miss that schedule, we need to re-schedule.

Every project manager who learned their ropes will agree that even in a classical, plan-driven approach, this happens all the time. Likewise, every Agilist will concede that we need a product vision, some working agreements, and a bit of forecasting. We can also agree very easily that we need frequent inspection points and to check whether we're on track, and to change direction when that's not true. So - where does the disagreement come from?

Ultimately, we're talking about the probability that an assumption we made is wrong. How likely did we to bet on the wrong horse? How likely are we riding a dead horse? And how likely is the race not going as planned?

Statisticians understand that probabilities aren't 0 or 1, but somewhere in-between. Depending on how likely an event is, we should use practices appropriate to deal with the uncertainty. And depending on how far away an event is, the less likely we can predict it. Hence, the actual question becomes:

How do we deal with uncertainty?

The answer to this question is extremely contextual. We only know that rigid practices without flexibility will be more problematic when we ran into something that we didn't expect - and being so flexible that we can't make any form of prediction isn't sensible, either.

Summary

The question that we should be asking is how much it will cost us to learn that we are wrong? When the answer is tolerable, we are doing okay. Otherwise - we are gambling.

And in some cases, it could be the most wrong and costly thing to not have a detailed long-term plan. Even though that's not considered to be very "Agile."

The OPEN Transformation Roadmap

When looking at SAFe's "Implementation roadmap," we basically see "Training, training, training, training, do something, training, training, training, bye - have fun!" That looks great if you're a trainer - but it has little to do with how I, as a coach, perceive the journey of organizational change.
In this article, I'm trying to give you a short summary on how I personally perceive a change initiative - with "OPEN Transformation roadmap!"

Organize
Group	Activities	Objective
Change Direction	Formulate Change Objectives Coalition Formation	A guiding coalition that agrees on clear, relevant change objectives.
Change Planning	Change Backlog Change Coordination Organize Calendar	An overview of the predictable activities - what, when and by whom.
Knowledge Foundations	Basics Training Self-Study Q+A Sessions	Everyone has a fundamental understanding of the changing principles, practices - and what it means for them.
Role Alignment	Role Clarification Coaching Touchpoints	Those actively leading and conducting the change understand their roles and responsibilities.
Prepare
Flush the System	Identify hindering Tasks, meetings, roles & responsibilities Identify incompatible Incentives & Measurement Categorize current hinderances Determine flushing actions	Hindrances to change and suitable resolutions are identified, and resolution begins.
Change Overview	Problem-Solution Fitness Assessment Change Recommendations Extend Change Backlog	There's a map connecting Status Quo, change opportunities and the desired future state.
Team Preparation	Team Structure Planning Working Environment Setup Tooling Configuration Calendar Revamp Kick-Off Event	Teams are known and have the necessary means to get started.
Content Readiness	Content Preparation Feature Refinement Establish Backlog	Content and backlog items are prepared, refined, and established to start development in the new ways of working.
Execute
Event Setup	Establish Events Prepare Events with Role Holders Coach-led Events Team-led events with Coaching support	Events are set up, facilitated, and embraced by the people doing the work. Collaboration, transparency, and continuous improvement thrive.
Continuous Support	Daily I&A Sessions	Regular sessions where the change coalition reviews and adjusts their ongoing application and learning on the new ways of working.
Next Steps
Ongoing Support	Active Coaching Disengagement On-Demand Coaching	People receive Coaching support to address situational challenges and needs.
Change Review	Change Benefit Analysis Closing Assessment Further Recommendations Update Change Roadmap	The current state is transparent, recommendations for adjustment and further change are acknowledged and pursued.
Conclusion	Celebration Retrospective Wrap Up	The Adoption itself is concluded, and the organization continues on their Continuous Improvement and Learning Journey.

And yes, the acronym was chosen deliberately: First, it's catchy and memorable. It radiates confidence that we know what we need to do. And most of all: it makes explicit what needs to be emphasized: The "roadmap" itself is OPEN, and it leads ... into the OPEN!

No, performance isn't defined 94% by the system.

There's a persistent myth proliferating in the Agile space: allegedly, "94% of an organization's performance is attributed to the system, while only a mere 6% depends on the individuals." This widely circulated belief shapes perceptions about the dynamics of productivity, teamwork, and leadership in countless organizations - but: it's false. And here's why.

The 94% myth

Could it really be the case that we can hire individuals without ambition, experience, or talent and expect nearly identical results as we would from a team of motivated, skilled, and dedicated professionals? Does the concept of "systems over individuals" hold up in the real world of work, where unique skills, passions, and contributions of individuals often drive innovation and excellence?

The reality is more nuanced than the oversimplified notion of 94% versus 6% in performance. To understand what's going on, we must first trace back to the origins of this myth in the writings of W. Edwards Deming, the renowned statistician and quality management guru, and dig out the roots of this quote. In doing so, we'll discover that he wasn't making a case that individual performance is almost irrelevant - to the contrary!

What's the "System?"

Let's start by defining what "the system" actually is - let's take a look at what the systems thinker Russell Ackoff repeated on multiple occasions:

A system is never the sum of its parts; it’s the product of their interaction.

Russell Ackoff

Before we explore deeper, let's sprinkle in a quote from Dan Pink on organisational systems:

• Autonomy: the urge to direct our own lives.
• Mastery: the desire to get better and better at something that matters.
• Purpose: the yearning to do what we do in the service of something larger than ourselves.

These are the building blocks of an entirely new operating system for our businesses.

Dan Pink, "Drive"

While we can formidably argue whether Pink's statement is an assertion, anecdotal evidence or fact - what matters it that Dan Pink sees within the individual the building blocks for a better organisational system.

Out of the Crisis

Let's now explore what Deming actually wrote:

I should estimate that in my experience most troubles and most possibilities for improvement add up to the proportions something like this:

• 94% belongs to the system (responsibility of management)
• 6% special

W. Edwards Deming, "Out of the Crisis" (p. 315)

As you can see: what he mentioned isn't that performance is (almost) exclusively attributed to the system, but that most of the problems are systemic and require active management attention.

Untangling system and individuals

Let's use these definitions to untangle what "the system" is, versus what "individuals" are in our context:

The System

As Russell Ackoff aptly stated, a system is not simply the sum of its individual components; rather, it emerges as the product of their intricate interactions. In the context of organizational performance and management, "the system" encompasses the collective structure, processes, culture, and interdependencies that define an organization. It represents the holistic framework within which individuals operate, a complex web of relationships, rules, and practices that determine the organization's overall effectiveness and outcomes.

The Individual

Drawing from Dan Pink's insights, "the individual" embodies the human element within the organizational context. It's the unique person, with their aspirations, skills, motivations, and contributions. Within the organization, "the individual" serves as the driving force behind the building blocks of autonomy, mastery, and purpose. Autonomy represents the urge to self-direct, mastery is the pursuit of continuous improvement in meaningful skills, and purpose signifies the desire to contribute to something greater than oneself. These qualities collectively define the individual's role in shaping and enriching the organizational system.

The misconception

If '94% of the performance can be attributed to the system, and only 6% to the individual' -- then we could hire people without ambition, experience, or talent and get almost identical results as we would get from hiring people who care for what they do, know what they do, and are excellent at what they do. However, that's a massive misconception which is only possible due to a conflation of terminology which tries to separate "the system" from "the people making up the system" (which doesn't work!) - The people making up the system are the basis of the system! And a system comprised of autonomous, highly qualified, purpose-driven individuals has a different basis than a system where these are missing!

The System's Role

According to Russell Ackoff's definition, "the system" encompasses the intricate web of interactions and interdependencies within an organization. It includes organizational structure, processes, culture, and more. If we were to take the 94% attributed to the system at face value, it might suggest that the organization's performance is almost entirely determined by these systemic factors. This perspective can lead to the misconception that individuals are replaceable, and hiring decisions are inconsequential.

The Individual's Role

On the other hand, Dan Pink's insights highlight the critical importance of individual motivation, skills, and purpose in driving performance. If we consider individuals as mere cogs in the system, the statement implies that their personal qualities and contributions are almost irrelevant. However, if that were the case, that contradicts the notion that individuals require autonomy, mastery, and purpose within the organizational system!

Shaping effective systems

Great systems of work are shaped by motivated, gifted individuals who interact and collaborate to maximize the entire system's performance. They uplift one another, and won't tolerate being dragged down by someone who neither can, nor wants to contribute.

A high performing system of work is synthesized by optimizing the interactions of the individuals therein, while carefully paying attention that individuals wo have no place within that system don't get to negatively impact the Drive of those within.

Imperfection

Everyone can have a bad day. Even a bad week or month. And we all have our strengths and weaknesses. And nobody's omniscient. That's not what we're talking about.

But when you go out claiming that it doesn't matter whether people are qualified or motivated - you're sending an utterly destructive signal: It means that you don't respect those who put in the hard work, the learning, and the passion.

So: just don't.

You can only build great systems from people who pursue autonomy, mastery and purpose.
And you can't let people who have neither interfere with them.

Disagree?

Maybe you will disagree.

But unless you'd be fine getting major surgery from a belligerent teenager who doesn't even want to learn how to make a proper incision - I hope you're not seriously going to claim that most of the performance is in the hospital, and the surgeon themselves is neglegible to your health.

The power of stakeholder promises

In the dynamic world of product management, one thing remains constant: the importance of stakeholders. Whether they're customers, employees, investors, or partners - stakeholders play a key role in the success of your product. How can you ensure that you're meeting their expectations and delivering on your commitments? The concept of "Stakeholder Promises" gives you an answer - so let's explore.

And since we're at it, let's start out with an example of stakeholder promises for this article:

Our promises to Product Owners:
1. You will build better products.
2. You will enhance your professional credibility.
3. You will have more effective stakeholder interactions.

The importance of Stakeholder Promises

Stakeholder Promises play a crucial role in guiding your product development journey. They are more than just commitments; they are the pillars upon which trust, credibility, and alignment with organizational goals are built. Focusing on Stakeholder Promises empowers Product Owners to navigate the complex landscape of stakeholder expectations effectively.

Alignment of Goals and Needs

Stakeholder Promises reflect on your values and your commitment to various stakeholders. By aligning your product with these promises, you keep the work in sync with the broader objectives of the company.

Trust and Credibility

Fulfilling Stakeholder Promises demonstrates your dedication to meeting stakeholders' expectations. This, in turn, builds trust and credibility with your customers, employees, partners, and investors.

Effective Prioritization

Defining Stakeholder Promises helps you prioritize features and enhancements that truly matter to your stakeholders. It's a compass that guides you in making informed decisions about what to build next.

Transparency and Communication

Promises serve as a foundation for transparent communication. You can openly discuss how your product aligns with these promises, fostering a sense of inclusivity and cooperation among stakeholders.

What Are Stakeholder Promises?

Stakeholder Promises are explicit commitments made to various stakeholder groups. These commitments are derived from the vision and encompass a wide range of areas - from customer satisfaction over employee well-being all the way to ethical business practices. Essentially, they represent the organization's pledge to contribute positively to the well-being of all stakeholders.

Take the example of Yamaha, where you see promises made to customers, employees, business partners, communities, and even the environment: These promises form the foundation upon which their products and operations are built.

Defining Stakeholder Promises

Here's a simple process that you can apply for defining meaningful Stakeholder Promises:

Step 1: Identify Product Vision

The foundation of Stakeholder Promises lies in your product's vision. Start by clearly defining your product's vision, which serves as the guiding force for all your commitments.

Step 2: Identify Key Stakeholders

Identify the primary stakeholder groups relevant to your product. These may include customers, employees, investors, partners, and other parties with a vested interest in your product.

Step 3: Relate Vision and Stakeholders

Establish a clear connection between your product's vision and the needs, expectations, and aspirations of your identified stakeholders. This step ensures that your commitments align with your product's overarching goals.

Step 4: Define Everyone's WIIFM

For each stakeholder group, define the "What's In It For Me" (WIIFM). In other words, articulate what value, benefit, or impact your product promises to deliver to each group. Be specific and consider how your product addresses their unique needs and concerns.

Step 5: Make Specific Promises

Make your promises effective and actionable:

• Make your promises specific, so there's no ambiguity about what you aim to achieve.
• Quantify your commitments wherever possible. This allows you to track progress and measure success objectively.

Step 6: Collect Feedback

Before finalizing your Stakeholder Promises, share them with the relevant stakeholder groups and seek their input. Such an initial round of feedback provides valuable insights and ensures that the promises resonate with your stakeholders.

This step-by-step guide will equip you to define Stakeholder Promises that are clear and actionable, and also well-aligned with your stakeholders' expectations and your organization's mission.

Successfully using Stakeholder Promises

Here are six tips to support you in maximizing the impact of your stakeholder promises:

Align your strategy: Your product and any work done on it should directly contribute to fulfilling your stakeholder promises - or at least: not contradict them.

Prioritize: Stakeholder promises help you prioritize what matters: Features that directly address one or more stakeholder needs or expectations have more impact on your product's success.

Communicate: Use Stakeholder Promises as a basis for transparent communication. Regularly update stakeholders on how your product aligns with these promises and any progress made.

Seek feedback: Actively seek feedback from stakeholders, especially those for whom promises have been made. Act on what you learn to improve your product.

Continuously improve: Frequently revisit your stakeholder promises, keep them up to date, and use them as a benchmark for improving both your product and pactice.

Be Responsible: Actively align your actions and outcomes with the standards outlined in Stakeholder Promises.

Conclusion

Never underestimate the power of Stakeholder Promises: They serve as a guiding light, directing your product development efforts towards fulfilling commitments to your customers, employees, partners, and the broader community. By understanding, defining, and leveraging these promises effectively, Product Owners and teams can build products that meet and exceed stakeholder expectations, while simultaneously contributing positively to the well-being of all involved parties. By paying attention to your stakeholder promises, you'll not only create better products - you also build trust, credibility, and sustainable relationships with your stakeholders.