Part II. The Disciplined Way to Talk With People

Starting an engagement

Listen to an audio summary of this chapter here.

Be prepared

Before working fully with a company, it is important to be prepared. It will waste everyone’s time if you are not.

One way to do this is to identify one or two people who are providing behind the improvement initiative. Talk with them prior to any meeting with the rest of the people. This enables you to focus on the message and not have to spend as much time learning about the organization. Being prepared like this demonstrates respect.

Be Respectful

In general, people don’t like to be told what to do. In the Agile space, many folks are even more sensitized to it for several reasons:

People doing product development are used to having a great deal of leeway in how they work.
Many Agilists are heavy-handed. Those that are, are usually using the popular frameworks. Stories of people telling people “they must do this” or “they must do that” are rampant.
When you come into an organization, you’ll be walking into this presupposition.
Product developers are thinkers, they often know more than they are given credit for and they like to think they know what’s going on.
They may be doing some form of Agile already.
You may be coming in after multiple failed attempts which has only increased resistance.
You may be coming in after someone came with training, spun up some teams, and told leadership that Agile is complete.

There are two ways to lower any resistance you might face because of this. Both have to do with letting the people know you respect what they know and letting them tell you what didn’t work before, really hearing them out..

Story 1. It’s not about you, it’s about them.

Open up an engagement with something like this.

“Hi, I’m <name>. As you know, I’m here to help you and your organization improve. But I want you to know that this is not a me leading things. Yes, I have a lot of experience doing this. I’m in a lucky position where I get to talk with a lot of different companies so I’ve seen a lot of different things and I can often spot challenges and potential improvements because I’ve talked to a lot of people. But I’ll never know as much about your company as the least experienced of you. We want to bring our blend of experience and work as a team, together to solve our problems. Me with what works in different places and you, in what will work here.

Story 2. I’ll be making hypotheses, but you’ll be presenting the evidence

I tell this story at the start of any session where I’ll be introducing new ideas, and I have said this before.

“Hi. I’ll be presenting a lot of assertions. An assertion is a statement where there is a claim for evidence. Except I won’t be providing the evidence, I want you to provide the evidence from your experience. We often talk about running experiments to prove or disprove theories. The experiments take place in the future. But most of the time we can use our past to validate or invalidate our experience.

In our case here, however, I’ll be talking about how to create value. You all have been doing this for a while. You may not be using the methods I’ll be talking about, but you do have experience about what works and what doesn’t. That should give you insights to see if what I’m saying makes sense. So, if something doesn’t make sense, please challenge me on it. One of several things could have happened:

1) I may be wrong

2) I may have misstated something

3) you may have misunderstood me

But I assure you that real learning takes place when you challenge my statements because you believe your experience does not validate what I’m saying.

What’s the difference between experts and those with less competence?

Listen to an audio summary of this chapter here.

I have found that the most significant difference between experts and those with less competence is what they attend to. Experts pay attention to certain things and ignore others. Less competent people are often unaware of what an expert considers significant and pays attention to what an expert ignores.

But it’s not just what an expert attends to. They also see differences between things whereas a novice sees just one thing. These differences are called “distinctions.” A distinction is a difference in the state of things that is useful.

An expert carpenter knows the difference between cutting wood with the grain or across the grain.
An expert snow skier uses differences in the snow to see types of snow – powder, wet, etc., Whereas I’ll just see white snow
An expert small boat sailor – will notice the difference when waves have ripples and when they don’t. She’ll attend to the relationship of the wind to the sail.
A good bicyclist will understand the difference between using the front or rear brake. And the rear and front derailleur.
A good composer will understand the difference between a major chord and a minor chord – as will someone playing something by ear.
A good Agilist will understand the difference between flow and timeboxing.
A good Agilist will understand the difference between an artifact that is releasable and one that isn’t.
A good Agilist will understand the implications of working on small batches instead of larger ones.
A good Agilist will see when it is necessary to start with values before taking action or when to take action first and then clarify values. and the difference between starting with values before taking action and starting by taking action before worrying about values.
A good Agility will understand the context and the impact of that context on the Agile transformation.

Distinctions as a way of thinking

How you solve challenges is related to how you see the issues. But you see the problems through distinctions that you’ve learned are essential to pay attention to and a set to ignore.

Attending to distinctions is a great way to learn. When faced with someone who says there’s a difference between two things that you don’t see, consider how to have a conversation with them. You can say, “there’s no difference between these two things,” or you can ask, “I don’t see the difference between these. Can you explain what you see?” The first sets up a competition between the two of you, while the second gets around cognitive bias (which impedes learning) to some extent. Of course, maybe the difference is not useful, but there’s more to learn if you consider the possibility and it provides the space for everyone in the conversation to consider newall the possibilities..

You can help people learn by attending to what they aren’t seeing. Notice the distinctions they apparently are not attending to. It is often a good practice to ask if they see differences that you see but that they don’t appear to.

This perspective is consistent with Edgar Schein’s observation that “We do not think and talk about what we see; we see what we are able to think and talk about.” It may be you can’t see something that is there.

The Pickup Sticks Model of Creating Curriculum

Listen to an audio summary of this chapter here.

“You can’t teach someone something unless they already almost know it.” – unknown

In a nutshell

When you want to teach someone something that complicated:

Be clear about what you want to teach them

What are the distinctions needed for them to understand that?

Which of these are they missing? Find enough so there’s a path from what they already almost know to what you want them to know.

Teach these distinctions in this order

Consider this for a minute. What do you do when you want to teach some concept that seems beyond the grasp of someone’s current understanding? They can’t see this new truth in terms of their existing knowledge. While realizing this may be frustrating, it provides valuable insights into creating a teaching strategy.

Years ago, I was in a situation where I had to teach advanced concepts to people. I had no idea how to do this. It felt like what I wanted to teach was buried under several concepts they needed to know first. While reflecting on this, a flash of insight from the game of pickup sticks occurred to me.

When I was a kid, my older brothers always beat me at the game of pickup sticks. I always went after the high-scoring sticks at the bottom of the pile because I could get more points. It occurred to me this was like me now trying to teach the concept I wanted to convey before having someone learn all of the ideas on which it is based.

I noticed that when you take off the top stick in pickup sticks, which is easy to do, another stick becomes on top. Removing this one is also easy. It occurred to me that these “easy to remove sticks” were like the concepts people already almost knew. Therefore, an effective strategy to teach a difficult concept would be to walk through those things people already knew until I got to the concept I was trying to teach them.

I call this “the pickup sticks model of curriculum building.” Consider a concept you want to teach to someone. Consider the ideas needed to understand this new concept you want them to learn. Instead of talking about this concept itself, consider what steps are required to go from where they are to what you’d like them to understand. Formulate a step-by-step path from what they know to the concept you want to teach by presenting these distinctions.

Take this approach when teaching complex concepts. If there is disagreement about any one idea it is much easier to discuss one by itself than the entire set. This approach can make a daunting task manageable.

Agile pick-up sticks

When considering what the pick-up sticks are for Agile, consider the two endpoints -“what do we want them to know?” and “what do they already almost know.” Here’s an example:

end goal (bottom stick): overloading people causes delays
what they already almost know (top stick): interruptions in workflow cause waste

Most people already almost know that delays in workflow cause waste. Just ask them “what happens when work is interrupted?” They’ll likely answer “multitasking” which everyone knows is bad. Ask them if something else happens. They may see that this causes them to delay giving things to others which may cause multitasking for them. Ask “what other side effects may happen.” Point out that slowing down the completion of work means we will detect errors late. This is especially bad for software developers who now will take more time to find errors when detected.

Now we can move on to what causes these delays. What has us put work down? It’s clear that the multitasking we can see is being caused by working on too many things. A summary might be that multitasking is what is easily seen. But it’s a symptom of working on too many things, and it is correlated with work waiting to be done which causes waste.

It’s not a debate

Listen to an audio summary of this chapter here.

When people know a useful concept, it is normal to try to convince other people of it. Even if this is done with good intentions, it feels uncomfortable to people. It reactivates times they have been talked down to by arrogant people. Trying to convince people of something is not an effective way of creating new possibilities for people.

Instead of debating, we need to have a discussion for discovery. The reality is that none of us are right all the time. As a coach, you may:

be wrong
say something incorrectly
be misunderstood

It is much more effective to have a conversation with someone to discover what is more effective. Even when you’ve been down the road before, acting as if you are on a road of discovery with whomever you are talking to will make you more effective. The intention is to have a dialog of discovery with the attitude that both you and the people you are talking to will learn. Very often you will learn more than they will. This is a good thing. This is the heart of the Socratic method.

[1] Socrates taught by asking questions and drawing out answers from his pupils to challenge the completeness and accuracy of their thinking. Here are the six types of questions Socrates posed:

Clarifying concepts. These questions get students to think more about what they are asking or thinking about, prove the concepts behind their argument, and get them to go deeper.

What exactly does this mean?
How does this relate to what we have been talking about?
Can you give me an example?

Probing assumptions. These questions make students think about the presuppositions and unquestioned beliefs on which they are founding their argument.

What else could we assume?
What would happen if…? (our assumpton is wrong)
Are we assuming anything?

Probing rationale, reasons, and evidence. When students give a rationale for their arguments, dig into that reasoning rather than assuming it is a given.

Why is that happening?
What evidence is there to support what you are saying?
Can we test that this key assumption is correct?

Questioning viewpoints and perspectives. Most arguments are given from a particular position. So attack the position. Show that there are other, equally valid, viewpoints.

Who benefits from this?
Why is it better than or different from…?

Probing implications and consequences. The argument a student gives may have logical implications that can be seen.

Do these data make sense?
Are they desirable?
How do [these assertions] fit with…?
What are the consequences of that assumption?

Questioning the question. You also can get reflexive about the whole thing, turning the question on itself. Bounce the ball back into their court.

Why do you think I asked this question?
What does that mean?

It takes skill to do this

This is not something everyone does naturally. Years ago, when I was coaching FORTRAN programmers in object orientation, I knew how to do it and would talk with people about it. I asked some questions as guidance, but I was leading them in a direction I knew to be right. Then I sat in on a University of Kansas professor who was visiting and teaching some basic object orientation. He was gracious enough to let me sit in on his classes. I just listened and observed.

The thing that struck me was that he asked questions based on where they were. He didn’t seem to be trying to lead them anywhere, just went with the students’ knowledge. I was amazed at his patience. After a couple of hours, one of the students had a shift in her thinking and said something to the effect “if that’s truer objectives would have to be responsible for themselves.” This was the key insight needed. And just after she said it you could every other student got it. It was almost comical, the jaws dropping around the circle.

I was impressed and amazed. When things like this happen, I like to ask what did happen?

In thinking about it I realized the professor had confidence in his work. He had faith that his line of questioning would lead to what he believed. If it didn’t, he would learn something.

The key is to know the answer but dispel it as the answer and just engage with the people you’re talking to.

[1] From the University of Nebraska-Lincoln

What to say to someone when they just don’t get it

Listen to an audio summary of this chapter here.

If you just jumped here, you should read the chapter What’s the Difference Between Experts and Those With Less Confidence first.

We have all had the experience of someone being hard to convince when the evidence is clear. It could be a co-worker, a manager, or someone who reports to you. A negative attitude often accompanies this, making you think this person is a jerk. But the moment you throw up your hands and label the person a jerk, you’ve lost all hope of getting them to change their mind.

An approach of not judging can often help, one that I have often used as a coach and trainer. Ask yourself, “What would an intelligent, motivated person be looking at (or not be looking at) that would have him/her take this position?” In other words, pretend that they aren’t a jerk or belligerent.

There is more power to believe you are talking to a motivated, intelligent person, even if they are not than to think you are talking to a jerk. In my experience, people coming across as belligerent are usually just looking at the situation differently than I am and don’t know how to have a conversation about it. Sometimes they feel threatened in this situation. Sometimes so do I. 🙂

This attitude can give you insights into what to do. You can discover what thoughts they are having that are holding them back.

Don’t tell the person they are wrong in their thinking. Instead, ask them why they are thinking this way. Engage with them, don’t judge them. They will often tell you what they are looking at.

It is very often the case that talking about differences of opinion is difficult but talking about the reasons for what we believe is not as difficult. Such a discussion often leads to great insights for you and the person you are talking to. Be prepared that it could be you looking at the wrong things. Your willingness to learn creates better energy and helps the person improve their attitude. Admit that it may be you that needs to learn something.

Maybe Something Is Missing

We must remember that our ability to connect the dots may be because we’ve got more experience at it or that we’ve been down this road before. Because we take pride in what we know, we often attribute this to a lack of ability in the person we’re coaching. Good coaches will see if they can bridge the thoughts needed to reach a reasonable conclusion. Again, judging the person being talked to as not being able to get there is not helpful.

Taking a learning attitude opens lots of possibilities.

Of course, sometimes you will run across people who are more interested in arguing than learning. I suggest this occurs less frequently than you might think. I have seen this just a few times in my years of consulting. Just remember, you cannot control anyone’s thoughts.

The bottom line is you have more power in the situation when you take the attitude that people are good and want to learn. True power is not achieved by controlling others. It is in helping others see what is in their best interest and how to achieve it.

How to get management to listen to you

Listen to an audio summary of this chapter here.

Many Agile coaches complain about management’s lack of wanting to truly understand Agile. This topic is about how to talk with management in a way they will be interested in learning about the value of Agile. The trick is to talk with them from their perspective and to take advantage of what they know and care about.

Getting management to understand Agile requires:

The first step is to respect management and be open to dialog. The Agile space has long ignored or held management in contempt. Not only is this unfair, but it’s also counterproductive. Like all roles, there are managers that are masters at management and those that are not.. The fact that they don’t understand things does not make them evil. It just puts the burden on you to explain things.
Understand the business perspective. Speak to management from management’s business perspective. Know the strategies, the customers, the products and services being delivered and look for anything in the system that may impact the manager in his/her role. Speak from their point of view. Please don’t say we have to work on fewer things; tell them we want to faster delivery value faster, with less wasted effort, and with predictability.
Don’t expect them to buy into Agile. Agile means different things to different people. Reading the Agile Manifesto to them will seem pedantic.
Never say, “then we wouldn’t be doing Scrum.” They don’t care. And if they are the ones that told you to do Scrum, they may feel you are making them wrong. And if they are, then it’s even worse for you.
Let management understand what’s happening.
Never believe people are coming with ill intentions. Their behavior may be due to a lack of understanding.
Don’t assume management is trying to keep a command-and-control attitude. Eli Goldratt once observed, “A comfort zone has less to do with control and more to do with knowledge.”
Be able and prepared to explain why Agile works. This usually requires knowing some first principles that managers can relate to.
Understand the basic premises of Lean so you can explain why it works
Understand basic value stream management, so you know to explain how local optimizations don’t often lead to global improvements.

Many Agilists blame managers for not fully participating in an Agile adoption – or even resisting it. But consider the impact of consultants ignoring them, not respecting them, talking down to them, calling them chickens, and barring them from important meetings. All in the name of Agile/Scrum. If you were in their place, what would your opinion be of it? Acknowledge that and do something different.

Some thoughts from Eli Goldratt from The Choice (with comments)

“The difficulty is that if I’m not sure, really sure that a 2nd effect does exist, I might stay inside the box; it is always safer to stay within the comfortable boundaries of a box than to jump out into the unknown. Since the other effect is not within that box, I will not find it. I’ll give up searching and remain stuck with a tautology (circular logic).”

“A comfort zone has less to do with control and more to do with knowledge”

Comment by author: Many blame managers for being in a command-and-control mode. It’s a self-fulfilling prophecy when you claim this and don’t provide managers with basic insights that would enable them to give up control.

“… it is obvious that we should expect resistance when the person is seeing a different cause-and-effect relationship than we are employing. How much resistance? Well, it depends on what led our clients to believe in their existing cause-and-effect connection. I now believe that we had better distinguish between two different types of situations—one where people have experience and the other where people do not.”

Comment by Author: When the people who are pushed outside their comfort zone don’t have the experience to judge whether or not the causes and effects underlying our suggestion have merit—causes and effects that are in direct contradiction to the one they assumed—is an explanation enough to cause them to invest the considerable time and efforts needed to launch, monitor and analyze a test?

Getting Executives to Understand Agile by Talking About Value Streams

Listen to an audio summary of this chapter here.

Many in the Agile community criticize a company’s leadership for not understanding Agile. However, much of this lack of understanding is due to many agilists not talking to them in a manner that executives are interested in. Executives often don’t want to learn Flow, Lean, or the Theory of Constraints. I suggest a better way of communicating the value of Agile is by talking to them about value streams and value stream networks in a way that makes sense for them. Here’s an example.

Consultant: Hi. I know you’ve heard a lot about how companies are adopting Lean and Agile methods. But instead of talking about methods, I’d like to talk about what we, as an organization, want to accomplish. So let me start by asking you what you’re interested in.

Executive: Well, I’d say the top things I’m concerned about are:

Innovating for our customers
Avoiding the waste of developing products that are not useful
Being able to quickly deliver value at a reasonable cost
Being able to provide a great customer experience with both the products and the supporting service
Having an effective sales organization
Creating an excellent environment for our employees to work in

I would expand customer service to customer experience. And I would also include something about time to market or responding to change. Creating value at a reasonable cost isn’t good enough if it’s two years late.

Consultant: Great. Let’s look at these and see how we can help. First, what does innovation for your customers mean regarding your services and products?

Executive: Well, regarding our products, I’d like them to add value to our customers beyond what they might expect.

Consultant: What would that look like?

Executive: Well, they would find themselves using our products in better ways – making their lives easier.

Consultant: You mean that they’d find themselves working in a different way? In a way that they’d find is better and more effective?

Executive: Exactly.

Consultant: To introduce a term, this workflow you’re describing is called the customer value stream. It describes a customer’s path from starting to get value until achieving it. I’m hearing you say that you’d like to be able to improve how they do this.

Executive: Yes, but how can we do that?

Consultant: Well, first of all, we need to make explicit that that’s what it is we want to do, and you just did that. We use the term “customer value stream” to share a common language and know what we mean by that.

Executive: OK, that makes sense, but I can’t control what our customers do, so how do I improve their value stream?

Consultant: This is a two-step process. First, as you’ve just stated, we must recognize that we’re trying to improve how our customers do their work. A great way to do this is to have our products and services interact with them in a way that improves how they get their job done. This “interaction” is called the customer journey.

Executive: OK, that makes sense. So, we have our development teams focus on how our customers’ value streams can be improved, and we design our systems to improve customer journeys. Sounds good, but it also sounds expensive.

Consultant: Yes, at first, it sounds like we’re doing more work. But there are lessons to be learned in improving our customers’ value streams and how we improve our own. Let’s consider things customers like and don’t like. First, what do customers think about waiting between the steps they have to take?

Executive: They don’t like it.

Consultant: Exactly. Eliminating delays in a customer’s workflow is a good idea. Now, consider what happens when your developers work, and things get delayed. Say, one person needs to talk with another person, but that person isn’t available.

Executive: That will not only cause frustration, but it’ll likely cause extra work because of multitasking.

Consultant: It will also cause delays in getting feedback about if we’re working on creating the right innovation. The more delays, the greater the time to get value. And if we make a mistake, we won’t detect it for a longer time than if we didn’t have these delays.

Executive: Can’t we tell our people to work faster?

Consultant: Sure, but consider this. Are they not likely working as fast as they can? Pushing them harder will likely just create errors.

Executive: I don’t know; a little pressure is often good.

Consultant: And I’m not saying it isn’t. But consider the time from starting an improvement until it’s completed. I’ve been watching your people and can see they are busy. But I suspect that precisely because they are busy the work is waiting around.

Executive: What do you mean?

Consultant: Well, consider this. Someone starts working on something and needs help from someone else who is working on several things. Is this other person likely to be available?

Executive: Probably not. The more they are working on to get more done, the more likely the person needing their help will have to wait longer until they have time to get to them.

Consultant: Exactly, and while they are waiting, they start something else, so the piece of work they made the request for …

Executive: just sits there for a while. Hm, I see. So, what do we do about this?

Consultant: The trick is not to get people to work faster but to eliminate the delays, as much as possible, between the steps in the workflow – that is, in the development value stream.

Executive: But the work in the development area isn’t a stream. Things go back and forth, across teams, all over the place.

Consultant: Yes, very perceptive. That’s why we also call it the development value stream network.

Executive: OK, let me get this straight. To innovate, we need to improve how our customers work. We call that their value stream, or the customer value stream. To influence this, we attend to how they interact with our systems, which we call the customer journey. We need to improve our development value stream networks by removing delays in them. This speeds up feedback and value delivery. Have I got it right?

Consultant: Yes. Now we’ll leave how to do this for another day. But there are still other types of value streams.

Executive: This is beginning to sound a little complicated.

Consultant: Well, there is a fair amount to learn. But all of these value streams have a lot in common. And there are straightforward ways to start.

Executive: So what other value streams are involved?

Consultant: Consider what internal work you do. You have groups to market, sell, deploy, support, etc., the products. Each group has its own value streams. We call these operational value streams. You also have value streams for legal, HR, etc. All of your value streams should be about creating value for your customers and/or your employees.

Executive: All should work to provide value quickly, without delay or wasted effort.

Consultant: Let’s look at that list you gave me at the start:

Innovating for our customers
Avoiding the waste of developing products that are not useful
Being able to quickly deliver value at a reasonable cost
Being able to provide a great customer experience with both the products and the supporting service
Having an effective sales organization
Creating an excellent environment for our employees to work in

Notice how value streams help the first five of these directly. We get innovation by attending to customers. We can lower the waste of developing products that are not useful by getting quick feedback. Reducing delays reduces waste – in building new products and customer service and sales.

Now consider this, what would it feel like to work in an environment where you weren’t wasting time waiting for others?

Executive: It’d be great.

Consultant: Then we’ve covered them all.

Executive: Is there more to this value stream stuff?

Consultant: Yes, quite a bit. Consider how people will be able to align when they all understand we’re interested in value add. This is a holistic view. Everyone can recognize their role in the bigger picture. We can also use what we know about value streams to see where and how to improve them.

Executive: How do we do that?

Consultant: There are a couple of ways. The most common way is what is called value stream mapping. In value stream mapping, we draw out all of the steps of the value streams.

Executive: Sounds like that takes a lot of time.

Consultant: It can be. That’s why we’ve come up with another way which gets most of the value but takes only a fraction of the time. We call it the idealized value stream.

Executive: Why do you call it that?

Consultant: We’ve discovered, after looking at hundreds of companies, that the core way they should be working is similar. This core, of course, doesn’t include certain things that may be particular to certain companies, such as FDA regulation or working with hardware groups. But even in these cases, the core work is the same, and regulation and hardware are just additional requirements on what to do. Knowing this enables us to look at what we should be doing and contrast it with what we are doing. Then we can see where we need to improve.

Executive: And everyone can get on board because we’re all united around adding value, supporting it, and being efficient.

Consultant: Yes. And there’s another advantage this gives us. Even though many people in the organization may need to accomplish the same thing, the way they do it must be adjusted to their situation. This enables people to self-organize while fitting into the bigger picture. This enables people to work in a way that suits them while being able to coordinate with other groups in the organization.

Executive: Very cool. You’ll have to teach me more later.

Extra Reading: Cutter Consortium Article Why Leaders Should Focus on Value Streams.

Why You Need to Talk With People Based on Their Own Experience and How to Do It

Don’t ask people to follow you

I have always disliked comments I hear from many Scrum proponents that those new to Agile must first follow its rules and only then can you vary them. The metaphor of playing chess is often given as a common example. Shu Ha Ri is also mentioned. But chess is a game. It’s set. It’s not for everyone. Scrum is not for everyone. Following it for a long time to discover that is not effective.

But this has many disadvantages and is somewhat disrespectful in my mind. It presumes that people can’t start using their own understanding and experience right from the start.

The question is “how do you get people new to something started in it?” Clearly, they are new to the practices. But to presume they are new to the problem and can’t use their experience is presumptuous. They may not have been doing things properly, but they are not new to their workplace.

Come from understanding

You must find something in common with what they were doing and what you’re wanting them to do. That may not be the practices, but the first principles on which the practices are based can be used. Experience in following and not following first principles can be used to demonstrate why practices should follow them. Unfortunately, Scrum does not mention these but merely asserts following it works. So does “buy low and sell high” in the stock market. Understanding how is important.

First principles and practices

Let’s look at an example of a first principle and how it relates to a Scrum practice.

Often reducing batch size is all it takes to bring a system back into control. Eli Goldratt

Small batch sizes are a powerful tool to increase urgency, motivation, and accountability. Don Reinertsen

The principle here is to use small batch sizes. The waterfall uses large batch sizes. In Agile it’s small, increments. A trainer/coach can now talk about the practice of small batches not as something to follow but to avoid the bad experiences the person has had with large batches.

Talking to managers

This is particularly important with managers. Most managers got to their positions by being able to solve problems and get things done. Many, as do most people, identify their personal value with their position. To expect managers to ignore what they know because something is unsound.

Paraphrasing Margaret Wheatly – we say that people innately resist change. But the resistance we often experience from others is not to change itself. It is when change is imposed.

When we tell managers how to do Agile without the first principles that underly it we put them in an uncomfortable position. Many won’t want to admit that they don’t know something. Instead, they’ll just say that it won’t work. When we include first principles in the conversation, we can engage with managers in solving their problems. We can circumvent the lack of getting management buy-in by talking to them in a respectful manner – showing them how the principles they can see when pointed out, apply to the practices that now need to be followed. It is ironic that many Scrum proponents talk about never telling people what to do but Scrum is essentially based just on that – follow it or you’re not doing Scrum.

This approach is in Eli Goldratt’s comment “A comfort zone has less to do with control and more to do with knowledge.” It is the basis for Amplio’s method of dealing with complex systems by moving taking advantage of what you know while learning about something you didn’t know when you get surprised. You move forward and increase understanding as you go while being ready to pivot due to black swan events. Using first principles gets managers engaged by enabling them to help create better environments within which teams can work.

Other damage done by not having first principles

Unfortunately, Scrum does not present first principles. Instead, the creators of Scrum have created their own principles. Instead of incorporating theory into experience, Scrum relies on empiricism (actually, relies on empirical process control) and complex adaptive systems.

Teams often find themselves in a situation where a Scrum practice doesn’t seem to be working. Unfortunately, it is difficult for a team that has not been armed with first principles, to tell if the problem is they aren’t following the practice properly or if the practice is not the right one to follow.

The fact that there is no set of practices that is universal sets up a dilemma for these teams. They try to make Scrum work but eventually feel they must do something different. Unfortunately, different is not always better and the practice they move to may not solve their problem but merely avoid it. This is the infamous “ScrumBut” defined by Scrum.org – “Scrum has exposed a dysfunction that is contributing to the problem but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”

The solution here is to understand first principles and find a practice fixes the problem by following first principles better than the prescribed Scrum practices. Scrum’s immutability is a symptom of the lack of first principles. Saying Scrum’s practices are immutable and then blaming people for changing them obscures the real responsibility for what’s happening. Without providing a way to change its practices, Scrum lays landmines for its adopters who, when stuck in a difficult situation, and without being given a way to tell if a change is good, has, in their frustration, make a change, which often makes things worse (e.g., abandon timeboxing without following practices from flow). Scrum proponents then declaring “well they weren’t doing Scrum” merely abdicates the responsibility that they weren’t prepared to remove the impediment they were faced with.

What Amplio Provides Here and How, If You’re Using Scrum, to Avoid This Problem

Amplio provides several approaches to solving this problem in different chapters in this book. They include:

A list of some key first principles
The factors for effective value streams which presents first principles in an actionable format
How to change a practice with confidence it will be an improvement
Rethinking ScrumBut and ScrumAnd

Are you attending to their “listening”?

I was introduced to the term “one’s listening” by Dr. Fernando Flores in the 80s. This “listening” is what’s going on in a person’s head when they listen or read. You’re experiencing this now, likely asking yourself “what the hell is he talking about?” That’s what I’m referring to as “your listening.”

Words, in themselves, don’t have meaning for more than one person at a time. While the speaker has something in mind when they speak them, this may or may not be the same as when a person hears them. Instead, the words heard evoke a conversation in the person’s head that may or may not be what was intended by the speaker. Rather they mean what the receiver gets evoked in their head.

This is why communication is so fraught with misunderstanding. If people have different understandings when one person says something another person may very well hear something else (not in their ears but in their head).

As George Bernard Shaw observed: “The single biggest problem in communication is the illusion that it has taken place.”

This is why it is important to attend to someone’s listening. When we’ve described certain concepts repeatedly, we can even anticipate what this listening will be based on past conversations. And, of course, we can ask. When writing or creating training materials, however, it is important to make a decision about what the likely listening for your audience will be.

Explanations that take this listening into account will be better than just an explanation of what you are trying to describe.

Why Coaches shouldn’t tell people what to do and why you don’t need to

I often hear that coaches should never tell people what to do. While I agree with this, I don’t believe the common rationale for it – that it may cause resistance – is the strongest reason. Very often people want to be given a solution. That’s why they hired a coach in the first place.

There are two other reasons, far more important. The first is that it implies the coach knows more than they do. This, of course, is not true. While the coach may know more about Flow, Lean, Theory of Constraints, and organizational development, the people being coached know a lot more about the actual work being done. If the coach is external, then the team also knows more about the organization and how it works. This knowledge may be critical in deciding future actions. Ignoring this may also damage the relationship between the coach and the team.

For external coaches, the biggest reason not to tell teams what to do is that they need to figure it out for themselves. Not having them figure it out for themselves shortcuts the thought process they need to go through in order to understand the details of what to do. People will often follow the advice in many situations. But if they don’t understand the first principles underneath it, when they try to implement it and hit a difficult situation, they may not figure out how to get beyond it. They’d stall and then blame the coach thinking the coach was wrong with the suggested approach. And s/he would deserve the blame even if the approach were correct because s/he didn’t prepare them for it.

Coaches can avoid telling people what to do by providing the “why” of the contemplated advice. Understanding the theories of Flow, Lean, and the Theory of Constraints, along with the Factors for effective value streams, usually provides for accurate predictions of whether or not a change in the team’s way of working will be an improvement. For example, changes that remove delays in a constraining part of the workflow will likely result in an improvement.

The more you violate first principles the more likely you are to make the situation worse. While lessening the violations of first principles doesn’t always lead to improvement (the violation may not be in the constraint of the system, and/or other actions may be needed) it usually opens the possibility for improvement.

The coach should focus their conversations on these concepts, having people confirm theories of Flow and Lean based on their experience. Guide ppl with questions that give them a sense of what will happen if they make certain decisions

It’s like telling someone “if you stand in the middle of the road w/o looking, you may get hit by a car.” They’ll know to get out of the road. You don’t have to tell them to do so.

Understanding Anger – A Personal Story

Some people are natural coaches. They have a great temperament for it and never get rattled. I am not one of these people.

When I started coaching in the mid-90s I’d get angry at times. I knew this was not a good thing. But it’s not like I chose anger. I just got angry.

It wasn’t like I was always angry. I led some study groups and was really good. But there was a person I was coaching one-on-one and when she took a long time to understand a concept, I’d sometimes put a lot of tone into my voice. It was not good. I was fortunate she never complained to my boss.

After this happened a few times I stopped and looked at what was going on. I asked myself why I was getting angry at her. I knew that fear was always underneath the anger. It wasn’t logical, but I realized that I was thinking that if she didn’t understand then it meant I wasn’t doing a good job and was going to lose my contract. Kind of warped logic but how I was built.

People tend to think that we control our thoughts – or that we should be able to. I had done some work on personal development years ago and knew that wasn’t true. You can see this for yourself. Next time a person cuts in front of you while driving, just notice how your upset comes up. You don’t think about it – it just happens. That’s what was happening to me. I just got angry.

I realized I was kind of in a dilemma. I couldn’t really take responsibility for her getting what I was trying to convey. It could have been beyond her abilities. But in this case, I knew that that was not the case. She was a very smart person. I just wasn’t doing the job.

On reflection, I came up with these conclusions:

I can’t be responsible for a person I’m coaching to get it.
I also can’t be responsible for the pace at which they learn.
But I can be responsible for myself being patient
I can also be responsible for continuing to look for different ways to convey thoughts to people
I can always take the attitude that the person I’m coaching is doing the best they can.

I wish I could say that when I got these insights I just got better. But that’s not what happened. It took a few years, but I did improve on a regular basis. My bouts of anger happened less often and were less vehement. It took a while (euphemism for years) but I eventually got to the point where I’d almost never give tone in my conversation.

I admit to a “relapse” a few years later that’s worth mentioning. I was teaching back-to-back design patterns workshops to a long-standing client. On the third day of the first workshop, a person was being particularly obnoxious in trying to make political statements about banking. Anytime I used banking as an example he’d ask why a bank would want to do what I was suggesting. He would sometimes talk about how banks didn’t care about anything but making money. It was totally irrelevant to the conversation. Somehow, I got past that day, but barely. I was so glad to be rid of him.

The next morning, I got to the classroom for the second course. It was an advanced design patterns workshop that was intended to be taken by people who took the first workshop but after applying what they learned for a few weeks. I was unhappy to see him there. After a little time, I asked how we might solve a problem of an audit report or something like that. Something a bank would definitely want. Sure enough, he started in on me right away. I got so frustrated I lost it.

Fortunately, an associate of mine was in the audience – Scott Bain. Scott was not just one of the best trainers and coaches I knew, he was always amazingly even-tempered – a natural coach in my book. I asked him what I should have done – because I was hopeless with this guy. Scott’s answer was amazingly simple. He said I could have just said “well let’s just assume a bank wanted to do this.” By postulating it I could have just sidestepped any generalities he was going to bring up.

I don’t think this ever came up again, so perhaps this isn’t a useful technique. But it’s worth knowing.

Learn By Teaching Others

In “Seeing What Others Don’t: The Remarkable Ways We Create Insights.” Gary Klein presents a variety of approaches people use to create better models of understanding. It presents ways to help people become more insightful. The article continues to demonstrate thathow understanding how one becomes insightful allows you to help others “connect the dots.” This actually goes both ways. As you help others connect the dots, you see more connections than you had before.

It is well known that a great way of learning something is to teach it to someone else. Doing so forces you to notice your own thinking more clearly and helps you discover any errors in it. While reading guides or trusting others’ insights are useful, if you follow them, you’re not learning why they are right. It is this deeper knowledge that is more important. And it may be that they are not as right as they think.

It is important to reflect on what you believe and how it can connect the dots for others. This brings in another’s perspective and highlights any assumptions you will need to convey. This often uncovers assumptions you were not aware of. Once you notice these, ask yourself, or better yet, other people, if they are correct. This helps break any echo chambers you have set up. Additionally, having a dialog with people helps focus on what’s being said and loosens any presumptions that you may have.

The “curse of knowledge” is that we stop questioning our understanding which leads to not exploring new ways. That we jump to conclusions without investigating the path we formerly took to get there. We have a tendency to think that others who disagree with us are wrong. This is natural – it’s called being a human being. But just knowing this does little good. One must take action. Looking to see how others can understand by reflecting our thoughts is good action. Both they and you will learn something.

When we expose our thinking as possibly being wrong, it can often take courage to accept that it could be wrong. Instead of identifying ourselves with our thinking, we should identify ourselves as learners.

Telling others to follow us is a lazy path. When you dig deep and explain why things work you both learn more. And it’s more respectful besides. That speeds learning for them, and provides a degree of openness that speeds learning for you.

Why Comparisons Are Useful

Some people in the Agile community don’t like methods to be compared. But comparisons between concepts are useful for several reasons:

People learn new concepts easier when contrasted with something they already know. It’s also easier to describe new things this way. Try explaining what an electric car is without using a gasoline-powered car in the discussion.
Creating distinctions between things leads to expertise. Experts are experts to a large extent because they see things other people don’t and ignore things other people attend to.
These distinctions also create possibilities for creating something new.
Comparisons can be used to decide which choice is better for a particular situation.
Comparisons create options.
A comparison may demonstrate that something isn’t working well related to another approach.

In science, comparisons are used to see which hypothesis better explains a set of data. For example, we compare the Ptolemaic theory Vs the Copernican theory vs Kepler’s theory of what was at the center of the solar system and the shape of their revolutions via comparisons. There was no Ptolemaic or Copernican bashing. Galileo was jailed by the church, however, because his beliefs disagreed with dogma. The church called him a heretic. In the Agile church, we call these “bashers.”

Neil deGrasse Tyson – “the difference between science and religion is religion can’t abide being wrong science seeks to be wrong.”

The issue is – are you taking a scientific approach to what’s being presented? It’s useful to view every approach as a hypothesis on how to improve performance. That is, consider Disciplined Agile, Flow, LeSS, Kanban, Lean, SAFe, Scrum, Theory of Constraints, … as hypotheses.

When you take this attitude, there is no bashing. There is only learning. One of the things we have to overcome as individuals and consultants is our cognitive biases. This is very hard to do. It’s often easiest when we talk with people of a different mindset and compare our ideas.

When you surround yourself with people who have the same cognitive biases you are in an echo chamber that is hard to break out of. The scientific approach can help here. Compare the data resulting from your beliefs with the data at hand. This can be frightening but is required for consistent learning.

Upton Sinclair maxim applies to everyone, including you – “it’s hard to get a man to understand something when his salary depends upon his not understanding it.”

<< Part I: Understanding What Is Needed.

Part III: Useful concepts for a professional coach to know >>