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.

The dictatorship of Relativism

Unfortunately, the relativism which permeates modern society is also invading the "Agile" sphere - and thus, organizations. This is especially detrimental because these organizations build software systems which have a significant impact on potentially millions of other people. 

It's all about Perception

Perception is extremely important in how we interact with the world around us. It's the combination of our sensory organs, our experiences and our neural processing which detemines how we perceive a situation. Therefore, people with different backgrounds will have widely different perceptions on the same subject.
Yet, to build up anything sustainable, we need to be as accurate and precise in our perception as possible.

There are still facts

Without trying to harp too much on the Covid pandemy - a virus doesn't care what we would like the situation to be, or whether we believe that it's a significant threat. There's nothing we can discuss or negotiate with the virus and we can't tell it anything, either.
We can't bargain with it, we have to face reality and work our way from there.
The same goes for business figures. And IT. You can't argue with the bank account that it would be nice if it were just a bit more positive. You can't tell a crashing stock market that developers feel bad about it. Your server doesn't care which of its 0's you would prefer to be 1's. What's there - is there. You have to submit and deal with it.

How sustainable is the willful ignorance and denial of the facts that reality confronts us with?

Thoughts and opinions

Is it okay to have a clear opinion on a matter? Yes.
I would even go so far as to state that many people who claim to "have no opinion" are either deceiving themselves or (trying to) deceive others. In some cases, I would go as far as attributing malice. This becomes most obvious in cases where people who profess to have no opinion become militant against someone who voices theirs. If you're really un-opinionated either way, why is that specific opinion so much of a problem?
The scientific approach would be to examine a claim based on the evidence, and if it holds, to support it - and if it doesn't hold, to dismiss it. There is no, and I repeat, absolutely zero reason to attack the person who proclaims an opinion simply for having it. And still, that is what we see. Logic dictates that we must discredit the idea, not the speaker!

Is an open, transparent workplace consistent with censorship and thought crime?

Predictive capability

A general rule of science is that "models with predictive capabilities are better than those without." The quest to increase the predictive capabilities of our models has brought us running water, heat and electricity for our homes, it has given us cars, computers, the Internet - and sufficient food onto our plates.
While arguably, no reputable scientist would say that any scientific model is perfect or beyond scrutiny, we first need to find a case where scientifically validated models and methods do not yield the predicted outcome before we should discard them - especially where they have proven time and again to produce significant benefits.

What are these "better ways of working", compared to the effectiveness of verifiable methods which have been proven to achieve significant improvements?

Patterns

Evolution has ingrained us deeply to recognize patterns. Our brains are wired to seek patterns everywhere, and match to the most probable ones.  When we look at the sky, we see flowers, sheep - and many other things. That is our mind playing tricks on us. But it doesn't discredit patterns as a whole. 

For example: Five people ran in front of a train. They all died. See a pattern there? Do you really need to run in front of a train to figure out what will happen?

Should we dismiss the idea of patterns, and in the same breath apply patterns that have nothing more than anecdotal evidence as support?

Leadership

Especially in times of change, we need orientation. And in almost every case, even a sub-optimal fixture is more beneficial than a complete loss of support. Few leaders think of themselves as beyond scrutiny, and oddly, it's those who do so tend to attract the largest following in times of turmoil.
Is it better to lead or to not lead? When people need direction and are unable to find theirs, it's usually the most ethical choice to set a direction first, and then offer the opportunity for change.

Would we prefer everyone struggle by themselves, denying them the benefits of rallying around an idea they can all agree to?

End the Relativism

Not everything is relative.

There are facts. We can misinterpret, misunderstand or misrepresent them - but they are still there. Instead of soft-cooking the facts, we need to get better at interpreting, understanding and representing them.

Everyone has an opinion. Neither are facts equal to opinions, nor are people who have a clear opinion automatically wrong. We have logic and science to tell us which is which. By celebrating the freedom to have even a wrong opinion, we learn to be respectful towards one another. Reasoning teaches us to sort out the wheat from the chaff.

We need predictability. We can't predict everything, but we can predict more than nothing. The more predictability we have, the more likely we will still be alive tomorrow. Instead of mushing up everything with the terms "complex" and "unknown", we need to simplify as far as possible (but no further) and learn as much as we can.

We rely on patterns. We're really biased in the patterns we observe and how we interpret them. At the same time, there are repeatable and consistent (scientific) patterns and (esoteric) phantasms. The distinction between the two is what brought us to where we are today, for a good reason.

Society is based on leadership. Strong leaders can be a great boon to others. Beneficial leadership can propel hundreds of thousands of people to a better future. If we want to truly help people, we help those who have the potential to lead to do it for the better.

Stop the trash coaching

If you are an "Agile Coach" who:

• institutes a culture of relative interpretations until it becomes impossible to discern what's right or wrong - you're destroying people's ability to make the critical, timely decisions.
• hushes up people who boldly go forward with their opinion - you're instituting a totalitarian system where creativity and courage are impossible.
• constantly harps on everything being unknown - you're removing the very basis of what makes a company successful: understanding.
• rejects well-established patterns and methods because allegedly, those things don't exist "in the Complex" - you're not reducing complexity, you're pulling in chaos!
• denies the value of proper leadership - you're opening the door towards anarchy and decay, not towards teamwork or growth!

None of these things are helping your client grow. These destroy people's ability to do the right thing.

Do the right thing

Forget the labels. It doesn't matter whether we're called coach, consultant, advisor or whatever.
The client has a problem to solve, and they need help. Guidance. Support. Whatever. You're there to make a positive difference.

When the client needs to:

• Figure out what's going on - establish what we know and what we don't know. Don't pull that which is known into chaos. 
• Get the facts straight, help them get the facts straight. Institute metrics, create transparency. Collect data. Gather evidence. Minimize bias instead of dwelling on it.
• Have reliable methods or techniques - start with the ones that have proven to be most reliable, then inspect and adapt from there. We don't need to re-invent the Wheel, and we most certainly don't need placebos or magical thinking.
• Get out of a mess quickly - lead and teach others how to do that. Don't let people stranded or disoriented when every minute counts. There's time for talk, and time for action.
• Move forward - show the way. It doesn't matter whether you "help them find theirs" or you just bluntly tell them what your opinion is. Break the "analysis-paralysis". Companies have business to do. It's better to revise a wrong decision than to remain indecisive or lost.

By doing these, you will be a tremendous help to the people around you, and a good investment for your clients.

Conclusion

While it's good to check the adequacy of our mental models: People to whom everything relative, or who promote the idea that everything needs to be discussed and strong decision-making is off-limits do not belong into business. Especially not into IT.

When you identify problematic stances and behaviours in your "Agile Coaches", get rid of them. Quickly. They will do more harm than good.

And if now you conclude that I don't have a "proper Agile Coaching mindset", that's totally up to you. I don't see "Agile" as an esoterical space where everything goes and nothing is true - I see it as a company's ability to do the best possible thing, swiftly and reliably. And that requires knowing what "the best possible thing" is. Where that conflicts with the label "Proper Agile" - so be it.

The six terminal diseases of the Agile Community

The "Manifesto for Agile Software Development" was written highly talented individuals seeking for "better ways of developing software and helping others do it." Today, "Agile" has become a 

playground for quacks of all sorts. While I am by no way saying that all agilists are like this, Agile's openness to "an infinite number of practices" has allowed really dangerous diseases to creep in. They devoid the movement of impact, dilute its meaning and will ultimately cause it to become entirely useless.

The six terminal diseases of "Agile"

In the past decade, I've seen six dangerous diseases creep into the working environment, proliferated and carried in through "Agile". Each of these diseases is dangerous to mental health, productivity and organizational survival:

Disease #1 - Infantilization of Work

"Hey, let's have some fun! Bring out the Nerf Guns! Let's give each other some Kudos cards for throwing out the trash - and don't forget to draw a cute little smilie face on the board when you've managed to complete a Task. And if y'all do great this week, we'll watch a Movie in the Office on Friday evening!" Nope. Professionals worth their salt do not go to work to do these things, and they don't want such distractions at work. They want to achieve significant outcomes, and they want to get better at doing what they do. Work should be about doing good work, and workers should be treated like adults, not like infants.

An agile working environment should let people focus on doing what they came for doing, and allow them to bring great results. While it's entirely fine to let people decide by themselves how they can perform best, bringing kindergarten to work and expecting people to join the merry crowd is a problem, not a solution!

Once we have mastered disease #1, we can introduce ...

Disease #2 - Idiocracy

Everything is easy. Everything can be learned by everyone in a couple days. Education, scholarism and expertise are worth nothing. Attend a training, read a blog article or do some Pairing - and you're an expert. There's a growing disdain for higher education, because if that PhD would mean anything, it'd only be that the person has got a "Fixed Mindset" and isn't a good cultural fit: Flexible knowledge workers can do the same job just as well, they'll just need a Sprint or two to get up to speed! 

And since we're dealing with idiots now, we can set the stage for the epic battle of ...

Disease #3 - Empiricism vs. Science

I've written about this many times - There's still something like science, and it beats unfounded "empiricism" hands down. We don't need to re-invent the Wheel. We know how certain things, like thermodynamics, electricity and data processing work. We don't need to iterate our way there to figure out how those things work in our specific context.

Empiricism is used as an  idiocratic answer from ignorance, and it's increasingly posed as a counter to scientific knowledge. Coaches don't just not point their teams to existing bodies of knowledge - they question scientifically valid practices with "Would you want to try something else, it might work even better?" The numbers don't mean anything - "In a VUCA world, we don't know until we tried." - so who needs science or scientifically proven methods? Science is just a conspiracy of people who are unwilling to adapt.

Which brings us into the glorious realm of ...

Disease #4 - Pseudoscience

There are a whole number of practices and ideas rejected by the scientific community, because they  have either failed to meet their burden of proof, or failed the test of scrutiny. Regardless, agile coaches and trainers "discover", modify - or even entirely re-invent these ideas and proclaim them as "agile practices" that are "at least worth trying". They add them into their coaching style or train others to use them. And so, these practices creep into Agile workplaces, get promoted as if they were scientifically valid, and further dilute the credibility and impact of methods that are scientifically valid.
NLP, MBTI and the law of attraction are just some of these practices growing an audience among agilists.

And what wouldn't be the next step if not ...

Disease #5 - Esoterics

Once we've got the office Feng Shui right, a Citrine crystal should be on your desk all the time to stimulate creativity and help your memory. Remember to do some Transcendental Meditation and invoke your Chakras. It will really boost your performance! If you have access to all these wonderful Agile Practices, your Agile Coach has truly done all they can!

(If you think I'm joking - you can find official, certified trainings that combine such practices with Agile Methods!)


Even though it's hard, we can still top this with ...

Disease #6 - Religion

I'll avoid the obvious self-entrapment of starting yet another discussion whether certain Agile approaches or the Agile Movement itself have already become a religion, and take it where it really hurts.
Some agile coaches use "Agile" approaches to promote their own religion - a blog article nominates their own deity as "The God of Agile" (which could be considered a rather harmless cases) - and some individuals are even bringing Mysticism, Spiritism, Animism or Shamanism into their trainings or coaching practice!

Religion is a personal thing. It's highly contentious. It doesn't help us in doing a better job, being more productive or solving meaningful problems. It simply has no place in the working environment.

The Cure

Each of these six diseases is dangerous, and in combination, their harmful effect grows exponentially. At best, consider yourself inoculated now and actively resist against letting anyone induce them into your workplace. At worst, your workplace has already contracted one or more of them.

Address them. Actively.

If you're a regular member (manager / developer etc.) of the organization that suffers from such diseases: figure out where it comes from and confront those who brought in the disease. Actively stop further contamination and start cleansing the infection from your organization.

If you're a Scrum Master or Coach and you think introducing these practices is the right thing to do: if this article doesn't make you rethink your course of action, for the best of your team: please pack your bags and get out! And no, this isn't personal - I'm not judging you as a person, just your practice.

Five signs you've got the wrong agile coach

You've set out to begin your organization's "Agile Transformation" and, lacking the expertise, you've brought in external consultants and/or coaches to make the endeavour successful. But since you're not agile yet, how do you know whether you have the right people on board?
Here are a few pointers that will help you identify rotten eggs - i.e. you can be almost certain that after the consultants leave, the show will be over, and best case you've only wasted money for nothing.

#1 - Lack of Battle Scars

Having the seniority to assist another organization in their agile transformation, the coach should have a lot of war stories to tell. Stories of experiments, pitfalls, troubles, joyful moments and cheerful victories. Stories of what they have experienced firsthand (not hearsay!).
What people tried, what they set out and where they landed - the differences between intent and destination, the obstacles and dangers on the journey - the small nudges that made the difference and so on.

If you see that the coach either has little to say from personal experience or is only quoting others ("double-hearsay"), beware!

#2 - A shelf full of solutions

It doesn't matter what your problem is, they already have the bottled solution ready! Just follow their advice, and you will become Agile. NOT!

Especially when they promote solutions as a silver bullet, i.e. universally applicable without concerns for context - you're in for trouble.

#3 - Change without change

Following pre-concocted agendas, outlining the change on fancy slide decks without ever talking to the people doing the actual work or knowing the real struggles they have isn't going to work.
The first three questions I would expect to ask: "Why would you want to become Agile?", "What will be different in a year?" and "What have you tried so far?".
If there are no comprehensible answers to these three questions: what exactly do you expect as a result?

#4 - Not rocking the boat

Many experienced consultants have learned to avoid challenging status quo and messing with people in positions of power. This is a great approach to maximize the amount of billable hours and to please those who decide whether their contract will be renewed.
As attributed to Einstein, "Problems can not be solved with the same mindset that created them.", it's essential to rock the boat - to identify and tell people about the root cause assumptions which lead to the problems that an agile transformation is supposed to solve. And if key decision makers aren't aware how they are contributing to the problem - how would they know what they must change to solve it?

Consultants who only compliments senior management aren't going to make an impact.

#5 - We've got this!

Probably the killer criterion for spotting fake coaches: They can do it by themselves! They have so much experience and expertise that whatever is brought to them, they have the right answer. Senior management doesn't need to involve at all, because the coach knows how to handle everything. Teams don't need to worry, because the coach will teach them everything they need to know.

The coach who offers the solution without teaching you how to find your own solution - doesn't help you learn, and if you don't become a learning organization, you're not going to be agile.

Conclusion

I would like to conclude with my favorite TheraminTrees quote, "People who don't want you to think are never your friends!"

A "coach" who doesn't make you think and challenge how you think - is the wrong coach.


Sour aftertaste? 
Let's fix this: Here are ten signs you might just have found the right coach!

Clearing our own mental model

In the wise words of Marshall Goldsmith, "For everything you start, you need to stop something." - when we are embarking a new journey, we need to throw out some old ballast. One of the biggest burdens we carry around are our own mental models, shaping our perception of reality and therefore, our thoughts, behaviours and actions. When was the last time you did some housecleaning for your own mental model?

How our mental model affects us

Everyone builds a mental model based on at least three assumptions:

1. Reality exists
2. We form a model of reality through interaction and observation
3. Models with predictive capability are better than those without

From that starting point, we are building everything we consider "real". Probably the most noteworthy assumption is #2. It indicates that during every single second of consciousness, we are shaping our model of reality.
Our mental model of reality has assumed it's current shape from the second we were born until today. Each aspect and angle of this model is based on observations, interaction and deduction.
Our choice of action is then determined by the outcome we predict based on our own model.


The problem with our mental model

"All models are wrong, some are more useful than others" - another quote I picked up somewhere.
We do not know reality. We can't. We only can form a "pretty likely model of reality" - and that model only exists in our mind! The shape of our mental model is determined by the interactions we had - and the observations we made. Since we are neither omniscient nor omnipotent, we didn't have some important interactions and haven't made some important observations - or have misinterpreted some observations.
This means our mental model of reality usually suffers from three key drawbacks:

1. Incompleteness
2. Inconsistency
3. Incongruence

Incompleteness means that there are events beyond our comprehension.
For example: I don't understand why there are black swans in Australia. I have never bothered to learn how this came to be, so I couldn't explain why Swans can be white or black, but not green.

Inconsistence means that if we scrutinously considered everything we know, we would realize that multiple things we assume as "true" individually can't be "true" together.
For example: I consider Tim to be a nice person, and I am aware that Tim is not nice to Alice - so what is it then? Is Tim nice - or not?

Incongruence means that different people models of reality may either fail to overlap (I know what you don't) or mismatch (I think this is true, you think it's false).
For example: The UKIP supporters think it's good to leave the EU, while the EU proponents think that's a terrible idea. Either party drew their conclusion based on a number of assumptions and facts that may either be unknown, weighted differently or dismissed by the other party.


Mental model housekeeping

To do some proper housekeeping, we need to be aware of the following:
1. Our mental models are just that - models.
2. We benefit from having a more accurate model.
3. Incongruent models can be aligned through open interaction with other people.

Now, let us discuss some methods for doing this housekeeping:

Aligning concepts

We have so many inconsistent concepts, just like the one above.
Once we become aware where these inconsistencies lie,
we can uncover the reason why we have these concepts.
Next, we formulate a hypothesis for the conflict, then design an experiment to disprove at least one of the concepts.

It could be that we failed to disprove any of them - in which case, we probably haven't dug deeply enough and need a better hypothesis.
It could be that we managed to disprove all of them - in which case, we may need to forget everything leading us to either conclusion.

If we disproved all but one of them, the best way forward is to discard the ideas that no longer hold true. Especially in this case, it could be that even what we believe now is still wrong: We just don't know until we have more information.

How do I align concepts - in practice?
It's quite simple. When I discover that I have conflicting ideas, I mentally rephrase "Tim hates me." and "Tim is a friendly person" into "I assume Tim hates me". Then, I ask myself, "Why would Tim hate me?" - then I may go to Tim, and be quite upfront: "I feel we don't get along very well.". Tim might meet that with an unexpectedly friendly: "What can I do so you feel more comfortable?" - my first assumption is already invalidated. My model is more consistent now.

Pruning loose ends

We are bound by so many concepts that arise seemingly without reason. 

For example, Tim said something bad to me yesterday - and now I have the concept "Tim doesn't like me". My concept is not founded on a sufficient amount of evidence.
This concept now binds my interactions with Tim, even though it is merely a loose end in my mental model. The more loose ends I carry around, the less freedom I have in my interactions with my environment.

Through introspection, we might drill into the "Why" of picking up this loose end and tying it to our model. In our attempts to do this, we complicate our model by adding numerous assumptions without any foundational evidence.
We need to become aware of what our "loose ends" are - and consciously discard such concepts.
This helps us form a more consistent model of reality.

This approach is based on Occam's Razor, the suggestion that "The model relying on the fewest assumptions is often the best"


How do I prune loose ends - in practice?

Tim might actually have said to me "Dude, you messed that one up." I can now integrate that sentence into my model right away, filling the missing gaps with unspoken assumptions, one of which may be "Tim doesn't like me". I can also choose to simply say "Yup", and regardless of whether I agree with Tim or not, I simply don't attribute these words to my understanding of Tim's relationship with me.

In retrospect, I may need to be aware that "Tim hates me" and question myself, "How much evidence does support this concept?" - unless the evidence is already overwhelming, the easiest thing may be to simply go to Tim and say, "Want to have a chat?", seeing if that chat generates evidence to the contrary. 

Probably the hardest way of pruning loose ends is to drop the concept as it pops up. Since our concepts are hardwired in our brain, pruning like this becomes a difficult exercise of psychological intervention: becoming aware of the dubious concept, then redirecting thoughts into a different direction when the concept manifest. This method does not resolve the underlying inconsistency and is therefore unhelpful.

Resolving dissonance

My concepts often don't match your concepts, because neither my experience nor my reasoning process is the same as yours.
The "easy way" to resolve dissonance is war - just get rid the person who doesn't agree with you. Unfortunately, that doesn't mean that your model of reality got any better.
When our own strive is to obtain the best possible model, we need to attune our model based on others' ideas and reasoning.

First, we need to expose ourselves to others' thoughts.
Then, we need to discover where our thoughts mismatch those of others.
Next, we try to uncover which assumptions lead to the mismatch.
Together, we can then form a hypothesis of which assumptions are more likely.
Then, we can begin aligning concepts together, coming up with a shared model that is more congruent.

Resolving dissonance requires two additional key assumptions:
1. It could be that my model is wrong.
2. I can find out enough about other models to integrate a portion into my own model.


How do I resolve dissonance - in practice?
Nothing easier - and nothing nothing harder than this. Just talk. Unbiased.
Have an open conversation without predetermined outcome.

Punching holes

We typically assume that what we know and observe is true. Then, we build new assumptions on that. Very rarely do we spend time trying to disprove what we know.
The Scientific Method is based on the idea that we can't prove anything to be true, but we can prove something to be not true. We consider as "probably a good explanation" by exclusion, i.e. when every experiment to prove that the opposite failed. So, our goal should be to come up with an experiment to prove us wrong.

We can improve our mental model by using this approach to try and punch holes into our model.
If we succeed - our model is bad and we can discard the assumptions we just invalidated.
If we don't succeed - it still doesn't mean our model is "right", it only means that it's the best we have for the time being.


How do I punch holes - in practice?
When my model assumes "Tim is unfriendly", the most effective way to punch holes is creating situations where I am exposed to Tim in settings which minimize the likelihood for him to be unfriendly.

Summary

Frequent clearing our mental model is very helpful in improving our understanding of the world around us - and our interactions with others.

The exercise of cleaning always requires the following:
1. Being consciously aware of our assumptions.
2. Doing something about it.
3. Never being content with our current understanding.

Simply starting is the best way.

Are you an organizational catalyst?

The newest buzzword in the agile community is "Catalyst". The Scrum Alliance considers being a "Catalyst" an essential part of being a coach and an agile leader. It's actually taken from the book "Leadership agility" by Bill Joiner.
It's always funny to hear coaches talk about the need to ask questions and reflect on your own behaviour, then doing exactly the opposite by unquestioningly adopting buzzwords. They have picked up something that seems to sell well and are now following in herd mentality. Since "agile coaches" are promoting something they don't even understand themselves, let me take some time to explain what a "catalyst" actually is!


The myth: "A catalyst speeds up a transition into a new state".
That's actually true, but you need to understand how a catalyst does that.
Catalysis is a highly complex chemical process with lots of constraints that one should be aware of when using the term.

No Philosopher's stone

A universal catalyst ("Philosopher's stone") that can make any kind of change happen does not exist.
Every catalyst is a "one trick pony" that can do only one thing in a very restricted context. In a different context, a catalyst will be useless or even an inhibitor. Do you really want to be good for one thing, and only that one thing?

Energy parity

The definition of a catalyst states, "In the presence of a catalyst, less free energy is required to reach the transition state, but the total free energy from reactants to products does not change"

This may be understood as "less energy is required". No: It means less energy is required to reach the transition state, but the total amount of energy to reach the goal does not change!

Let's translate what this means: The catalyst destabilizes the system in an otherwise stable state. Then, it channels the energy difference throughout the change process. All consumed energy is lost, and all the remaining energy must be invested before the catalyst is out of the system. The catalyst actually binds energy until the process ends.
The catalyst takes a massive active role in the change process. Typically, not much would happen without the catalyst. Every single aspect is being modified by the catalyst on more than one occasion.
The catalyst is an extrinsic change funnel, which in an agile context is equivalent to stating that the change is imposed on the target. A catalyst completely destroys autonomy.

Irreducible complexity

Catalytic reactions are highly complex. Scientifically, a catalytic reaction looks like this:

1. X + C → XC
2. Y + XC → XYC
3. XYC → CZ
4. CZ → C + Z

The same process, without a catalyst, would look like this:

1. Y + X → Z

The catalyst is an essential component in every stage of a catalytic process, and there is no direct relationship between start and end of the process, although the catalyst is not necessary for the process to take place. Not only is the catalytic process significantly more complex than necessary, it may be impossible to figure out the natural relationship between X,Y and Z if one has never observed the reaction without presence of the catalyst.
The catalyst becomes "irreducible complexity" and hides the simplest way to reach a goal.

Bottleneck

A catalyst "participates in the slowest step of a reaction, and rates are limited by amount of catalyst and its activity."

This simply translates into "The catalyst is the bottleneck of change."

Potentially unsustainable

A catalyst "does not change the energy difference between starting materials and products."

This also means that the energy difference between the starting point of the change and the endpoint thereof is independent of the catalyst. Catalysts can induce highly unsustainable change that would not have happened without them. Catalysts might even be the cause for creating an unstable system.

Value neutral

Catalysts also "do not change the extent of a reaction".

This is basically stating that the same result could have been achieved without the catalyst by investing more energy. Effectively, this means that the presence of the catalyst really only reduces the energy investment, but it does not add any extra value.

Change exempt

Let's close this discussion with the final straw: A catalyst, by very definition of the word, "remains unchanged after the reaction."

What this means: While the catalyst did put a lot of effort into the change, the catalyst ultimately was not changed. For the catalyst, the change was just a temporary thing that is completely brushed off, left without a trace.

Should you be a catalyst?

Let's sum this up: An organizational catalyst is someone who:

• Is a one trick pony potentially causing damage with their involvement
• Does something that could happen in different ways without them
• Starts processes that can't be terminated until all energy has been spent (i.e., removes agility)
• Interferes dramatically with others' autonomy
• Adds significant complexity which can no longer be taken out of the system
• Becomes a massive bottleneck and Single Point of Failure
• Hides the real change going on from those who are involved
• Does not learn anything from what they are doing

Decide for yourself.

Be careful of so-called "agile coaches"!

An agile coach is supposed to help agility "stick" within an organization. But that is not always the case. Unfortunately, the label "agile coach" is not a protected trademark. Anyone can wear that title. As such, there is a huge risk that the so-called "coach" will do more harm than good. Caveat emptor!
Here are a few stories of what "agile coaching" I have experienced so that you can actually avoid it. As a disclaimer: I do not consider all agile coaches to be quacks. There are a few whom I highly respect. But there's a lot of quackery giving them a bad name - and not many talk about it.

Purposefully unhelpful 

Probably the most idiotic phrase in the arsenal of an "agile coach" is "You need to find this out by yourself". Of course, that is supposed to inspire self-learning. But honestly. Not everyone wants to learn everything by themselves. Here's my story:

I just came into a new enterprise as a consultant. I asked the team coach "What's the wifi password?" - "You need to find that out by yourself"

This guy was serious that I should rather learn the WiFi password by myself than have someone "tell" me. Dude. I can paint a picture of a stick-man, label it "agile coach" and it'll be more useful than such a coach. Why do people even hire coaches who can't even discriminate when self-learning makes sense?

One trick pony

They say that for a coach, moderation, conflict management, coaching and mediation are key skills. This has the unfortunate side effect that we see "agile coaches" popping up who are domain experts in these exact subjects - and nothing else! Meaning: They are sociology or psychology majors who have never written a single line of code and are now trying to teach developers how to work better. Here is my story:

I was working with a team that faced numerous difficulties. One of these was the lack of a coach. So, they hired one who was really good at talking and creating a positive mood: Actually, too good. Unfortunately, this person had only ever attended a 2-day Certified Scrum Master course and NEVER worked with a software development team.
They had zero knowledge of things like technical debt, Continuous Integration, software testing or other engineering practices - not even PO stuff like backlog management, value prioritization or right-sizing the work!

The team was going in full circles, continuously struggling to figure out stuff "everyone knows" and caught management attention eventually because of high defect rates and unusually low throughput. It was blamed on the developers. The team got disbanded and forcefully rearranged. The "coach" never realized anything was wrong - because hey, the team was always happy and learning!

Feigned expertise

How can you coach something you're actually clueless about? It seems that for some "agile coaches", agile experience is truly optional. They think that having a couple certifications qualifies you and give themselves a label of expertise they do not actually possess. Here is my story:

I am occasionally meeting with an "agile enterprise coach" (CSP) to discuss about the various problems they face. Based on their CV, they've got a decade of "agile experience". At first I was befuddled when they started asking me trivial questions about stuff like backlog prioritization or why people limit WIP. I realized that this person had never really worked in an agile way: They had no idea what the real purpose of Continuous Integration was, they had never even attended, much less moderated a Retrospective - and they haven't actually seen what a workable Product Backlog looks like!

Oddly enough, this person is seriously working in enterprise agile transformations, introducing Scrum to teams, even coaching/educating internal Scrum Masters and managers. Looking behind the scenes revealed that things could have been done within weeks that their clients are still struggling with after years.
Seems like the old conmen statement "There's a sucker born every minute" still holds true.

Hiding incompetence

A coach can always conveniently hide between "stimulating self-learning". I'd call it more fair to say "Some things I know. These I will help you with. Other things, we'll learn together". Especially in the latter category, I personally call it un-ethical to climb on a pedestal and profess to guide others' learning journey. But here's my story. I heard it over a cup of coffee with an upper manager:

A large product group tried to adopt Scrum for the development of an important product a good decade ago. Long story short, 500-people Scrum is not the same as one team. So, they had, "challenges". And since they couldn't figure out any way of getting past a specific one, they spent major bucks and flew in a highly reputable "Scrum coach" to make progress. For two hours the coach answered every question with a counter-question or reframed it. But the client felt there was no substance. Finally, the manager's collar popped and he bursted out: "Now tell me, ONLY with a Yes or No: Do you know how to solve this problem?" Pushed into the corner, the answer was "No". At which point, the manager exploded: "Then this meeting was 100% waste." Not only did they never try to approximate a solution or give helpful pointers, they simply left the client stuck with an unresolved problem. Even years after, to that manager - and their peers - "Scrum coaching" is associated with that specific name and has a very sour aftertaste. 

It should be fairly easy to state what your competencies are and what aren't. It's fair game to state that you don't know everything. But when others rely on your help, it's unfair to leave them hanging.
Note how "problem solving" is not mentioned by coaches as a coaching skill.


Getting away from the stuff that I would actually call fraudulent, where the client's ignorance of one's own incompetence is used to make a quick buck, let us now turn to the softer area of mindset.

Unable to see the big picture

Good coaches should be unbiased, because bias prevents us from seeing the big picture. Reflection and self-awareness help us to overcome bias to serve others better. Or: So is the theory. Some of the most biased people I have met in my life bear the title of "agile coach". Their bias is so incredible that they try to convince me of silver-bullet solutions that simply won't work in context. Here's my story:

I was once working with a company that had a HUGE quality issue: Their legacy product was a technical garbage heap: Developers literally had nightmares about the code base. Some threatened to quit were they forced to dig into that mess any deeper. Customers were rioting, Customer support was desparate. Customer problems (such as: lost orders, missing payments, wrong products shipped) never got fixed. I like to name things the way they are. When a customer spends money for A and then gets B, that's a DEFECT. A failure that the customer does not want. Period. So, I was fighting tooth and nails with management to limit WIP and value-prioritize defects so that we could actually drive down defect rates. The results were splendid: Customer Service actually started giving names to developers that were no longer synonymous with "monkey". Anyhow. Comes along this veteran "agile coach" who suggested "You shouldn't call them defects. Wherever I go, the first thing I do is to remove that label. This will cause an important mindset change!"

I spent over an hour mostly listening to why it's important for the team that the PO treats all the work equally. They didn't even account for the fact that "defect", in that case, was not merely a label but a metric to draw attention to the horrible technical mess, so that we could have sufficient power to weigh the need for a long-term technology change against the need for short-term business evolution (i.e. new features).
I did get their point, but I saw they didn't get mine. And they didn't care to.

Misunderstanding assumptions

As I stated elsewhere, people can and do make assumptions all the time. We navigate in what we perceive as "reality" by making and deriving assumptions. And some of them are inconsistent with each other or with evidence presented. As such, we should always be ready to anabdon our assumptions in favour of better ones. "Five Why" analysis can help us explore our assumptions. But some people just don't get it. Here's my story:

A team gathered for their retro. Within a few minutes, they simply decided "We need to write more unit tests". So, the team dug out their Five-Why tool: "Why?" - "Beacuse we have too many defects" - "Why?" - "Because we don't have enough unit tests." - "Why?" - "Because we didn't think they were that important." - "Why?" - "Because we didn't know." - "Why?" ... - "Dude, shut up your food hole!"

This team had already learned their lesson, but the coach made it look like there was more to it - down to the point where they really just got nauseating. "Five Why" is one of many ways to uncover false or misleading assumptions, but there's a point where it's fairly safe to simply let it go. A coach should not dig out all assumptions. They should be aware which assumptions are reasonable and which are unreasonable.

Wrong focus

Agile coaches might focus on the wrong things when they miss the big picture. Especially when their understanding is limited, they will quickly optimize in the wrong direction. Here's my story:

I was working with an organization where a certain middle manager always tried to impose their specific ideas (such as: separated test team, using HPQC rather than spock etc.) on teams. As i was doing my best to rally management support for the teams' ideas, I got into the line of fire from that manager. Basically, he was undermining the techical quality measures built by the teams with an email to ALL the PO's and coaches. So, I replied to ALL, because I wanted ALL to take a stand. What happened? This "agile coach" suggested introducing business email etiquette rules, because they felt bothered by a Reply-All on a matter they considered personal between me and the manager. So, we had etiquette rules enforced. Great! Problem solved! ... About half a year after I left, the manager won - now they have a Test Department reporting test results in HP-ALM. But hey, at least they have formal email etiquette rules!

It's actually quite funny how often agile coaches propose a solution without engaging in direct dialog with the concerned parties - and without trying to understand the problem they are solving. There was no mediation sesssion held to uncover why the conflict actually existed. The real problem never got solved. Neither any of the many coaches nor any PO bothered to understand the fundamental problem.

Conclusion

Am I perfect and pointing fingers elsewhere? No. I undoubtedly have some communication issues and maybe many of the situations I encountered would have turned out different if I had known how to better communicate. But I learn.
However, I would also expect "agile coaches" to bring honour to their profession.

When the solution isn't known, approximate. But be straight about it. Never claim to help others with things you don't understand: That's fraud.

Especially from a coach, I would expect the following: Be fast to learn, but slow to judge. Engage in dialog. Never decide before verifying your own assumptions. Be ready to discard your preformed assumptions. Don't draw biased conclusions. Let people know when you don't know.

It's called PDCA for a reason: Never act before checking. And, from a coach, I'd expect that to be a double check.

Don't play games: a coach is not a mad scientist!


Final disclaimer: I do not consider all agile coaches to be quacks. There are a few whom I highly respect.

Agile learning for starters

I have previously discussed the "cost of learning" and it's impact on the learning strategy. After establishing that we should always keep this cost of learning below the Point of No Return, let us consider the differences in learning. The dogmatic statement "A coach should not prescribe a solution, but foster self-learning", presumes that self-learning is universally the best approach. But is it?

Let us consider which companies/teams typically call for help, based on this simple model:

Do you know why you don't know what you don't know?

There's a hidden relationship to the Cynefin Framework hidden: Software development is a socio-technological problem, and the issues of communication, understanding and skill are just a few factors affecting the team's performance. We work in the complex domain, where any model has an inherent error.
Usually, when a company requests external help, they tend to be basically aware that they don't really know what their problem is and that they assume someone else can help them make progress. In terms of our model, uncertainty is high and people admit that their specific knowledge and understanding of the problem domain is shallow. That's good. It's a basis for learning.

Initiaing problem solving

We have a wicked problem here: How do we know we're doing the right thing - and how do we know we're getting better at it?
A consultant has no choice other than first gaining clarity whether the problem is comparable to a problem where a solution is known, so would first try to drive down uncertainty - by asking questions and experimenting with the process.

If the problem is in a domain where deep expertise is available, the problem solving process is reduced to tapping into available expertise.

If the attempt to reduce the problem to a domain where a solution is known fails, this indicates that we're working in the domain of the Unknown.
This one splits down again:Either, we know that all known solutions fail, in which case we need to innovate - or all attempts to reduce uncertainty failed, which indicates our problem is ill-defined and we need to clarify the problem until we have a workable problem.

Innovative problem solving

If there is need to innovate, we're pretty much clear that we'll be using empirical data, feedback loops, inspect+adapt and experimentation to iteratively anneal the situation. The best thing a consultant can do in this situation is to provide support based on their own experience to discern which experiments make sense and what the available data implies.

There are tons of techniques for innovative problem solving, starting with Kaizen Events, Design Thinking, TRIZ ... potentially even a full blown Design For Six Sigma (not advised). Determining the suitable problem solving technique may also at the discretion of the consultant.

Introducing known solutions

When expertise is available, the consultant must factor in the impact and urgency of getting the problem solved.
Impact is high when there is a risk of crossing the Point of No Return, i.e. destroying the company / team, or have individuals lose life, health or their job.
Urgency is high when you only get one shot.

• If both impact and urgency are high, a dogmatic solution will save time at the expense that the inherent understanding remains low. Autonomous learning is purposefully replaced with prescriptive approach for a greater good.
• If impact is high, yet urgency is low, the consultant may choose to underline the solution process with moments of learning to deepen understanding. This will reduce long-term dependency and the risk for misunderstood assumptions around the solution.
• If the impact is low, yet there is a sense of urgency, the consultant might actually provoke "learning from failure" to create deep understanding for the next time.
• If both impact and urgency are low, the consultant should not invest further time. Providing a pointer on how the team could learn solving the problem can be sufficient. If they learn - good. Otherwise - no harm done.

Summary

In this article, I described only the consultant's approach when the team is lacking knowledge and ability that is available to the consultant. A different approach is required the team's knowledge already exceeds that of the consultant.

A good consultant weighs the costs of learning against the benefits of learning and chooses the optimal approach, carefully considering the tradeoff between short-term results and long-term results.

Innovative problem solving should generally not be used for known solutions, since that approach is inherently inefficient. Although it facilitates learning, it also maximizes the cost of learning.

Peoples who dogmatically insist on facilitating innovative problem to maximize learning solving might force the team to reinvent the wheel when a firetruck is sorely needed. That's not helpful. It's snake oil.
There are times for learning and times for just doing. Know the difference.

Coach, Trainer or Consultant - a false dichotomy

There are a lot of opinions going around on the Internet concerning "coaching vs. consulting". Especially coaches who like to discern their position will pose this question and suggest that consulting is somehow inferior to coaching. Let's leave the emotional aspect out of this and reduce this to assumptions. In this article, I will include "training" as well, because of the significant overlap. 

The model

For all three services (coaching, consulting, training), there's two sides involved: Service provider and service taker (client). Both make assumptions about themselves and about the corresponding other party. For simplification purposes, we will not list all assumptions, but focus on the essentials that are related to learning.

Underlying assumptions for each role

Interpretation of the model

The first thing we should be clear about is that these are all just assumptions.
Since they are assumptions, it's good to clarify that both client and service provider have the same understanding of these assumptions beforehand, since they define expectations.
These assumptions are not axioms, since each variable can be verified objectively by asking questions and observation. Neither client nor service provider should turn any of these assumptions into dogma and insist they be true regardless of reality. You must accept that any of them may turn out invalid at any time.

Provider responsibility

For each of the three roles, the service provider is expected to have a clearer understanding of the big picture than the client. As such, regardless of whether you are coach, trainer or consultant - you need to be actively on the lookout whether the above assumptions are valid. One skill you need to bring to the table is the ability to realize when they are invalid, because it breaks the model of your role. When they are invalid, you must take steps beyond dogmatic insistence on the definition of your role in order to move into the direction of success.

Client responsibility

The main reason for getting help is that you don't really know what you may need to know. Your initial assumptions may be invalid because of what you did not know. Given better information, you need to adjust your course of action accordingly.

Application

Roles are really just transient. 

It's probably easiest for the trainer who provides a specific training service to stick to the agenda and simply leave. Worst case, the training did not help and the very limited few days of training are wasted. However, even trainers often add coaching techniques and modules to their trainings where they actively generate learning with their clients. In rare cases, that may turn into consulting sessions. When a trainer leaves, the client should have an appetite to try out the training knowledge and learn more.

The line is significantly more blurry for coaches and consultants.

The best thing a consultant can do is enable the client to solve the specific problem and related problems individually by producing learning within the organization. This may include domain-specific trainings in skills the consultant provides and coaching key players in doing the right thing. When a consultant walks out, the client should be able to say "From here, we can move forward by ourselves." - which is the best thing a coach would also hope to achieve.

For a coach, the main difference to a consultant is that there is no specifically defined problem initially and that the coach is not expected to come up with a solution. However, a good coach should understand that there are situations where simply giving a directed pointer to existing solution in order to instill an appetite for learning and experimentation is a good way forward. That's a training situation. Also, sometimes, the coach needs to take carefully considered shortcuts in the learning process to prevent irrecoverable damage: That's consulting. Depending on where on the learning curve the team is, that can be quite a big part of the job.

Summary

Assume that coaching and consulting are two distinct roles and that you are either-or is a false dichotomy. In the same breath, it's an even worse misinterpretation to consider one of them"superior" to the other, because both simply rely on different assumptions. A good consultant will use significant coaching techniques in context, and a good coach will use significant consultative techniques in context as well. "Context" depends on observation and interpretation and is usually very mixed. Be ready to accept this mix. Your actions then also need to reflect this mix.

Being dogmatic on one specific role and insisting on the above assumptions as axioms is done only by people who are unable or unwilling to consider the systemic implications of their own actions. That's snake oil. Caveat emptor.

So, I'm not an agile coach, after all ...

I recently applied for a Certified Enterprise Coach - and got rejected. It took me a while to get over the rejection, and I had some good discussion with one of the application reviewers. What I learned: My understanding of "Coach" is not the same as others. Then I found this post on LinkedIn about what a coach is, and decided: I'm not a coach. I consider that what others promote as "coaching" to be snake oil selling and therefore, unethical. As such, I will gladly refer to myself as "enterprise consultant helping others be more successful by becoming more agile" (short: agile consultant) instead.

So, what are my reasons for stating "I'm not a coach", then?

For now, I'll just sum this as a response to the "Top 5 Criteria of an Agile Coach" delined in the quoted article.

1. An Agile Coach must not own the delivery or the outcome expected from the team.

Would you hire a football coach who openly states that "I'm not responsible for how the team performs!"? Where would you get the idea from that a coach has no outcome responsibility?
There is a difference between short term, mid-term and long-term performance and one must definitely understand the concept of special cause variation. But when I see that my coaching engagement makes no significant difference in the team's performance, then I am not doing my job! Convincing my client that this is how it's supposed to be and that I deserve my paycheck even when my coaching makes no difference at all - is purest snake oil!
My take: An agile consultant keeps an eye on short-term, mid-term and long term capability of the organization and understands the systemic impact of specific choices. They understand that there is often an anticorrelation between short-term and long-term performance and understands when tradeoffs between the two make sense. They are aware that taking a short-term hit in performance might yield long-term learning and growth. Likewise, they understand which short-term performance boosts will lead to long-term disaster. They help agilists make informed decisions to understand the consequences of their actions.

2. An Agile Coach must not try to be a great coach or expect to be loved by the team.

Well ... this is dubious. Your job isn't to be everyone's best buddies, but if you don't want to invest into building a trust relationship, you shouldn't even start. Likewise, it's not about who you are as a coach, but about what you want to achieve with your client. If you put focus on your person instead of on the change you're guiding, you're the wrong person in the wrong place!
My take: An agile consultant is a trusted partner of everyone in the organization, and their greatness is the impact they make, not who they are or what they do. If your footprint isn't felt even years after you left, you're not worth the money. And if people don't reminiscence about your work admirably or positively, you're probably in the wrong business.

3. An Agile Coach must not solve the team’s problems.

I just can't get this image out of my head:
A child fell off the bridge and is drowning. A coach passes by, sees the frantically screaming child and helpfully states "Well, now would be a good time to learn swimming." - and walks off.
There is a time for everything! People who don't understand that and deny help in time of need are not just not coaches, they are inhuman bastards! Now, it's important to understand when is the right time for help in order to not fall into the trap of helper syndrome.
My take: An agile consultant is aware when is the right time for what. They understand that, just like you can't let a 4-year-old child figure out how to drive an SUV in the city center, there are situations which are beyond the teams' current level of expertise. They will take control to prevent irrecoverable damage, they will guide to steer away from disaster, but just like a parent, they will let teams take a few hits here and there in order to be more self-reliant later. In the same way, they might even create challenging situations for people to grow. And they understand when is the time for which approach.

4. An Agile Coach must not stay too long with the same team.

This was stated as maximum 3-6 months. In that time, you can hardly achieve meaningful, sustainable change. I am not even concerned whether that is sufficient to get the team to trust you, think a bit, run a few experiments and make a few changes. However, in challenging environments, this is hardly enough to drive out old habits. Hidden opposition to new ways of working can easily keep low profile for that timespan, especially when they know they just need to outwait you. What I see too often is that once coaches leave, within a few iterations, people are back to the former status quo.
My take: An agile consultant should focus on making an impact that lasts even long after they leave. They are not keen on leaving before the cookie crumbles. They want to contribute something meaningful, and they take as much time as it takes. Understanding Kotter's model of organizational change, they see the entire process of change through before they leave. They help in institutionalizing change, rather than taking off before sustainability is reached.

5. An Agile Coach must not make prior assumptions about the team.

We all make assumptions - all the time - and we can't even think without making assumptions! To assume that we can make no assumptions is ignorant! An agile coach who does not understand the nature of assumptions will not be able to make suitable assumptions and may not catch invalid assumptions in time. This plays right in line with point (4) above - be aware of the dangers that your own model of reality imposes on your work!
My take: An agile consultant must purposefully make critical assumptions and invest time into verifying them without bias using the Scientific method - preferably by finding evidence to discard them in favour of a better model of reality. It's actually good to have a certain set of assumptions and a clear plan how to reject them!
For example, "The people here are lazy" is a useful assumption in the sense that you now have to find a way to disprove it. Evidence-based rejection of this idea will become both the basis of your trust relationship (see 2) abnd the first small victory on your road to excellence. The art of the agile consultant is to find a effective experiments to disprove false assumptions quickly, completely and without a spark of doubt.

Conclusion

I've witnessed too much snake oil selling in the agile community and am pretty much fed up with it. When people try to define the term "coach" as someone who seeks absolution for their inability to make a difference even before engaging a client relationship, I can only advise: Don't hold your breath. Find someone who has the guts to take a stand for what they believe in!
I gladly reject the idea of being an "agile coach" when the idea of coaching is to not help people who need help, not make an impact and spending as much time as possible staying vague and undecided before taking a quick exit and not taking responsibility for their own work.
I do not want to be such a person. If there's nothing I can do for you, I will tell you. When I won't make a difference, I'm wasting your time. I'll jump into the river to save you from drowning, but only until you're out of danger. When you can swim by yourself, I've achieved my personal goal. But I'll be looking for evidence to see that you don't need me.

I am a consultant, supporting your agile journey. My job is done when you're more successful.
Sorry. I don't have snake oil for sale.