I had an interesting conversation with a colleague about handover points that teams have in their processes and how to decrease them. He was explaining how to approach this problem in the Agile (Scrum) context; by allowing teams self organize around the work that needs to be done and having T-shaped team members, thus, avoiding silo culture. This was not the interesting part of the conversation.

What made this conversation interesting was, he actually wanted to know why Kanban did not care about silo culture; on the contrary, encouraged it. I was a bit shocked but none the less went along with it. I knew his question was sincere and I knew he was in a discussion on this topic with other Agile enthusiasts/evangelists in the work place.

So I asked “Why would you think that Kanban encourages silo culture?” …

He started to build his case from the team boards; “Kanban boards display the detailed flow of work the team has. They analyze and then build and then verify and then … That is Waterfall.“^{Answer 1}

He continued with one of the insights I told him before; “Since Kanban flow does not go back [flow backwards], that means they have to finish analysis for good and should never do analysis again in their flow. What would happen if a bug is found in Test column and development is needed? It has to go back to the development column. This encourages silo culture.“^{Answer 2}

The following content is about how I answered his questions and explained some of the common mistakes that most people make when talking about Kanban; The Evolutionary Change Management.

A1. The Detailed Flow/Process Visualisation

When people, mostly Agile evangelists, see a board that has more columns than a typical Scrum board (ToDo, InProgress, and Done), they tend to see a Waterfall disguised as Agile. The relatively detailed visualisation of process/work flow just brings back either their awful encounters with waterfall or a training session/blog post where they might have been given a check list outlining things to look for in a dysfunctional Agile team. They see people working in a silo culture environment. Which might be the case but this should not lead to a hastily conclusion that the team is doing it wrong.

Agilists see these columns as a wall separating the team members by their job descriptions and not allowing them to cross over to the other side. At worst, see these columns as a way of categorising team members in a racists way by their titles and positions; a mindless group of people who do what they are told in a context given/forced to them. Well surprise, scary but that is how most organizations work. Because they have been working like this for a long time, they might not know any better.

That is why we have lean/agile change initiatives, to let them see/experience a different way of working than they used to. Kanban; the evolutionary change management is one of them. Kanban provides pragmatic, actionable evidence-based guidance to organizations who would like to change for the better.

The first principle of Kanban is; you do not talk about… oops… that’s not the one.

The first principle of Kanban is; start with what you do now.

When a team introduces Kanban to their environment, they might start with the visualisation of the system. And the system they are working in might be Waterfall. Kanban encourages to visualise the current system how it is now, not how it should be. So it is perfectly understandable when some one looks at a Kanban board and thinks Waterfall. That is because the team, who owns the board, might be using Waterfall method.

A core practice of Kanban; visualise.

Change is hard and people react to change. People might resist passive aggressively and this resistance might not be detectable. Change or the need for change has to be accepted/understood by everyone in the system in order to be successful. At what point to start a change initiative than a place you are already familiar with. If it is Waterfall than let it be Waterfall at first. The resistance to change will be much lower than forcing a completely new way of working style.

Resistance is futile! (if < 1Ω)

All of the principles of Kanban are about respect. Respect the people who have done work and still working in a way that they think is best for the organization. My job as a coach is; start with what they do now, let them decide on their own by providing options for them, study and learn the system with them before suggesting any options.

A2. Manage Flow

In Kanban, flow should always go forward. Also In nature, one does not very often see a river flowing backwards. That is how flow of work is managed easily; deciding what needs to get done first. Forward flow helps to keep the FIFO status of the columns (queues/buffers) intact, making the system more predictable. That being said, let us refresh our memory on the comments which my colleague made.

“Since Kanban flow does not go back [flow backwards], that means they have to finish analysis for good and should never do analysis again in their flow. What would happen if a bug is found in Test column and development is needed? It has to go back to the development column. This encourages silo culture.”

My colleague was making these comments while thinking in the waterfall and silo culture context. Because that is what he could only see; a Waterfall variant which encourages the silo culture. The only thing that is not fitting in his context is flow going forward. He is insisting that flow must go backwards when needed. This is a common mistake every body can easily make. Allow me to explain why with my current knowledge.

When people see the process/work flow divided in to specific columns, they think that those are the only places that an action, implied by the column name, can be taken. They literally take the column names as the actions. That is the problem; Analysis column is interpreted as any work that is in that column can only be analyzed, Development column is interpreted as any work that is in that column can only be developed and no other action can be taken. So on so forth. If you are thinking this is how Kanban boards work, you have been misguided.

Columns are merely place holders for work items in the system and each of them has defined policies that need to be fulfilled before advancing to the next. The columns explicitly indicate what needs to be done so any work item can be moved forward on to the next by who is capable of making it happen.

A core practice of Kanban; make policies explicit.

To answer the question “What would happen if a bug is found in Test column and development is needed?”; the work item stays at the Test column and we draw a bug icon on to a sticky note and attach that to the work item.

The Test column does not mean that only testing activities can be done here. It means that this item has gone through development and currently being tested.The board signals that attention is needed from the team who are capable of solving the impediment and policies help how to remove this impediment which is, in this case, a bug.

In each column different services/policies might be required. It is not recommended to move the item in to the Development column. The policies defined in the Development column might not be applicable here; you do not need to develop the whole thing again, but only need to fix a code and test it appropriately. The work item might even need analysis and this could be done by the team member with testing capabilities.

The need to flow backwards is eliminated by using policies. With flow moving forward, I can easily see which items are my priorities and decide what to do about them. Kanban board is providing me pragmatic, actionable evidence based guidance.

Wrap Up

In short, Kanban does not encourage silo culture. Kanban board signals where necessary collaboration is needed by making polices explicit, helping decision making and flow management. All the team has to do is follow the guidance shown by Kanban and take necessary actions. These are the properties of a self organized T-shaped team if you ask me. 😉 Instead of imposing/forcing them to be self organized and work in a T-shaped manner Kanban lets them choose to work this way if it is appropriate. The team decides.

Kanban shows you how your work works. With Kanban there is no right or wrong implementation, there is only shallow and deep. You will still benefit from the shallow implementation of Kanban but keep in mind that there is more to it. Follow the evolutionary path, start with what you do now.

I would recommend visiting the Lean Kanban University website for more information about Kanban; The Evolutionary Change Management.