Understand Perspectives

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

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

Who is right?

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

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

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

Defensive Reactions

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

Communication Breakdown

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

Strained Relationships

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

Closed-Mindedness

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

Barriers

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

Missed Opportunity for Understanding

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

Ten tips to improve your communication

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

Express Curiosity

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

Listen Actively

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

Adapt and Connect

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

Seek Common Ground

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

Acknowledge Agreement

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

Use "I" Statements

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

Offer Information

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

Be Patient

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

Frame respectfully

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

Stay Constructive

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

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

Conclusion

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

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

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

Assume Positive Intent.

10 Signs You're Facing an Agile Fanatic

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

Denialism

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

See also: "Argument from Ignorance."

Tunnel Vision

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

See also: "Ad Hominem Fallacy."

Guru Idolatry

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

See also: "Argument from Authority."

Manifesto Memorization

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

See also: "Formal Fallacy."

Dogma Defense

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

See also: "Personal Incredulity."

Framework Fundamentalism

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

See also: "False Dilemma."

"Not Real Agile"

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

See also: "No true Scotsman."

Purity Over Delivery

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

See also: "Slippery Slope."

Blaming

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

See also: "Attribution Error."

Elitist Tribalism

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

See also: "Othering."

Conclusion

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

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

In Scrum we do ...

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

Scrum has no prescriptions.

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

Does it make sense?

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

Does it work for you?

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

A better question

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

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

Agile vs Waterfall - the wrong question

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

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

Finding the right question

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

What "Waterfall" isn't.

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

"Everything that's wrong"

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

A sequential, linear approach from idea to completion.

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

A stage-gated approach to product development.

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

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

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

What "Agile" isn't.

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

Scrum is not Agile

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

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

Inadequate processes, plans, documents, or contracts

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

Lack of direction or tracking

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

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

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

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

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

The actual choice

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

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

How are we dealing with assumptions?

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

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

Which mechanisms do we employ when reality contradicts our assumptions?

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

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

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

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

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

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

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

How do we deal with uncertainty?

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

Summary

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

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

The OPEN Transformation Roadmap

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

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

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

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

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

The 94% myth

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

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

What's the "System?"

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

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

Russell Ackoff

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

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

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

Dan Pink, "Drive"

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

Out of the Crisis

Let's now explore what Deming actually wrote:

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

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

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

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

Untangling system and individuals

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

The System

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

The Individual

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

The misconception

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

The System's Role

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

The Individual's Role

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

Shaping effective systems

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

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

Imperfection

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

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

So: just don't.

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

Disagree?

Maybe you will disagree.

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

The power of stakeholder promises

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

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

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

The importance of Stakeholder Promises

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

Alignment of Goals and Needs

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

Trust and Credibility

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

Effective Prioritization

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

Transparency and Communication

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

What Are Stakeholder Promises?

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

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

Defining Stakeholder Promises

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

Step 1: Identify Product Vision

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

Step 2: Identify Key Stakeholders

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

Step 3: Relate Vision and Stakeholders

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

Step 4: Define Everyone's WIIFM

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

Step 5: Make Specific Promises

Make your promises effective and actionable:

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

Step 6: Collect Feedback

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

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

Successfully using Stakeholder Promises

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

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

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

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

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

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

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

Conclusion

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

Test Coverage and Fermentation

Measuring test coverage makes sense - but maybe not in the way you think. Here's why:

Test Automation coverage is like fermentation bubbles

1. Seeing it doesn't mean things are going to be fine
- but not seeing it may indicate that the process itself may not yield good results.

2. could see it and still get an unconsumable product:
Coverage only tells you that code was executed by tests, not whether there are quality risks or issues.

3. When you don't see it on new stuff, this most certainly tells you that you'll have problems:
Your testing process and your development are out of sync, and that's a pretty good indicator that your development process itself is low quality.

It also tells you that the team is definitely not practicing TDD - because just like fermentation bubbles, test coverage is a side product, not a goal, of TDD.

If you ran a pickle factory - what do you think would happen if you set a target for amount of fermentation bubbles?

Focus on the pickles - not the bubbles.
But when there are no bubbles (tests) - you need to investigate.

10 signs your Scrum Master doesn't understand Scrum

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

10 Signs that Your Scrum Master Doesn't Understand Scrum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

Let's Scrum better!

10 signs that your Transformation has failed before it started

"Agile transformation" is a popular buzzword these days, and the promises improved efficiency, better collaboration, and increased customer satisfaction are too hard for any enterprise to ignore. However, the transformation journey is not without its pitfalls. Let's take a tongue-in-cheeck snipe at some of the common causes of transformation failure.

You Know That Your Agile Transformation Has Failed Before It Started, If you...

Brought in consultants to prescribe the details of what everyone must do, when and how.

An Agile transformation doesn't come with a one-size-fits-all approach. When consultants define roles and processes without considering the unique challenges and context, we'll get a "square peg, round hole" solution. Successful transformations rely on collaboratively progressing on the Agile journey, letting teams experiment and adapt based on their own understanding and experience with a continuous interplay of opportunity, ideas, execution and feedback.

Spend more time documenting the Future Mode than experimenting or talking to people.

Agile transformation is about establising a habit of growth and learning based on iteration and continuous improvement. An overreliance on assumption-driven documentation without enough actual interactions and experiments achieves the opposite.

Already know the perfect solution, before having made a single change.

Agility is only required because we have to deal with uncertainty. An agile approach needs to acknowledge that perfect solutions rarely exist. Assuming that a "perfect" solution can be found without experimentation, learning or adaptivity will lead to missed opportunities for improvement and won't make the future organizational system any more flexible.

Can show the future on a slide deck, but not in a team.

Agile transformation is built on "individuals and interactions," not on a top-down declaration by some smart folks who know it all. A vision that exists only on a slide deck without any backing of teams who can tell "war stories from the trenches" doesn't instill much trust.

Have defined the correct process that everyone just needs to follow.

Rigidly following predefined processes is what got us into the mess that agility tries to address by fostering adaptability and flexibility. Imposing a "correct" process without degrees of freedom undermines autonomy and the opportunity to take advantage of domain specific benefits, leading to decreased motivation and ultimately, failure to realize any significant improvement potential.

Declare a mandatory universal "Agile Standard" for all teams.

Each team and organization has its own unique challenges, needs and potential. A one-size-fits-all Agile standard that disregards context stops teams from effectively practicing Continuous Improvement. Successful agile organizations treat the diversity of teams as an advantage.

Consider teams deciding their own ways of working to be a problem.

Empowering teams to self-organize and make decisions that impact their work is the means by which organizations reduce risk of failure and coordination overhead. Treating team autonomy as a liability annuls this advantage.

Apply so much rigor that Team Retrospectives don't let people change, experiment, or learn to do it better.

If the rigor and formality tells team members that their ideas aren't welcome, they'll quickly stop highlighting opportunities for improvement. When teams can't figure out how to improve in their context, "Agile" will merely become a new status quo without any sustainable benefits.

Believe that "people are doing it wrong," without giving them any leeway to do it better.

Agile transformations often involve a shift in thinking and culture, not just the mechanics of Agile practices. Blaming individuals without understanding the systemic barriers causes demotivation and resistance. A successful transformation acknowledges that there is no single "one right" approach, and focuses on enabling teams to find what works best - for them.

Your Coaches can recite the doctrine by heart, but don't understand the psychology of change.

Coaches play a crucial role in guiding teams on their transformation journey. Reciting Agile frameworks, values or principles without understanding the human aspect of change and the psychology of team dynamics alienates people and deprives them of the meaningful support and guidance they require. Successful coaches empathize with teams, create a safe space for learning, and tailor their approach to the needs of the individuals and teams they work with.

Closing remarks

Although this list might be slightly humorous, it highlights some serious pitfalls that can seriously derail transformations. Understanding these reasons for failure will help you become more successful on your Agile Journey. Being agile, fostering collaboration, and living agile values and principles is as essential for the teams doing the work as it is for the change towards Agility itself.

An Organizational Measurement System

"How can we create a measurement system for an agile organization?"

There are more and less helpful approaches, and there's also a lot of situational context to consider. And yet, in the big picture, there are numerous metrics that (almost) universally make sense, at least to consider.

"Metrics" by craiyon.com

Metrics Context

Before exploring the metrics, we need to consider that each of these metrics applies in a specific context. For example, Strategy metrics are of secondary concern to team members, whereas Team metrics might be of secondary concern to strategic management. When talking about "secondary concern," that means: "We understand what's being measured, and we should be informed about relevant information coming out of these metrics, but our focus is elsewhere."

While in traditional enterprise contexts, these levels are often staffed with separate individuals, the contextual structure of the metric levels doesn't necessarily coincide with a hierarchy: In a startup, a single individual in a 1-person company might have to make decisions at any of the respective levels, and separation of concerns helps to clarify the context.

The measurement system

Different metrics are applicable at the different organizational levels, and they are only of limited value at others. We discern Leading Indicators and Lagging Indicators. The key difference between these two is that leading indicators enable predictions, whereas lagging indicators provide information that could trigger further inspection and potentially adaptation. A balanced mix of leading and lagging indicators in all core domains (Technology, Organization and Product) provide a solid basis for data driven decisions.

To keep this list somewhat manageable, some metrics, such as for example, "Flow," are comprised of an entire set of standard metrics encompassing this performance indicator.

A potential KPI system for an Agile organization

Layer	Technology Metrics	Organization Metrics	Product Metrics
Strategy	Technical Capability Development Flow	Strategic Risks and Impediments Strategic Information Quality Initiative Alignment to Strategy Budget Allocation Employee Empowerment and Engagement Execution Capability	Market Share Market Analysis Innovation Index
	Development Value Stream Performance Technology Attrition	Value Chain Performance Plan Execution Rate Investment Efficiency Strategic Risk and Impediment Resolution Flow Communication Effectiveness Employee Retention	Customer Retention and Growth Revenue Growth from Initiatives Objective Achievement
Portfolio	Technical Investment Plan Strategic Execution Alignment	Initiative Pipeline Capacity Forecast Portfolio Health Portfolio Risks Key Person Risks Competence Index	In-process Inventory Lifecycle Horizons Product Health Value Differentiation Customer Satisfaction Investment Decision Criteria Revenue Forecasts
	Product Releases Risk Variability	Ability to Execute Portfolio Delivery Flow Portfolio Risk Flow Strategic Initiative Budget Variance Portfolio Resource Utilization Efficiency	Initiative Health Hit-Miss Ratio Benefits Realization Customer Satisfaction Long-term Financial Performance
Product	Delivery Frequency Delivery Cycle Time Deployment Frequency Deployment Success Rate	Dependency Map Risk and Impediments Flow Risk Escalation Frequency	Product Backlog Size Feature Lead Time
	Release Frequency Release Quality Service Quality	Delivery Flow Efficiency In-Process Inventory Constraint Performance Product Risk Flow	Product-Market-Fit Product Usage Net Promoter Score (NPS) Feature Time-to-Market Customer Growth and Churn
Team	Continuous Delivery Performance Mean Time To Detect (MTTD) Mean Time To Restore (MTTR) Code Quality Automated Test Coverage	Skilling and Competencies Innovation and Ideation Rate Process Throughput Rate Known Risks and Impediments Impediment Resolution Throughput Impediment Escalation Rate Process Flow Efficiency	Customer Proximity Feedback Quality User Research
	Continuous Integration Performance Technical Debt Mean Time Between Failure (MTBF)	Ability to Execute Meeting Effectiveness Team Morale and Satisfaction Employee Retention Rate Process Throughput Yield	Inventory Dead Features Customer Engagement Customer Feedback

The organizational levels

This section contains information about the various organizational levels referenced above.

Strategy level

The Enterprise Strategy level defines the long-term direction, vision, and objectives of the entire enterprise. It plays a crucial role in setting the overall course for the organization and aligning it with its core values and mission. This level focuses on making strategic decisions that guide the allocation of resources, determine key initiatives, and ultimately drive the success and growth of the business.

In addition to defining the strategy, this level is also accountable for communicating the strategic direction throughout the organization. Effective communication ensures that all employees understand the vision and are aligned with the organization's goals. It also enables teams at lower levels to make decisions that are consistent with the overall strategic direction.

The Enterprise Strategy level contributes to the organization's success by providing a sense of direction and focus. It helps prioritize initiatives, allocate resources effectively, and avoid wasteful activities that do not align with the long-term goals. This level fosters a cohesive and unified organization that works towards a common purpose. It provides a roadmap for other levels of the organization, allowing them to plan and execute their work in alignment with the broader strategic objectives.

Portfolio Level

The Portfolio level in an organization is responsible for managing and optimizing the collection of projects, programs, and initiatives that collectively contribute to achieving the enterprise's strategic objectives. This level exists to ensure that resources, including financial, human, and technological, are allocated efficiently and effectively across various value streams and projects, aligning them with the overall business strategy.

Portfolio management plays a vital role in evaluating initiative proposals, assessing potential risks and benefits, and determining their strategic fit. This includes analysing factors such as expected outcomes, investments, resource requirements, and potential impacts on other ongoing initiatives.

Additionally, a portfolio fosters alignment and collaboration between different business units and departments by coordinating initiatives and ensuring they complement each other. The Portfolio level avoids duplication of efforts and helps maintain a clear focus on the enterprise's overall strategic direction. This enables the organization to invest in the right initiatives at the right time, and make informed decisions about staffing, resource allocation and project prioritization. This level also provides visibility and transparency into the status and performance of the entire project portfolio, helping stakeholders track progress and make data-driven decisions.

Portfolio agility facilitates strategic agility, allowing the organization to adapt its portfolio in response to changing market conditions and emerging opportunities. By regularly evaluating and adjusting the portfolio based on business needs and performance data, the Portfolio level ensures that the organization stays on course to achieve its strategic goals while remaining responsive to dynamic market forces.

Product Level

The Product level in an organization is focused on delivering value to customers through the creation, enhancement, and management of products and services. This level is dedicated to understanding customer needs and preferences, translating them into actionable product features, and ensuring that the delivered products meet high-quality standards and align with the overall business strategy.

At the Product level, product managers, product owners, and cross-functional teams work collaboratively to design and develop products that address customer pain points and fulfill market demands. They define the product vision, strategy, and roadmap, taking into account market research, customer feedback, data analytics, and business objectives.

The Product level is responsible for understanding market trends, customer preferences, and competitor analysis. They use this information to identify market opportunities and define a clear product vision that aligns with the enterprise's strategic goals.

At the product level, people work to deliver customer-centric products that create value and drive customer satisfaction. Through effective product management, this level ensures that products meet customer needs, are user-friendly, and stay competitive in the market. By continuously iterating and enhancing products based on customer feedback, the Product level helps retain existing customers and attract new ones.

The Product level plays a pivotal role in organizational success by bridging the gap between customer needs and business strategy. It aligns product development efforts with the overall enterprise goals, enabling the organization to build and deliver products that provide value, gain a competitive advantage, and sustain long-term growth and profitability.

Team Level

The Team level in an organization is the operational level where work is executed and tangible results are produced. Each team comprises collectively works towards achieving specific product goals.

Successful teams focus on continuous delivery of working, high quality, shippable product increments. Constant and early feedback from stakeholders and customers enables them to iterate and improve the product rapidly.

The Team level contributes to the organization's success by being the driving force behind the actual creation and delivery of value to customers. By embracing Agile principles and practices, teams become more adaptable and responsive to changing requirements and customer needs. An iterative approach allows them to identify and address issues early, reducing the likelihood of costly late-stage defects.

Ultimately, the success of every organization depends on its teams. Teams are those who have to deliver products on time, operate within given budgets, and meet customer expectations. Self-organised, highly motivated, capable individuals are the keys to excellence in product development.

Closing remarks

While on the one hand, additional metrics mean additional effort - on the other hand, inattention to crucial metrics may lopside and bias decisions and lead to a "Cobra Effect" - that is, people do what makes sense based on the metrics to the detriment of an organization's success. Hence, choosing the right metrics and adequately balancing them is a delicate process.

Setting up a measurement system suitable to your specific organization can't follow a universal recipe - considering context, such as market influences, industry specific constraints and organizational culture is highly relevant to successful measurement. Likewise, abstraction levels should only be institutionalized where necessary.
Are you looking for further guidance? Don't hesistate to reach out to me!

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.

Why Agile Coaches need to care about Delivery Speed

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

An Agile Coach setting themselves up for failure

Cycle Time Matters

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

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

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

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

Don't make it a false dichotomy!

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

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

Verdict

Agile Coaches who discount speed of delivery will struggle

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

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

Conclusion

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

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