“From now on, we should only communicate by email so we won’t get disturbed unnecessarily and we’ll be able to focus on the code.”

We’re in a sprint retrospective. This proposal comes from one of the Scrum team’s developers. It’s quickly applauded by other developers. Even the other members of the team seem to see an advantage. It’s true that in a discussion we sometimes lack preparation, it’s better to regroup your ideas on paper after all.

You, the Scrum Master, are puzzled by this ‘solution’. You want to wave the Agile manifesto, talk about the efficiency of communication channels, praise the benefits of collaboration… But before saying anything, ask yourself the following question : “And if I let the team fail?”

The value of the experience

One of the first thing to consider is the value of the learning that the team will get out of it. Indeed, if applying this solution clearly shows everybody the added value of collaboration as well as the loss of efficiency linked to using emails within the team, the value of this learning can justify the time the team has invested in trying this ‘solution’.

Furthermore, since it’s a solution coming from the team itself, it will mobilize to respect it. It will do everything in its power for this solution to be successful. However, knowing in advance that despite all its efforts it will be difficult to be more efficient than with direct communication, the results will be all the more eloquent for the team having experimented with it.

The cost of the experience

It’s good to consider the value of learning, everything has a cost. This cost has several dimensions. One obvious dimension is financial : the money spent in salaries for the members of the team. Beyond the obvious, we also need to consider the human cost. What effect will that potential failure have on the team’s dynamic? Will it put in danger the participation and self-organization? What’s the team’s maturity level? Is it ready for this learning or will it be offended by the fact that the Scrum Master did not act during the retrospective?

And on the level of the work to be done, will this experience have a negative impact on a delivery expected by the Product Owner? Could the team blame a stakeholder for taking this path?

Failure or not?

One of the main responsibilities of the Scrum Master is to reinforce the Scrum roles. On the level of the development team, this translates into favouring empiricism and self-organization. When it’s about how the team self-organizes, through this responsibility the Scrum Master should assume a passive role. On the other hand, the Scrum Master is also asked to be a change agent that increases the team’s productivity. Finally, he is responsible for the blockers to the smooth operation of Scrum. This brings shades of grey to the very black and white definition above.

To help navigate this gray — especially when facing anticipated failure — I often use the following analogy : my two-year-old daughter is swinging on her chair. Despite a few parental warnings (“Be careful, if you fall you will hurt yourself…”), she seems to want to continue. If she is on her tiny chair (one foot off the floor) and it’s on a soft carpet, she will only get slightly hurt by falling. She will cry, but nothing potentially serious. The value of learning (I fell when swinging, it’s dangerous) is worth the cost (slight impact and a little pain). If she does it on a taller chair placed near a staircase, the value of the same learning certainly isn’t worth the cost of falling down the stairs.

Here, we can associate the image of the child to the Scrum team : trying things and learning by living the result of these trials. If it’s bereft of more difficult learning by an overprotective Scrum Master, the team will have trouble owning and putting up with future failures — somewhat like an overprotected child. Be protective of your Scrum team, but let it learn. Small failures lived as a team forge the temperament and often have a positive impact in the long run.

Previous post

How could more authentic love fuel your leadership?

Next post

Journal of an Intern

pawel mysliwiec

Diplômé en 2004 et certifié Professional Scrum Master, Pawel a joué divers rôles depuis le début de sa carrière – programmeur, analyste, chargé de projet, coordonnateur, responsable de produit et, plus récemment, architecte d’affaires – dans des contextes de réalisation de projet tant traditionnels qu’Agiles. Depuis 2011, il met en application les méthodes Agiles dans des équipes de projets informatiques et aussi dans celles responsables des activités commerciales.

Convaincu de la force des principes Lean et de la philosophie Agile, Pawel s'est joint à Pyxis en 20015 pour continuer à aider les personnes et les organisations à découvrir une façon de travailler valorisante, responsabilisante et efficace et qui demeure centrée sur la valeur pour le client.

1 Comment

  1. Barb Schultz
    14/08/2017 at 17:20 — Reply

    thanks for the times you have let me fail. . . great article

Leave a reply

Your email address will not be published. Required fields are marked *