The Castle Is Under Siege - are you the bard?

“If you focus on people being busy, you get people being busy.”

You’ve probably heard that one in some Agile training or coaching session. It sounds profound. But it’s often used in ways that are… well, wrong.

This kind of slogan gets thrown around as if it’s gospel. It’s Agile Coaching Dogma: stemming from half-understood principles and applying Goodhart’s Law in isolation.

Let’s be clear: it’s nonsense. And it misdirects.

The Castle Under Siege

Imagine a medieval castle under siege.
Enemy troops on horseback are approaching fast.
The guards are scrambling to prepare.

The defenders need bows: Everyone will be dead if the siege succeeds.

But there’s only one fletcher.

He’s already buried in work, literally stringing bows as if his life depends on it. There’s a line of guards waiting, each of them waiting for a bow. He’s clearly under pressure.

Meanwhile, his apprentice is chasing that irritating mouse which gnawed at the bread overnight.

Just at that moment, a bard arrives with a clearly urgent request:: “ My mandolin broke, and I really need you to take a look. It’s for the royal banquet tonight. The king will be very upset if there is no music!”

So what’s the real problem?

The issue here isn’t just who’s busy — it’s how busy they are - and what they’re busy with.

What we're talking about here isn’t micromanaging everyone’s calendar. It’s understanding the Critical Path and applying the Theory of Constraints.

1. You have a bottleneck on your Critical Path to success.

The fletcher is the bottleneck. No bows = no defense. No defense = everyone's dead. Preventing that situation is the mission. Everything else is a means to this end.

2. The performance of the bottleneck defines the outcome.

In any system, the bottleneck limits total performance. Here, it's the speed at which the fletcher produces bows which defines whether the castle stands or falls.

3. When the bottleneck is overburdened, stop everything that doesn’t contribute to the Critical Path.

Seriously - cancel that mandolin repair request. Forget that status report. And that retrospective can wait until the archers are equipped.

4. Everyone else's job is to support the bottleneck.

Even if they're inefficient. Two guards stringing bows badly still gives you more bows than one fletcher collapsed from being overworked.

"But they're not specialists, it's not their job description, they aren't trained ..." - you underestimate human ingenuity. They will learn. They will grow. And even if they can't do all of it, there's most certainly some steps where they can relieve your bottleneck.

5. If others are blocked, and it’s not on the Critical Path?

That’s not the bottleneck’s problem. Trying to make it the fletcher’s problem only increases the risk of failure.

Everyone has their own "highest priority. And that's exactly the problem: not knowing the Critical Path, not understanding the price your request towards the bottleneck has in the Big Picture - that's how you destroy performance and slow everything down!

Does it resonate?

In a cartoon, the issue is obvious. You see the problem.

But in real organizations?

• Workloads are hidden.
• Everything seems critical.
• Risks are opaque.
• Goals are unclear.
• And attention is given by status and urgency, not by impact.

So what happens?

• Managers ask the fletcher to put down the bows and provide a status update.
• Consultants draw the fletcher into working sesstions to map the fletching process.
• Agile Coaches pull the fletcher into a retrospective and point out that skipping the Dailies means he's not embracing Agile.

Meanwhile, the castle is about to be overrun.

The brutal truth

The fletcher doesn’t need your coaching right now. The fletcher doesn’t need an alignment workshop. The fletcher needs help!

If you’re not helping, get out of the way. And then figure out how you can help.

This is Theory of Constraints

• Identify the bottleneck.
• Utilize the bottleneck.
• Protect the bottleneck.
• Support the bottleneck.

Not everyone in your company is the fletcher. But someone is. Do you know who?

And if you’re not helping them?

You just might be the bard.

Predictability in middle management? Good luck!

If you’ve ever worked in middle management, you’ve likely felt stuck between chaos from below and control from above. Executives demand structure, predictability, and process adherence. Teams, on the other hand, thrive on flexibility, adaptation, and autonomy.
And the manager? They’re caught in the middle, playing a never-ending game of Rock-Paper-Scissors.

Management: A Game of Rock-Paper-Scissors

You may wonder: What do management and Rock-Paper-Scissors have in common? Middle management is a shark basin - the other a lighthearted, simple hand game often played by kids. I often thought about how to explain what happens in middle management to people unfamiliar with it - and came up with this game as a simple model of what middle management has to deal with.

The Three Moves

As a middle manager, you can ultimately play only one of three moves:

Rock = Stability

Large companies are noisy, chaotic and unpredictable. Playing "Rock" means standardization, consistency, documentation, governance, and regulatory compliance create some predictability.

On the downside, an overuse of Rock makes the process itself the goal, and that causes tremendous waste.

Paper = Delivery

Paper is about taking action, getting stuff done, and produces measurable outcomes. With increasing levels of repeatability and reproducibility, performance becomes scalable.

Paper work is smooth. (all puns fully intended.) Unfortunately, Paper will eventually lead to "doing efficiently that which should not be done at all" (ref. Peter Drucker) - and the biggest threat to businesses is investing into results nobody needs.

Scissors = Disruption

Scissors cut through waste, inefficiency and outdated practices. A play of Scissors is leading innovation, making changes, and turning processes upside down - doing something new, or in ways that were never tried (here) before.

The opportunity of Scissors are immense - and yet, an overuse of the Scissors kills productivity: It destabilizes the organization, causing confusion and chaos.

So then - what is the best move? None.

Let me explain.

There's No Single Best Move

Every move creates the conditions for its own counter:

• Rock sets the basis for productivity - but ultimately, Rock itself is unproductive. Hence playing Rock means that Paper (being productive) becomes the next best move.
• Paper means being productive - but also, outdating. A prolonged period of playing Paper must be followed by a play of Scissors (change).
• Scissors cuts the waste - but it causes chaos: forcing Rock (stability).

The Real Complexity: The System Remembers

Middle management is a game played over time and not in isolation. Past moves shape future conditions. There are other players (your fellow middle managers, your teams - and your customers.) To win, you must think several steps ahead:

• Focus on Rock - and you'll lose to Paper. The player who plays Paper in a game of Rock, Rock, Rock - becomes the winner by default: being a results-driver an environment valuing process conformity over outcomes will be a refreshing change to senior leadership.
• Focus on Paper - and you will struggle with Scissors. The player who brings a novel idea into a stagnant organisation wins, as even small, actionable changes can make a world of a difference.
• Focus on Scissors - and you can't handle Rock. When you're constantly facing the reinforcement of status quo, change will be ineffective - regardless of how good and necessary.

Moving in sequence

And now comes the key challenge: "what should you play next?"

Let's explain what the real problem here is: You're playing a Multiway Rock-Scissors-Paper. You're playing against others (a solvable problem), but you are simultaneously playing against your own past and your own future.

We have established that if you played Rock yesterday, your best move today is probably Paper. And if you play Paper today, your best move tomorrow is Scissors. And after Scissors, you'll have to play Rock again.

But that means that you've got to make a tradeoff between scoring today, and scoring tomorrow. And you can only score today if you prepared for it yesterday.

So then, it's all clear: Play Rock, Paper and Scissors in succession.

Right?

Well - not so quick!

Making a winning move

Even if we assume a fully predictable system - the issue is that you're not playing alone. You're competing with other managers on budget, with other companies on market share, and with customers on business versus customer needs.

So if you played "Rock" yesterday, and you're fully predictable, a competitor will play Scissors on you - because you'll be playing Paper today, and that means, you'll lose.

But then - if you can't play Paper, should you play Rock? Well, then you're not being productive, and then your customers will play Paper on you.

Wouldn't that mean the safest bet after a Rock move is Scissors? Yes.

Except - because it's the safest bet, others will prepare for you playing Scissors by playing Rock.

So you should play Paper?

You see where this is going.

Your own predictability is reducing your odds of making a winning move - so your best chance is to not create any hints on what your next move could be.

The winning strategy: unpredictability

We've discovered that being predictable is a losing strategy.

And a manager always playing the same move is definitely predictable - hence, a single move can not be a successful strategy.

We've also seen that a sequence is also predictable, so "Stabilize, Perform, Disrupt" as a cycle is also not a winning strategy.

That leaves only one strategy for success:

• Play all three moves dynamically, and never lock into a single mode.
• Introduce controlled unpredictability to avoid becoming exploitable.
• Plan for future moves (n+2), not just the next one (n+1).
• Break your own pattern before the system forces you to.

And the desire for Predictability? That's the Problem.

Stakeholders constantly demand predictability: "We need a roadmap." "We need a deadline." "We need clear processes." "We need clear roles." Oddly enough, these demands create the very unpredictability they despise:

• Playing Rock (stability) reduces performance, requiring a rapid move to Paper (performance). And that means less focus on "How", and more focus on "What and When."
• Playing Paper (performance) leads to stagnation, inviting Scissors (disruption). This is going to be uncomfortable, but the only way to remain in business.
• Playing Scissors (innovation) leads to chaos, demanding a follow-up with some solid Rock (stability). But the people who thrive in creative chaos are the first who leave when things get cast in stone.

There’s No Easy Way Out - just a smarter way to play

The fundamental truth of middle management is that it is not a "problem that can be solved:" it is a system that must be navigated.

• Expect stability, and you'll be blindsided.
• Expect performance, and you'll be sidelined.
• Expect innovation, and you'll be slowed down.

Winning in middle management isn't about picking the right move - it's about ensuring you remain ahead of the game and are ready to make your move at the right time.

The only way to be sustainably successful in middle management is that you must know all three moves, you must know how to play them well, you must know when to play them - and what to do when one is being played on you. And why you can't win by locking in any of them.

So, the next time someone asks "predictability in middle management" - just smile. Because now, you know the truth: Good luck.

Organisational GRIT

Many people wonder, "What's the difference between a successful organisation, and one that struggles?"
Throughout my decades of consulting and observation, I have observed four factors that I call "GRIT."
Take heed of these, and you're most likely in good shape. On the other hand, ignore these at your own risk.

The GRIT Factors

When analysing what's going on in a company, there are four factors at play that create GRIT - in healthy organisations, these are naturally tended to and require little effort.

However, unhealthy systems of work neglect one or more of these, with dire consequences:

Goals

The first factor of a healthy system of work is that people have clear goals: things we want to achieve in the future. That can be the personal goals, team goals, business goals.

Best case, everyone has all of these - and all of them align.

Worst case, people have no goals, in which case they will show up just to get paid.

The worst case scenario lends itself to all kind of doomsday scenarios for a business owner: nothing getting done, people wasting their time with unfruitful conflict, or people leaving to make more from their life.

Relationships

The second factor of a healthy system of work is that people have positive relationships with the people around them. That includes their team, other departments, business partners and customers.

Best case, everyone has sustainable, sufficiently close relationships that make their network resilient.

Worst case, people's relationships are toxic or adversarial.

I don't think it requires further explanation what happens when the customer is treated like an enemy - but many organisations seem to be entirely oblivious to the cost in time, effort - and ultimately money - that is wasted with infighting.

Improvement

The third factor of a healthy system of work is that people continuously pursue improvement at all levels: make work faster, easier, better. Reduce risk, friction, cost. Make customers happier. Go home with less stress and more happiness.

Best case, the system of work makes that a natural part of the work, and everyone actively contributes.

Worst case, processes and tools deteriorate and everyone is looking the other way.

It's easy to figure out what happens when improvement is not part of people's thoughts or actions, but that's the reality in many organisations: The tyranny of the Urgent makes improvement fall over the edge until the cost of fixing things has reached frightening levels, and people are scared to even get started.

Tomorrow

The fourth factor of a healthy system of work sounds very abstract - "tomorrow" - so let me make it a bit more tangible: Tomorrow, a competitor may arrive on the market. Your business model may get disrupted. A key player in your team may move on. Are you prepared?

Best case, the company is constantly and persistently putting efforts into being prepared for the uncertainties and inevitabilities of tomorrow, and people are not scared to look into the future.

Worst case, everyone knows that the business is heading downhill, but people close their eyes to this uncomfortable reality. And with every day, the looming specter of Tomorrow becomes more threatening.

It doesn't take a lot of imagination where a company is headed when they have no plans for Tomorrow. And yet, few can articulate a clear plan.

Building GRIT

Building a company with GRIT is easy if that's how you've always done it. But if you've never done it, it's staggeringly hard. In fact, it seems insurmountable. So I'll give you a few pointers for getting started on the journey of building GRIT.

1. Itemize the most important Challenges, Opportunities and ongoing Activities in each sector.
2. If a sector has few or no items in it, it's a blind spot. Take some time to think!
3. Ask yourself, "How can we improve our situation?"
4. Take action on the first item and see where it leads you.

Now, that wasn't hard, isn't it?

From now, you may frequently revisit your GRIT matrix, see what pops up and whether you're making progress.

By taking GRIT building serious, you will see a significant reduction in risk, stress and fear - and significant boosts in sustainability, employee satisfaction and business outcomes.

Give it a try!

The Phenomenon of Prevalence Induced Concept Change

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

What is Prevalence Induced Concept Change?

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

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

Transitioning from Classic Project Management

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

Classic Project Management

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

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

Modern Delivery Approaches:

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

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

The Impact of PICC

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

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

Preventing Misconceptions Caused by PICC

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

Define the Benchmark

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

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

Create Transparency

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

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

Manage Expectations

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

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

Conclusion

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

10 Signs your Management is Hurting your Teams

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

Lack of Accountability

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

Intransparency

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

Poor communication

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

Unrealistic Expectations

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

Siding Against the Team

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

Favoritism

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

Micromanagement

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

Ignoring Feedback

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

Unsupportiveness

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

Lack of Appreciation

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

Closing remarks

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

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

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

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

Check your moral compass

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

The Moral Compass

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

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

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

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

The Moral Compass Quiz

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Your alignment is: Undetermined.

Conclusion: Interpreting Your Results

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

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

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

I will leave you with three questions to reflect upon:

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

How do we make money?

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

Intonation matters

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

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

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

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

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

Conclusion

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

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

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

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

The Scrum Master as a Trash Collector

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

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

Organizational trash

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

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

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

Where does this trash come from?

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

The Scrum Master as a Trash Collector

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

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

Summary

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

Do Scrum Masters need to be technical?

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

My answer is a clear "Yes and No."

Accountability

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

In Practice

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

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

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

Closing remarks

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

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

"Agile" is not sacred

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

Agile is not a Religion

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

The Cult of Dogma

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

Agile is Dynamic

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

Science and Agile: Kindred Spirits

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

A place for skepticism

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

Welcome Valid Critique

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

Lab conditions

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

No Sacred Cows

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

Letting go of ideas

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

Being flexible

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

Scrutiny and Validity

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

The Crucible of Scrutiny

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

Emotional Resilience

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

Constructive Criticism

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

Avoid Buzzword Bingo

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

Be Positive

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

Be Reasonable

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

Summary

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

Is the Scrum Master an entry-level role?

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

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

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

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

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

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

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

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

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

Understand Perspectives

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

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

Who is right?

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

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

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

Defensive Reactions

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

Communication Breakdown

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

Strained Relationships

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

Closed-Mindedness

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

Barriers

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

Missed Opportunity for Understanding

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

Ten tips to improve your communication

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

Express Curiosity

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

Listen Actively

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

Adapt and Connect

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

Seek Common Ground

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

Acknowledge Agreement

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

Use "I" Statements

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

Offer Information

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

Be Patient

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

Frame respectfully

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

Stay Constructive

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

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

Conclusion

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

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

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

Assume Positive Intent.

10 Signs You're Facing an Agile Fanatic

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

Denialism

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

See also: "Argument from Ignorance."

Tunnel Vision

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

See also: "Ad Hominem Fallacy."

Guru Idolatry

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

See also: "Argument from Authority."

Manifesto Memorization

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

See also: "Formal Fallacy."

Dogma Defense

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

See also: "Personal Incredulity."

Framework Fundamentalism

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

See also: "False Dilemma."

"Not Real Agile"

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

See also: "No true Scotsman."

Purity Over Delivery

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

See also: "Slippery Slope."

Blaming

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

See also: "Attribution Error."

Elitist Tribalism

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

See also: "Othering."

Conclusion

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

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

In Scrum we do ...

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

Scrum has no prescriptions.

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

Does it make sense?

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

Does it work for you?

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

A better question

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

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

Agile vs Waterfall - the wrong question

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

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

Finding the right question

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

What "Waterfall" isn't.

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

"Everything that's wrong"

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

A sequential, linear approach from idea to completion.

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

A stage-gated approach to product development.

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

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

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

What "Agile" isn't.

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

Scrum is not Agile

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

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

Inadequate processes, plans, documents, or contracts

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

Lack of direction or tracking

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

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

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

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

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

The actual choice

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

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

How are we dealing with assumptions?

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

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

Which mechanisms do we employ when reality contradicts our assumptions?

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

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

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

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

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

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

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

How do we deal with uncertainty?

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

Summary

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

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