8 lessons learned from implementing Kanban through STATIK
Working with different clients is one of the most striking and, at the same time, most rewarding characteristics of the consulting activity. We get to know new concepts, environments and people with whom we work hard, we guide, but above all, from whom we learn a lot as well.
In one of these opportunities in which we work and learn together with the client, I had the chance to participate in the development of a STATIK cycle aiming to improve the beginning of the implementation of the Kanban system in a large area of the company. In this specific case, the teams had been working with Kanban for about six months, but with clear different levels of knowledge about the method. The idea of applying a solution based on Systems Thinking came from one of the team members due to a training he had carried out in which STATIK had been indicated to introduce Kanban into the organization. This idea was fully accepted by the department's general management and put into practice the next available moment.
The attempt was to follow the steps of STATIK in a sequential manner, although a shallow prior reading on the subject suggested that this wouldn’t always necessarily the best way. I don’t want to start this case study by giving any spoiler but throughout the application, which was scheduled to occur in a whole day, it was evident that this strategy, in their case, was not, in fact, the most advisable.
A workshop was prepared in the best agile style, with the room arranged in the form of working groups and post-its available for everybody. In the original agenda, the facilitator had set aside one hour for the first STATIK step regarding the department's purpose. However, what seemed like a light discussion that would lead to an obvious consensus, ended up taking half a morning. Discounting the coffee-break time, it was a surprise that exploring the criteria that define customer satisfaction with deliveries has taken so long. It shouldn't have been that unexpected, because according to David Anderson himself, the team's maturity influences this configuration a lot. We did not get to sketch any quantitative metrics, but it was a fruitful exercise to start the morning.
#1 Lesson Learned: keep the team always in line with the vision and purpose of the work being developed.
The second step involves understanding the sources of dissatisfaction with the current system. In practice, every Kanban system makes use of these sources for its own improvement. This information will directly influence classes of service, amount of work in progress, type of demand, among other points. The team's internal view of how they understood the system and how they thought it should be was very interesting. However, a small great detail was left out: clients were not asked to speak and were not even interviewed beforehand. Only the internal vision of the team that developed the service was considered. As much as it is a valid point of view, it is not the view of who receives the service. Unfortunately, this error was only identified during the workshop and that STATIK step had to be rescheduled. Forcibly the team started to realize that trying to develop STATIK in the waterfall format might not be the best alternative for them.
#2 Lesson Learned: Understanding dissatisfaction is an iterative, collaborative and osmotic process in which all stakeholders (internal and external) must participate.
As soon as we got back from lunch, we would move on to the third step. At least that was the plan. Interestingly, in the first fifteen minutes of conversation, the team itself concluded that their members were confused about the concepts of type of demand and class of service, which constitutes the sixth step of STATIK. The team knew and used the concept of user stories well, but it was clearly not unanimous in the team to differentiate between the characteristics of demand and its prioritization. We had a very productive debate about the types of demand that the department received and how to classify them in terms of their classes of service. In practice, a typology has never been discussed either for demand or for its classes of service. This was the central point of this part of the workshop. It was not intended to have a perennial definition, but it would be nice to start from some elucidation. Four types of demands were defined (new functions, corrections, improvements, back office) and also four types of classes of service based on the classic division: urgent, fixed date, standard and intangible.
The energy caused by the simple creation of these classifications was so great that it us took almost the whole afternoon. In practice, the meeting had to be extended for another day. Many ideas emerged from these simple definitions, ranging from the post and badges color to heated discussions about the volume of each demand, the nature of its arrival, considerations about the value generated, risk analysis, so on. Most importantly, many interesting questions also arose: were there any hidden classes of services? What is the relationship between classes of service and lead time? To what extent would it be necessary to use all classes of service for all teams? These were questions that would hopefully lead to the definition of a couple of work policies. Although rudimentary, that would already serve to better mark what was being developed.
#3 Lesson Learned: types of demand and classes of service influence team work agreements and, consequently, the system flow.
The next morning, we tried to analyze the system's capacity. The understanding that the application of WIP limits favors not only speed, but also the regularization of the work pace and the location of bottlenecks seemed well understood and commonly agreed. However, as much as each team had a vision of its own bottlenecks, the metrics (or their rough sketch) made with the support of some burnup graphics using the good old excel were not accurate enough to reach a conclusion about the department as a whole. Some argued that they should start using a cumulative flow diagram (CFD), others suggested that the CFD was nothing more than sophisticated burnup. But regardless of this discussion about the tool, everyone there understood that starting to work better with metrics was important and that even the way to configure each card on the board could be optimized to facilitate both lead as well as cycle time analysis. At the same time, it was concluded that this should be the subject of another workshop at a different time, other than that. There were more basic definitions that should be tried out before more sophisticated metrics were implemented. This was a tough decision, but the team has voted and agreed with it.
#4 Lesson Learned: metrics are important to measure the limits of the system's capacity, but they also need to respect the right moment of the team's maturity for its implementation.
Regarding the workflow, we tried to analyze how it was modeled for each of the four types of demand defined in step three of STATIK. One thing is the mapping of processes related to the value chain that is being worked on and another is the analysis of each demand as it enters the queue to be developed until it is delivered. As it was necessary to have a starting point, an attempt was made to make a general analysis based on the processes that were being produced in the current Kanban boards. The simple study of the number of processes led to subtle discoveries about how orders arrive for the teams, the different definitions of DOR and DOD, in addition to which rules were being used in each flow. At a certain point in the discussion, this mapping led the team to form work groups that should join together post-workshop to propose actions to improve the workflow.
#5 Lesson Learned: it is of fundamental importance to study and know the workflow in order to increase collaboration between teams.
In theory, all the work done previously would lead to a better design of Kanban boards. We were already in the afternoon of the workshop and the modeling of the workflow that had just been done led to new columns in the developed Kanban boards. If the degree of understanding of the systems and even the department as a whole and its dependencies had grown, on the other hand, the complexity had also accompanied the epiphanies. My intervention at that point was to suggest that a Kaizen style of small incremental improvements should be adopted. Especially because although the findings we have had over the past two days had been enriching, it was necessary to walk safely before we could run.
#6 Lesson Learned: increase the Kanban board on the basis of experimentation and not try to embed all the complexity of the process at once, especially considering the low maturity of the team using the method.
The one that would be the last step of the of STATIK process involves socializing the design of the Kanban system and negotiating its introduction. Everyone agreed that any new implementation would require greater adherence from everyone involved, including other stakeholders who had not previously participated or had little participation in Kanban boards development. The way the systems were being operated until then, even considering the good intention of the teams, represented more build design up front (BDUF) initiatives than MVPs.
#7 Lesson Learned: more than just getting hands-on and starting to put masking tape and post-its on the wall, socializing is an important moment to gain a certain complicity of the main stakeholders within the whole process.
In addition to the feeling of immense learning through experimentation, it became evident that applying all Kanban techniques combined at once is not a good practice. STATIK is definitely not a static protocol and proves to be much more useful when developed in an exploratory way, following the increase in maturity of the team itself.
#8 Lesson Learned: As stated at the beginning of the article, consulting work teaches us a number of things, if we are paying attention and willing to learn. Within this context includes our own tendency as consultants to try to transform each and every process into a formula or recipe to be applied. This temptation must be tamed according to each scenario, respecting the organizational culture and considering the characteristics of the environment.
So be it!