I recently worked on Kanban adoption with a new customer, who informed me that Kanban was already underway and wanted me to help finish the adoption.
On the first day, I was taken to the Kanban boards, two of them, and was introduced to the 15-person team. I noticed right away that the Kanban boards lacked a good number of essential elements to be considered an actual Kanban board, such as explicit policies and well-defined classes of service. Furthermore, the boards were not for separate projects. One was for the development phase; the other for the test phase. Also, the adoption work was delayed by a month because a key person (the champion) wasn’t available earlier.
In this company’s approach to adoption, the champion read a portion of David J. Anderson’s book, Kanban: Successful Evolutionary Change for Your Technology Business, drew what he claimed was Kanban boards, and populated them with cards. He then established daily Scrum meetings, one per board, and then a Scrum of Scrums. Although the customer sat six feet away from the team, the customer was never invited to those meetings. Team members were not allowed to touch anything on the board, and communication remained the same as it had been before using the Kanban board. As a result, the boards were abandoned the moment the champion left for a conference, and the champion himself didn’t touch the boards on his return. The adoption approach had been entirely anti-lean.
I entered the adoption first by making sure the stakeholders learned lean-agile thinking, and then by improving communication and collaboration. The office space was very well set for a lean-agile environment, but the modus operandi was entirely individualistic. I brought the customer in despite the customer’s concern that it would open a communication and collaboration can of worms. To my own surprise, the customer was awesomely active and willing to do what it takes to do things well. I helped the team identify wastes and areas of improvement. It wasn’t until the end of week one that I introduced the team to Kanban. With all the previous work on lean-agile, the team found it rather easy to understand Kanban.
The team had to deliver a portion of the system being developed to the customer by the end of week two. When I started working with the team, and as I helped raise all the issues, it became clear to them that it was going to be impossible to deliver on time. Well, thanks to the work on changing the team culture to be lean-agile and bringing Kanban in the right way, they finished on time. Although there was still technical debt to deal with, the delivery was in good shape because of the focus on delivering the highest possible value to the customer.
By the way, the champion never showed up to any of the training session or the adoption efforts. All he did was join a Kanban exercise on the last day, and it became evident that he was far from ready to teach, Kanban because he himself didn’t understand the basics.
- An anti-lean approach to Kanban adoption is a recipe for failure.
- Beware of whom you choose to champion your adoption efforts.