Agile coaches, Scrum Masters and coaching practices
Jul 26, 2017 · 4 min read
Here at Talentsoft, we now have a quite big bunch of teams inside a group of more than eighty developers. To help these teams, we have set an agile center that proposes coaching to them, help them reach their goals, improve their performance… all of this based on their own needs and what they are willing to change in the next coming weeks or months

Here I want to share with you what does an agile coach inside our teams :
- As a very first principle we apply this principle Lyssa Adkins described in her book Coaching agile teams: agile coaches entrust the teams with their own problems. As an agile coach, you aren’t responsible of solving the problems of the team but to help them solve their problems on their own (and this is a whole position to enact to succeed here as a coach)
- The ultimate goal of the coach for a team using the agile Scrum method is that they must own Scrum themselves. When the team begins to look for new ways of using the method on their own (hence mastering it), the coach has won a decisive battle
- When something does not work the agile coach ensures that all together the team will test a new way of doing it to find a solution

Regarding to the way a team works, here are some key elements of what we can observe in those so called successful teams:
- The Product Owner (PO) : the PO is a member of the team who represents the customer and to be specific the customer needs.
He has the comprehensive functional vision. He defines the what and when. He trusts the team to know how to do things. As Henrik Kniberg said: his second job is to say no. A good PO knows when to say no and uses this key talent efficiently.
A PO also spends at least 50% of their time speaking to the developers. At the end of the sprint, he’s the one responsible to decide if features are mature enough to be delivered or not - Developers are certainly not just code writers. They will bring a lot of value by helping the PO to define the content of the User Stories (even more while doing it with a QA Engineer). But you may know that not all developers are able to do this, it depends on seniority level a lot
Differences between an Agile Coach and a Scrum Master
- The Scrum Master eases the use of Scrum as needed by the team. He continuously removes the impediments external to the team that prevents it from using Scrum. He protects the team from the distractions and helps it keeping focus on the goal of the iteration. The Scrum Master makes the team apply the rules of Scrum
- The agile coach helps the team to use Scrum or another method on their own. He has no direct responsibility on the results of the team, but looks for the team’s performance. He facilitates the meetings and day to day of the team. He uses more communication tools than just agile principles (transactional analysis, maturity models…)
Tips to remember for an agile coach
Here I share some tips I gathered in my different teams along time which may be useful for an agile coach :
- There is a Scrum framework, and its implementation is customized by each company, each agile environment, each team being made of different people
- A change always create a perturbation
- If everyone is okay, it means that the change is small. It’s not always bad. In the contrary it’s not always a problem to have people against a change
- If I manage the technical debt, my velocity will decrease. Yes, of course. At the beginning and then I’ll found a cruise rhythm. But if I don’t manage it, I’ll crash
- People often said “if I write test it takes time”. But often they don’t measure how much time they spent to fix bugs
- The velocity sometimes decreases because of the way the P.O. does things : a bad written story is difficult to develop and to test
- About velocity, don’t discuss the measure unit (story points, men days…). Just don’t change along time. The real use of velocity is to compare it with previous measures to improve it. So it’s must be homogeneous along time
- Always use post-it in meetings to avoid influence bias. Post-it helps thinking and allows to capture information.
For example, in a Poker Planning meeting with 2 developers, let’s say one junior and one senior: if you don’t capture answers to questions about estimation of a story, the junior developer could be influenced by the senior one who talks first and modify his or her estimation. Unlucky for you, this day the junior developer had thought of a brilliant way to develop the story and it was really easier. If they had written their estimations on post-it, everyone in the team has a better chance to explain their choice - Facilitate means reformulate and ask questions, point out problems and risks with disguised questions
- When somebody complains about something but stays vague and general, ask for examples to define clearly the problem
- When somebody complains about someone absent, just say “okay, how could we tell him when he’s back?”
- Be wary of words such as “just”, “awesome”, “impossible to maintain”, “unbearable”. They are often a subjective reading
- Coach isn’t the intermediary for the team, he’s not their savior either
- Ask provocative questions may sometimes help: “If you had free rein, what would you do?”
- When doing a retrospective, assume that everybody has done their best for a successful project
