Many teams practicing agility use the Definition of Done (often referred to as DoD) to determine, based on objective and shared criteria, if the User Story (US) is well completed. These criteria also serve as a “contract” between the team and the customer.
This DoD is regularly translated into a list of points to check and is, most of the time, displayed on one of the walls of the team’s office. During my coaching, I even met a team using an Excel sheet filled in by each developer for every US made… which made me think of the traceability of the Verification (VER) process of the CMMI-DEV, but that’s another story.
But, will you tell me, what does the Lean Kanban have to do with this Definition of Done story?
In Lean Management in IT, we are used to using the IT Kanban board to materialize a flow of production driven by the customer’s request (internal or final). This flow (or process) is therefore divided into stages between its point of entry (the customer’s request) and its point of exit (delivery to the customer). The ideal being the one piece flow punctuated by the takt time, the kanban board limits de facto the number of pieces in progress.
What can be found in the Definition of Done? Criteria, as indicated earlier. But if we look more closely, these criteria are in fact – for a very large number of people – steps in the value creation flow. For example:
– Code review is performed -> step: Review code ;
– The US tests are passed and are OK -> step: Test the US ;
– The PO has seen the demo -> step: Show Demo ;
– The technical documentation is up to date -> step: Update technical documentation ;
– The code is merged -> step: Merge the code ;
– The version is deployed on the test environment -> step: Deploy on the test environment.
– • …
However, it is very common that delivered US do not have the right level of quality or their necessary documentation up to date, for example. This is due to a visual management that can be improved, because the DoD displayed in this way is no longer useful. Of course, the information is displayed and accessible by all team members, but after a while it is no longer “visible”, because the brain has become accustomed to seeing this poster.
You may try with corporate posters decorating the walls in your company 😉
Too often, the boards of the teams we meet are made of To Do / In Progress / Completed steps (no, this is not a Kanban board), which do not allow the team to easily know where the US is and what is happening in the process, because all the activities are concentrated in the “In Progress” column. In fact, a trick had to be found to determine whether or not the US is complete, hence the “Definition of Done”. By using the Kanban principles to transform these criteria into a flow step (i.e. detailing the steps in the In Progress column), teams can see the progress of the US on a daily basis… and much more!
For the record, the authors of The Lean Strategy define visual management as follows: “Visualization is a technique specific to Lean, which animates the workspace and allows employees to easily confront problems because they are obvious to them.“
The “step” type criteria of the Definition of Done are usually transformed, by teams practicing agile, into tasks (in addition to the US) in the sprint – so as not to forget to perform them – and complete (overload?) the In Progress column. With the IT Kanban board, there is no need for these additional tasks because the US Kanban card moves through all the stages to be completed. Therefore, if for a US it is necessary to update the technical documentation (one of the criteria of the DoD), this will be done when the US kanban card is in the ad-hoc column.
Let’s take the example of the criterion “US tests are passed and are OK”. With a classic board, a KO US card does not change column and remains in In progress with, possibly, an indication. On an IT Kanban board, the Kanban card of the US moves back to the Achievement step and an item is created in the red bin (as it is a quality problem) of the “Test the US” column, to trigger a problem solving aimed at understanding why this US is not right the first time.
As for the customer, the columns of the Kanban board materialize, in the same way as the criteria of the Definition of Done, the contract with the team since a user story is finished once it has been through all the columns (steps of the flow) – and according to the takt time – and ended up in the Finished column.
An other article Improving Kanban or Adjusting DoD? is the very example of a development team – running in sprint – which, following a validation problem, decided not to adjust the Definition of Done criteria, but to change its IT kanban board.
Other DoD criteria can be transformed into performance indicators (The measure to see the performance) of the team, such as Unit tests cover at least 80% of the code or Technical debt does not increase (in relation to a target). With this type of indicator present on the visual management and updated at the end of each sprint (or daily with automatic testing/analysis tools launched at night), improvement actions can be undertaken immediately if the coverage rate deteriorates.
One day, a developer asked me where to place criteria such as “The application must run on all current browsers” (limited however on the number of versions of each browser). When should these criteria be tested? At the earliest technically, i.e. in the Realization stage, even if the business tests (during the Validation stage) can also perform them, but it is already relatively late in the flow. It may therefore be interesting to add lower level end of stage criteria on certain columns of the IT kanban board. This would allow each person to know whether what is done is OK or KO; one of the basic principles of visual management, as the authors of The Lean Strategy remind us: “For the sake of motivation as well as autonomy, employees need to know at a glance whether they are successful or not.”
The columns of the IT kanban board are not set in stone. It may be necessary to add a column showing a step to improve the quality and what needs to be produced in the value stream. The important question is to ask what value this step brings: does it add value (to the customer) to the product/service or is it wasteful (adds delay)?
Not only does the IT kanban board makes the criteria of the Definition of Done “active” (and no longer passive -> simply displayed), but it makes many more things visible (the flow that moves or not, non-quality with the red bin, expectations, overloads…). It’s “all good” for the team, and this is only the beginning!
Important: one should not believe that with only columns materializing a flow, the team is practicing Kanban. I invite you to read or reread “Kanban, may the force be with you!” to understand the fundamentals necessary for the proper use of Kanban.
Original post in French written by Jean-Philippe Douet, translated with Deepl.
Better, Faster, Together - Operae Partners blog 