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.

Check your moral compass

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

The Moral Compass

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

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

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

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

The Moral Compass Quiz

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Your alignment is: Undetermined.

Conclusion: Interpreting Your Results

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

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

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

I will leave you with three questions to reflect upon:

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

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.

Understand Perspectives

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

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

Who is right?

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

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

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

Defensive Reactions

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

Communication Breakdown

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

Strained Relationships

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

Closed-Mindedness

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

Barriers

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

Missed Opportunity for Understanding

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

Ten tips to improve your communication

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

Express Curiosity

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

Listen Actively

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

Adapt and Connect

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

Seek Common Ground

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

Acknowledge Agreement

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

Use "I" Statements

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

Offer Information

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

Be Patient

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

Frame respectfully

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

Stay Constructive

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

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

Conclusion

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

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

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

Assume Positive Intent.

10 Signs You're Facing an Agile Fanatic

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

Denialism

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

See also: "Argument from Ignorance."

Tunnel Vision

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

See also: "Ad Hominem Fallacy."

Guru Idolatry

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

See also: "Argument from Authority."

Manifesto Memorization

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

See also: "Formal Fallacy."

Dogma Defense

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

See also: "Personal Incredulity."

Framework Fundamentalism

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

See also: "False Dilemma."

"Not Real Agile"

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

See also: "No true Scotsman."

Purity Over Delivery

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

See also: "Slippery Slope."

Blaming

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

See also: "Attribution Error."

Elitist Tribalism

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

See also: "Othering."

Conclusion

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

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

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

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

The 94% myth

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

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

What's the "System?"

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

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

Russell Ackoff

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

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

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

Dan Pink, "Drive"

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

Out of the Crisis

Let's now explore what Deming actually wrote:

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

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

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

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

Untangling system and individuals

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

The System

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

The Individual

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

The misconception

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

The System's Role

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

The Individual's Role

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

Shaping effective systems

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

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

Imperfection

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

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

So: just don't.

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

Disagree?

Maybe you will disagree.

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

Dealing with Organizational Debt

"Organizational debt" is a metaphorical term used to describe the accumulation of inefficiencies, shortcomings, and suboptimal practices within an organization over time. Similar to technical debt, it refers to the consequences of choosing expedient solutions that will require revisiting and improving the situation later on.

Organizational debt is often created by a desire to "just make it work:" when people opt for quick and convenient solutions to address immediate needs or challenges, they often ignore the long-term consequences. Effectiveness, scalability, and sustainability are often not considered in the heat of the moment. While shortcuts and compromises keep things going, a failure to address the systemic impact of these decisions will eventually take a massive toll on the organization's ability to operate efficiently and adapt to changing circumstances in the future.

"Organizational Debt" image created with craiyon.com

How can we deal with
Organizational Debt?

The following table is a guide which you can use to determine whether you have organizational debt, and how you can address it.

How to identify and address Organizational Debt

Organizational Element	Organizational Debt Indicators	Potential Remedial Actions
Purpose and Mission	Lack of clear mission statement Vague objectives or conflicting goals Disconnect between company mission and daily work	Clarify the organization's mission and objectives Communicate the mission effectively to all members Align goals across departments Identify and explore gaps between vision, mission and execution
Structure	Complex and rigid hierarchy Unclear reporting lines Overlapping roles	Make the hierarchy less felt Streamline the organizational structure Clarify roles and responsibilities
Leadership and Governance	Lack of transparency Poor decision-making processes Leadership conflicts	Foster transparent communication Implement clear decision-making protocols Address leadership issues promptly and proactively
People	High turnover rates Low employee morale Skill gaps within the workforce	Create open feedback channels to proactively resolve dissatisfaction Improve employee engagement and recognition programs Invest in training and development opportunities
Culture and Values	Unhealthy work environment Lack of shared values Lack of identification with values	Cultivate a positive and inclusive culture Reinforce core values through internal communication Lead values by example
Processes and Methods	Inefficient workflows Lack of process clarity Outdated procedures	Identify and resolve bottlenecks Frequently revisit and improve processes Document and communicate standards
Resources	Limited budget Inadequate technology Inefficient resource allocation	Analyze resource allocation and prioritize essential investments Seek cost-saving opportunities without compromising quality Embrace innovation to optimize resource utilization
Stakeholders	Poor customer satisfaction Strained vendor relationships Disengagement	Collect feedback from stakeholders and act on it Enhance customer support and engagement strategies Involve communities in decision-making
Communication	Ineffective communication channels Information silos Miscommunication	Optimize communication channels and protocols Encourage open and transparent communication across all levels Use collaboration tools to facilitate information sharing
Adaptability and Innovation	Resistance to change Reluctance to embrace new technologies Outdated practices	Foster an intrapreneurial culture of innovation and risk-taking Institutionalize grass roots innovation Invest in ongoing training and education
Measurement and Evaluation	Inadequate metrics Unsuitable performance tracking Not relying on facts	Identify relevant success metrics Conduct regular reviews to inspect and adapt Adopt data-driven decisions-making and improvements
Ethical Responsibility	Embellishing outcomes Passing the Buck Failure to address concerns	Provide "psychological safety" Encourage opennenss and non-judgmentalism Develop and promote a code of ethics

Don't hesitate to reach out if you need coaching on how to do this in practice.

Leading by Absence

You may be familiar with classical leadership approaches - such as leading by doing (being in the trenches, doing the same as you expect others to do), or leading by example (which is slightly different, as you show patterns for others should follow) - but have you ever thought about "leading by absence?" This technique is very important for Scrum Masters and Managers alike to grow teams and personalities. If you're a parent, you may be familiar with how necessary, yet difficult this approach is.

Let's explore how this approach can positively impact leadership dynamics and enhance team dynamics.

How to Lead by Absence

The concept of "leading by absence" refers to a leadership approach where a leader intentionally creates space and provides leeway for their team members to take ownership and make decisions in their absence. Leading by absence means you steps back and allows others to take the lead and responsibility, while still providing guidance and support as necessary.

Leadership by Absence is a delicate act of balance

"Leading by absence" recognizes that effective leadership isn't about being at the forefront or making decisions. Instead, it acknowledges the importance of empowering others and fostering a sense of autonomy, trust, and accountability within the team. By giving team members the opportunity to lead and make their own decisions, leaders focus on nurturing their growth, developing others' skills, and building a more self-reliant and resilient team.

These are some key aspects of leading by absence:

Delegation

To lead by absence, team members need to be clear which tasks and responsibilities they are expected to take over. The leader trusts their team's capabilities and gives them the autonomy to make decisions within their assigned roles.

Support and guidance

Those who lead by absence deliberately step back and create space, while still providing support and guidance when needed. They offer assistance, clarify expectations, and provide resources or feedback to help their team members succeed.

Empowerment

Leaders who choose to be absent aim to empower team members by fostering a culture of ownership and accountability. It encourages individuals to take initiative, make decisions, and contribute their unique perspectives.

Trust-building

Leaders who practice leading by absence build trust with their team members. They demonstrate confidence in their abilities and create an environment where individuals feel valued and supported, which increases motivation and engagement.

Continuous learning

This leadership approach relies on opportunities for learning and growth. Leaders encourage their team members to learn from their experiences, both successes and failures, and promote a culture of ongoing improvement and development.

Conclusion

Leaders who practice "leading by absence" promote collaboration, innovation, and individual growth within their teams. They leverage the diverse skills and talents of their team members while fostering a sense of ownership and shared responsibility for achieving goals.

Note of caution:

Despite the similar name, "Leading by Absence" is the opposite of "Absence of Leadership:" It's a deliberate choice that requires careful consideration and patience. Wheras it empowers and enables teams, an absence of leadership implies a lack of guidance, direction, and support.

To put these into contrast: Leaders who lead by absence create a space for others to step up and become more successful, whereas an absence of leadership puts others into turmoil and endangers their success. Effective leaders strike a balance between providing autonomy and support, ensuring that team members have the necessary resources, guidance, and clarity to thrive in their roles.

Defining Enterprise Coaching

I call myself an "Enterprise Coach," rather than an "Agile Coach" - because I feel that what the market typically understands under "Agile Coach" doesn't really match what I do. I work to improve organizational systems, and Agile frameworks and approaches are just one tool in my belt when doing that. And recently, with the TOP Structure, I have reclassified and restructured how I myself see this role. Let me share my defintion, which I have turned into an interactive site that also gives you a score at the end, so feel free to tick the boxes of competencies you believe that you bring to the table.

We'll take a look at the role of an Enterprise Coach through the lens of the TOP Structure, which - to keep things as simple as possible, stands for "Technology, Organization, Product." These are the three core pillars for (almost) every modern enterprise. An Enterprise Coach works at system level, hence they need to be familiar with all three pillars, as well as their interactions, at every level of the organization.

Domain Overview

The TOP Structure offers an integrated competency model to frame key skills and experiences across three primary domains: Technology, Organization, and Product. These domains encapsulate the broad range of expertise necessary for excellence in Enterprise environments.

Technology

An Enterprise Coach won't necessarily be a profound technology expert, but needs a solid understanding of the technology landscape and the technical practices within it. They should be familiar with how Agile methodologies and principles apply to software development, IT operations, and technological innovation. This includes understanding DevOps, Continuous Delivery, TDD, BDD, and many other technical practices associated with Agile environments. They use this knowledge to guide teams in adopting appropriate technical practices that allow them to work effectively and sustainably.

	Topic	Details
	Lean + Agile Practice	Possesses a comprehensive understanding of Agile methodologies and how they apply to technology and software development environments.
	Software Development Lifecycle	Understands the software development lifecycle and how Agile principles apply to various stages, from demand collection to development, testing and even operational maintenance.
	Technical Practices	Familiar with technical practices like DevOps, Continuous Integration/Continuous Delivery (CI/CD), Test-Driven Development (TDD), Behavior-Driven Development (BDD), pair programming, and automated testing. Can provide guidance to teams in adopting these practices as needed.
	Technical Facilitation	Able to facilitate technical discussions, bridging the gap between technical teams and business stakeholders. Can communicate technical complexities in a simple manner to non-technical team members.
	Digital Transformation	Understands the role of technology in digital transformation and can guide the organization to leverage technology for business agility.
	Technology Trends	Stays updated on the latest technology trends and innovations, and understands how they can influence Enterprise systems.
	Systems Thinking	Understands the interplay between technical systems and processes in an organization. Applies a holistic approach to problem-solving.
	Technical Debt Management	Understands the concept of technical debt and can guide teams on strategies to manage and reduce it.
	Scalable Architectures	Understands the principles of building scalable and flexible architectures. Can guide teams in aligning their technical practices with these principles.
	Tool Familiarity	Familiar with typical tools used to organize technology work. Can guide teams on using them effectively.

Organization

This is a key area for Enterprise Coaches. They need to understand organizational dynamics and how to build collaborative environments across teams and business functions. Skills in this area include change management, strategic thinking, leadership, and communication. They should have experience in leading organizational culture shifts, influencing stakeholders, facilitating conflict resolution, and mentoring other Coaches and leaders. They need to understand how to design and implement strategies that align with the organization's structure, culture, and business objectives.

	Topic	Details
	Organizational Design	Understands how different organizational structures impact the organization's ability to reach its goals. Able to guide changes in organizational design to improve alignment between structure and goals.
	Theory of Constraints	Understands how to maximize effect with minimum change in large organizational systems.
	Change Management	Skilled in leading and managing organizational change initiatives, particularly Agile transformations. Understands the psychological and social aspects of change and can help address resistance.
	Strategic Thinking	Able to design and implement change strategies and how to align them with organizational objectives.
	Leadership	Demonstrates strong leadership skills, guiding teams and individuals through change and fostering a culture of continuous improvement.
	Influencing Skills	Able to influence stakeholders at all levels, including senior leaders, to foster beneficial change practices.
	Communication Skills	Excellent verbal and written communication skills. Able to clearly articulate the benefits of change to different audiences.
	Conflict Resolution	Adept at facilitating conflict resolution and consensus-building among diverse stakeholders. Able to maintain harmony within teams during transformation efforts.
	Coaching and Mentoring	Experienced in mentoring and coaching Agile Coaches, Scrum Masters, managers and leaders within an organization. Can help develop leadership capabilities across the organization.
	Cultural Understanding	Aware of the cultural aspects within the organization and how they impact its ability to reach its goals. Able to guide cultural shifts to align closer with intended goals.
	Performance Management	Understands how to align performance management systems with organizational goals. Can guide changes to recognition and reward systems causing undesired behaviors.
	Assessment	Able to qualify the organization's current state to guide continuous improvement efforts with empirical data.

Product

Enterprise Coaches don't manage products directly. Instead, they support and enable product development efforts. They need to understand how roles such as Product Owners and Product Managers operate, and how product strategy, roadmapping, and backlog management can be conducted effectively. Their understanding of product management can help facilitate alignment between product strategies and ways of working, as they coach product-related roles in the organization.

	Topic	Details
	Product Management Practice	Able to apply product development functions, including concepts such as product-market-fit, design thinking, incremental bets, and iterative development.
	Value-Driven Delivery	Understands how to align product development practice with the delivery of value to customers and stakeholders. Can guide teams to refocus from output to value.
	Lean Principles	Understands Lean principles such as minimizing waste, amplifying learning, and delivering small batches. Can guide teams in applying these principles to their own work.
	Product Strategy and Roadmapping	Familiar with various approaches to product strategy and roadmapping, and can help align these with organizational objectives.
	Customer Centricity	Understands the importance of customer feedback and user experience in product development. Can guide product teams in adopting a customer-centric approach.
	Business Model Understanding	Understands the organization's business model and how product development aligns with it. Can guide product teams in aligning their work with the business model.
	Market and Competitive Analysis	Understands market trends and competitive dynamics that could affect the product. Can guide product teams in responding to these trends and dynamics.
	Metrics and Analytics	Understands how to use product-related metrics and analytics, such as customer satisfaction scores, throughput, yield rates, etc. Can guide teams in using these metrics for continuous improvement.
	Risk Management	Understands how to manage product-related risks including technical debt, market shifts, etc. Can guide teams in effective risk management practices.
	Product Owner/Manager Coaching	Skilled in coaching Product Owners and Product Managers on their roles and responsibilities, including for example backlog refinement, stakeholder management, and cost-benefit optimization.

So - how are you doing?

You scored:

• 0 / 0 Technology Competencies (%)
• 0 / 0 Organization Competencies (%)
• 0 / 0 Product Competencies (%)

That means you consider yourself equipped with % (0/0) of the TOP Structure Enterprise Coaching Competencies.

Would you like learn more about the TOP Structure, and how to become a TOP Structure Coach? Please visit The Official TOP Structure Page.

Don't be Joe!

Working with Joe is a pain. If it was up to me, I wouldn't hire Joe. And I would advise every employer to also not hire Joe. Not because Joe would be a bad person. But Joe does and says bad stuff. Stuff that's bad for Joe's team. For his company. For the credibility of Scrum, even for "Agile" as a whole. And for Joe. Joe has good intentions - and "the road to hell is paved with good intentions." So - don't be like Joe.

Joe isn't a real person. Joe isn't a single person. Joe is what Joe does.

Joe is a collection of antipatterns that I quite often observe with inexperienced "Agile Coaches" or newly minted "Scrum Masters." We're all learning, and you might even have spotted Joe in what I did. I'm no better - just a little wiser. We need to have empathy with Joe, and Joe needs to reflect on their actions, as well as the consequences of their actions.

Maybe you got pointed to this page with a "don't be Joe" comment? Don't consider it an attack. Consider it a learning opportunity. We're all Joe on occasion. What matters is what we do about it. The less Joe we are, the more successful we will be.

Here comes Joe

I believe that Joe wants to do a good job. Unfortunately, Joe doesn't know what "doing a good job" in coaching means. And that spells trouble. 

Joe is certified

On their very first Sprint Planning session, Joe's team asked why they had to do Planning Poker. Joe answered, "I am a CERTIFIED Scrum Master, and that's the way you have to do it in Scrum." The team couldn't trust their ears: Joe's CSM certificate made him an authority on Scrum? They shook their heads, but obliged. The next morning, when Joe entered the office, he was shocked.

The entire back wall of the office was plastered with certificates. Joe thus learned that two developers held a CSP, two had obtained PSM-II, and everyone had gone through Scrum training years before Joe. Above that list of certificates, the team printed a big banner, "We know what we're doing, and if anyone has doubts - we have the certificates to prove it."

Joe was humiliated, and he could never establish any form of credibility with his team. Within just a few months, Joe left - and the team clearly told management that they'll never accept a Scrum Master who borrows authority from a silly certificate.

What should Joe have done?

Scrum training is really just something that gets us started on our learning journey. Joe should respect that others around him had their own learning journey, and it could be that they are much further than he himself.

Joe should be humble in order to build trust: "I am new here. I don't know who you are, how you work - or why you work this way. I would like to learn. How are you currently planning? How does that work for you?" These are simple, yet extremely effective ways to figure out where real problems are. We don't need to make changes "because Scrum says so." We'd like people to be successful, while reducing unnecessary pain.

If the team doesn't know about Planning Poker, and they have one of the problems it can address, Joe might start the conversation with, "I learned a technique in my training. Would you want to give it a try?"

And most of all - Scrum doesn't even mention Planning Poker. It's an optional, supportive practive. Joe should learn what makes or breaks Scrum before making bold claims.

Joe focuses

During a Retrospective, Joe went into great lengths to explain to the team that developers need to be "T-Shaped," or even better: "M-Shaped:" They should have a broader horizon, not only doing software development, but also learn how their business works, how to test, how to engineer requirements - everyone should be able to do everything.

One developer asked what Joe understands about software development. He answers, "I am a Scrum master. I don't need to understand. My focus is Scrum."

Another one inquired what Joe understands about the product. Again, "My focus is Scrum."

How about the company culture? Yet again, "My focus is Scrum."

Developers shook their head, then proceeded, "Isn't that hypocritical? You expect us to understand things you yourself don't understand, and you allegedly have a reason, but not us? How come?"

Joe reasoned how the Scrum Master's role is ensuring Scrum is done properly, and how challenging that is. The team wanted to have none of it, asking "Do you really believe that your stupid little 17-page guide is more complex than all of Software Development, our product, and the entire company around us?" - Joe countered, "The Scrum Master is a very special role, and if I'd get into those domains, I couldn't meet my own role properly."

What should Joe have done?

The true value of a Scrum Master is their ability to lead meaningful change. The question, "but what is meaningful?" - requires the Scrum Master to know enough about the context to ask the questions that need to be asked. At a minimum, Joe should be curious about what the team is currently doing before proposing any changes.

While Joe doesn't need to be a senior developer, Joe should show some openness and try to learn just enough about development to determine whether any of his suggestions even make sense to someone who does. It's all right if Joe doesn't understand anything about development: sitting down with a developer and having them explain how they work is a fast and easy way to figure out what the team is currently doing. Quite often, when people explain things, they already realize that something "we've always done" just doesn't make sense.

Joe also won't need to understand the details of every single one of the product's features. Without ever having managed a product before, however, Joe's advice to the Product Owner will be of limited value. Joe could start their own pet project - for example, running a Kickstarter campaign. The learnings will be invaluable for Joe.

Joe also should do a reality check: Understanding the organizational context is Joe's job. Indeed, that's the most important thing Joe has to do in order to help the team become effective.

Finally, Joe should invite rather than impose. Instead of telling his team to change their ways of working, Joe could create a link between a pain that people have, and how a specific change could make their life better.

Joe highlights complexity

Joe has learned from coaching that "in complex, adaptive systems, you can't know the outcome until you after tried." Joe uses this line to discourage any form of plan-driven approach, as well as any prediction of outcomes.

When management asked for a delivery forecast, Joe suggested - "we don't know, it's done when it's done." When developers discussed an implementation, Joe suggested - "Why don't you just get started? You'll know later if it worked." Joe's team was unaware of good engineering practice. Joe took it easy - "In the Complex Domain, we don't even know until afterwards whether we needed them."

Eventually, Joe's team got into a real pickle: the low quality product irritated stakeholders. Joe argues, "That's uncertainty. We use Scrum because of uncertainty."

Joe never mentioned that neither complexity nor uncertainty are binary: Things can be more or less complex, and more or less certain. Joe pushed his team into Chaos by removing whatever certainty they had, and making things complex that could have been simple.

What should Joe have done?

Joe's doesn't need to highlight the existence of complexity - success isn't knowing about complexity, it's simplifying until things become manageable.

"Complex" isn't an absolute. Planning, forecasting and good engineering practice could all help to make things simpler. It's just that we shouldn't bet on them.

When Joe's team has to make a forecast, Joe needs to learn what the forecast will be used for, and what the simplest way of providing the necessary information is. Clarifying margins of error and the tradeoff between accuracy and value reduces the complexity of forecasting.

When Joe's team wants to discuss implementation, Joe could probe where the team is uncertain, and what the consequences of a wrong choice are. Planning ahead just enough to avoid poor choices that could be hard to reverse is smart. If Joe was smart, he would even encourage the team to ask, "What will be the long-term consequence of this choice?" - and coming up with possible alternatives before implementing anything. That would reduce the impact of technical debt, which in and of itself causes complexity in other areas.

Equipping people to do the work they need to do can remove a whole layer of complexity in the "How."

Joe shows flexibility

Whenever someone addressed a question to Joe, he displayed his zen-like wisdom by always answering "it depends."

Joe's team eventually got fed up with this answer, because - of course: it depends. They knew that already. But: on what? Joe was missing that part.

During a Sprint Review, a senior developer proudly announced that they had fully automated Joe - the team presented a website with a free form field, and when you hit Enter - a text would appear: "It depends." Joe's manager rolled her eyes - it became Joe's last working day: his default answer wasn't earning him any respect - neither within, nor outside the team.

What should Joe have done?

Yes, it's true that "it depends." The question is: on what does it depend? What are the important factors that we need to focus on? Where are the forks in the road? What makes A preferable to B - and why?

The answer, "it depends" avoids commitment to the inquiry. A conditional answer is only valuable when it reveals viable alternatives or relevant risks.

If Joe doesn't know an answer, the best option might be - "I don't know - let's find out together?"

If Joe knows only one answer, he might state, "The only thing I'm aware of is this. We could research alternatives."

If Joe has limited experience, he might answer something like, "I have experience with this. I know there are alternatives, but I have no experience with them."

Finally, a coach doesn't get paid to be a dictionary. Stating, "I don't know" is not a character flaw. Much rather, it would be a character flaw of Joe to make it look like he has an answer, when really - he doesn't.

Joe keeps the rules

Joe took his responsibility very serious to make sure that his team had a proper Scrum environment where the rules were followed.

Joe's Scrum Team had visitors from other teams during their Daily. As one developer mentioned that there was some issue with a component being worked on by another team, that person couldn't stay silent any more and stepped forward. Immediately, Joe stepped in, "The Daily is only for the team. Nobody except for them speaks." The silenced developer raised his hand and barely could open their mouth before Joe escorted him out of the room: "If you can't follow the rules, you're not welcome."

It later turned out that Joe's team was building incompatible features and their sprint's work could not be integrated without major rework: Joe had successfully stopped the only person who could have helped from speaking up.

What should Joe have done?

Communicating the right things right at the right time is extremely difficult - even if we dedicate our entire life to this topic, we still get it wrong more often than not. The journey starts with a realization that communication tends to be pretty messy almost everywhere.

As a Scrum Master, Joe has to work on helping people communicate more effectively. When they don't know how to do this, Joe has to find out. Blocking necessary communication is never the right solution - someone will always end up with bruises.

Joe's first responsibility isn't simply to make sure that the rules are followed: Where team members lack essential information, or they aren't providing necessary information to others, that's a high-priority impediment that dramatically reduces their effectiveness - and Joe is accountable for the team's effectiveness.

Joe should try to discover where, how and why information flow between the team and outside actors is broken, and work on fixing that. Scrum has very little to say about information flow across team boundaries. When people outside the team are part of the same system as Joe's team, Joe has to find ways to help everyone communicate more effectively, not just the team amongst themselves.

If in the short term, this means breaking the rules of Scrum, Joe should accept this breach, point it out, and ask, "How should we deal with this next time?" Otherwise, Joe risks being called a Scrum Fanatic, who inists on rigorously following the rules, "without reason and against all reason."

Joe protects the team

During a Sprint Review, one of the stakeholders mentions that they're not happy with the outcomes of the Sprint. Immediately, Joe intervenes to point out that the team acted based on available information, and "if you don't give us the correct information - you need to work on that."

On another day, there was a full server outage. It turned out that someone entered data that corrupted the database. Again, Joe was ready: "You have to train users properly. It will take us days to clean this up. You can use that time to train your users properly, so this doesn't repeat."

Yet another day, finance needed some figures to calculate investments. Joe shot down the request, "If we'd help you with that, we're not going to meet the deadline for the trade fair."

Joe was slippery like an eel. Whatever problem stakeholders faced, Joe always found a way to flip it around and make sure that the problem landed somewhere else. This indeed protected his team both from overload and blame. One day, though, a sales executive mentioned to a board member, "They're not helping at all. Each time I meet them, I wish I hadn't wasted my time." - that was also the team's last Sprint.

What should Joe have done?

"Protecting the team" is a responsibility that needs to be considered in context.

Sheltering the team is a short-term mechanism to stabilize the environment. By pushing the problem elsewhere without defusing the conflict, Joe sets the stage for drama that will make things worse for the team in the long term.

Joe needs to show courage by taking ownership of the conflict, and guide parties to resolve it.

Likewise, Joe needs to create an environment where everyone from his team feels confident to courageously say, "Yes, we didn't think of this. Let's work on this and find a solution that works for everyone."

Summary

Did you realize how I managed to sneak the five Scrum Values - Courage, Commitment, Focus, Openness and Respect - as well as the foundation of trust - into the article? Joe becomes a beacon of all that Scrum is, not so much by what he knows - but by being. Every day, Joe can take a few minutes off to reflect in silence, "Which of the things I did today reflect the Scrum Values, and which of my actions don't? What could I do tomorrow, so that I am a living example of what the Scrum Values mean?" Joe could also invite his team, his peers and his management to give him feedback on how they see the Scrum Values in what he does.

We make mistakes. We have setbacks. We act based on what we know today, and tomorrow we may cringe at what seemed like a good idea today. We progress not by trying to be perfect, but by dedicating ourselves to learning. If Joe keeps this in mind, then one day - Joe will be a Master of Scrum.