"But how will I adjust priorities?" This was the existential question that Ophélie asked when our tickets were finally transformed into digital kanbans.
It must be said that the last transformation had been the most radical: not only would the "start date" replace the "end date" as the sorting item for the tasks within the technical team, but the field itself would no longer be editable once the date had passed, even if the task had not been started, even if another client had brought in a more urgent or more important task. Of course, this date is crucial: for us, it corresponds to the date of the initial request for an external customer or, for an internal customer, to the date on which we anticipate availability within the technical team. Because of a simple remark by a Sensei, pointing, midway through a mundane conversation, that he didn't understand the order of each developer's tickets, she had lost the ability to continuously modify the schedule for the entire technical team. Gone were the days she could shift a ticket or postpone another according to the pressing demands of a loyal customer or the high expectations of a potential client.
The previous transformations had had less of an impact on her. First, there was another remark during a gemba walk with our Sensei: "no help chain, no kanban." We therefore added a "trigger andon" button on each ticket. By clicking on it, the developer indicates that he needs help: his manager is automatically assigned to the ticket and a message is sent on our internal chat tool. This button complements another one, « to the red bin": this one allows the developer to specify that the request being processed is - one way or the other - problematic. It allows him to materialize it will be necessary to come back with the team leader or the CTO and to explore the root causes of the problem.
The list of tickets that went through the "red bin" or the "andon" has become a gold mine for our "gemba code" routine: by taking the time to delve into the details for this or that ticket, by finely analyzing lines in a log file or by dissecting the source code, the members of the technical team have brought to light design errors, lack of training, security gaps, and knowledge deficits. These discoveries have become a wall of continuous improvement that every developer can come to - whenever he or she comes into the office.
A good context for these explorations is the arrival of PHP8. This new version of our programming language forces us to dust off a lot of old knowledge. For example, when we discovered that our continuous integration server was not displaying notices, it was because the procedure for updating a server was out of date, not just some PHP initialization file. Or when a specific plugin started to give us errors, it was the mechanism to ensure compatibility with all plugins that needed to be addressed, not just the impacted users.
But it was by blocking their start date, by materializing the launcher, that the kanbans spilled over from the technical team to the teams in direct contact with the customers and end users of our software. And we switched from managing day-to-day operations with accordion-like delivery dates to managing them with a start-up date set in stone. Of course, this works because at our level of maturity, we know that a task should not take more than 8 hours of effective work and that, consequently, a task started on any day should be « live » on the following day. This technique ensures a task more complicated than the others will no longer slip imperceptibly to the end of the project: we want the problems to surface quickly. And that another, more complex task will not be left to the one specialist within the team: we want the necessary training to be carried out as close to the need as possible. By losing the "choice" of taking an easier or more common ticket, developers gain opportunities to improve their skills.
Because kanbans are a system: they are a real transactional framework between customer and producer, guaranteed by the responsiveness and support from the rest of the organization. Because of their power to reveal discrepancies and problems of all kinds (the virtue of lead-time), they imply a web of trust between the stakeholders and offer countless learning opportunities.
Of course, this beautiful mechanism can be interrupted at any time. We had the opportunity to verify it when a developer went on sick leave while another one was forced to take days off to take care of his little boy. The kanbans started to freeze, triggering automatic andons: Ophelie found herself in the middle of the exchanges with all the stakeholders. Not because the task was already well behind schedule, but because the start date had passed, which - from the client's point of view - was at least 24 hours in advance. Enough time to agree with all parties and check each other's priorities. Copious time to demand better tools for her daily work. Sufficient time to build trust beyond the team, with customers and users. Reasonable time to find the full measure of her function, "Customer Success Manager".
