Definition of Done or Working agreement?
Definition of Done is the agreement between Product Owner and team. As ultimate goal, team is delivering potentially shippable product increment every sprint, thus, your Definition of Done shall be equal to what's required to make your product increment potentially shippable. However, your current Done may be only part of what's needed to get potentially shippable, constrained by your current technical capability. When we defined our Definition of Done several years ago, I found that we also added some criteria that are not really part of what's required for being potentially shippable. For example, we may make our product potentially shippable without automating the tests, though we added automated tests into our definition of Done. Why did we add them? Because we'd like to make sure that our development is sustainable. If we rely on manual tests, we shall soon find that regression efforts go up exponentially. We can not really afford, thus, we may not do regression in full all the time. Then, every now and then, we break existing functionality without knowing it. What's in Done and potentially shippable is actually no broken old functionality, while test automation is a practical mean towards that. I realized that there are two kinds of criteria in Definition of Done. One is customer/product and result oriented, which are all required to become potentially shippable; the other is process oriented, which defines the way of working. Over time, i also noticed that when team got mature, they tended to have less process oriented criteria in their definition of Done.
During a recent co-training with my colleague Emerson, I learnt from him that he always included those process-oriented criteria into working agreement. That is interesting, and it makes me wonder why we took different approaches and what differences they actually have. Here's my thoughts. Although it seems trivial since team will do according to both Done and working agreement anyway, there are profound differences. Scrum team is self-managing under certain boundaries. The most important ones are timebox in sprint, and Definition of Done. Organization and Product Owner executes the control through setting the boundary, while team self-manages within the boundary. Working agreement is completely up to team, thus, it's not part of the boundary set by the organization and Product Owner. In my environment, while we adopted Scrum, the concerns about self-managing still prevailed and the feeling of uncertainty from management was still strong. Thus, we kept more control by setting strict boundary through adding more process oriented criteria into Done. On the contrary, Emerson's environment seemed putting more trust on team, thus, they left those to the working agreement, which is created and owned completely by team. Either consciously or unconsciously, we chose the different approaches based on different assumptions and level of trust, and control.
Have you noticed the difference and what's the assumption behind your approach?
