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.

Don't be Joe!

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

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

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

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

Here comes Joe

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

Joe is certified

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

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

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

What should Joe have done?

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

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

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

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

Joe focuses

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

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

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

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

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

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

What should Joe have done?

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

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

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

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

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

Joe highlights complexity

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

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

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

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

What should Joe have done?

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

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

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

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

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

Joe shows flexibility

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

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

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

What should Joe have done?

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

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

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

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

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

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

Joe keeps the rules

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

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

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

What should Joe have done?

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

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

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

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

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

Joe protects the team

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

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

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

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

What should Joe have done?

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

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

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

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

Summary

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

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

The Management-Coach clash

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


Upton Sinclair said it all with his famous quote:

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

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

Asserting authority

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

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

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

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

Solution focus

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

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

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

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

Getting people to think

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

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

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


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

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

Defusing the conflict

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

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

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

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

Things that never meant what we understood

We throw around a lot of terminology - yet we may not even know what we're saying. Here are three terms that you may have understood differently from how the original author's intention:

1. Technical debt

Technical debt has been used by many to denote willfully taken shortcuts on quality.
Many developers use the term to imply that code has been developed with poor craftsmanship - for instance, lack of tests or overly complicated structure.

Ward Cunningham, the inventor of the term, originally saw Technical debt as a means of learning from the Real World - software built upon today's understanding incorporating everything we know at the moment put into use. He took the stance that it's better to ship today, learn tomorrow and then return to the code with tomorrow's knowledge - than to wait until tomorrow before even creating any code!

In his eyes, code should always look like it was consistently built "just today", never even hinting that it had looked different years ago. Technical debt was intended to be nothing more than the existence of things we can't know yet.

Technical debt always implied high quality clean code - because that is the only way to incorporate tomorrow's learning in a sustainable way without slowing down.

2. Kaizen ("Continuous Improvement")

Kaizen is often understood as an approach of getting better at doing things.
While it's laudable to improve - many improvement initiatives are rather aimless. Especially Scrum teams easily fall victim of such aimless changes when each Retrospective covers a different topic.

Taiichi Ohno, known as the father of the Toyota System which inspired Lean, Six Sigma - and Scrum, stated, "Where there is no standard, there can be no Kaizen".

Another thing that many of us Westerners seem to be unaware of: there's a difference between Kaizen and Kairyo - with Kaizen being an inward-focus exercise of becoming the best we can be - which in turn enables us to improve the system - and Kairyu being the exercise of improving the system itself. This, of course, means that Kaizen can never be delegated!

Kaizen requires a long-term direction towards which people desire to improve themselves. Such a direction is often absent in an agile environment - short-term thinking prevails, and people are happy having done something which improved the process a little.

What this "something" is, and how important it is in comparison to the strategic direction may elude everyone. And there's a huge chance that when we consider what we actually want to achieve, our "improvements" might even be a step in the wrong direction.
Have you ever bothered talking about where you yourself are actually heading - and why?

3. Agile

"Agile" is extremely difficult to pinpoint.  It means something different to everyone.
Some think of it as a project management methodology, while others claim "There are no agile projects".
Some think of a specific set of principles and practices, while others state these are all optional.
Some confuse a framework with agile - some go even as far as thinking that "Agile" can be packaged.
Some are even selling a certain piece of software which allegedly is "Agile".

Yet everyone seems to forget that the bunch of 17 people meeting at Snowpeak were out to define a new standard for how to better develop software - and couldn't agree on much more than 6 sentences.
Especially in the light of Kaizen above - What do 'better ways' even mean, when no direction and no standard has been defined?
A lot of confusion in the agile community is caused by people standing at different points, heading into different directions (or: not even having a direction) and aiming for different things - and then telling each other what "better" is supposed to mean.

The Agile Manifesto is nothing more than a handful of things that seemed to be consistent across the different perspectives: It answers neither What, How nor Why.
To actually make meaning from that, you need to find your own direction and start moving.

What is a Scrum Master?

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

The narrow definition

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

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

The broad definition

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

People

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

Agile Frameworks

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

Management

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

Psychology

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

Philosophy

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

Economics

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

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

Summary

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

The effect of new ideas on learning

"It's always good to learn something new" - or so the proverb goes. Let's examine whether this is true, and how to maximize the impact of our learning.

In this article, I will classify new ideas into two categories: growth beliefs and limiting beliefs.

How our beliefs affect our learning.

To keep this article short, I will make a claim that I'm not going to back up further: Whatever we learn is merely a new belief, a new concept we hold about reality.

Growth beliefs

A growth belief is an idea which accelerates our future learning. Adopting a growth belief has a sustained beneficial effect on our ability to understand the world. Growth beliefs tick off slowly by slightly broadening our horizon, allowing us to integrate new ideas faster. Thinking in networks, a growth belief is a belief where further beliefs can easily be attached to. The following illustration visualizes the idea:

Upon the growth belief, further ideas are built and can be adopted easier.
The growth belief acts as a sustainable basis for growth of ideas

Limiting beliefs

A limiting belief is an idea which inhibits our future learning. Adopting a limiting belief has a long-term negative effect on our ability to understand the world. Unfortunately, the danger of limiting beliefs is that in the short term, they might give a massive boost to our ability to understand certain things. Again, thinking in networks, a limiting belief has a strong connection to related ideas which are oftentimes adopted immediately - while at the same time, the limiting belief is inconsistent with other ideas which become harder to adopt:

The limited belief is closely related to similar ideas
 - and inconsistent with other ideas, which we then struggle with or reject. 

When conflicts between ideas arise, we usually reject the new idea based on the ideas we already hold. Subconsciously, we find reasons why the new idea is wrong - either by trying to prove how it is deficient, or by trying to prove how our current belief is "superior". We are no longer open to listen to the merit of the new idea, as long as the cost of adopting it feels higher than the cost of rejecting it.

Discernment

Unfortunately, there is no certain way to know upfront which beliefs are growth or limiting ideas. As a general rule of thumb, though: The easier an idea tries to explain a complex problem, the more likely it will turn out to be a limiting belief. Or, in more scientific terms: The level of explanatory power of an idea is directly related to our long-term understanding of reality. Beliefs which we hold despite low or no explanatory basis are most likely limiting and should be put under scrutiny.

When ideas with higher explanatory power conflict with ideas we already subscribe to, we should examine what really makes us believe the things we already do and potentially discard the ideas we already hold.

Conclusion

It's only good to learn new things if we can either understand where the things we learn inhibit us, or if we have a mindset of letting go of inhibitive ideas. The latter is extremely hard, as beliefs we have already adopted are often strongly related and make up what we see as "real" - so the best thing is to avoid the trap of adopting limited beliefs wherever we can spot them.

Another thing we need to understand: One person's growth belief might be another person's limiting belief, based on both where the person currently stands and what the person is looking for. When we discover ideas to be truly limiting, it may already be too late to discard them without rejecting a major portion of who we are.

So - be careful what "new things" you learn! It might cost you dearly, years in the future!

The Cost of Learning

Time and again, I read stuff like: "The role of the coach is to guide a client in solving their problems, rather than providing a solution". Well - Reducing complexity is a talent, and this statement is a strong simplification. Here's why I personally think this isn't always the best choice.

Cost of Change

One basic premise of agility is "Responding to change over following a plan".This value is made real by constantly reducing the cost of change, to the point where you'll never need to follow an invalid plan simply because it costs less to continue doing the wrong thing. A low CoC is a premise for "being agile".

Correlation between agility and Cost of Change

Let's look closer: Change does have a cost associated, and you can't simply declare that cost to be Zero, in disregard of every evidence to the contrary. You must understand what the cost of change for a given change at a given time actually is.

This is where the coach/consultant comes into play. Both have the responsibility of inducing change. The coach would work on getting the responsible people, for example the teams, to embark the change process by learning by themselves. They need to be cautious, as especially in the initial stages of agility, the cost of change may be extremely high.

Cost of Failure

There's a problem in the learning process: Learning, obviously, means that you haven't done it yet. And that can pose a problem: You might fail. Well, failure is not inherently bad. We might argue that failure is an essential part of the learning process. That may be true, but you need to be aware of the failure costs.

Expected Cost of Failure

The danger that a person/team/organization is exposed to is a correlation of likelihood and incurred damage. For example, it's low danger to "learn" that putting salt into a cup of coffee is bad and therefore, you should use different containers for salt and sugar next time.
It's a completely different thing to "learn" that it's a bad idea to first pull the pin from a hand grenade, then put the grenade into your pocket: There won't be a next time.

In both cases, we assume that failure may occur. In the first case, we will assume that we can safely let people find out what happens, because the cost of failure is low. In the second case, however, it would be highly immoral to know the cost of failure and still let people figure out what happens.

Impact on the approach

We should always consider the cost of failure for any potential course of action. Low-risk topics that pose little danger to organizational health are not typical scenarios for requiring external support. Hence you wouldn't hire a consultant for that. People are more likely to ask for help the closer they feel to being to the Point of No Return.

Self-learning is a better course of action only when two conditions are met: 1) We will not cross the point of No Return and 2) It's a positive long-term business case.
Even though, I do admit that 1) automatically invalidates 2), the latter might still be easier to figure.
If those conditions are not met, a prescriptive course of action is more appropriate.

A feasible learning model

Depending on the consequences, we a different strategy is required:

When the cost of failure is low and people are likely to come up with a good solution, there is no need for outside involvement. Where the consequences are bearable while time is precious, guided learning can speed up the process and we can avoid reinventing the wheel. 

When there's a high risk of incurring an irrevocable, negative outcome by not doing things in a specific way, then "Do this, think about it later" is an appropriate course of action.

The highlighted boxes in the model are the most economic situational approach - the green, blue and red horizontal areas with lighter color should be considered depending on the predicted outcome.

Summary

There is no one answer to how learning should take place.
While it's very convenient to simply lean back and "encourage self-learning", that's not always appropriate.
Just like a parent would not encourage their two-year old kid to "discover the miracles of 220V AC", a coach might need to become quite prescriptive.

The directive is basic human ethics: "minimize overall harm". We can both do harm by neglect (damage to team's credibility, business etc.) and intervention (damage to understanding and desire to explore). There's a tradeoff, so choose wisely.