Pages

Thursday, July 4, 2024

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.

Wednesday, June 5, 2024

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.

Wednesday, May 29, 2024

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?

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

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

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

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

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

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

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

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?"

Thursday, May 23, 2024

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.

Monday, May 20, 2024

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.

Monday, April 22, 2024

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.

Tuesday, April 2, 2024

"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.
No religious worshipping of Agile!

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.

Saturday, January 13, 2024

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.