This is part 2 of current series on organizational maturity, evolutionary change, and Kanban. Catch up on Part 1: Organizational Maturity & the J-Curve Effect for more context.
What follows is in no way intended to be an exhaustive set of Kanban board designs. Also the underlying workflows modeled on these boards are in no way intended to represent prescribed processes or intended to bbe copied. They merely represent real world actual examples I’ve seen over the past 10 years.
Introduction
We’ve seen a lot of variants of Kanban Board designs over ten years. Recently, I’ve come to realize that certain styles of board design, scales or implementation and sophistication of the underlying kanban system, correlate to levels of organizational maturity. This is important because it gives Kanban coaches a means to start a journey of evolutionary change with the right level of stressor (visualization and kanban system design) to provoke just enough stress to enable improvement without too much stress such as to break the system and provoke a backlash ending the adoption of Kanban.
If you’d like to learn more about Kanban coaching, you might like to consider taking the Kanban Coaching Masterclass. See listings…
Personal Kanban
Figure 1. Personal Kanban
A personal kanban board is for an individual. The use of a “next” column is intended to relieve the individual of overburdening from the size of the backlog which may be very large. The number at the top of the column represents the WIP (work-in-progress) Limit. The individual pulls work from Next when they complete something. They may then replenish the Next column by selecting an item from the backlog. Replenishment discipline may be on-demand or at some regular cadence. It is likely that large backlogs may require some quality time set aside for selection what is to be next and hence a cadence is more likely with a big backlog. With smaller backlogs on-demand replenishment of Next is likely at the time when an item is pulled into In-progress.
Personal Kanban is usually task focused and the tickets have meaning specifically to the individual. The owner of the board is usually both the owner and the service delivery provider though some variants exist such as a “honey-due” style board where a spouse places tasks for her partner on the board, or where a task involves managing a vendor such as a plumber or electrician.
Aggregated Personal Kanban
Personal Kanban started in the office, circa 2008, and spread to the domestic environment. However, it is common for an individual to adopt it at home and then bring the idea to their office, as happened with Maritza Van Den Heuvel in South Africa. This inadvertently earned her the nickname “mother of Kanban in South Africa.” If personal kanban catches on around an office, it isn’t a huge leap to suggest there is value in a common board – everyone in a team or department can see what others are doing. There is a documented case study of this from Rob Ferguson, formerly of the Banfield Pet Hospital, a Mars company. Rob won a national quality assurance prize for the improvements that an aggregated personal kanban board brought to their work. He was responsible for raising awareness of the technique as a valuable step on the ladder and its subsequent inclusion in the Lean Kanban curriculum as a form of proto-Kanban.
Figure 2. Aggregated Personal Kanban
In an aggregated personal kanban board, each team member gets a row for their personal kanban. The whole team, and others such as department managers have visibility into the tasks under management. Like personal kanban, these boards remain task focused. A board like this is very focused on managing workers and breaks the core Kanban Method, Service Delivery Principle of “managing the work, let the workers self-organize around it.” This isn’t workflow-centric or service-oriented and hence is considered a form of proto-Kanban.
Team Kanban
Team Kanban is quite simply personal kanban for small groups, typically 2 to 4 people, seldom more than 6. While often task focused, there may be a move to represent customer requests on the board. It moves towards the Kanban Method principle of “managing the work, let people self-organize around it” and it is possible that the team represents a single service and that such a simple board is service-oriented. If the custome for the request takes delivery directly from this team, we would consider it a service-oriented design and a simple but complete kanban system. More often than not, the team is actually part of a larger workflow and/or the items on the board are not customer-valued work items but local workflow tasks. In this case, a team kanban is most definitely a proto-kanban implementation.
Figure 3. Team Kanban
A Team Kanban board looks like a personal kanban but each team member has one or more avatars illustrating which work tasks they own or are collaborating on. The WIP limits are displayed at the top of the columns and represent a limit for the whole team. There is a move towards managing work as a collaborative activity and away from managing individuals. As with personal kanban, In-progress items are replenished from Next. The replenishment of Next is either on-demand or follows a cadence determined for the team’s convenience.
Emergent Workflows
When a process or workflow is poorly understood or perhaps nascent and emerging within a company, perhaps it is a new service and the people are still learning how to deliver it, then it has become common to use a variant of a team kanban board. We’ve seen examples of this in places such as the marketing and community development department at Tupalo in Vienna, captured in this case study. In boards like this a qualitative assessment is often made on the completeness of an item and this is used to place the item left to right relative to its percentage complete. In higher maturity organizations, there may be a quantitative assessment of completeness even though the specific workflow is emergent and low maturity. A board like this is not exclusive to a low maturity organization, instead it is an indicator of the nascent nature of the workflow.
Figure 4. Emergent Workflow Board
Emergent workflow boards are similar to Team Kanban and use avatars for team members to indicate what they are working on. Typically, an emergent workflow board is service-oriented. The tickets reflect customer-valued work. In general the level of kanban maturity and sophistication is growing even though the workflow is low maturity and nascent. This is still considered a proto-kanban system because of the nascent workflow but it is likely that it does represent a pull system.
Per Person WIP Limit
With this style of board, we now have a sophisticated understanding of a service-delivery workflow. However, the organization is not emotionally, psychologically or sociologically ready for a pull system. Individuals are seeking relief from over-burdening. The answer is a per person WIP limit, like a personal kanban, but implemented as part of a collaborative working affort. The per person limit is implemented with Avatars. In some examples, such as that at Tupalo, we have seen innovations such as one large avatar for a main task or work item where the individual carries the ownership and responsibility, while two smaller alternate avatars show when the individual is collaborating with another person in a secondary or assisting fashion without specific ownership or responsibilities.
Figure 5. Per Person WIP Limit, Unconstrained Workflow
In Figure 5, the system WIP is unconstrained and the result is that lead times will be unpredictable. A system like this may improve quality, offers relief from overburdening to individuals but the system may continue to be overburdened. As a consequence there is a failure to delivery faster with greater predictability. A system such as this can be implemented as a push system. It is considered a proto-kanban system because there is real evidence of it evolving into a full kanban system such as with Posit Science in San Francisco – a case study we use in our Kanban Management Professional (KMPII) training.
Decoupled Cadences & Constant Work-In-Progress
Grant Ammons recently brought this pattern to light with a somewhat controversial post on Medium Ditching Scrum for Kanban – the best decision we’ve made as a team. Figure 6 shows an interpretation of a Team Kanban with decoupled cadences and a WIP limit spanning the Committed and In-Progress columns. This loosely models a Scrum Board but without the Sprints. Technically the bracketing of a single WIP limit across the system is known as a CONWIP (for “constant Work-In-Progress”). A CONWIP is a form of pull system. This received the briefest of coverage in my Kanban book in 2010. So with a CONWIP we have a pull system and it is borderline whether we’d consider it a full pull system or whether we would still view it as proto-Kanban. I believe the decision depends on two other factors: is it a team level implementation? basically a team kanban with CONWIP; or is a CONWIP on a nascent emergent workflow? If it is either of these I believe we’d still view this as sufficiently shallow to be considered proto-Kanban. If the CONWIP spanned a defined service delivery workflow then we’d view it as a full pull system. For this to happen, Figure 6 would need to look more like Figure 10 but with a single CONWIP spanning the workflow columns.
Figure 6. CONWIP for a Team Kanban
Aggregated Team Kanban
For many years, we thought of the boards in Figure 7 as degenerate interpretations of actual kanban systems, and named them for their unbounded “done” buffers. These unbounded states effectively decouple the system and mean that it isn’t a kanban system and that the work in the system is unlimited. The system is not protected from overburdening. This was occuring in organizations where they did understand the service-orientation and were able to model defined workflows for service delivery but were not mature enough to handle the use of WIP limits and a pull system as a stressor to catalyze improvement. This became a common form of proto-kanban even amongst organizations that had completed the foundation level Kanban System Design (KMP I) training from Lean Kanban University.
In the autumn of 2013, Mike Burrows and I had the epiphany that what these boards actually represented were aggregated ubt decoupled team kanbans. This became part of our epiphany on the scale free approach to scaling Kanban, that the goal is always to eliminate unbounded buffers or queues. By eliminating the unbounded “done” buffers in Figure 7 you scale Team Kanban to a Service Delivery Kanban. This is a significant step forward, as it introduces pull from the customer and changes the stressor for the organization with the primary feedback loop moving to the replenishment meeting. These concepts will be expanded in the fourth post in this series.
Figure 7. Aggregated Team Kanban Board
Each team could have its own team kanban board. However, there is collaboration value in aggregating across the service delivery workflow and visualizing the end -to-end process. This is similar to aggregating personal kanban board into a single department board but at a different level of scale.
Proto-Kanban
The term, Proto-Kanban, was coined by the academic software engineer, Richard Turner, of the Stevens Institute. Previously we’d been using the term “shallow Kanban” for partial implementations but Rich pointed out that these shallow implementations often matured and evolved into something deeper and full pull systems emerged. So “proto” refers to an evolutionary predecessor where there is the intent to pursue the use of kanban systems and evolutionary change. A random board on the wall with some sticky notes on it, visualizing some work or workflow, would not be considered proto-Kanban unless there is intent to use the visualization as a stressor in an intentional pursuit of evolutionary change. Without intent, it’s just a board on the wall, visualizing something.
Full Kanban Systems
We consider something a full kanban system when there is end-to-end pull, a model for a workflow with a series of states and a series of WIP limits linking those states, a formal commitment point, and a replenishment meeting where the system is replenished up to its available WIP limit or according to the free kanban signals. Kanban are signals and indicate a limit to the capacity of the system. When capacity is limited across the full system, we can expect lead times to shrink dramatically and for the predictability of lead time to improve dramatically. A full kanban system offer not only relief from over-burdening but also predictability. Full kanban systems give us more levers to manage flow, and they offer us the WIP limit as the stressor to catalyze change and improvement – usually with the goal of improving smoothness of flow, reducing lead time while improving predictability. Kanban systems originated in Japan and Japanese industrial engineers use three terms to label wasteful activities: muda – non value-adding; mura – unevenness; muri – overburdening. Kanban focuses on both mura – unevennes – and muri – overburdening. Proto-kanban can generally only be said to assist with muri – overburdening. This is a key differentiator between proto and full Kanban and also strongly communicates the value of maturing into a full kanban system.
Kanban systems are modeled for service delivery workflows. There is a default service-orientation in the design of the system. The work items within the system are of types requested byb customers. There is customer focus and a focus on customer-valued work. The system is aligned with the Kanban Method principle of “manage the work, let the workers self-organize around it.”
Physical Space Kanban
Figure 8 shows a style of kanban board which became very popular in Brazil, advocated for by Alisson Vale, an early Kanban adopter, leader in the community and first year winner of the Brickell Key Award for his achievements and contribution. Alisson was looking for a solution which helped to bootstrap the use of WIP limits and to enforce their adoption. He was looking for something that worked in low discipline environments. The flip side of the coin is that this style of board has been known to retard innovation and evolutionary change. There is too much inertia in the physical instantiation of the board and making changes carries too much overhead. Alisson later admitted some regret about this inertia. So choose this style of board with caution.
Figure 8. Kanban board using phsyical space for kanban signals
With the board in figure 8, an empty slot repesents a kanban pull signal. The number of slots represents the total WIP limit for a given state or activity. The I ticket is some form of expedite request that is permitted to override the WIP limit. The small red ticket attached to A implies that A is blocked so that I can be worked. Whoever was working on A will be servicing I. I is breaking the WIP limit. Temporary over-ride of a WIP limit is permitted so long as you know why. This style of board doesn’t not lend itself neatly to such override. This may be a good thing as it discourages breaking the WIP limits but it may also discourage the tactical use of classes of service and this may create resistance to adoption in uncertain or highly variable environments.
Movable Token Kanban Boards
In Figure 9, the kanban is a physical token such as a magnet or a clip. This style of board became popular in Europe and was first seen in places such as ASR, a Dutch insurance company in an implementation led by Olav Maassen and Jesper Sonnevelt. A very good example of it is shown in the Tupalo case study. Here the tokens, such as magnets, represent the WIP limits. It is possible to do interesting things such as use the color to signal additional information such as “pullable”, or “blocked.” A board design like this is more flexible and lends itself well to innovation, mutation, and evolutionary change. It does, however, require a little more discipline and maturity to make it work. It is easy to add additional tokens. Sometimes we want this, as we wish to temporarily break the WIP limit. We need to remain disciplined to insure this doesn’t become permanent and the WIP slowly increases over time.
Figure 9. Movable Token Kanban Board
Virtual Kanban Systems
Figure 10 shows a board typical of the type used at Corbis in Seattle in 2007. These were to inspire the Kanban Method and became the default style of board for Kanban training. From as early as 2006, I was describing such systems as “virtual kanban systems” because there is no physical signalling token. A pull signal is generated by subtracting the WIP limit displayed at the top of a column from the number of work items in that column. This style of board requires the greatest level of discipline to keep the WIP limits and utilize the pull system properly. It is also the most flexible to change.
Figure 10. A Virtual Kanban Board
Adding Classes of Service
With any of the boards in Figures 8 through 10 we can start to embellish them with additional capabilities. For the purpose of illustration only, figures 11 through 13 are based on virtual kanban boards like figure 10.
Classes of service describe how work items of a given class should be treated. Primarily this is used to speed the flow of some work across the board, usually at the expense of other work. Use of classes of service increases the overall variability in the system and reduces predictability in delivery of some work in order to increase the speed and predictability of other items. This is usually a good risk management trade off and hence we wish to visualize it to facilitate the benefits.
Figure 11. Virtual Kanban with Classes of Service
Figure 11 shows a board where work item tickets are colored according to the class of service they receive. In addition, the items of any given class of service are controlled by a WIP limit. This means that we now have 2 dimensions to the kanban signalling. The “Input Queue” in the picture demonstrates that there are kanban signals for 4 items, one of which must be an orange ticket – by default this is a fixed delivery date ticket – and the other three must be purple tickets – by default these are known as intangiblbe class of service as the have a short to medium term cost of delay which is not tangible or insignificant. It is common to see board where only the lowest and highest classes of service have WIP limits. This is a “barbell” risk hedging strategy where the risk of urgent items is offset by the capacity allocated to non-urgent items. In such cases, other class of service items are free to occupy the remaining capacity regardless of specific type.
Aggregated Services
In Figure 12, a single workflow system, and a single group of people collaborating together, deliver work of multiple types. This can be viewed as offering multiple services from the one single service provider. Each type of work, and hence each service offered, is modeled using a different row on the board. These are often referred to as “swim lanes” in the vernacular of the Agile community. It is also common to allocate capacity to a swimlane. This restricts the maximum delivery rate of any given type and insures that all the supported types receive service. By creating WIP limits for the rows, we also introduce a 2 dimensional kanban system where the pull signal can be for an item of a specific type. If classes of service are also deployed then the pull signal mechanism can be 3 dimensional.
Figure 12. Aggregated Services Virtual Kanban Board
In this example shown, the total WIP across the columns is equal to capacity of the kanban system as shown by the WIP limits across the columns. While this might be a desirable design, it is not required. It is possible and often necessary for the WIP limits on the rows to sum to a greater number than the capacity of the whole system. Figure 12 shows cards of multiple colors so we can assume classes of service are also deployed but not explained in this illustration.
Improving Labor Pool Liquidity
Figure 13 shows a board which illustrates a technique that emerged at Constant Contact and Ultimate Software around 2010. By aggregating teams into larger departments and servicing multiple types of work in a single system, the possibilty emerged to have small dedicated teams to individuals rows (or swimlanes) on the board, while keeping around half of the available workforce as felxible workers who could be applied to any given service as required. This provided the flexibility to respond to ebb and flow of demand from one work item type to the next.
Figure 13. Dedicated Teams Per Service with Flexible Staff Augmentation
As shown in Figure 13, each row provides a service for a specific work item type. Each service has a dedicated 2 person team. Each team has a senior member, a master, who has an apprentice under tutelage. Typically, the apprentices will be rotated with a cadence every few months. After serving time working on each row on the board under supervision from a team lead, they can be promoted to the flexible pool of workers. Flexible workers are given an avatar. The avatar can be moved to any location on the board in order to boost the available labor for that service as demand requires it. This pattern provides for greater overall system liquidity than would be true of the individual parts if each had its own kanban board and its own dedicated team. The flexible workers are said to be generalists or “t-shaped” people because they have a depth of knowledge in at least one area and skills across all required areas of the aggregated service. Figure 13 does not show classes of service but it if quite possible to employ all 3 strategies from slides 11 through 13 together.
Conclusions
This set of 13 kanban board designs is not intended to be an exhaustive set of designs, rather it reflects patterns of kanban system and board design maturity. Tomorrow in part 3 of this series I will explore how each of these designs relates to organizational maturity and how kanban coaches can use their assessment of maturity and knowledge of kanban design patterns to kick off a successful kanban initiative.
If you would like to know more about becoming a kanban coach take a look at Kanban University and consider attending our Kanban Coaching Professional training. The illustrations for this post were lifted directly from Lean Kanban University training class materials – specifically the Kanban System Design and Kanban Management Professional classes with the exception of Figure 13 which is taken from the Enterprise Services Planning training class.
