Why Understanding Principles Is Essential in Coaching Others.

August 1, 2008 — Posted by Al Shalloway

Whenever I attempt to coach others, I have to acknowledge two things:

  1. People will only do what's in their best interest
  2. You can only get people to change their mind if it makes them right to do so

(Take a look at Joe Caruso’s excellent book, The Power of Losing Control, for more about this).

These strongly inform my beliefs about how to help people learn new approaches. I am often asked how to get other people to learn about Agile or Scrum methods. It can feel frustrating when you feel that the team should be doing something differently from the way it is currently being done… how do you get them to change?

In this blog, I discuss my approach and why understanding the principles underlying the practices is so important.

Look at the concerns behind the approaches

Imagine you are in a situation where someone is doing something you don't agree with. The first tack is often to look at what they are doing rather than what concerns they are really trying to address. That is not effective. I suggest that, almost always, the concerns they have are right but the solutions they have for addressing those concerns are wrong.

For example, suppose someone says, "Look, we need to do this design up-front to make sure that we have an architecture that works." They are taking a waterfall-ish approach. As an Agile person, you might be so taken aback by this approach that you miss what their real concerns are. Now, in this case, what is wrong and what is right? Look at the concern being expressed:

  • Solution: Create a good architecture that works.
  • Concern: Don't want to re-write code/architecture

What do you do?

You could tell them that their approach is wrong; but this will likely put them on the defensive. And that is not a good place for a constructive dialog! Instead, start by looking at their concern. If you cannot deduce it (and even if you can), you can always just ask. In this case, I'm pretty sure they are afraid they will lose time re-working the architecture if they don't get it right up-front. In other words, they want to be efficient. Or, perhaps they are concerned it will take too long to make changes to their code if they get the architecture wrong. In either case, they are concerned that the efficiency of development is not be compromised.

Well, I am concerned about this, too! I can agree with them. But I have a completely different solution.

The question is "why do I have a different solution?" The answer is because I am operating from a different set of beliefs. And these different beliefs result in a different set of practices that address the same concern.

Beliefs lead to practices

Discussing beliefs can be difficult because people often don't challenge them. Rather, they just assume they are true or act as if they are. Trying to change someone's beliefs directly is often difficult because it feels like an attack on them personally.

Working from the two principles I mentioned at the start of this blog, if I can get them to learn something that throws their belief into question for themselves, they may change their beliefs on their own... and thereby change their practices.

It works. But first, you have to understand what those beliefs are. And that is hard.

Discern the belief system

When someone does something I don't agree with, I start by asking myself, 

What belief system would have someone think these practices are best when I believe those practices are not right?

In the example above, my first question would be, "What does this person believe that has them think that designing an architecture up front will work?" I can imagine many options. First, they believe that it's possible to do design up-front. Second, they believe that architectures cannot be designed to change over time. Those are probably good assumptions.

An even better approach would be to ask. This follows another good rule: Assume Nothing!

Another approach is to look at what they are focusing on. Beliefs are often informed by what people are looking at… what they assume to be true and real. That informs what they believe works.

Leading to change

You have several options available to you to help change behavior. Contrast the things someone is looking at and ignoring with the things you look at and ignore. Ask which things tend to be more predictive. This can be an objective conversation. You both are just trying to learn.

If you've observed enough evidence about how things behave, you may be able to state a principle about how what you are looking at affects the things you want to change. In my manufacturing case, the principle would be that minimizing delays will lower cost and improve quality. What's powerful about this is that you can talk to the person and they can see from their own experience how this belief system makes sense. They start realizing that looking at something different from what they previously looked at will be more effective. They have changed their belief system based on their experience by your having had them shift what they are to look at. True, they have to change their minds into looking at something differently (or at different things), but they adopt the new belief because they believe it now and it is consistent with what they are looking at. They are smarter than they were – not dumber. It is not a right Vs wrong thing anymore, but a making both people smarter. They have actually convinced themselves (OK, so you helped). By the way, if it turns out your belief system was wrong, then you learn something – which is also good.

My suggestion is to learn which beliefs are useful to have and which ones aren't. Discover what your associates (clients) believe. See what principles they follow that support those beliefs. See what principles you know would question those beliefs. And then, have a conversation with them about it. In essence, you look at the concerns they have (which are likely good) then deduce the beliefs that they must have to follow the practices they are suggesting. Find principles that throw these beliefs into question if your experience is that they are wrong. If you are right, your associate may learn something. If you are wrong, then you may learn something.

It's a win-win.

Alan Shalloway

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban