During the retrospective of an agile team using a Kanban board in the Lean sense (read the article Kanban, may force be with you!), its members looked at the pieces made (delivered) in relation to those to be produced (the Kanban cards present in the backlog) in the sprint. First, look in the red bins for quality defects and do the Pareto if necessary. This exercise done, it turned out that because 2 tests were declarde KO, 2 functionalities could not be delivered; this is what the visual management revealed since both were in the red bins.
The team, eager to understand, launched a PDCA. For 2 unfortunate functionalities only, will you tell me? Well yes, for 2 unfortunate features. It is one of the principles of Lean Management – which probably got lost somewhere in agile techniques – one must stop at the slightest problem. In the ideal Lean world, the team should have stopped when the problem occured to solve the cause of the problem; which is what Toyota has been doing for decades. Let’s continue…
The search for causes
While practicing the “5 Whys” technique in the framework of this PDCA, the team realized that the 2 functionalities to be tested had indeed been modified (hypothesis check by looking in the code), but not pushed on the test environment (hypothesis check by doing a check on the test environment). The person in charge of the tests who did not obtain the expected results concluded, very logically, that these 2 functionalities were not compliant.
Readers with an appetite for agility will tell themselves that the team did not have a clear and common vision of the DoD (Definition of Done) of the development stage… and this is true, because as the questioning continued, it became obvious that not all team members shared the same definition of DoD and in particular the fact of making available the functionality added or modified in the test environment. The classic question: and why? Some will say that it (the DoD) is not correctly written, others that it is not displayed and visible by the whole team…
The solutions
The team put forward 2 opposable proposals for improvement, the first one aiming at updating the DoD and the second one proposing to improve the Kanban board to make visible the cards (functionalities) available on the test environment. A long debate was launched by several protagonists.
Both are good, but one will bring more value to the team. Which one will they choose…?
Adjusting the DoD or improving the Kanban chart?
If you follow my articles on Visual Management (Visual Management boosts self-organization) and Kanban, you will have understood that I am in favor of making things visible (I will even say: making it physical). So, to improve the Kanban board.
Why should I do that? Simply because this action of pushing the functionalities on the test environment is a step in the value creation process. And, as a step, it must be visible on the team’s kanban. Writing it in the DoD wouldn’t change much, in the end. The DoD should, in my opinion, contain states and not steps in the process. If documentation is to be done after developments, it should appear on the kanban board and not in the DoD.
The team decided – without any influence from me, it is not the role of the Lean coach – to test (Lean principle) the proposal to add a column “Make available on test environment” with its 2 sub-columns (“In progress” / “Done”) to its Kanban table.
A better understanding of its flow
By adding this column, the team now has the ability to see if the functionality is actually available on the test environment; testers no longer have to worry about whether or not the kanban card in the “Done” sub-column of the development stage stopped, or not, before the functionality was dropped on the test environment. As long as a kanban card is in the “Done” sub-column of “Make available on test environment”, the person responsible for testing can take over (pull flow principle) this kanban card.
A better ability to detect problems
Some detractors say that it makes the kanban board change again, to which I reply that a visual management – kanban board or not – must be modified to adapt to the context of the team. It is not set in stone!
Yes, it is one more column, but it is an additional possibility for the team to understand what is going on in its process. It will allow them to see if there is bottlenecks in the “In progress” sub-column of “Make available on test environment” and to question why. But also to question the team’s ability to continuously deliver the functionalities to be tested and thus limit variability, underload and overload.
Before modifying your DoDs, ask yourself if what you want to add corresponds to a state or a step.
Original post written in French by Jean-Philippe Douet ; translated with Deepl.
Better, Faster, Together - Operae Partners blog 