Category Archives: kanban

Lean Startup Blues

Estimated Reading Time: 4 minutes

Yesterday I had an interesting session with a company who’s been a big believer in Lean Startup and the MVP concept but have lately reduced the amount of MVP-driven product development dramatically. Not because there is less uncertainty to iterate through but due to something we can call the “Lean Startup Blues” – the lack of faith that the MVP process works at scale over the long term.

The main challenge is that building MVPs is not enough. Some organizations don’t really close the learning loop as often as they would like to. They build MVPs but they don’t spend enough effort to really learn whether this MVP is in the right direction. What typically happens is that they move on to another idea after the MVP goes to production. Iterative development is dangerous when there isn’t a steady captain at the helm. The ability to shift direction brings back the classic dysfunction where the first phase of many ideas are abandoned or moved into maintenance mode where it is hard to have a serious impact. It is actually the fear of this that drives many Product Managers and business stakeholders to specify all they think they will need up front because they know they have a limited window in which to get it. After this window is closed most chances are their project will be abandoned. Several difficult changes need to happen to overcome this problem. First, people need to trust that MVPs will lead to learning and a wise decision between pursuing an MVP towards a real feature/product or killing it.Then, people need to trust that the right prioritization decisions will be made in the future and that if it is really a good idea to continue investing in an idea then this will happen. To make it harder, people need to think holistically – taking the chance that their ideas will not turn out to be winners and therefore will be abandoned – as opposed to trying to force implementation of their ideas by going for a full implementation instead of an MVP.

Using the right Kanban reality board can at least make visible the amount of this dysfunction going on by showing the size of features and the amount of MVPs that are left as is without leveraging the learning to drive further development and business value in that direction. Steps like “Deployed”, “Validate/Learn”, “Pursue” can help you see what is really going on. Having WIP limits on these stages will force some discussion about what to kill and what to pursue and end purgatory for the miserable MMFs.

Another thing that might be a challenge is actually learning whether the MVP hints at gold or not. Data-driven decision making is the holy grail but it is very hard to get there. Some organizations are giving up on it and don’t do any learning/feedback at all. Soft learning is better than no learning process at all in my opinion.

The problem with MVP purgatory is not just that we lose on the business benefits. It is also that since an MVP is typically an experiment, it typically leaves the product in a state of debt. Both technical debt – since we developed an MVP we allowed some shortcuts on the architecture/automation/clean code/etc. And Product Debt – We added a feature, it covers a certain set of use cases, but if we did the MVP right it is not whole. far from it. It was actually painful to go with it in the first place but since we were looking for the real minimum to enable learning, we did it. But the assumption is that we will either follow through or kill it. Letting the MVP stay in the product as is leads to usability issues, maintenance issues and makes future development more difficult.

Leave enough MVPs in purgatory and people will simply stop using the MVP approach. They will prefer to skip on the fast learning loop and get back to familiar ground of developing something cleaner and more usable even if it is not useful.

The way out of this mess is to have a clear policy that says you either kill it. really kill it. Or you clean it. really clean it. Please decide. And limit the amount of ideas that are in progress without a clear decision. And don’t allow starting a new MVP unless there is room for it. Make room for it by selecting another idea and kill it or clean it. Or pivot it. This is “Stop starting start finishing” applied at the MVP portfolio level.

By the way MVP is just one option of how to approach building something. It is a good option when there is a lot of business/requirements uncertainty. If not, just build minimal slices of functionality that are marketable (also called Minimum Marketable Features / MMFs) and release them. Don’t expect to do much learning and don’t skip on the technical excellence while building them. With MVPs you keep the option to kill it or grow it to later. But that option has a price. Refactoring to clean or killing a feature doesn’t come for free.  If there isn’t a lot of uncertainty that price might not be worth it. So define your policies for how to build different kind of risk profile ideas/features/products. assign the right profile to each idea. feel free to move ideas between profiles along the way as more information becomes available. Make the team building it aware of the profile. Explain to them the context. This will help them make the right tradeoffs along the way.

Another interesting thing to look at would be the “Killed Ideas/RIP” bucket. You would expect to see some ideas ending up there. That is a good thing. But you should also expect to see the cycle time until that area grow shorter and shorter meaning faster learning loop. (Just be careful to avoid setting it as a target otherwise people might not kill an item just to avoid increasing the time to kill metric…)

To sum up, there is nothing bad with the Lean Startup MVP concept. It is actually a great idea. Done right. And doing it right requires discipline & process maturity. attention to end to end flow from idea through validated learning all the way to kill/grow. Enterprise Kanban looking at the portfolio of MVPs/MVFs is a great way to grow this discipline and maturity. It also requires strong Product Managers who are able to define effective MVPs, guide the learning process, have the courage to hit the kill switch or to stick to something even though there is a lot of pressure to “start the new thing”.


May the WIP Games begin…

Estimated Reading Time: 2 minutes


Hatsav (Maritime squill) – By Dany Sternfeld on Flickr

The day has come for FLOWer to bloom (maybe we should call it “Hatzav” (maritime squeel) after the flower that brings the autumn here in israel… btw we are in the middle of october and it feels like July, can’t wait for the Vienna weather next week in Lean Kanban Central Europe 2012 – you’ve got your tickets already, right?)

Introducing FLOWer

A couple of months ago I’ve written about experiencing Kanban system design and if you’ve been waiting to see what I’m talking about, today AgileSparks is soft launching FLOWer. Well, at least an initial version of it focused on experiencing the effects of WIP on flow and ROI/Profit of the business. You are welcome to go try FLOWer now.

A couple of notes about the beta:

  • Starting the simulator and seeing it in action doesn’t require any registration. Just open it and kick the wheels. Tweaking the settings requires registration which is currently done by simply associating your google account. We are assuming most people have a google account. We only keep your emails so we can be in touch, we don’t do anything else with your data.
  • We are currently in beta mode which means we limit the amount of users registered to the system. Hurry up and register. First come first serve.
  • We are still figuring out the pricing model. You can leverage that and enjoy it free at the moment. And we will make sure we take good care of early adopters that help us shape up the product.
  • We are trying to make the simulator and the game self-explanatory. We’re probably not there yet, so please comment or leave feedback on the site itself with anything that wasn’t clear, didn’t work as you expected, or points you just felt stuck at.
  • The simulator will run on any modern HTML5 browser. Chrome, Firefox, Safari… iPad Chrome/Safari… But that also means IE is NOT SUPPORTED. 

PS Participants of AgileSparks upcoming Kanban training (on 30-31/October) will also play FLOWer, including advanced scenarios that are “in the oven” at the moment…

So, what are you waiting for? Go ahead and play! (Sorry, we didn’t include a Boss Key… but maybe your boss would also like to see how intelligent context-specific and adaptive application of Stop Starting Start Finishing is a way to bring home more Benjamins!)


Looking forward to Lean Kanban Central Europe 2012

Estimated Reading Time: 2 minutes

Lean Kanban Central Europe Conference OCT 22-23 2012, Vienna

October is Lean Kanban conferences season in Europe. I chose to return to speak at Lean Kanban Central Europe (#LKCE12) taking place this year in lovely Vienna. If you are not aware of the conference or still contemplating whether to come, here are the things I’m especially looking forward to:

  • Chance to hear the latest and greatest from the Lean/Kanban/Systems community leaders – Keynotes from David J Anderson, Dave Snowden, Don Reinertsen are always home runs, no matter how many times I’ve heard them already. And I’m looking forward to hear Stephen Parry for another perspective on Lean Services.
  • The funky and exciting Pecha Kuchas / Lightning Talks. I gave a Pecha Kucha for the first time in LKCE11 last year and found it was a great learning experience that affected my presentation style even in regular session. Can’t wait to see what the lucky Pecha Kuchers have for us this year. Can Arne top his Munich performance???
  • The new rehashed version of Jeff Anderson’s work on transformation using Lean Startup concepts as well as Jasper Sonnevelt’s talk about Top Down versus Viral Spread, both very related to things I’m focused on these days.
  • Combination of LEGOLand and smart advice about Toyota/Kanban Kata at Håkan Forss’s talk. I hope to hear what new he’s been thinking of since the Kanban Leadership Retreat last spring.
  • Jim Benson’s talk is focused on Lean Meetings this time. I use Lean Meeting concepts I learned from Jim all the time. If you’ve never heard about Kanban Agenda Meetings, Lean Coffees and the like, you are in for a treat that will change your approach to the activity you spend a major part of your work life in… (If you’re interested in this also check out Death by Meeting by Lencioni )
  • Attaching Kanban to the Command&Control World of Project Managers Nikolaus Rumm
  • In Defense of Ambiguity by Joshua Bloom – Seems to tie in with Art of Action by Bungay which I’m reading at the moment. The power of Intent and maneuvering freedom in a complex world…
My personal goals are:
  • Selling a couple of copies of Holy Land Kanban. Oh, and use a LKCE12 discount coupon for the ebook version if you can’t wait for a dead-tree copy!

And all of that is secondary to meeting interesting new people, seeing old friends again and having interesting discussions over great drinks and food…

So, see you in Vienna?

Implementing the Kanban Method using Scrum (a.k.a Scrum with a Kanban spirit)

Estimated Reading Time: 9 minutes


If my last postrattled your cage, let’s see how you like this one… This post is a thought experiment. This hasn’t been tried in the field, and might be the worst idea in the world. But at a minimum it might be a way to understand better Scrum and Kanban. Let me know what you think.

The Context

Let’s assume a client or stakeholder in the organization wants to go agile and Scrum has been dictated to us – something like “Hey – I heard Scrum is a good thing. I want one of that please. I don’t care about other kinds of approaches. I want Agile. Agile==Scrum. Give me Scrum. Scrum. Scrum. Scrum.” (only SLIGHT exaggeration of real life…) Let’s also say we like the Kanban Method of evolutionary change management towards Lean/Agile and we actually believe it is a better approach to change management in the discussed context. So basically it might be a nice idea to give the organization what it wants – Scrum, while giving the organization what it needs – an evolutionary approach to change management. Is that possible? Let’s try to use the Kanban Method thinking and principles while implementing them using Scrum practices and building blocks. Here we go, enjoy the ride…

Foundational Principles:

Start with what you do now

Well, Kanban says to start with your current way of doing things. Scrum is perceived as a revolution, so let’s see along the way whether we are able to minimize the changes to the current way of doing things.

Agree to pursue incremental, evolutionary change

This is actually quite easy to live with since Scrum is also an Inspect and Adapt framework that seeks to look for incremental evolutionary change using Scrum as a baseline.

Initially, respect current roles, responsibilities & job titles

Here comes a tough one. Scrum comes with roles, responsibilities and some might say even job titles. Let’s see how we deal with those. One way is to say forget it. I know you’ve read about Scrum Masters, Product Owners and the Scrum Team. But we believe there is no need to change roles & responsibilities up front not to say define new job titles in the organizational structure. This might work and is a reasonable approach but is quite a “cop out”. Lets try to go a bit deeper …

Scrum Team

At least the Scrum Team is quite core to how scrum works so we can probably say that we will define Scrum Teams that will not make any change to existing organizational structure. If we want to play strictly to “start with what you have” we can map Scrum Teams to the current functional teams whatever size they currently are and whatever skills (or lack of cross-functional skills) they currently have. A major alternative here is to start with “Managers Scrum”. See “Managers Kanban”for the general idea. Applied to Scrum this means leaving the individuals/actual teams alone for the moment. Just create a “Scrum Team” that is comprised of the managers of the relevant functional teams. These managers will run Scrum together for a while until they learn the ropes and are able to go sell and deploy Scrum with their teams, or alternatively decide that different teams might be needed before deploying Scrum fully… I will probably elaborate on this approach in a separate post. Let me know if it interests you to push it up the priority rank…

Product Owner

I would ask the organization who decides priorities or align priorities amongst multiple stakeholders at the moment, teach the “Product Owner” role and responsibilities and start with the people currently involved in the prioritization and backlog grooming activities wearing the “Product Ownership” hat. If needed, they will do it as a team. It is far from being the strong Product Owner that Scrum advocates, but we will evolve in a direction that deals with product ownership issues if we see that there’s a problem and that the Product Owner is the right solution. Some in the Kanban community have a strong case against the Scrum Product Owner. I have to say I’m on the fence on that one.

Scrum Master

Oh the Scrum Master… Well recently even in pure Scrum implementations we (AgileSparks) talk about the Scrum Master being a management style that should be undertaken by the individual leading the team (yes yes we believe that even self-organizing teams should have a leader that enables this self-organization). So I find it quite plausible here to talk about Scrum Master being a very good description of the coaching style of management that teams need in order to gel and perform better and better over time. And then I say we don’t need to define any specific role like that but the people leading the teams should be inspired. For sure we don’t define Scrum Masters as a position in the HR system. What we might do is find a great coach/practitioner candidate and ask him to play the “Scrum Master”/”Kanban Practitioner” role for the organizational unit (several teams)

Encourage acts of leadership at all levels

This is quite orthogonal to the actual flow framework we are using. But since Scrum is notoriously exclusive of managers (at least the perception is that it is…) lets make sure that managers understand they need to lead their teams to better and better performance, better and better alignment with what users/customers value. Of course Scrum Teams should show leadership by self-organizing to perform better and better. Those leading teams should show leadership by investing energy in team building and performance, decentralizing control while ensuring alignment with the organizational initiatives and values.

Visualize Work

First actual step is decide which teams comprise the flow of work and visualize the work flowing in and out of those teams using Kanban Boards and work in the teams using the same Kanban Boards or Scrum Task Boards if someone finds a very good reason to do that. Note in this step there aren’t any sprints or ceremonies yet.

We will use a Product Backlog with Product Backlog Items to visualize the “incoming”/”future” work. A Release Backlog can be used to visualize the subset of that work that is targeted for the current release. Work already in progress or done in this release will also be in the Release Backlog but with a status indication of the work state. Based on this information we can understand how far along in the Release Backlog we are and how the Release is doing. A Release level Cumulative Flow Diagram or Burnup can also help us visualize Project/Release state and help us feel safe and aware of what is going on.

Manage Flow

Now that we have the flow visualized we need to manage the work with the concept of flow. Here Scrum gives us some clear guidance that is helpful.


We will work in Iterations of 1-4w (Also called Sprints although that is a horrible name. Sprinting should mean short-term acceleration to deal with a special situation. Iteration pace should be sustainable). Let’s assume a cadence of 2w here as that is a reasonable iteration length that many times use successfully and also allows a good frequency of flow management activities. So every 2w we will have a “Business Day” in which we hold :

  • Iteration Demo – review the completed work of the last iteration and get product-level feedback on it with relevant stakeholders. The completed iteration should be available as an increment of Potentially Shippable Product which means all items completed are working tested software and the relevant build is a candidate for shipping after no more than a short (few days) hardening.
  • Iteration Retrospective – review and adjust our processes based on the last iteration
  • Iteration Planning – based on what’s next on the product backlog,  product-level feedback from the Demo and process-level feedback and decisions from the Retrospective, We pull backlog items into the next Iteration. Pull = We take in the right amount of items to have an effective iteration. Not too few to avoid being bored. Not too many to avoid too much multi-tasking and context switches and the danger of not completing anything. Another meaning of Pull is that the team working on the iteration does this planning and makes those decisions. It is important to have a couple of more product backlog items queued up in case we are able to accomplish more than the amount we pulled. The purpose of the planning to is to establish this focused “Iteration Backlog”/Forecast and verify everyone on the team and in product ownership on the same page regarding what the relevant product backlog items mean, the priorities between them, how they will be demonstrated in the Demo, and the level of quality/functionality expected to say they are done (Definition of Done / Acceptance Criteria).
Every day of the iteration we will hold a short (10-15min) “Daily Scrum” standup meeting in which we manage the flow within the Iteration. In this meeting the Team and Product Ownership meet in front of their visibility board (Kanban / Taskboard). They talk about flow since last meeting (What I did last day, what cards I moved), expected flow until the next meeting (What I intend to work on today, cards I’m about to Pull/Complete) and mainly impediments. Impediments can be work item specific or flow problems (bored waiting for devs to deliver something, seeing too many defects in what was delivered feeling uneffective, etc.) Impediments can be solved quickly in this meeting or taken offline by identifying an owner that will deal with them until the next meeting. Items with impediments/blockers can be marked using a special indication on the visibility board. Systemic Flow impediments can also be marked (e.g. mark the interface lane between Dev & Test with a red post-it saying “Nothing ready for testing 23/9”.

Implement Feedback Loops

Note that since we implemented Scrum ceremonies we are already deep into Kanban Method’s “Implement Feedback Loops”. The Iteration ceremonies provide feedback loops about Product and Process. The “Daily Scrum” provides a tactical feedback loop. Some teams learn to use the “Daily Scrum” to have a tight light-weight process feedback loop as well and add “Kaizen Moments” as necessary when dealing with what appear to be systemic impediments.


Make process policies explicit

We also made some of the process policies explicit by setting the “Definition of Done” of items to be declared Done at the end of the iteration.

Now’s the time to make more of our current policies explicit. Use your current de-facto ways of operating. You will have a chance to change/improve them in your process adaptation feedback loops:

  • What is the level of readiness of a product backlog item before the team is ready to pull it?
  • Any definitions for the interfaces between roles in the team?
  • Any other clear policies governing the work of the team, relations to product ownership, etc.? Estimation policies? Defect Fixing? Release Criteria?
The Iteration ceremonies we defined are also explicit process policies. They answer questions like how do we replenish the system, how do we deliver, etc.

Limit Work in Progress

Now after we have a flow system working, it is time to apply the real pressure. We need to constrain the system to guide it towards better flow. In Kanban we do this by limiting Work in Progress. Applied to Scrum this translates to constraining ourselves to work just on items pulled into the Iteration. We will not start working on any other item unless the Iteration is safely done. This sounds trivial, but when there are several people with different specialties on the team it is not trivial at all. It drives people to collaborate. It drives different pains/inefficiencies to the surface and requires us to deal with them.

Note that the Iteration focus is not the ideal way to limit WIP. It is not that clear and explicit and it is harder to go on a diet that tightens the WIP limit from iteration to iteration since the Iteration focus is based on velocity which might not improve so fast even if our focus is improving. Also note that in order for the Iteration Forecast/Backlog to be effective WIP limits we need to plan carefully our capacity and capabilities for the whole iteration to avoid taking on too much (and not challenging ourselves to focus) or too little (and straining our focus to an unrealistic and unhelpful level).

We can always later apply classic Kanban per-lane WIP limits of course. And since many people that want Scrum don’t really understand that the Sprint Forecast/Backlog is a way to constrain and guide improvement we can just skip to the easier and clearer approach of per-lane WIP limits. This will also make it easier to get across the end of sprint inefficiency.

Improve Collaboratively using Models

A remaining but important feedback loop is the Ops Review which is a data-driven feedback mechanism that increases accountability to improvement results and accelerates improvement activity. We will add this routine later on typically. There is nothing like that in Scrum but there is nothing saying it shouldn’t be done. Just add it on top of Scrum when the organization is mature enough for it. (I would say after a few months of managing flow and limiting WIP so the systems are stable, clear problems have been solved using Retrospectives, and it is time to seek more pervasive improvement opportunities. )

At this point we try to decentralize the improvement activity to the teams/people. We give them different models to use like Variability / Positive Deviants / Queuing Theory / Principles of Flow / etc. and expect them to suggest and execute improvement experiments and share successful conclusions for reuse by other teams.



I hope this article conveys the message that the Kanban Method can be applied using Scrum as the process framework. This can be useful in case Scrum is chosen by the organization due to various reasons but we believe an evolutionary guided change approach is a good fit for the context or we would like to complement Scrum with the useful change management ideas in the Kanban Method.

I’ve yet to try this in the field but the biggest risk I see in this approach is that Scrum IS focused on flow at the team level and there’s the danger of localized focus when using it as the main process framework. I also have an hypothesis that starting with “Manager’s Scrum” looking at the end to end flow rather than work at the team level this might be overcome.

I’d love to hear what others think. Does this makes sense? What would you do differently?


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

Estimated Reading Time: 11 minutes

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 engagements we run at AgileSparks 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.



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.


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.


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…

This is the topic of my upcoming session in Lean Kanban Central Europe 2012 in Vienna by the way. If you are around and interested, come and participate. I will try to make this an interactive session with room for opinions and ideas.



updated: Added “Why I think it works” section