🇮🇹 Leggere in Italiano 🇮🇹 / 🇫🇷 Lire en français 🇫🇷
A few days ago, I was observing a Sprint Retrospective. The Scrum Team decided to work on the Definition of Done (DoD), identified as the most important topic to adapt for the next Sprint. The discussions were open and animated, when an unexpected discussion emerged during the session.
Two new developers have recently joined the Dev Team, now composed of five people. The team growth has changed the dynamics, adding complexity and the need for a revision of the Definition of Done.
The Scrum Master invited the Product Owner and Dev Team to generate ideas for the DoD. Lots of post its were generated and shared then, some items detailed, other less precise. Afterwards, the discussion got stuck on the level of details of the documentation, especially for testing purposes.
The question was: how precise and detailed should the DoD be? Should we be specific, for example: “non regression tests documented, validated by a pair, run and the result stored on the folder XY”. Should we just be happy of having a phrase like: “non regression tests”?
The answer to this question is, of course, whatever the Product Owner and Dev Team decide together is acceptable, provided that they continuously improve through inspection and adaptation.
This is when an unexpected conversation started between the DevTeam members: one of them arguing that simply writing “non regression tests” wouldn’t ensure that the colleague performed enough “good” and “significant” tests. He could just have done something to get rid of the test and move on to the next one.
At this moment, a bell rang in my mind, a red flashing neon with the letters “T R U S T” started to blink as well… (yes, strange things happen in my head sometimes :-))
Starting from the assumption that the Dev Team is a group of professionals that are self-organized to create a Done Increment at the end of each Sprint, if they are unable to agree on a DoD definition and use wording like “how can I know if you really did a good test” it’s, in my opinion, the evidence that the issue is probably relying on having trust in the other team member’s work.
I validated my assumption of the situation with some open question.I know now I have to help the DevTeam restoring trust to become effective again. What started as a DoD discussion, finally revealed a deeper issue: a lack of trust between the DevTeam members.
I’m confident this team will overcome these difficulties, and will be an high performing Dev Team quickly!
Take aways
- I constantly check for lack of trust. Often this is the problem. You can check my “Exploring the Scrum Values Workshop” article for ideas.
- Changes in team composition may affect team productivity, read the Tuckman’s stages of group development to know more.
- As a Scrum Master, learn to identify where the real issue is, by cross-checking the topic at stake, people behaviours, people wording and body language.
- As a Scrum Master, stick to the Scrum Guide and the rules of the game (especially if you’re less experienced) many times, this is the starting point of my explanations.