Agile coaches, Scrum Masters and coaching practices

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 set an agile center that coaches them.

Here I want to share with you what does an agile coach inside our teams :

  • As a very first principle we apply what Lyssa Adkins said in her book “Coaching agile teams”: agile coaches entrust the teams with their own problems. As an agile coach, you aren’t there to solve the problems of the team but to help them solve their problems on their own
  • The ultimate goal of the coach for a team using the Scrum method is that they own Scrum themselves. When the team begins to look for new ways of using the method on their own, the coach has won
  • 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 of working of a team, this is what we can observe in some successful teams :

  • The Product Owner : the P.O. is a member of the team who represents the customer. He has the functional vision. He defines the what and when. He trusts the team to know how to do things. As Henrik Knijberg said, his second job is to say no. A good P.O. knows when to say no and uses this key talent efficiently. A P.O. spends 50% of their time speaking to the developers. At the end of the sprint, he’s responsible to decide if features will be delivered or no
  • Developers are certainly not just code writers. They may help the P.O. defining the User Stories. But you may know that not all developers are able to do this

Difference between Agile Coach and 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

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 customised 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 rythm. 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
  • 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 saviour
  • 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
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.