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.

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.

10 signs your Scrum Master doesn't understand Scrum

As an enterprise Coach, I meet a lot of Scrum teams. Despite its widespread adoption Scrum is rarely done well. Many Scrum Masters, the pivotal role responsible for fostering a high-performing team, aren't even prepared to grasp the essence of their job. Being an advocate for continuous improvement and a firm believer in the power of sarcasm to make a point, I'm not here to cast blame or ridicule anyone, but to tigger a discussion. I genuinely believe that most Scrum Masters who find themselves in these situations came there unwittingly, and want to do better. But they may lack the right understanding or guidance to see what's wrong. So - here goes my Top 10 list of common pitfalls and misconceptions how a Scrum Master could get in their own way of fostering an environment of growth, learning, and continuous improvement:

10 Signs that Your Scrum Master Doesn't Understand Scrum

Customer Focus? Maybe Later - For Now, Let's Get Scrum Straight!

A Scrum Master who prioritizes "getting Scrum straight" over customer focus misunderstands the core value of delivering value to the customer. Scrum emphasizes customer collaboration and responding to their changing needs, ensuring that the team builds products that meet their expectations and bring maximum value.

Team Dynamics? We Had a Team Building Workshop at the Kick-off, So We're Good.

Believing that a one-time team building workshop is sufficient for effective team dynamics disregards the continuous effort needed for building and maintaining a high-performing team. In Scrum, fostering a collaborative and self-organizing team is an ongoing process, requiring consistent support and attention from the Scrum Master.

Transparency and Openness? Nah - Nothing Beats a Great Hidden Agenda!

A Scrum Master who drives a hidden agenda undermines the essence of Scrum's core foundation of trust. Transparency allows for honest visibility into the team's progress, challenges, and achievements, fostering trust among stakeholders. Hidden agendas defer problems caused by misalignment into the future, at which point they may have grown significantly.

Facilitation? Servant Leadership? No, They Need Someone Who Gives Them Clear Direction!

While there are reasons for being directive, that should be a last resort. Facilitating collaborative discussions and informed decisions improves understanding, and thereby reduces risk. By taking a directive stance as a default, the Scrum Master introduces themselves as a dependency into the team and hampers their growth and collaboration.

Focus on the Sprint Goal Now - We'll Talk About Impediments in the Retro!

Let's be clear - it's not an impediment unless it significantly impacts the team's ability to deliver value. What would you think about a car mechanic who told you, "Just ignore your flat tire, go to work and come back, you can always fix the tire later." Most likely, you won't be going anywhere with a flat tire - and even if you will, the price, cost and duration required to fix a broken hub will exceed the cost of the flat tire by orders of magnitude. While this could be necessary for survival, it should be an informed Product Owner choice, and definitely not a default strategy.

You Want Time for Learning? Just Look at All That Unfinished Work in the Product Backlog!

The Product Backlog is infinite, as it gets replenished in line with demand. A team deferring necessary learning in favor of Velocity loses their edge, and will eventually lose both. Learning isn't a luxury that competes with unfinished work, it keeps the effectiveness of the team up, and trades a bit of time in the short term for improvements to quality, scope and risk in the long term.

Releasable Product Increment? Once a Quarter - otherwise, it's Too Much Overhead.

Delaying the delivery of a releasable product increment contradicts Scrum's principle of delivering value with minimal delay. Even in settings where releases are scheduled at a low frequency, a failure to keep the Product in a releaseable condition introduces risk into the process: as long as our product isn't in a releasable state, we neither know how much work it is to bring it into this state - nor whether we will have the capacity to do so when we need to.

We Wouldn't Need Feedback if you Just Learn to Write Better User Stories!

Creating a false dichotomy between writing user stories and collecting feedback is a thorough misunderstanding of Scrum's empirical approach. User stories only inform us what we believe a priori about what users need, whereas feedback validates that we did indeed solve their problem. Just think of the last time you went to a restaurant and didn't like the meal: Would you have liked the waiter to blame you for not correctly specifying what you like?

That's the Standard Process. You Can't Change It Just Because It's Stupid.

Scrum is a vehicle for enabling the team to find the process that allows them to perform at their optimum. A broken or ineffective process leads this ad absurdum. Scrum encourages continuous inspection and adaptation to optimize processes and outcomes, fostering a culture of continuous improvement and innovation.

Definition of Done? Yeah, we have one ... somewhere ... Let me find it.

The DoD is one of Scrum's core commitments, as it defines how the team is committing to work. Lacking transparency, clarity or commitment to the Definition of Done is a common source of poor quality and conflict. A good, transparent Definition of Done builds shared understanding both within the team and with stakeholders.

Conclusion

Having a well-informed and capable Scrum Master is essential for a successful Scrum team. I have deliberately phrased the above signs with some sarcasm and hyperbole. In practice, they're often much more subtle. Recognizing them enables you to take proactive steps to improve the effectiveness of the collaboration between Scrum Master, team and stakeholders.

If you spot any of these signs in your team, maybe ... try raising it in the next Retrospective?

Let's Scrum better!

Why Agile Coaches need to care about Delivery Speed

I often come across the sentiment that "Agile is not about speed of delivery." I believe that claim is a severe misunderstanding on what makes a team agile - and worse: it's already an early warning sign that at some point in the future, the Agile Coach will struggle to explain what exactly they're doing. Posing a false dichotomy between Agile and Cycle Time sets up their teams to underperform in comparison to teams coached by someone who understands both the impact of Cycle Time, and how to actively reduce it.

An Agile Coach setting themselves up for failure

Cycle Time Matters

Many traditional organizations I encounter still apply outdated delivery models, often stage-gated with various in-process queues and handovers. When a company takes half a year from demand to release - I'd say they're already well above average. In fact, a one-plus year delay from idea to value isn't uncommon. In such scenarios, managers and stakeholders often request their coaches to actively address time to market as a key success metric. For good reasons.

When we talk about agility, speed of delivery plays a crucial role. Cycle Time, which measures the time from development to production, directly impacts an organization's ability to respond quickly to customer needs, market changes, and emerging opportunities. An organization's agility is closely tied to the ability to rapidly deliver value to customers. The quicker they can do this, the more responsive and competitive they become. It's essential for Agile Coaches and Scrum Masters to recognize that optimizing Cycle Time is not a deviation from Agile principles but rather an integral part of fostering agility.

Reducing Cycle Time has several benefits to agility: First, it allows us to obtain customer feedback faster and more often, enabling them to validate assumptions, make adjustments, and iterate more rapidly. This feedback loop facilitates continuous learning and ensures that the delivered software meets customer expectations and quality standards. Shorter Cycle Times also reduce the delay between occurrence and resolution of risks and issues. Additionally, short cycle times reveal potential bottlenecks and delays. All these factors reduce rework and improve our ability to create value.

Furthermore, actively minimizing Cycle Time enhances adaptability and responsiveness to changes in the market. Rapid delivery enables organizations to iteratively experiment, learn, and adapt their product or service offerings based on real-time feedback. This fosters innovation and competitiveness. Agile Coaches who understand these aspects will guide their teams to optimize Cycle Time as a means to promote agility.

Don't make it a false dichotomy!

Assuming that "Agile Mindset" and "Delivery Time Optimization" are at odds would be a false dichotomy, but let's entertain the thought and see what the long-term consequences would be for a team whose coach would make an either-or decision, and focus on either one, or the other. In our scenario, we will assume that the Delivery Time is currently so slow that management is correct in being concerned - i.e., that the team is struggling to deliver one releaseable increment per month, and that Delivery Time Optimization would orient itself on Minimum Continuous Delivery requirements. These given, let's take a look at business relevant outcomes and how they'd develop over months and years:

Metric	Explanation	"Delivery Time" Focused Coaching	"Agile Mindset" Focused Coaching
Time to Market	Timespan between idea and value.	Strong - More deliveries, reduced batch sizes and shorter wait times. Faster commercialization.	Variable - "Results not guaranteed."
Product Quality	Software meeting standards and expectations.	Strong - High delivery frequency requires effective quality practices like automated verification.	Possibly - No direct measurement or systematic approach to address quality.
Customer Satisfaction	Maximizing feedback points while minimizing low-quality experiences.	Strong - Rapid delivery with definitive quality verdicts enables better control of dissatisfaction factors.	Limited - Limited opportunities to improve customer satisfaction through controlled delivery points.
Feedback Integration	Collecting input on ideas and Working Software.	Strong - Abundant and timely feedback, potentially multiple times per day, depending on stakeholder availability.	Uncontrolled - Feedback effectiveness unquantifiably tied to delivery process effectiveness.
Adaptability and Agility	Speed and accuracy in acting upon learnings.	Strong - High delivery frequency fosters adaptability and enables effective change implementation.	Poor - Limited means to determine the level of adaptability.
Collaboration and Alignment	Staying in sync and acting in unison.	Strong - Continuous Delivery exposes lack of alignment or collaboration through pipeline failures.	Difficult to quantify - "Soft" collaboration with unmeasurable outcomes.
Risk Reduction	Minimizing impact of issues and delays.	Strong - Mitigation of risks through proactive risk analysis and automated testing.	Poor - No inherent risk control mechanisms.

Verdict

Agile Coaches who discount speed of delivery will struggle

Agile Coaches who primarily focus on promoting the Agile Mindset without actively driving speed of delivery and its enabling technical practices and processes, such as Continuous Delivery, will likely struggle when asked to show clear, measurable outcomes. Here's why:

1. Lack of Transparency: Stakeholders and decision-makers often require evidence of improvements in key metrics, such as time to market, product quality, customer satisfaction, or change failure rate. Without indicative metrics that demonstrate the effectiveness of technical practices like Continuous Delivery, it becomes challenging to achieve significant improvements in these areas, making it harder for the coach to showcase the impact of their work.
2. Inability to Improve: Sustainable speed of delivery is a lagging indicator for the adequacy and quality of a team's technical practices. The Agile Coach ignoring speed will limit their ability to help teams meet stakeholder expectations. This leads to missed opportunities, increased lead time, and decreased competitiveness, rendering their coaching ineffective.
3. Limited Control over Quality and Risk: Teams that don't implement the practices supporting a rapid succession of deliveries will struggle to address quality issues and effectively manage risks. Systematic quality control mechanisms and risk mitigation strategies are essential enablers to consistently delivering high-quality products, hence scrutinizing and optimizing sustainable speed of delivery creates a strong focus on implementing the necessary supporting practices.
4. Inadequate Feedback and Collaboration: Rapid feedback and effective collaboration are essential drivers of agility. The Agile Coach who solely focuses on the Agile Mindset may overlook the importance of technical practices that enable fast feedback cycles and promote collaboration.
5. Limited Adaptability and Agility: Agility relies on an ability to adequately respond to changing market dynamics. Sustained delivery speed, supported by its enabling technical practices, is a powerful leading indicator for the level of adaptability and implementing effective change. Without leveraging practices that support rapid delivery and iterative improvement, the coach may hinder the team's ability to learn, adjust, and continuously improve.

Conclusion

The Agile Coach who neglects Sustained Delivery Speed and its incorporating technical practices, such as Continuous Delivery, is much more likely to struggle in demonstrating significant long-term outcomes. They may miss critical gaps in quality practices, feedback mechanisms, collaboration, and adaptability, thus leading to predictable challenges in meeting stakeholder expectations, driving improvements, and effective agility.

Important: This article consciously emphasizes "Sustained Delivery Speed." Our concern isn't the speed of typing, but the inherent capability of minimizing the time required for turning an idea into a high quality release candidate. Cutting corners to get one shipment through the door will quickly undermine a team's ability to maintain a high pace of deliveries - this tactic always results in incidents and failures which devastate a team's ability to maintain their pace. Hence, sustained delivery speed is an aggregate measurement that requires observing many technical metrics "under the hood," such as build time, build failures, incident frequency, recovery rates, and many others.

What's the value proposition of Agilists?

CapitalOne just fired all of their professional Agilists. They state that Product Managers can just take on Agilist responsibilities on top: Why?

The role of Agilists

Many Agilists think that their role is a subset of:

1. Introducing "Agile" ways of working by training, teaching methods and launching teams.
2. Supporting execution by organizing schedules, facilitating events and resolving impediments.
3. Doing managerial tasks such as monitoring and reporting team health, progress and performance.

Even the people doing these three are often different folks:

• Category 1 folks are a temporary role. It's better to contract them on demand: What do you do with them after everyone has been trained and is working in an agile team?
• Category 2 folks could give senior management the impression that "a Scrum Master is just a Junior project assistant with stickies and Sharpies." Self-organized teams shouldn't need them. They are clearly overpaid, and probably not doing their job.
• Category 3 folks are considered redundant by many developers, there are often also complaints that they're stopping developers from doing what really matters - they're contributing to the problem that "Agile" set out to solve.

When an organization sees agilists as defined by the three points above, all I can say: Firing them all is justified. An entire job family is technically designed for "doing efficiently that which shouldn't be done at all" - is redundant.

They don't have a long-term value proposition.

The Value Proposition

There are three pillars to every company: product development, organizational development and technology development. Scrum focuses exclusively on Product development, and SAFe somehow also blends Technology development in. But who develops the organization?

The real role of agilistas 𝘴𝘩𝘰𝘶𝘭𝘥 𝘣𝘦 in organizational development: build organizational capabilities, and improve systemic collaboration and communication.

Resolving delivery impediments is not enough - the organizational system must be ready today for the challenges of tomorrow: New business opportunities arise, existing business models become obsolete, even entire markets collapse. Having the capability to deal with that is critical to company survival. And yet - few agilists are working on this. Their approach is "hope and pray" that no major disruption will occur, and so they walk like lemmings to the cliff.

Learn about the TOP Structure

The failure of "Agile" roles is can be avoided with the TOP Structure: It gives Agilists a clear, indisputable value proposition, and meaning to their work.

And that's the very reason why every Agilist and manager should be familiar with the TOP Structure. 

Stories that aren't

 Let's take a look at the "User Story Template" (also known as: Connextra Template, by origin) - "As a ... I want ... so that ..." - straightforward enough. It's common in the "Agile" space, and many inexperienced Scrum Masters and coaches learn that teams should formulate their work like this.

The result?

Formally it's correct. It's a "user story" based on the template. 

Now, what's wrong with it? About everything.

Let's leave aside for a minute the fact that this story is as much of an antipattern for "INVEST" as it could be, and focus instead on the use of the template:

1. The "user" isn't a "user". 

If we start calling developers "user", then next thing we know, testers, analysts, and project managers are also "users". It becomes a hollow, meaningless term.

A "user" is someone who actually uses the end product. 

Like ... a Candy Crush user is, for example: the "mother of a small kid who only has 5 minutes before the kids will cry again."

(Of course, developers can be users as well. But that would require them to actually use the product, in which case they wouldn't be a developer, but ... for example, a "mother-of two who sits in front of computer screens all day ..." - if that's your demographic!)

2. The want is a means, not an end

"Wants" should be something that this specific user wants to have and would be willing to use our product for, like "simple and easy fun". No user ever wants a Customer_ref_ID. Maybe they need it to identify themselves, but ... can you name anyone who wants to use a product because it has a Customer_ref_ID? 

Could you imagine running a marketing campaign with the slogan, "We have a Customer_ref_ID" - if not, then you're probably not addressing anything someone wants. 

Take it as a lithmus test for formulating "wants":

If you would feel weird to see it on a billboard on the way to work - it's probably not a proper "want".

 

3. The reason is self-serving and circular.

In more abstract terms, the reason is "so that I have it." - it doesn't explain which problems it solves.  It adds no information. It doesn't help us verify whether we're adding value to the product, and it doesn't help us verify whether we actually need it. It's a fake reason.

Let's, for argument's sake, assume that both the user and the want were valid: we still don't know why you want to refer to the customer by ID, and how that is better than what you're currently doing.

A good reason statement shouldn't repeat the "want", but explain why the "want" is relevant, which problem we're solving, how the world is better after the need is met.

Good reasons invite developers to understand why the user has an unmet need.

Ten dysfunctional Scrum Master patterns

There's a lot of material out there on what a Scrum Master allegedly is and does, although many of the tips are indeed antipatterns that will keep the team from ever reaching top performance. So let's take a look at what a Scrum Master is NOT. Here are ten dysfunctions in the Scrum Master role - and better alternatives!

The nurturing parent

A recurring theme with Scrum Masters who think they're doing a good job while actually achieving the opposite is that they take the role of a parent for the development team. The term "Scrum Mom" has been coined as an antipattern, although the issue goes much further and deeper.

Brief detour into psychology
Let me refer the unaware reader to Eric Berne's book, "Games People Play" for the full mechanics of Parent-Child dynamics. For brevity sake:

Eric Berne suggests that people are always in one of three so-called "ego states" - Parent, Adult or Child. Transactions among adults or between parent and child are "stable". Others are "crossed" (i.e. broken / unstable). Consequently, by assuming a "parent" role, one pushes others into a "child" role and vice versa.
The more frequent this happens, the stronger a parenting Scrum Master will instill childish behaviour and attitude within the organization!

The blue transaction among adults is "stable".
The crossed brown transaction is unstable - the trigger doesn't match to the response!

The Pamperer

To paraphrase Atlassian, the Scrum Master may want to do any kind of thing that's required to get the team to hum - fixing hardware, changing room temperature, bringing coffee and whatnotever.
This brings us into the "I'm only trying to help" game described by Berne: Team members get used to absolving themselves of taking care of their own basic necessities.
This eventually brings the Scrum Master in a defensive position: They constantly have to guess what other people need, and if anything goes wrong, developers might turn against the Scrum Master with blame.

Adults find taking care of their basic needs part of their own identity, and will enjoy an environment where they can do this by themselves: It instills a sense of autonomy and control.
The Scrum Master should get NEAR to the team, help them become aware of their own needs and build an environment where people can meet their own need with little effort.

The Protector

A common misconception is that the Scrum Master should cotton-wrap the team in a cozy little bubble, safely protected from "the mean outside world" so that developers can focus on writing software. This creates two separate issues: First, developers lack the interactions and understanding to figure out what's going on around them. Second, it creates another unhealthy mechanic: Dependency. Developers become unable to cope with the surrounding organization, relying on the Scrum Master.
Again, the Scrum Master ends up fighting a losing battle: If they do a perfect job, everyone will push organizational issues on them - and if they make the slightest mistake, they will be blamed for inadequacy.

The Scrum Master's responsibility is to educate people - both within the team and around - which interactions are helpful and which aren't. Avoid the trap of buffering these interactions. Unhelpful interactions cause conflict, and defusing this conflict is part of the growth process. Learn conflict resolution techniques.

The Facilitator

Yet another common misconception is that the Scrum Master has to organize things for the team - such as, when meetings take place, who is invited and what the agenda is, then to facilitate the show. This is just a specific form of pampering - developers assume that the Scrum Master knows best (sly "Tangled" reference) about meetings.  Continuously organizing or facilitating meetings is not a Scrum Master responsibility, lest we fall into the "TAGAWI" game where meetings won't be held if not for the Scrum Master. Especially new Scrum Masters will not realize that they're falling for a game and thus are very likely to lose.

The Scrum Master's responsibility is educating developers initially why and how to conduct Scrum events like a Retrospective, so that they can learn the importance of these meetings and how to make them valuable. Instead of organizing meetings, the Scrum Master is well advised to let developers take this responsibility and help them sustain this practice.

The decision maker

In many organizations, a Scrum Master may make decisions either as a surrogate manager, a spokesperson or as representative of the team. While it's valid that the Scrum Master represents a decision that has already been made, the Scrum Master is not a decision maker!

The Surrogate Manager

When teams move to self-organization, they may occasionally feel lost, because decisions that were made by others for them now lie with the team. As such, they might look to the Scrum Master to fill this decision gap. It does provide a sense of safety and comfort to let others make decisions in times of turmoil - even if that decision is wrong, the responsibility rests elsewhere. Long story short, if the Scrum Master caves in, they fall for a parent role, stopping the team from becoming truly self-organized.

The Scrum Master might want to explore with the team "Why" the team wants the Scrum Master to make this decision and "What" will happen as an outcome. By facilitating the right discussions, the Scrum Master empowers the team to make their own decisions and live up to it - propelling self-organization!

The Spokesperson

Developers may also ask the Scrum Master to fetch a decision that rests elsewhere in the organization. Terrible Scrum Masters will assume that they can make a decision instead, which will put them into the worst possible position: if they get it right, they still usurped another person's position, if they get it wrong, everyone will blame them.
Bad Scrum Masters will run off diligently to find out from the decision maker. They just fell for a game: the team plays the "helpless child" and looks to the Scrum Master for a solution.

Rather than acting as an intermediary, the Scrum Master should build networks of people, connecting others directly. If needed, the Scrum Master may need to act as a facilitator in meetings so that a mutually acceptable solution can be worked out.

The representative

In a video by Atlassian, they suggest that the Scrum Master should represent the team in backlog refinement. While it's okay for the Scrum Master to represent a specific decision the team has already made, the Scrum Master lacks the understanding of content and technical background to communicate details on behalf of the team. As such, the Scrum Master is always guessing and still likely to make mistakes.
It's very misguided to believe that a non-technical person can decide on technical details, and the details are what makes or breaks the outcome. This sacrifices effectiveness in the name of "efficiency", turning teams into "delivery factories" (another parent-child dynamic).

When teams keep out of meetings which provide an opportunity to acquire essential information and provide essential feedback, there is probably a strong parent-child dynamic at work - either developers are being pressed into a "child mould", or they are themselves in child mode and press others (for example, management or the Product Owner) into a "parent mould".

The Scrum Master should carefully examine why this is happening - oftentimes due to fear or negative organizational culture.

The bouncer

I cringe whenever I hear that a Scrum Master should act as bouncer, shooing people away from the team. Why? Because people have needs. When others feel the need to interact with the team and get called off, this will most likely trigger resentment and other negative emotions which will eventually have a backlash. Acting as a bouncer, the Scrum Master creates two separate parent-child dynamics: Towards the team (sheltering) and towards the outsider (controlling communication).

The Scrum Master should get NEAR to the approaching person, then learn why this need exists and how it can be met. One-on-one interaction can build a more positive working environment and may lead to different solutions than what the approaching person originally intended.

It's incredibly important for the Scrum Master to help others, irrespective of whether within or outside the team, to find ways to meet their needs on an "Adult" level.

The Ambassador

Occasionally, the Scrum Master may be asked or feel tempted to represent the team towards outsiders, so that the team doesn't get interrupted. This makes the Scrum Master a filter of information and a translator, both of which can become incredibly dangerous.

What a Scrum Master may do is have first discussions to see if the interaction is indeed helpful for the team and the organization, and if this is the case, they should bring people together directly in the most effective way.

Further reading

I have hinted at the book "Games people play" by Eric Berne.

Other books in this context are:

• TA Today by Ian Stewart and Vann Joines.
• Transactional Analysis in Psychotherapy by Eric Berne.
• I'm OK, You're OK by Thomas Harris.

Note that the reading of these books will not make you a professional therapist or psychoanalyst, and I strongly encourage you to stay out of trying to do therapy or wielding this knowledge as a tool - although understanding these things gives you a much better understanding of what's going on. 
Do NOT, and I can't emphasize this enough, do not start calling out transactional dynamics within your team or use TA interventions loosely. You're going to leave a trail of devastation.
Much rather, I invite you to silently reflect on how you are contributing to the situation and what you yourself can do to improve.

What every Scrum Master needs to understand about Development

Not every Scrum Master is technical. Indeed, some of the best Scrum Masters I know have a sociology or psychology focus - so it's all fair and square to say that they're don't know how to develop code. This may (or may not) pose a problem depending on how advanced the team's engineering practices are: you can't get the team to deliver sustainable value when they don't know how to do that.

At a minimum, the Scrum Master should to realize whether the team is aware of what they're doing - and if they aren't, bring in a technical coach or senior developer who can teach the team the ropes. There are many nuances, and a non-technical person will not see everything. Once developers are on the right track, they can very well figure out where they need further help.


tl;dr: of all the categories below:
Absence of the practice causes delay, incurs cost, reduces stakeholder satisfaction and may kill the product (and in smaller organizations, the business!)

Here's what to look out for:

Automation

Phrased positively: If we do indeed automate everything that can be automated, we gain a much better understanding of what's actually needed to get something to work. Automated activity also frees developer's heads for doing new work rather than repeat activity. Everything automated can be tested, so we can test not only the software but also the meta-processes, bringing quality to another level. We create repeatability, reliability and confidence in the processes.
Plus, we eventually save time.

Dead giveaway? Team members have paper (or electronic) documents for standard activities they do all day.

Constant Refactoring

Refactoring should be a day-to-day activity as part of regular work. Every line of code should be refactored as soon as it becomes necessary.
Deferring refactoring will eventually put product development to a screeching halt, which can be fatal for smaller companies. I have seen products die entirely because one day, developers discovered that new features couldn't be integrated any more without breaking something else.

Dead giveaway? Developers complaining about code quality.

Unit Testing

Over the months/years, code will become more and more difficult to maintain unless there's a decent amount of unit tests. The time it takes to make even minor changes will explode in the absence of good unit tests: What might take seconds with unit test coverage could take weeks in untested code.

Dead giveaway? The "tests" folder in the repository doesn't get updates with every new version.

Continuous Integration

Problems in the codebase are often not visible until the latest version of the build (which must be subject to automated tests) has been validated. In highly complex environments, changes to one part of the code base may break other code, which will become visible only when those pieces play together. The risk of this happening increases with every change made. As developers do multiple things sequentially, the effort of locating the root cause of an issue becomes increasingly difficult to uncover with passing time, and every change ("fix") to an unstable codebase will amplify the problem.

Dead giveaway? Developers call things "Done", and there's no Working Build for it yet.

Code Smells

You don't need to be a developer to discover "code smells" which will eventually become a problem.

 Some of the most obvious code smells are:

• "Mountain Ranges": The code, rotated 90 degrees left, looks a whole lot like a mountain range. Such code is too complex to be feasibly testable
• "Copy+Paste": Code that looks eerily similar multiple times over or developers who outright say that they develop by copy+pasting existing code segments, then modifying them, produce code that eventually becomes unsustainable.
• "The Gigabyte Class": A class that is unusually large will eventually become a problem. As a rule of thumb, a class with more than 5000 Lines of Code is probably fishy. YMMV.
• "Treasure Hunt": When you see developers moving across myriads of classes all the time to understand what's going on, there's probably a code structure issue.

There's tons more of code smells, but these are the most common to see when developers don't know how to create Clean Code.

Dead giveaway? Developers don't understand code produced by other team members.

The Management-Coach clash

When an agile coach or Scrum Master is brought into a traditional line organization, there is a high risk of misunderstanding and clashing, oftentimes leading to frustration. Why is that so? Let us explore the traditional expectations towards different roles.


Upton Sinclair said it all with his famous quote:

It is difficult to get a man to understand something when his salary depends upon his not understanding it.

As I had these discussions multiple times in the past, here is a short diagram to illustrate what causes the clash. We will explore below:

Asserting authority

Managers get paid to be in control of their domain. When things aren't under control, they are expected to bring them under control. A good manager is expected to be able to state at any time that everything happens according to their provision, and nothing happens that wasn't agreed beforehand.

A consultants' authority is granted and limited by their hiring manager, and the consultant is expected to exercise their authority to drive their specific agenda in service of their manager.

A coach doesn't assert authority over others, and won't drive a predetermined agenda. Instead, a coach helps people realize their own potential and freely choose the course of action they consider best - although clearly within the scope.

And that's where coaches and managers clash:
Managers might think that coaches will exercise authority over the team and thus be sorely disappointed when they see that the coach isn't in control of the team's work, and the coach will be sorely disappointed when management reveals that they think the coach is doing a crummy job for not taking control.

Solution focus

Managers are expected to have a solution, and do whatever it takes to get one. The proverbial statement, "Bring me solutions, not problems" is descriptive here. When higher ranking people within the organization ask a manager about something within their domain, the only appropriate answer is either "This is our solution" or "We are working on a solution."

For consultants, the only appropriate answer is "This is the solution", or maybe "I need x days and then I will give you the solution"

Coaching is an entirely different book: "The solution is within you. I will help you find it." - maybe the coach does have a clear understanding of the solution, maybe not. This isn't even relevant. Important is that the coach guides others in finding their solution.

And that's where coaches and managers clash:
Managers might think that coaches are problem solvers. With this expectation, either the coach should take proactive steps to install a solution before the problem occurs or immediately resolve any issue once it occurs.
Looking at the flip side of the coin, the coach may argue that they can't work with managers who always look to the coach for the solution and aren't willing to spend time and reflect on the situation.

Getting people to think

In traditional management, managers are considered intellectual, "thinkers". Their job is to think, so that others can do. (Let's ignore for argument's sake that most managers' calendar is so cluttered with appointments that they have zero time left to think.) Statements like "This is above my paygrade" are epitomes for a corporate culture where thinking is considered the responsibility of management.

A consultant has a higher self-interest in getting some people to think - at a minimum, the hiring manager should put enough consideration into the consultant's proposal to understand how their solution will affect the organization, preferably in a beneficial way.

Coaches take another stance: Ideally, they encourage others to think by asking probing, critical questions and being skeptical about other people's solution - in order to help people get beyond preconceived notions and think in wider horizons. The more thinking a coach does for the organization, the less sustainable the solution will be once the coach leaves.


And that's where coaches and managers clash:
Managers might expect the coach to use their free time to think of better ways of doing things and then come back with a clear list of improvement suggestions that just needs to be ticked off.

A coach might not do that, which neither means the coach is lazy nor that the coach isn't smart enough to do that: The coach will have a number of items in mind that need to be worked on, and help the organization get to these points one by one, when they are ready. Maybe the only thing management sees is that coaches asks a few key questions so that people will think about what's really going on and which systemic changes will improve the situation.

Defusing the conflict

Misalignment of expectations is the main cause of frustration between coaches and management. Early and frequent communication helps. Coaches need to understand how managers tick, what they get paid for and what they expect. Likewise, managers should be cautious about hiring coaches before they understand how a coach works.

For a manager, it's okay to get a consultant rather than a coach, and indeed that may be better than hiring a professional coach and expecting them to work as a consultant. It's also okay to tell the coach to tone down on the coaching and dig more into consulting.

For a coach, it's okay to start a serious discussion whether coaching or consulting is more congruent with management expectations, and propose switching into a consulting mode as fit. It's also okay to tip your hat and take your leave when consulting isn't what you expect to be doing.

It's not okay to get angry and blame one another just because we don't understand each other.

Finding fertile soil for coaching

There are hundreds of poorly written job offers for "Scrum Masters" or "Agile Coaches" out there - mostly because clients don't understand what they should be looking for. And who can blame them? Why would they need you, if they did?

It's not Cockaigne

I have talked with numerous "Scrum Masters" who require that a Scrum Master job ad be written properly to represent the role of a Scrum Master as based on the intention of the Agile Manifesto and healthy Scrum. They already screen the job interview for any hints that the organization may not be agile and disengage at the slightest hint that the company "doesn't get it".

In my personal opinion, these people are cherry picking. A very important part of being a Scrum Master is creating a healthy Scrum environment - to expect that it already exists means taking the easy route.

And since life isn't a bed of roses, even seemingly perfect environments have challenges.
I heard the personal stories of Scrum Masters who were sorely frustrated upon being confronted with un-Scrum-like elements in their organization and having to deal with people who interefered with team autonomy. Those stories make me wonder: "What did you expect?"

There will be challenges. There will be mindset discrepancies. There will be arguments. And that is part of the job.

Good descriptions can be bad jobs

There might be a huge discrepancy between written words and unspoken expectations.
Here are just some examples of hidden pitfalls:

• "Guide the team in their self-organization" could mean "Track who does what, when and how long it takes"
• "Establish agile ways of working" could mean "Enforce adherence to the 'Agile' Jira workflow"
• "Help people adopt an agile mindset" could mean "Developers need to work faster and harder".

And that's just the tip of the iceberg. Below lurk further dangers:

• Your influence is limited to the team
• Rigorous adherence to rules
• You're expected to optimize for efficiency or utilization
• The need for supervision and control
• Pressure to meet quota

All of these are serious concerns, yet nothing to be afraid of - there are problems everywhere, so why should any specific company be any different?

A good basis

As agile coach, change is your job - you just need to be aware when you're fighting an uphill battle and are up alone versus an armada. In some cases, steering clear of a confrontation is better than running headlong into your demise. So, how do you know the difference?

It's about people

"People and Interactions over Processes and tools" - for none is this truer than for an agile coach. Take a note of how people behave in their interaction with others.

These character traits from members of the organization are hints that existing problems and challenges can be overcome:

• Trust: Invite and extend trust to and from others. Build networks of trust.
• Humility: Able to admit that not only things, but also they themselves aren't perfect.
• Kindness: Reach out in a generous, open-hearted way.
• Openness: Share and receive ideas.
• Accomodation: Give people a break for being in situations beyond their control.
• Consideration: Take care to minimize inconvenience for others.
• Curiousity: Ready to try out something completely different, even when the outcome is unclear.
• Mindfulness: Willing to consider cause, effect and circumstance.

As a counter-indicator, when these character traits are either absent or even exploited within an organization, this will pose a challenge that won't be overcome by a single Scrum Master.

Summary

The importance of human virtues and relationships in picking the right place to make an impact as a Scrum Master should not be underestimated. Forget the job descriptions and have a conversation.

Shift the focus away from what people currently believe about how Scrum should look like and take a closer look at the character which people within the organization exhibit.

Coaching and change are much easier when there are positive character traits visible. At the same time, when these traits are compromized, there's a massive chance that coaching will not have an impact and no change will happen.

Don't try to help everyone. Pick the people who are willing to receive it.

Addendum

A very good article with good interview questions a Scrum Master / Agile Coach may want to ask can be found here:
https://www.toptal.com/project-managers/scrum-master/5-scrum-master-questions

The 5-minute Retrospective: Try Speedrospectives!

Agility depends on receiving timely feedback and turning it into effective change action. Relentless improvement requires closing feedback cycles wherever possible and whenever possible. 

Why Speedrospectives?

Many new Scrum Masters follow the boring, time-consuming and ineffective "What went well/what didn't go so well" template and can burn hours of precious team time without causing significant change - this model often degrades to a platform for self-adulation and/or ranting.

The Scrum Master -- or any agile coach, for that matter -- should create a self-perpetuating system of Kaizen, "Striving for the better", and do this in the most effective way.

Have you considered a Retrospective after every single meeting in your organization, to improve these meetings themselves and thereby increase the value of communication? How much time should that consume to be worthwhile?
A regular Retrospective is unfeasible in this context - but where, when and how do you address improvement potential then?

An important part of behavioural change is to address the situation as it occurs so that the memory is still fresh and set the stage for a future, more desirable condition.

The 5-minute Retrospective

When you know your audience and the situation is already stable, there's no need to go through the (definitely helpful) 5-stage Retrospective Process, you can just cut straight to the heart of the matter: What should be different next time in order to get more value?

And that's where my handy Speedrospective template comes into play:

The diagram itself is self-explanatory:
"If we do this again, the next time, we should ..."

• Try: Introduce a new element or modify an existing element. For example, in a Retrospective, it could be: "Try whiteboards instead of sketching on letter-sized paper"
• Stop: Elements which should not be repeated. For example: "Multiple people talking"
• More: Elements which are helpful and could use strengthening. For example: "Collaboration on issues"
• Less:  Elements which, although helpful, are overdosed. For example: "Process explanation".

Schedule of the Speedrospective

Create sketch

If you're fast (which is what this is about), you draw an X and write 4 words. That should just take half a minute - or a minute, while you're explaining what's coming. (1min)

Collect items

Take 2 minutes to collect feedback - more time isn't needed, because if participants don't have anything on their mind, it's probably not important, anyways - and next time around they might prepare a sticky right in the moment when something happens because they know they can bring it up. (2min)

Decide

After issues are collected, vote ONE the group would like to see implemented. (1min)

Debrief

Agree how to make it happen and thank the group. (1min)

Summary

Speedrospectives are a highly effective tool to close feedback loops, initiate change and establish a culture of relentless improvement. The process is significantly more powerful than the "well/not well" template, because it's fully outcome focused.

Other uses

The suggested Speedrospective template can be used in many contexts, such as event closure - as well as in personal and organizational coaching.

Variations

There are many ways to commence a change-driving Retrospective within 5 minutes. The above approach is neither to be considered prescriptive nor the only way. Try experimenting with Speedrospectives and see what works for you.

A note of caution

Speedrospectives may miss fundamental change opportunities - for example, when we're having the daily frontend architecture status meeting, we will find ways of getting the most value out of this meeting without ever crossing the idea that the meeting itself isn't a good idea. They are not a panacea, just a simple power tool to support a continuous change mindset.

The Scrum Master role

What's a Scrum Master - what do they do all day?
Many companies seem to have trouble identifying the proper role for the Scrum Master, their job descriptions already hint that they're looking for something other than a Scrum Master, which implies that a successful hire is unlikely going to help the team succeed with Scrum.

What's not a Scrum Master?

A Scrum Master is definitely not a rebranded management role in any form or fashion. They are not available to help managers retain command or control of the Scrum team. Their role is not intended to do any work either on the product or on the process. They also are not a secretary or a kind of errand person for the team.
Also, contrary to popular belief, the Scrum Master is in no way responsible for the delivery - neither in terms of quality, nor quantity.

Even terms like "Evangelist" or "Enforcer" might hint at behaviours a that could cause potentially detrimential behaviour.

A Scrum Master's power, as odd as that sounds, comes from not having any power. By empowering the Scrum Master in any regard, they lose this superpower.

Then what is a Scrum Master?

As hinted in another post, a Scrum Master's responsibility is primarily the people and their interactions - helping the team focus on their goal, deliver effectively and support the resolution of impediments towards higher performance.

Most notably, a Scrum Master would create transparency, visibility and thereby awareness of key impediments more than they would actively resolve them. Why? Everything the Scrum Master does reduces the learning effect of the team or the surrounding organization.
In knowledge work, learning leads to understanding, which then becomes the baseline for performance. Therefore, the main responsibility of the Scrum Master is to make learning happen.

In one sentence, the Scrum Master is a "Learning Maximizer".


To support you, here is a list of traits that you might want to be on the look out either in being or in choosing a Scrum Master:

Not helpful	Helpful
Project Manager	Help management change from moving teams to work towards moving work to teams
Release Manager	Assist Product Owner and Developers in defining and tracking releases
Delivery Manager	Remind the teams of their responsibility to deliver
Process Manager	Reflect on the process
Team Manager	Remind people when they break their Working Agreements
Problem solver	Support the team in solving their problems
Scrum Evangelist	Teach Scrum in and around the team
Meeting Organizer / Moderator	Help the team have effective meetings
Technical / Subject Matter Expert	Expert in regards to Scrum, change management, coaching
Jira Admin	Support the team in discovering and using appropriate tools
Bouncer	Help people realize which interactions aren't helpful
Enforce Scrum	Remind people when they break Scrum
Track team‘s progress	Support the team in making progress transparent
Produce reports	Create transparency
Threaten, manipulate, coerce	Encourage the team to do their best

To wrap it up, here's an illustration of what a Scrum Master does or doesn't:

Agility isn't for everyone!

A lot of conflict in the workplace is caused by different expectations regarding the nature of the work. And agilists may not even be helping - they might just make it worse!

Here's why:

The Stacey Matrix - annotated with character traits.

Character traits per domain

Simple work gives confidence to people who excel at tasks that others may consider "chores". Although workplace automation has abolished a lot of simple work, there are still areas where well-defined, routine processes are commonplace. The most important characteristic to success in this domain is diligence - getting stuff done properly.

Complicated work rely on getting multiple pieces of work executed correctly and in proper sequence. This requires good coordination - putting multiple pieces of the puzzle together in the most effective way.

Complex work means that there is no one known best way of doing things, and there is no one specific goal to attain, either. Even though most of today's knowledge work occurs in this domain, people easily get irritated when they "just don't know" and still need to product results. The essential trait here is creativity - coming up with a solution in the face of the unknown.

Chaotic work occurs when there is no clear-cut way of doing things. Many people feel challenged working under such conditions, as the constant barrage of new information often invalidates former achievements. Resilience and a high amount of flexibility helps - changing direction whenever it makes sense!

The problem with "Projects"

The complex and chaotic domain are the places where projects crumble: The base assumptions of the project fall apart as soon as people start doing work. The coordinative ability of the Project Manager are of little help when the tasks to coordinate aren't helping achieve meaningful goals. Likewise, the most diligent worker isn't helping the company when the work isn't even going in the right direction.

It's extremely difficult to run a development project with the premise that project management is merely the meta-task of coordinating development tasks, as nothing would need to be developed if everything was clear to begin with.

A lack of flexibility often causes projects to fail in a sense that the outcome isn't needed when the project is done.
Likewise, a lack of creativity often causes projects to turn Red - objectives can't be met by following the plan. In unfortunate cases, the only creativity on a project team might be the project manager's ability to find excuses for the poor outcome.

Unless projects have people who exhibit the flexibility to deal with new information - and the creativity to do without proper processes or still do something useful when goals become invalid - the project is in trouble.

The problem with "Agile"

"Agile" dogma often seems to presume that all work requires flexbility, and that all workers are flexible.
Both premises are invalid. Not only are flexible, creative workers a rarity rather than a commodity - working in this domain should be an exception rather than the norm.
Creativity is often needed to pull unknown stuff into an area where slices of known work can be coordinated and executed, but that work still needs to get done.
Highly flexible people often enjoy the streaks of chaos that allows them to innovate - and they may not enjoy the grind and routine of doing the base work.

In a healthy team, there has to be a place for people who are diligent, for those who are good at coordinating stuff, for those who are creative - and for those who enjoy the whimsiness of the Unknown. Put together, such a team can be extremely effective.

Summary

We need to respect that not everyone is creative and that some prefer routine - and we need to respect those who can't bear routine work and their drive for change. And we are well advised to neither compare nor mix up such work: it's just too different.


Try discovering where people see their favorite work and help them find their place accordingly.

Avoid creating a culture where people enjoying only one type of work feel left behind. It might create a dangerous monoculture!

Want trust? Deal with fear!

"Fear is a bad advisor!" - proverb.
Positive working environments require trust. Trust can be given and earned - it can't be forced or demanded. Team building workshops often focus around building trust. Are they dealing with the symptom of distrust, though?

Here is a causal loop diagram modeling the relationship between trust and fear:

Red lines = dampening effect, blue line = strengthening effect. "=" sign = time delay

There is a direct relationship between trust and fear: Fearful people don't trust. Trustful people don't fear. Then, how do you get from A to B? It's not as easy as extending trust, although that helps.

The vicious circles

In the model, we see three different vicious circles which need to be broken almost simultaneously before trust can be established. I also hint a way to break these vicious circles.

Blame Games

Starting on the top left, the most visible fear cycle is related to Blame. Nobody likes to be blamed. Being afraid of blame, people hide their mistakes. in consequence either finding someone else to blame ("But you said ..." - "X told me...") or, when caught, receiving blame. Positive management must end blaming people. Blame helps nobody. Identifying someone responsible should never be aimed at having someone to blame, it should always be aimed at finding a way to change things for the better.
As coach, I have even resorted to the rather ridiculous tactic of saying "Ok, it's my fault. Now, how can you make sure it doesn't happen again?" - of course, it's ridiculous that it's my fault. That's not what matters. What matters is that the discussion about fault ends and we start talking change.

Coverups

The next vicious circle is related to information hiding. It's much harder to spot, as one can't know what one could know but doesn't know because it's being kept secret.
It takes a lot of sleuth work to put missing pieces together and discover where people are covering up inportant information revealing what is really going on. Why do people do this? Often, they either don't trust what will happen when uncomfortable facts are revealed - in which case it's a trust issue, or they know what will happen and don't like that - in which case it's a fear issue.
People wouldn't be afraid if failure was not perceived as a stigma with negative repercussions. Establishing a positive failure culture, "Hooray for failure" can go a long way. Just make sure that this Hooray is then hooked up with real learning and change - otherwise, a team member's trust in the team can turn into an outsider's distrust in the work of the team.

Choking Control

The third vicious circle is related to controls. Be that meetings, reports, supervision or checklists. While every single of these isn't necessarily bad, in sum, they can devastate people's ability to think, act and change. One control may be no issue, a hundred controls make it impossible to change anything - and simultaneously, often create a self-contradictory system where at least one control is always broken. People are constantly afraid of breaching control and spend more time on meeting control requirements than on doing actual work which helps the organization.
Managers stop trusting their employees when controls are broken, and employees stop trusting their managers when broken controls don't lead to more effective ways of working, but more controls. At worst, managers also stop trusting their controls when these prove ineffective and load yet more controls to control the controls.
Creating transparency what is truly going on and which processes are actually enforced by these controls can go a long way in abolishing their destructive force and minimizing control to truly helpful levels.

Conclusion

"Don't fear" or "We can trust one another" are hollow slogans. These don't help anything. "Building trust" without understanding the vicious circles and loopback dynamics leading to the low levels of trust we often observe in organizations.
The main lever for raising trust isn't simply building trust, but alleviating the fears which constantly chop at any small flower of trust sprouting up.

As coaches, we must understand both the fear dynamics and the fears driving people. Only then can we build the trustful environment needed to succeed.

What is a Scrum Master?

The question, "What is a Scrum Master?" may sound easy to answer - RTFM, the Scrum Guide has a very concise section. But when looking at what a Scrum Master really does, it becomes a profound topic in and of itself.

The narrow definition

The most narrow definition is that it's the one person on a single Scrum team making sure the Scrum Guide is being followed and the team successfully delivers on their Sprint Plan. Most people work in organizations that think of this narrow definition and also behave likewise.

For people looking to move into such a role, the best starting point is reading the Scrum Guide, getting a few books (such as Geoff Watts: Scrum Mastery) and a certificate or two (PSM-I from scrum.org or CSM from Scrum Alliance come to mind) then start job hunting and learning on the job.
Sticking with the narrow definition is not a very fulfilling job, as systemic impediments never get addressed.

The broad definition

The most broad definition is that it's a person coaching an organization on becoming more agile, challenging existing paradigms and opening the way to more flexibility, and this means individuals, teams and managers on every level - from intern all the way to senior executive.

People

When it comes to being a Scrum Master in a broader sense, then Scrum is maybe 5% of the picture. In fact, Scrum itself will become less and less important and - just like the Agile Manifesto states - people and their interactions will become prevalent.

Agile Frameworks

The first thing you will need to explore is the other agile frameworks, starting with the team-level ones such as Extreme Programming and Kanban - and getting yourself familiar with the organization-level ones such as SAFe (Scaled Agile Framework), Nexus, LeSS (Large-Scale Scrum), DAD (Disciplined Agile) and S@S (Scrum at Scale). Of course, that doesn't mean you will be using all of these - but you should have a sufficient understanding to comprehend where they are useful and what their limitations are.

Management

Having a bag of agile theory under your belt, you need to move into organizational design and management by reading publications from authors like Drucker, Deming, Crosby, Taguchi, Taylor etc - and learning to compare and recognize their models.

Psychology

You will also want to explore the field of psychology to understand how and why people tick the way they do. That's a vast field, where you might want to reach into behaviouristics and conditioning (Pavlov, Skinner), emotions (Ekman), basic needs (Maslov), negotiation models (Ury), transaction models (Berne), habits (Duhigg) and many others.

Philosophy

To round this off, you may want to gain a deeper understanding of philosophy, which also has a lot to offer, with the most notable things you may want to get being logic (assumptions, fallacies, mental models), axiology and epistymology.

Economics

As the subject of how wealth works - i.e., how value is created, consumed and transferred, there's a strong correlation towards making a company successful: you have to learn how decisions are made, why agents interact the way they do, and what are the driving forces of an economy (both local and global.)

It's not very useful to do all of this upfront, but continuing to learn while you're on the job and working to continuously increase your sphere of influence within the organization.

Summary

The Scrum Master is a very deep role which, when taken with a deep, serious learning attitude, has a lot to offer and provides a tremendous field for growth. If you put your heart into it, you will reach tremendous awareness of and influence on your surroundings.
Don't let people tell you that a Scrum Master is "just a team role". Great Scrum Masters can make a massive impact on their organizations.

Five Things to avoid as Scrum Master

What makes a good Scrum Master, what makes a bad Scrum Master? Here is my short list of things a Scrum Master will not do in my team. This post is written from a Product Owner perspective, so YMMV.

#1 - Dogma

This has got to be the absolute #1 on my list as it is my personal pet peeve.
I don't care what this or that guru said about Scrum, and I don't even care what you think Scrum means. I'm not using Scrum for Scrum's sake. I care for stuff that works - and for fixing stuff that doesn't work. I've had too many conversations with certified ScrumMasters who claimed "According to Scrum ...", and my only response was: "Show me the passage in the Scrum Guide!" (knowing full well they were proliferating a myth). If you can't explain to me (or my team) why the things you think should be different would work better than what we're currently doing, you're wasting everyone's time.

#2 - Factions

Your job as a Scrum Master is to create one high-performing team, and that just won't work if the team is wasting energy fighting against others (or even worse, against each other). If factions exist, you should try to mend them - and if none exist, I would expect you to be the last person to create some. Factions often come with actions such as placing blame (aka. finger-pointing) or perceived feelings of superiority. I expect you to not tolerate, much less support any such behaviour.

#3 - Menial labour

Also known as the "Jira Admin". If your entire responsibility in the team boils down to doing the things nobody else wants to do, such as updating tickets, writing reports or organizing meetings, you have clearly not understood your role. As Scrum Master, your value is exclusively limited to the additional performance you bring out in the team. If you can get 5 people to work 50% more effective, you're pulling your weight. If, however, you're just doing work that a minimum wage worker could do after a week of training, don't expect a higher pay than minimum wage.

#4 - Breach of trust

As Scrum Master, I expect you to be the person in the team who has the highest level of trust from anyone within the entire organization. I would expect that people should feel ready to confine their innermost secrets to you, even stuff that's totally NSFW, because they might need someone to talk about it in order to have a clear head for work. If you do stuff like reporting to management or tell team internal information to outsiders, you will never again be able to regain the trust you need in order to do a proper job.

#5 - Project Management

I do agree that not every team is ready for self-organization and sometimes, an intermediary path needs to be taken. As Product Owner, the person who would be doing inevitable PM activity would be me. As Scrum Master, frankly, you don't even need to know more about the team's progress than I and the team feel necessary. There is no reason why you should feel the need to coordinate, organize or report anything for anyone. Well, unless you're being asked to - and even then, you should ask "Why?"

Conclusion

If I see you, my Scrum Master, doing any of the above things, you're up for a long conversation with me regarding your role and responsibility. You will walk out with a clear list of things that you will change about your own behaviour as soon as possible.
If I see you continuing these things against better knowledge, I will make sure that I get a Scrum Master on my team who knows their ropes.

How do you identify a proper agile coach?

One of my personal pet peeves is the huge amount of "imposters", i.e. self-proclaimed, potentially even certified "Agile Coaches" who are jumping into a high-demand market.
The problem they cause: Not understanding what a coach even does, how to properly coach - nor what the intended outcome of coaching is supposed to be, they ruin teams rather than establish them.

A year ago, I myseld would have gotten a decent score on this list, and even today, I'm still learning. It is through my contact with a few select, truly inspiring coaches that I have learned the difference.
If you think you're a coach, you can use this list to reflect. If you are looking for a coach, this list is a non-extensive (potentially growing) list if things you want to look out for. Careful: A job interview may not be when you discover the signs. I observe my peers at agile conferences and meetups - and thus, this list was compiled:

How do you identify bad coaches?

When you notice these things about a "coach", proceed with utmost caution:

#1 Doing what the client asked

Most companies need agile coaching, because they don't know what agility is - and most likely also have little understanding on the power of growing people. As such, these clients can not be expected to understand where specific demands they utter are supportive or detracting agility. The agile coach should remain true to their role and also work with the very people who hired them, even when that means correcting the initial mandate.

- The Client doesn't need what they ask, but what they don't know.

Question: How can you understand the difference between what the client says and really needs - and how to get there?

#2 Calling Agile a method (or: process)

Many companies look towards "Agile" in the hopes of obtaining a better software development process. The "Agile umbrella" contains a whole bunch of methods, tools and techniques for improving both the way and outcome of development. Clients may believe that by changing the structure, adopting new roles and using new techniques, they will be agile. Bad coaches will go about doing exactly this and never realize that the systemic problems are caused by a philosophy that isn't consistent with agile development, therefore - never solving the root cause. The consequence? Yet another cargo cult. Lots of fuss, little benefit.

- Agile requires a mindset shift

Question: Can you identify the main reasons that might interfere with a new process doesn't yield benefits?

#3 Agile is considered a goal

Agility can never be a goal in and of itself. It's context sensitive and has to depend on the company's optimization goals. For example, agility in a fast-paced environment would look completely different from agility in a safety-critical environment - as agility accomodates the needs of the business, customer and market. It is merely a means to become more successful. "Being agile" isn't successful when the company can't meet the market demands.

- Agility is a means, not an end

Question: What is different once your client "is agile"?

#4 The Silver Bullet

Let's take, for example, Scrum. Scrum makes a lot of implicit assumptions on the team's environment for the team to succeed. When those assumptions aren't met, Scrum may potentially lead to disaster. Coaches need to be aware of what the success factors are, and then either first work to enable the conditions or choose an approach that is compatible with the current reality.

- Solution agnostic adaption

Question: How do you know that your approach will succeed?

#5 Preaching dogma

When you have a pressing problem in your organization, the last thing you want is a religious sermon on how you're not adhering to whatever dogma the coach subscribes to. This can get very irritating when the coach is unable to connect the current situation you are in with specific, actionable measures that will help you out.

- You need a pragmatic way forward

Question: How do you turn ideals into results?

#6 Hypocrisy

Advice given by coaches is doubtful when you don't see the coach themselves doing the very things they advise. The worst thing is "special pleading", claiming that they are exempt from the rules they want others to follow. The peak of hypocrisy is reached when they are pleading special on absolutes, for example: "Everyone must..."

- "Dogfooding" also applies to coaches

Question: Are you applying your approach to yourself?

#7 Narrow-mindedness

“Whatever the mind can conceive and believe, it can achieve.” - Napoleon Hill

Different thinking leads people to different conclusions. Speaking in terms of "right and wrong" becomes extremely difficult for an open-minded person who considers others' perspectives equally valid to their own. The faster a coach is in making statements like "No", "Wrong" or "Bad", the more likely they are narrow-minded. 

- People have reasons for their thoughts, words and actions.

Question: Will both participants leave the conversation with a sense of a broadened horizon?

#8 Preconcocted solutions

Maslow's "Law of Instrument" or "Golden Hammer" is a cognitive bias indicating that when you know only one way to approach a situation, you will rely on that way - regardless of whether it's a good idea or not. Similar to narrow-mindedness, the inexperienced coach will throw the one solution they know at the problem and hope that works out.

- Explore multiple feasible solutions before stepping into the solution space

Question: What will you do when you can't use any of your "Golden Hammers"?

#9 Change Push

Sustainable agile transformations rely on autonomy and intrinsic motivation. It is extremely challenging to find the levers within the organization where people *want* change and are willing to change something. It's much easier to push the change on others. This produces results much faster, but people will gladly return to old habits as soon as the coach is out of the building. Even "hard selling" is still pushing, so "convincing others to do what I say" doesn't count, either.

- Relies on "Pull". People must want the change.

Question: How will you approach change when met with resistance?

#10 Arrogance

I recently encountered a coach who literally said, "Everyone I work with is an imbecile." They may never have said this ad verbatim to their clients, but this coach carries the burden of the hidden belief that they are somehow better than the people they work with. This doesn't permit the coach to have a deeply rooted relationship of equals with their coachees. At some point, this attitude will become a barrier to coaching. This strikes as the Dunning-Kruger effect: " How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments"

- Radiate an aura of appreciation and humility

Question: How would you classify people with different levels of competence?

#11 Trying to change behaviour

There's an entire coaching approach called behaviouristic coaching, so behavioural coaching isn't inherently an issue. However, behavioural coaching doesn't focus on changing behaviours, it focuses on changing the beliefs which lead to the observed behaviours. The behaviour is *never* the problem - it's always a belief issue!

- Focus on beliefs

Question: What do you do when someone does things that should be changed?

#12 Process Change

Processes are external structures. They do have a strong effect on outcome, and of course, agile transformation is supposed to have an outcome. Any structural change is ephemeral - until people change what they believe, they will revert to familiar structures, and the longer a structure existed in the past, the more likely they will return. Once people understand how their old process was worse than what they can realistically do right now, they will drive the process change themselves.

- Change minds, then processes will follow suit

Question: How do you approach change to processes?

#13 Certainty

"I know that..." - Socrates would conclude this sentence with "... that I don't know anything."  The knowledge in the world grows faster every day than any human could learn in their lifetime. With new knowledge comes the revision of old knowledge - former beliefs no longer hold true. As Kant put it, "Reason puts to trial like a judge every statement presented and interrogates every witness to discover the truth." Our understanding grows as we learn to ask new and better questions. 

- Constantly challenge beliefs

Question: Which is the most fundamental belief you have changed recently?

#14 Blame-shifting

Even our very existence already affects the situation. When things around us go wrong, we always have a hand in it - knowingly or not. It's very easy to accuse or blame others for their actions, yet many people seem blind towards themselves and how they have affected the outcome. At a minimum, we need to understand that if we ourselves had done a little better, the outcome might have been better. Coaches are hired for leverage - and when the effect is undesirable, it's just not possible to fully abjure oneself of any form of responsibility.

- Be aware of the effect of yourself on the situation

Question: What do you do when a situation gets out of hand?

#15 Wallpaper Certificates

Certifications entitle people of being called something, more certificates entitle to better jobs. Or, so some feel. The difference between certified people and uncertified people may just be that certified people follow paths gone by others, while uncertified people do things that nobody else has done before. As agility is about finding new and better ways, the coach better have some experience which can't be minted into a certificate. If all the coach offers can be packaged in shined, stored, standarized boxes of certification, the coach isn't going to bring the team into new territory.

-Pioneer and discover

Question: What's the last thing you did that nobody did before?

#16 Relabeling

The easiest way to kill an agile transition is to reassign labels and keep the same structure. Product Managers become Product Owners, Team Leaders become Scrum Masters - and line managers become "Agile Coaches". There you go, transition done. That was easy. Nothing accomplished. Genuine change goes far beyond assigning new labels - the way of working is different and people may discover they aren't suited for the role that they were intended for. 

- Reframe the situation so that old structures don't stick any more

Question: If we remove any form of labels, new and old - how do you create a different structure?

#17 In it for the money

Certain certification bodies even advertise that agile coaches earn better money than traditional roles. Of course, this attracts people who are looking for easy ways to earn better money. They come, grab as much money as possible, then leave. Coaching, however, isn't about doing work as much as it is about making meaningful change. A good coach should have a portfolio of people who will tell stories how things have changed through coaching.

- Build positive relationships

Question: Aside from the money, what have you gained when you exit an engagement?

#18 Demanding trust

Trust is a precious and fragile commodity. You might consider trust like a porcelain vase: Once shattered, it leaves numerous shards that create a mess and leave deep cuts when touched. Demanding an upfront reserve of trust can leave people mortally wounded when exploited. Some environments make it difficult for the coach to build trust relationships, especially when managers are known to play a hidden agenda.

- Invite trust by extending it from your side

Question: How can you gain trust in a low-trust environment?

#19 Judgmental

It's easy to say that someone isn't coorperative or performing poorly. It becomes much more difficult to make such statements when you see that people are very good at adapting to their conditions and that their actions are the consequence of a very long history which formed them to become like they are. As coaches, we can't be fast to judge people without understanding why they are the way they are.

- Consider events, causes and circumstances

Question: What do you do when someone does a really poor job?

#20 Insistence 

The worst thing a coach can do is insist they know "what is right" and others don't. This is also the fastest way to create distrust and damage relationships. Those who insist on others following their lead aren't leaders in the first place. Real leaders make others *want* to go the right way, then offer help in moving forward. At the same time, they are forbearing when others choose a different route.

- Accomodate, provide leeway

Question: How far will you budge to make your coachee comfortable?

Bonus - Taking any job

A coach has better things to do than work with organizations who intend to abuse the coach for ulterior motives - or who don't even have an intention of receiving coaching. Roles such as "Delivery Manager / Agile Coach" should ring an alarm bell to serious coaches. Especially when the job description contains terms like "Responsible for the delivery" or "Reports individual performance", that's clearly a non-coaching role. In an interview, the coach would clarify what the real intention is, whether the job ad was written out of ignorance - and how this is supposed to turn out later. 

- Turn down offers that are in clear violation of a coach's identity

Question: How can you be a coach if you're expected to not coach?