Starting with Managers Kanban (also called Product Stream Representative Kanban)

The short version

Based on experience helping organizations go agile in the last few years, an emerging attractor for healthier more sustainable results seems to be the “Starting with Managers” pattern. This is a “training wheels” pattern which seeks fastest learning of the managers in the organization what going towards an agile flow feels like and entails as well as the fastest learning as to whether that is an approach the organization wants to commit to and deploy. Basically all elements of Kanban - Visualization, Flow Management, Explicit Policies, Improvement Feedback Loops etc. are implemented with Managers. People are aware that it is happening but not expected to directly change their behavior at first. They might get different “directions” from their managers due to different flow decisions but they are not “pulling work” on their own. This pattern is a change management pattern that seems to generate more buy-in and support at the managers level, which manifests as faster “stop starting start finishing” thinking, lower resistance and viral distribution of kanban systems in the organization.

For more details, see below…

The Context

Let’s say we are talking about a group with about 50 people. This group works on several products or projects at the same time, with a functional team structure mapped to the technology stack e.g. GUI, Business Logic, Database, Infrastructure, etc. Each of those functional teams has a team lead/manager, there is also a QA group which is mapped functionally as well (though sometimes QA is already a bit more tuned to the product side). This can be either the whole R&D group of a small-medium product company, the IT unit of a medium organization, or a product unit at a bigger enterprise product company or one IT department in a bigger IT unit. The majority of my engagements w are comprised of those atomic units, sometimes standalone and sometimes as part of a bigger enterprise engagement.

The Typical Approach

What we did until recently wouldn’t be a big surprise to anyone. We went in and implemented Scrum or Kanban at the team level combined with an end to end flow system typically using Kanban. You’d see the typical buzz and hassle of launching a couple of teams, training dozens of people, preparing backlogs and boards, and running iteration ceremonies for a couple of times until there is a stable agile framework running in the organization. Even when using Kanban it is still a big change to create all the teams, their kanban systems, teach them the ropes of how to manage flow, and work with each of the teams to start improving using WIP limits etc.

This approach has definitely been successful many times at bringing an organization to a “steady as she goes” agile delivery process. But I felt with so much energy invested into it it is a shame we cannot get even better results. We want to reach a “Continuously Improving” organization. And on top of that I always felt a certain friction/unnecessary tension while leading these engagements. In a combination of methodically looking to experiment with how we do things together with a string of “different style” organizations that wanted a different less “gang-ho” approach an alternative emerged.

”Managers are the biggest impediment”

The center of my exploration has been the role of managers in the success or stagnation of agile change programs. Looking back at previous engagements, in “Bright spots” I was typically able to create a stronger more involved management layer that drove agility forward. In cases where the focus was on teams and I couldn’t get managers to engage the results were mediocre. Every Agile survey you read says something about managers being the biggest impediment. They don’t support agile, they don’t enable agile, they don’t trust the teams, they are not patient, etc. I have a slightly different take on this.

I believe “Managers understanding is the biggest impediment”. They don’t understand enough about why agile and flow works. What is the role of constraints in driving improvement. What pull mode actually means. Many of them show a lot of good will and ask “What do you need for me” and get confusing answers. And we shouldn’t be surprised. We spend most of our energies and time on showing teams how to work in agile, why would the managers understand? Maybe it is my Israeli upbringing but as a Manager going on a new endeavor with my people I want to be first. I want to understand the deepest what it will entail. I want to be in front, not in the back. And so far we’ve been asking managers to take the back seat in agile change management programs.

So is the solution management training? Discussion of “Agile Thinking/Values” ? management offsite? These can be part of the solution, but if they end and then all the actual agile experience is at the team level with managers back doing their own things, I think it wouldn’t work. We are talking about changing the way the organization thinks and it’s de-facto mode of operation (Schein even calls this Organizational Culture). I believe in order to achieve that, managers need to run in front, be the first to try different ways of behavior, understand what they mean for the organization, and if they see it is a good way that should be repeated lead their people by example.

Start Small, Managers First

With this in mind, the concept of “Managers Kanban” emerged. This happened at around 3-4 clients around the same time with varying results but all of them quite encouraging ranging from stable and improving in a very difficult environment to another case with viral spread of kanban systems in an organization which is known to be very careful and measured in its approach to trying new things.

The concept is quite simple. Familiar with the Kanban Method? Great. Now choose an end to end Value-driven flow like a Product line or Project. Look at all the functional/technical teams involved as well as other stakeholders. Create a Kanban System that focuses on the interaction between those people. Typically the task-level work done by individuals engineers in the functional teams will be abstracted out a bit but in any case this system is like a chess board. Managers move their pieces and take action that they then translate to marching orders for their teams. When an event comes up at the team level the Manager is the one reporting about it at the end to end Kanban system. How do they manage their own team/people? I don’t care at the moment. Wait, I actually do care. I recommend they continue with what they did so far, at least for a short while.

One thing to note about this Kanban system is that it is a multi-level one. It starts with Features, moves to Minimally Marketable Features which flow end to end. When in development those MMFs are broken into User Stories. Each such story while in development can be in different states in multiple functional teams. These so-called “Team Stories” are visualized here in using different vertical lane per team, where each user story takes up one horizontal lane/position with a box in each of the team lanes to mark the involvement of that team in this story. The state of the work on this “Team Story” involvement is visualized by marking the box as empty=TODO, half-full=WIP (or even indication of % complete feeling e.g. 1/4 complete, 3/4 complete etc.), full=DONE (and waiting for the other Team Stories to be completed for the full User Story to move to DONE). This was a nice emerging visualization we came up with along the way. When they moved to an electronic tool (LeanKit Kanban) they started to use Avatars to just track involvement (It is very easy to track flow of Team Stories using the card taskboard capability though). A different company is using a somewhat involved swimming lane structure in Digite Swift-Kanban to visualize the same information.

To manage/lead this Kanban team comprised of Managers we typically assign a higher seniority manager. His role is to design the kanban system with the team, manage the flow, manage the improvement work. The side effect is that we get the management chain involved, leading. In the best cases even the VP of the group was involved in the system design and flow management/retrospective meetings. Nobody is excluded. When you start hearing the VP saying “Is this inline with Stop Starting? Do we think that so many things currently in WIP is healthy? What do we need to do in order to reduce it?” you know that there is something healthy going on. In some cases the “Project Manager” was assigned to lead this Kanban team. The benefit is that we instill lean/agile thinking into the Project Managers very quickly this way. The downside is that we don’t get the same traction with the core R&D managers this way. I don’t believe this is a core problem with the approach, just something to fine-tune. The important point is to make sure senior managers of the functions do a lot of “Go See”/“Gemba” - come from time to time to flow meetings that happen several times a week, pay a visit to a retrospective, etc. Ideally each senior manager should be the sponsor of one of these “Managers Kanban” and be accountable to achieving good flow and learning.

A great side-effect of this is that as the coach (internal/external you get much more face-time with the managers to gauge and influence their thinking and behavior.

Another way to look at this pattern is to see it as an answer to the question “What is the minimum viable change we can try to show us whether managers can really start thinking and behaving agile/“Stop Starting Start Finishing”? On the way we of course also let them learn how real agile thinking/behavior looks like so if they are convinced they want it they are well-positioned to take the next step and deploy it more widely through the organization

Viral Spread

When things go right, managers indeed “get it”. They “get it” so clearly that they go out and experiment with Kanban systems at their teams without the organization even suggesting it. All they need is permission to experiment and boards start popping up on the walls or in the electronic kanban system. In one example we seeded two “Manager’s Kanban” product-stream level systems and after a month or so we saw about 5-6 team-level kanbans in both R&D and QA popping up. The Product Managers that were lucky enough to be involved in the “Manager’s Kanban” experiment talked to their friends who grew jealous and wanted a Kanban system for their Product-Stream as well. Before long the constraint became wall-space and time to help nurture those self-emerging kanban systems. This doesn’t always happen though. I’m still not sure what are the key factors for virality here. I tend to think it is related to organizational openness and the amount of leadership by example and commitment to the “Manager’s Kanban” shown by the core R&D leadership, but it is certainly an important area to do some research/experimentation on.

Results

When I look across the different case studies I see different depths of implementation after around 9-12 months. But the common factors are reduction in the observed pains that led to looking at lean/agile as well as stable system of flow management - Visualization, Manage work according to Flow, Have explicit policies governing flow. There is typically quite a shallow shaky discipline around WIP limits at this point (which is quite typical in general for this stage whether it is Scrum or Kanban style of WIP limits being used) but there is the understanding and awareness that it is shaky and should be improved. There is also a shallow improvement practice/culture. Retrospectives and Kaizen moments but no model-driven improvement and no operation reviews, just initial sparks of looking at metrics and using them to drive ideas for improvement.

There are strong encouraging signs that the organization is looking to stabilize the flow and improve it. I’ve observed steps towards Continuous Integration, Feature Teams, ATDD, Continuous Stabilization (get rid of the stabilization lane and include it in the definition of done of testing) all driven from seeing flow (or lack of it…). There is also a lot of fine-tuning around the structure of the kanban system itself. The board, the meetings/ceremonies supporting it, who’s involved, etc. There is a slow but sure trend of people from the teams becoming the representatives in the end to end kanban system, on the way to a full kanban system without the need for “representative democracy”.

Another interesting area of experimentation is what kinds of extra team boards to maintain beyond the end to end boards. At the start these were (quite naturally) standalone boards e.g. Infra Team and Infra QA Team on different boards). Over time we are seeing more and more integrated boards being experimented with as a way to reduce the synchronization overhead that comes with a complex network of kanban systems.

Why I think it works

My hypothesis is that this pattern ensures the most important parties and the “usual skeptics” are on-board before going further with the change, using a practical experience rather than conference room convincing. It creates a very natural demand for full pull systems that decentralize control rather than having that dictated by the change framework. To me it sounds a very natural consequence of Kanban Method thinking which is I guess why I found myself doing this before I deliberately thought of the pattern.

Challenges/Impediments

This is far from a perfect solution. There are many challenges here. Some of you might have guessed them already. The main one is that this is not a scalable way to manage an organization. If all work is managed using “Manager’s Kanban” then managers continue to be a coordination bottleneck. There is a limit to the amount of kanban systems a manager can take part of and since lean/agile means working with smaller batches/work items the coordination costs will actually grow higher. For example the Infra Team R&D manager needs to monitor needs from his team across almost all product stream kanbans, synchronize that with his own team kanban system, sync with the QA lead, etc. This is a serious headache and cannot continue forever especially if the organization wants to scale to more activities more people without growing the management ranks significantly.

This is why “Managers Kanban” is just a temporary “Training” pattern on the way to full flow pull mode. You can consider it a kind of “Concierge MVP” - the goal here is learning about what works and is viable as a flow model. It is not a viable long-term model of managing the work. It considers the main risk of going lean/agile being the ability of the managers to think lean/agile, think flow, act according to lean/agile decision filters. When this risk is off the table, it is time to go to the next stage which is sustainable lean/agile involving the individuals with managers supporting but not necessarily involved day-to-day in the flow of work throughout the organization. The classic next step is to create stable Product Stream/Project/Feature teams that will be able to work together with Product Management on a specific value stream. These can be cross-functional, functional teams or a mix depending on the kind of work the organization is facing. Read more about those teaming options in an earlier blog post of mine.

Where Next

It really depends on a case by case basis but there are some lines of similarity in the next steps decided on by the different organizations I’ve worked with.

All of them are re-energizing their discipline and attention to Limited-WIP/Pull discipline. This includes monitoring WIP levels, trying to look deeper into reasons for WIP level exceptions, and providing the slack capacity to do something about the constraints leading to those high levels of WIP. In many cases this touches on the tough spot of Versatility of individuals and Collaboration between different managers and teams. All senior managers I talked with feel the pain of lack of collaboration between silos. And by now they all understand that implementing WIP limits effectively is a good way to drive towards collaboration, even without changing the organizational structure.

The other front is deepening the improvement routine. Retrospectives and chance kaizen moments are fine for the first steps of creating a stable system since the pains are very clear. But in order to sustain guided improvement the next step is to adopt something like the Toyota Improvement Kata as an organizational routine. This entails revisiting the goals/pains, setting up metrics that align with those goals and running a routine of improvement and coaching towards improvement, with Operational Reviews being a key part of continued engagement and accountability of the managers towards improvement.

Summary

I hope the initial shock of keeping the individuals out of the picture initially is wearing out by now… I would love to hear what you think about this pattern. Would it have helped you deal better with situations you encountered in the past? Would you consider using it? How would you improve it?

One question I’m playing with is how much of this is Kanban-specific and how much can be leveraged in a Scrum context. I tend to think one can create a “Managers Scrum” system but it is probably a bit more involved than search & replace kanban with scrum in this article… Expect a future blog post about this…

Here is the LKCE12 session video:

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.