Why we hate process

Process improvement (PI) specialists have historically dealt with the challenge of implementing PI initiatives in any organization – especially the resistance to change from the people impacted by the change. Last week, we had the pleasure of meeting a bunch of great folks at Adobe, where among other people, we met Devin Rickard who is responsible for that exact same task at Adobe. His efforts and Kanban’s ability to enable evolutionary PI truly resonate. This guest post by Devin highlights the challenges of PI and exhorts us to re-focus and think about PI from the perspective of the main beneficiary of PI – the Customer!

Handling ticket issues with Kanban

David J Anderson's book on Kanban shows us that a way to handle ticket issues is by attaching a color tag to a ticket to make it visible. An issue is ticket-related event that becomes an impediment to its value flow, such as a defect, insufficient definition, unresolved dependency, etc.

Visualizing cycles in Kanban

At a training session in Kitchener Waterloo, Canada. I was asked how to visualize and handle cycles in a Kanban board. The images below show a way to do it as a physical board and on an electronic board such as Swift Kanban. Tickets within a cycle move from left to right, from one column to the next until and cycle back as many times as necessary and once done they move to the Done column at the the end of the cycle. Note that columns inside the cycle can contain their own Done columns.

So how do YOU do Agile in a Distributed environment?

I was part of a very interesting discussion at a Silicon Valley high-tech giant a couple of weeks back that focused on doing Agile with distributed teams. We discussed several aspects of Scrum/ XP practices in distributed teams – and it turned out one of the main (some said “the only!”) challenges was the ability to run a Daily Standup meeting well!

Maturing the Kanban board

Organizations new to Kanban that have no experience with Agile usually find it easier to design their boards than those with Agile background because Kanban recommends the board to reflect the actual process rather than an abstraction. Compare for example Board 1a, quite common in agile practices, with Board 1b. 

Board 1a  

Board 1b 

This is a good start. As we all know, a project’s behavior changes over time. This means the Kanban board should keep up with those changes, but unfortunately many Kanban organizations don’t go about keeping the board up to date and that has undesirable consequences such as fake visualization and forcing the real process to adjust to he board process. Both of them affect quality and value delivery. Oh but there’s more to it. We miss big time on the identification of opportunities for improvement.

 I will illustrate the benefits of keeping the board up to date through a real case. One of my customers is a small Telecom business that provides technical services to some of the biggest Telecoms in the world. The very first coaching session I gave them right after finishing Kanban training consisted on helping them create their first functional Kanban board. As a coach I didn’t build the board for them, of course, but rather had them create it providing guidance as I saw it necessary. During that session I realized that the last portion of their process was convoluted so I decided to dig into process details with them rather than focusing on creating the board. Throughout the discussion the team agreed that part of the process was suboptimal and I made a recommendation which we agreed upon and so the first Kanban board was created reflecting the actual process but already suggesting a small but important change at the end. The change had to do with the customer verification phase.

I visited them to do a second round of coaching and was very pleased to see they had modified the board to be a show on Board 2a. I asked to a team member to explain the board to me and he did a pretty good job; and at the same time I noticed some hesitation explaining the sub-column labeled “Pending”. I decided the to dig in to it. Discussing this with the team it became clear that it had to do with dependencies they had with their subcontracted providers as well as with internal dependencies, and their cycle time was being affected by it. 

Board 2a  

I then suggested to them to further visualize “Pending”. The result was Board 2b. We added a new column to visualize de 3 subcontracted providers and also kept de original sub-column which was to be used only for internal dependencies.

Board 2b  

This change allowed to better understand the behavior of each subcontractor a well as to see how the customer was taking care of its own dependencies. The subcontractors behavior was quantified (the rest of the process had been quantified before from the beginning) and that allowed to show them how their response time affected final delivery. This motivated the subcontractors to improve, one of them started adopting Kanban also, and that resulted in significant improvement on delivery to customer. This also motivated a behavioral change on the team itself to take care of their internal dependencies more efficiently. The rend result was an increase of on-time delivery to customer from 86% to 99%.

Additional benefits surfaced from this such as the obtention of more contracts without having to increase staff.


--Masa K Maeda