Standards and the definition of done
Without standards there can be no kaizen, Taiichi Ohno.
Kaizen is a Japanese word that we can translate as “change for the better”. It’s widely interpreted as meaning “continuous improvement” when referring to process or flow.
As Taiichi Ohno (father of the Toyota Production System or TPS) highlights, to improve, you first need to have a baseline standard. From the TPS perspective, standards and the improvement of said standards, relate to two aspects:
- Process – the work carried out at a particular step on the production line.
- Flow – the overall flow through the production line from end-to-end.
So, if we’re to translate this to cross-functional product teams, our team can determine its baseline standards by asking three questions:
- What defines an item of work and when do we know it’s ready to be worked on? This denotes the start of our flow.
- When do we consider an item of work completed? This denotes the end of our flow.
- What are the individual steps that are required to take a piece of work to ‘done’? This characterises each step and what that entails.
In this way, the team defines the process steps that take the product or features of the product to completion. This then becomes known as the ‘Definition of Done’.
It’s essential to define done because it helps the team reach a mutual understanding of what an acceptable standard is. It also assists the team in an estimation of effort for a work item. For example, if the piece of work is a User Story, the acceptance criteria for the User Story plus the items on the Definition of Done have to be completed for it to be considered ‘done’.
So, where the acceptance criteria for a User Story can be used to gauge if we’re building the right thing, the Definition of Done is a way to gauge are we building the thing right? It defines the quality aspect of delivery.
In setting up a Definition of Done, or any form of working agreement, accept that not every eventuality can be foreseen or catered for. We should consider it a ‘living’ document, something that will mature and change as the team process evolves and changes.
If we discover a potentially better way of working, we should discuss it with the group that is bound by the working agreement, and a consensus (most people are happy) on whether to alter it should be reached. For most teams, this happens during the retrospective meeting but can also happen at any other time when the team gathers.
One final thought, when setting up a Definition of Done, and for working agreements in general, keep in mind the Agile Values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Agile Values will help our team form an appropriate agreement with an emphasis on ‘working’, rather than impeding. We should pay particular attention to the third value and in this instance instead of “Customer collaboration”, read just “collaboration”.
Contracts are inflexible, changes are not simple and to uphold them requires some form of policing. All very time consuming and should be avoided as much as possible, especially within a team.
Collaboration is inherently flexible and allows for change to occur more fluidly. It’s also self-policing, so no need for one individual to step away from the frontline, each team member has responsibility and is accountable for how things get ‘done’.