Disciplined Agile

Agile Coach: Coaching Tips

Here is a collection of tips that lean-agile coaches have gleaned in their work. They are simple phrases that guide expert coaches. They can be thought of as Trim Tabs for coaches.

Here are some tips, in no particular order:

  • What to say when someone just doesn’t get it. It’s easy to think someone isn’t understanding you because they aren’t trying. But it’s more effective to take another tact.
  • Understand the Disciplined Agile promises, and the thinking behind them.
  • Beware of the fundamental attribution error. The fundamental attribution error describes the tendency to over-value character-based explanations for the observed behaviors of others while under-valuing situational explanations for those behaviors. The fundamental attribution error is most visible when people explain the behavior of others. It does not explain interpretations of one’s own behavior—where situational factors are often taken into consideration. This discrepancy is called the actor–observer bias. Example: If Alice saw Bob trip over a rock and fall, Alice might consider Bob to be clumsy or careless (dispositional). If Alice later tripped over the same rock herself, she would be more likely to blame the placement of the rock (situational). An example more relevant to our field is the continual explaining away of the failure of agile approaches as a lack of commitment, motivation or discipline of the people involved.
  • Pay attention to learning and behavioral styles. Check out the Myers-Briggs test and the DISC Profile. People do not think, learn or behave the same ways. There are patterns that are helpful to be aware of.
  • Explain things from the perspective of the person you are talking to. We all too often explain things as if they are real and all we need to do is describe them. The truth is that our understanding of things lives in how we speak about them. If someone is unfamiliar with certain concepts, they will filter what you say into their view of the world first. They will actually never hear what you intended to convey. You must speak from their perspective, so they can build up what you mean from their own concepts.
  • Expand your repertoire of techniques. Don’t favor one approach; rather, use whatever helps the client move along in their development.
  • Become so familiar with every role that you can describe what is involved in each role and so that you can identify when someone is not performing as expected. Here are important roles to understand: product owner, architecture owner, developer and tester.
  • Coaching should happen at a regular cadence or rhythm.
  • Implement visual controls early. In an agile transformation, no matter what type of manager you are seeking to influence, visibility charts always help. Visual controls give clear direction and tangible evidence of the results of changes. It removes fear and gives clarity. It gives support for bottom-up and top-down approaches. It applies equally for managers who are driven by command-and-control and managers who have an intuition for change but lack the tools to guide it.
  • For longer term process changes, try to make people right. People’s concerns are almost always valid. When coaching, listen to what they are saying and feeling about their concerns. Listen and then build on that to help them see how your approach will help them be right. It almost never works to tell them why they are wrong.
  • It is better to ask questions than to give answers. Asking questions helps teams learn to observe their process and behavior. Push them back to their standard work to improve, “why aren’t you doing it this way?” As a coach, you sometimes need to be very firm in driving people back to the process and standard work and don’t give them slack.
  • Your two most important tools as a coach are your ears and your questions. Use all of your senses, including common sense, and remember that you have no authority. But you do have the ability to ask pointed questions directed toward the process.
  • As a coach, you must go to where people are doing the work. This lets you see what is actually going on. It creates fortuitous opportunities for coaching events. Lean calls this “going to the Gemba” to observe. It does not work to set up a Kanban board and a coach in a room and hope people will come to it.
  • Ask powerful questions. Powerful questions are more about discovery and challenging unexamined beliefs.
  • Attend to the bigger picture. Agile is not about individuals and teams doing what they want. It’s about individuals & teams doing what’s effective for them in the context of the whole. There is a difference. Developers often say they don’t want to write tests. When asked why, they give reasons that are always centered around themselves. The harsh truth is, it doesn’t matter what they want to do if it doesn’t include their role in the bigger picture (their team). The term “code complete” comes from developers thinking their job is writing code only. It’s not. It’s about adding value. Untested code has no value. This is the importance of the Lean principle “optimize the whole.”

Theories About Learning

Double loop learning is the modification or rejection of a goal / approach in the light of experience. Double loop learning recognizes that the way a problem is defined and solved can be a source of the problem. “Single-loop learning” is the repeated attempt at the same problem, with no variation of the method and without ever questioning the goal.

Here are a few resources to help learn about learning.