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 DevTeam, 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 DevTeam to generate ideas for the DoD. Lots of post 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 be the DoD? 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 DevTeam 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 DevTeam 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 DevTeam quickly!