I was requested by a client to provide a mapping of my organizational maturity model and patterns of Kanban maturity, to Jim Shore & Diana Larsen’s Agile Fluency model which has been boosted by the support of Martin Fowler. The clients’ request was based out of the simple need that his organization is already (somewhat) familiar with Agile Fluency and hence, he wants me to be able to explain to his people how my model maps into a context they already understand. I decided there would be value in sharing my thoughts on this for broad consumption.

Introduction

If you aren’t familiar with the Agile Fluency model, you can read the original article here. I’ve known Jim Shore & Diana Larsen for 10 years or so. I bump into them on the conference circuit from time-to-time. Most recently, they were in Malmo for Oredev last November where I gave the opening key note on social engineering.

Jim and I have a lot of mutual respect while recognizing that we have very different approaches to improving agility. As Jim says, he practices “kaikaku” (large managed change) and not “kaizen” evolutionary, start with where you are now, change. Jim only works with clients willing to replace their existing system of software development with his Agile method. So we are two different ends of the spectrum. Also Jim tends to work in small scale – teams of 2 to 12 people and in small departments, where I have been working with clients attempting Enterprise Services Planning with the intent to scale up to 100,000 people. Having identified the differences, it is still possible to provide some insight into how you might map Agile Fluency to Kanban Patterns and Organizational Maturity.

Agile Fluency & Organizational Maturity Models

Figure 1. Agile Fluency Model

Figure 1 shows the Agile Fluency model reproduced directly from the original web site. Figure 2 shows my recent Professional Services Organizational Maturity Model (PSOMM).

Figure 2. Professional Services Organizational Maturity Model

If we were to look at the diagrams only, we might come to a fairly quick and simple conclusion, there is a 1-1 mapping at each level. “Start Building Code” would map directly to maturity level 1. “Focus on Value” 1-star Agile fluency appears to imply maturity level 2 – there is an ability to define a customer and a customer-valued piece of work and to direct people and teams based on customer-valued requests. There is a consistency of process and the elements that go with it. There is an implied change in culture to be more externally focused and to recognize that there is a customer and a concept of customer value which can be captured when defining customer requests for work. “Deliver Value” 2-star Agile Fluency appears to imply maturity level 3 – because the team can deliver value on the market cadence and this sounds like “consistency of outcome.” There is also an implication that there is a significant step up in skills in order to provide consistency of outcome. “Optimize Value” 3-star Agile Fluency seems to map to maturity level 4. There is a focus on optimizing the economic outcome and in driving real business benefit from the capabilities achieved in the lower levels of fluency. “Optimize for System” 4-star Agile Fluency appears to map directly to the concept of optimizing an organization and its service and product delivery capabilities at maturity level 5. So there it is, a simple 1-1 mapping!

If only it were that simple! I believe some deeper analysis is required. I do believe that Shore & Larsen’s intent is essentially similar to the five maturity levels and that we should accept the 1-1 mapping at face value, but some deeper analysis and insight is required to see where there are gaps – not with intent but with practical, pragmatic, actionable guidance for improving and moving up the ladder whether you think of it as Agile Fluency or organizational maturity.

The Trouble with “Value”

I was probably the first member of the Agile community to write with any substance on the topic of “value” and optimize economic performance from Agile methods, in the form of a 63,000 word book published in 2003. Around that time, the Agile community wasn’t sufficiently interested in topics such as “prioritizing iteration backlogs based on value” that my submission for the Agile 2003 conference was rejected. The state of the art in the Extreme Programming community was to prioirtize based on technical risk. Agile was largely an internally focused movement. Yes, there was mention of “value” in the Agile Manifesto but when it came to practical guidance there simply wasn’t any. At the time, I wrote Agile Management, I thought defining “value” was easy(ish). I was obsessed by physical goods industry literature on optimizing industrial process, such as The Theory of Constraints, and convinced that all we had to do was determine the value for features and then use that information to prioritize and hence optimize economic performance. Now 13 years later, I can tell you that I am less certain that ever that we know how to define “value” in any meaningful way that can lead to a deterministic approach to optimization of economic performance.

What does “value” mean? If you read the text of the Shore/Larsen article it appears to imply a fairly simple concept – “is this story of value to our customers?” Answering this question is fairly easy. So if we take it at that level, we would map that to organizational maturity level 2: we can identify a customer; and we understand what would represent meaningful value to that customer; we are capable of sifting out tasks, and other items of internal value that are not meaningful to the customer. So there is some improvement in alignment and unity of purpose. We have customer focus. Followers of the Kanban Method will recognize some synergies with the Values and Principles of the Kanban Method.

“The trouble with value” starts when you try to get beyond the notion of “is this valuable” and instead try to quantify the value. I spent two chapters of the Agile Management in 2003 trying to wrestle with this and frankly the conclusion would be, in most circumstances, professionally services work, cannot be reduced to a quantitative measure of value, at best it can be reduced to a multi-dimensional qualitative assessment – I now teach this assessment method as a 1 to 1.5 day training class as part of the Kanban Coaching Masterclass and the Enterprise Services Planning curricula.

If we look at the definitions for 2-star to 4-star Agile Fluency it is implicit that we need a more elaborate approach to defining and understanding value. In the original article (granted it is from 2012) there is broad hand-waving that this is a solved problem in Lean Startup or Lean Software Development. To be honest this isn’t realistic. Lean Startup would help you validate a hypothesis that value may exist. I am not really aware of anything in Lean Software Development that provides specific insights into analyzing value. However, the Lean Product Development body of knowledge, work by Reinertsen or Kennedy, does provide some methods. It has become quite trendy to define value using variants of Reinertsen’s approach to “cost of delay”. I still find this material nascent and problematic and analyzing why that is true is the subject of another on-going series of blog posts at this site which started with “What we know about duration: part 1“.

So moving up the Agile Fluency model to 2-star level implies we need better ways of defining value. We have had some methods for this in the Kanban body of knowledge since 2007 – for example, making qualitative assessment of cost of delay and assigning classes of service to work items. This is consistent with my analysis that kanban system and boards can take you to organizational maturity level 4 as described in my recent blog post, Kanban Patterns & Organizational Maturity. The risk assessment method which I have now formalized into the Enterprise Services Planning curricula rather than trying to bundle it with Kanban as we did between 2009 & 2014 provides a comprehensive, if admittedly qualitative, complex and non-deteministic method for both assessing value and selecting, sequencing and scheduling using value assessment. Most of this work, was available in publicly accessible form in 2012 though it doesn’t appear in a convenient book, but a significant portion of it appeared in my talk at the Agile 2009 conference.

The Trouble with “Kanban”

Reading the Agile Fluency article, we have to recognize that when Shore & Larsen say “Kanban” they actually mean “Team Kanban” – a topic considered so trivial in the Kanban community that Lean Kanban University didn’t bother to teach it or have a defined curriculum for it until 2015 with the introduction of Team Kanban Practitioner. In Kanban Patterns & Organizational Maturity I define Team Kanban as a maturity level 1 behavior. I do, however, point out that there are times where a single team delivers a recognizable and atomic service and isn’t merely part of a wider workflow involving multiple teams. In the case where a team delivers a service and it is self-contained to that team, then we would view them as being at organizational maturity level 2, providing the work items were customer-valued work items.

From this analysis, we begin to see a blurring of the lines. 1-star Agile Fluency could exist at organizational maturity level 1 though there does appear to be an implicit understanding that a “team” delivers a customer facing service and hence, there is an implication of organizational maturity level 2 but at a small team scale, not involving more elaborate workflow. There may even be a greater implicit assumption that if a longer more elaborate workflow were needed, then the people with these additional skills should be brought in to the team to maintain its integrity and encapsulation as a provider of a complete service.

It is a pity that Shore & Larsen do not appear to know more about Kanban and that they assume Team Kanban is all there is when in fact many years before 2012, we’d largely decided that Team Kanban was so trivial as to be not worth our effort even documenting it, never mind teaching it. It is only in recent years with the recognition that so much of the market is at organizational maturity level 1 that we’ve decided to help bootstrap adoption by defining Team Kanban and associated training around it. In the Lean Kanban University, Team Kanban Practitioner, we do not assume maturity level 2. We do not assume a customer facing team with all the cross-functional skills embedded to deliver a turnkey service without dependencies. So for us, Team Kanban is very much at a “below Agile Fluency” level.

Technical Competency Improves

Where there is strong agreement between the models is at organizational maturity level 3 and 2-star Agile Fluency. With Kanban, and in the Kanban Management Professional (KMP) training and in the 5 chapter, section 4 of Kanban: Successful Evolutionary Change for your Technology Business, we look at ways of improving – improving delivery times for example. The Shore/Larsen model assumes that you can do this with Extreme Programming, which is a perfectly valid assumption, but it is one that comes with an agenda – you will adopt this Agile methodology. Kanban is anti-methodology. It is the “start with what you do now” and evolve method. In Kanban, we teach practitioners to identify opportunities for improvement and deploy specific practices, often Agile technical practices, in order to drive the improvement. Kanban uses model-driven improvement. Kanban also doesn’t assume a software development context. Regardless of the context, for example, advertising agencies or market research companies, we would expect technical competencies to improve in order to move through organizational maturity level 3.

The Trouble with Scaling

At 3-star Agile Fluency there is ambition to optimize economic outcomes. This is clearly a direct mapping with organizational maturity level 4. Where I differ from Shore & Larsen is in the manner and style of how this might be achieved. Their suggested approach is that you start adding the business functions to the team and the teams get larger and larger and more and more cross-functional. The Kanban approach to this is different. We use risk assessment to provide a common language for communication, collaboration and decision making. We believe that you don’t need to make teams larger and larger and more and more cross-functional in order to achieve collaboration. We believe collaboration comes from having a shared sense of purpose, unity, alignment and a common language for communication and a common framework for making decisions. Since 2014, I’ve chosen to package this in our Enterprise Services Planning training, rather than marketing it as “Advanced Kanban” as we were in the 2012-2014 time period. Kanban has been capable of taking organizations to maturity level 4 since 2007 and given the description provided, capable of taking more than just teams, but entire product or business units to 3-star Agile Fluency throughout the same time period. We already had a reference case study of Kanban on projects of over 50 people in 2007 and Kanban in use across an organization of 150 people with an annual budget of around $17 million. We weren’t playing with “teams” when it came to Agile fluency.

The Trouble with Optimizing

When I read Shore & Larsen’s description of 4-star Agile Fluency, I agree it is fair to say that Kanban hadn’t shown it could achieve all of this level, at their time of writing in 2012. However, a significant number of the attributes they describe were present and being reported within the Kanban community and at Lean Kanban conferences – use of Portfolio Kanban (for balancing risk and business initiatives), use of Upstream Kanban (for product management and real options), Operations Reviews as a product unit or business unit level, showing an understanding of a system of systems and how each independent workflow or project interacted and depended on others. This is all the more disappointing as Jim Shore had appeared at one of our conferences prior to the appearance of this 2012 article and there was plenty of such evidence all around him if he had cared to look.

What I can say now, is that I am quite confident that entire organizations can achieve 4-star Agile Fluency (and more) using Enterprise Services Planning.

Conclusions

It has proven important that I repackaged a lot of advanced and peripheral Kanban practices into Enterprise Services Planning because all too many agilists see or position Kanban only a team level method. If more senior leaders, and I include Shore and Larsen in this category, of the Agile community actually took the trouble to understand Kanban and what we’ve doing in the Kanban community over the past 8 years, they might come to realize we have a lot of answers, a lot of proven techniques, and that most of these concepts are complimentary and non-threatening to what they are already doing. Kanban and Enterprise Services Planning coupled to appropriate implementation of Agile technical practices can and will take you to a level of business agility that Shore & Larsen describe only as “aspirational.” If you have the aspiration to achieve 4-star Agile Fluency, we can take you there now, in 2016. And we can do all of this without reorganizing your business into massive, cross-functional teams. Kanban has never shared the Agile agenda of cross-functional teams. We believe in achieving collaboration through other means – shared language, transparency, visibility, shared decision making frameworks, fact-based, qualitative analysis techniques that drive consensus, customer focus, unity of purpose, and alignment.

I’d like to thank the client who asked for this evaluation and analysis, it was a useful and worthwhile exercise.

This is the first in a series of at least four posts about Kanban, evolutionary change and organizational maturity. If you like the content and feel you want to know more then consider taking one of my “Kanban – the alternative path to agility” training classes followed by the Kanban Coaching Professional Masterclass.

In this first post in the series, I look at the psychology and impact of traditional large scale managed change initiatives and how evolutionary change differs. We’ll see that organizational maturity and executive tolerance plays a big part in the success or lack thereof in traditional change management. As a consequence, evolutionary change is more likely to succeed with lower maturity organizations. This content has been a staple of the Kanban Coaching Professional Masterclass over the last 6 years. All credentialled Kanban coaches are familiar with these ideas and conversant in their use. If your Agile coach says he/she knows Kanban can can’t explain what follows to you, they aren’t qualified to be coaching Kanban or leading evolutionary change.

A model for organizational maturity

Regular readers of my blog over the past 17 years are familiar with my association with the Software Engineering Institute and my work with the Capability Maturity Model Integration (CMMI). I’ve been a key note speaker at the SEPG conference. I’ve given the most highly rated talk at that conference on another year. I’ve co-authored technical notes with SEI people and I authored Microsoft’s MSF for CMMI Process Improvement in 2005. I earned the respect of the academics at Cargenie Mellon because I actually understood the underlying idea behind the SEI – to implement the ideas of W. Edwards Deming for software engineering. The following model is CMMI inspired and hence pays homage to Philip Crosby’s Manufacturing Maturity Model (MMM). However, those knowledgable with CMMI will note that I’ve made some subtle changes. The purpose of this model is to enable a shorthand method for assessing organizational maturity in a general way, for any business, and without any need for an appraisal or formal assessment.

Figure 1. Professional Services Organizational Maturity Model (PSOMM)

Professional Services Organizational Maturity Assessment

Figure 1 showes the PSOMM model, using five levels similar to Corsby’s original MMM and the CMMI/CMM that followed it. The five levels are: Emerging; Defined; Managed; Quantitatively Managed; and Optimizing. While the names are the same at the CMMI, people familiar with CMMI will note the sutle and deliberate reversal of Defined and Managed. I find this change useful for pedagogical reasons. It also seems to make better logical sense – I am sure some academics in Pittsburgh will want to argue about that.

Maturity Level 1

Level 1 describes organizations with emerging processes or service delivery workflows. As the saying goes, at the SEI, “level 1 is very deep”. Level 1 models complete chaos through emerging maturity to almost completely defined processes and workflows. In level one, we observe, the chaos of “everyone for themselves” through functional team coordination, heroic efforts, random luck, and eventually to fairly defined processes and understood workflows. However, some inconsistencies persist. There is still a random element to how service requests are processed and as a result their is neither consistency of process or consistency of outcome. Energy is wasted resolving the lack of consistency of process, and a lack of consistency in how work is handled leads to a lack of consistency in the outcome – both in terms of what is delivered and the quality and consistency with which it is delivered. There is no consistency of product or service or consistency of service delivery. The system is fragile and prone to catastrophic failure. In the lower reaches of Level 1 it is completely unmanaged, nor is their any traceability or governance. The organization will tend to panic under stress and regress to an “everyone for themselves” mode of behaviour – structures, workflows and processes will break down. There will be a regression to a craft style of working with heroic efforts occasionally producing useful results at small scale. Coordination of larger groups of people becomes impossible.

Maturity Level 2

At Level 2 we have defined workflow processes. There is consistency of process for a service request of a given type. If we were implementing the workflow using a kanban system and board, we would be able to define the kanban system and use it consistently without rework or workarounds. At level 2 there is an expectation that work is handled in a consistent manner. We might expect quality improvements to both the product or service and the service delivery but there will be inconsistencies in what is delivered and how it is delivered. The system remains fragile and prone to failure. There is now an ability to trace work and report status. As a consequence, there is rudimentary governance of process – the right things are processed in the right way. What isn’t assured is the outcome. Customer expectations will not be met consistently and their is a failure to meet core fitness criteria metrics. Understress, there is a tendy to break discipline and workflows become erratic. There will be a regression to level 1 maturity.

Maturity Level 3

As level 3 the process workflows are now managed. We see marked improvements in the product or service being delivered and the manner in which it is delivered. There is a consistency of process as well as consistency of outcome. Customer satisfaction grows dramatically as customers find their expectations are being met. We will observe a significant trimming of the tail in lead time distribution and quality metrics such as defect rates. The system is now resilient and can bounce back from stress and adversity. Governance levels have improved and we’d consider the system to be well governed. The right work is processed in the right way with little rework, failure demand or customer dissatisfaction. The funds at risk are now considered well spent – costs are controlled, prices are fair, and customers get value for money. Understress there organization may exhibit resilience and hold together through the efforts of individual leaders. In the absence of these leaders, there will be a regression to level 2 maturity as consistency of outcome is lost.

Maturity Level 4

At maturity level 4, we see the introduction of quantitative methods for risk management and risk hedging. We aren’t just following a process and producing consistent outcomes, we are now using the data from the process to understand it better. We understand the variation in demand, in service delivery, in product or service quality. We understand business, delivery and technical capability risks that affect outcomes. We understand, track and manage dependencies between cascading service requests. We deploy probabilistic forecasting, mathematical formulae, and regression and iternative mathematical modelling techniques such as GARCH and Monte Carlo to provide deeper insight into the nature of work and how to manage for consistent outcomes and customer satisfaction. The system is now robust to stress and adversity because it mostly anticipates problems. When something unanticipated happens the system continues to show resilience and bounces back. The bounce is often faster and the negative impact of an unexpected event or change in external conditions is less severe than we would see at level 3. Under stress the organization holds solid. Processes are followed to deal with stressful situations and unexpected events. The organization remains robust and there is continued consistency of outcome for customers providing the stress isn’t too severe. In the event of severe stress then some consistency of outcome is lost but the organization is resilient and quickly bounces back to normal service levels and consistent outcomes.

Maturity Level 5

Level 5 is an optimizing organization. Level 5 can be very high. We might be optimizing only at the service delivery level, or we may expand to optimize at the product level, the service level, the market strategy and market segmentation level or at the entire business strategy level. At each level we see behaviour that is designed to probe complex conditions, sense changing conditions and respond with changes to process, workflow, market segmentation, and strategic position as required. At this level, stress actively catalyzes the organization to improve, to mutate, and evolve. At higher levels of maturity level 5, the organization is capable of complete identity change, abandoning core businesses and adopting a new identity and embracing new core business ventures. The organization is antifragile and can be said to be “continually fit for purpose.”

Learning Organizations

It is important not to mistake maturity level 5 with the concept of a learning organization. If the organization is capable of moving up the maturity ladder then it is a learning organization. Learning can and must happen at all 5 levels. The fourth post in this series will look at what is required to catalyze and provoke progression up through the maturity levels.

The J-Curve Effect

I first encountered the concept of the J-curve effect working at Sprint around 15 years ago while hanging out with executives with business school degrees. I was aware at the time of Jerry Weinberg’s work adapting Virginia Satir’s ideas of change from family therapy and psychology but I never saw them as the same. The y-axis in Figure 2 is shown as an abstract concept but you would implement it with a concrete business metric. The y-axis in Satir’s curve is metaphorical and related to the behaviour or identity of an individual. In the tangible, pragmatic, actionable, quantitative world of Kanban, we don’t do metaphors. So I don’t attribute this diagram to Weinberg or Satir.

Figure 2. Managed Change J-Curve Effect vs Evolutionary Change

In Figure 2, the y-axis is shown as capability or fitness for purpose, or a specific measure of fitness for purpose such as a fitness criteria metric. The current capability or fitness level is shown as the oscillating curve on the graph. This level of capability is delivered by the current process and the process is stable. We can assume from this picture that we are dealing with at least a level 2 maturity organization. Stable implies that the mean in stable and we have some natural variation within known bounds, or that the rate of change of the mean is stable and that we have variation within known bounds. This is a reasonable statement for defined service delivery workflows and is borne out by real data sets captured in real businesses. A capability might be lead time, or quality, or due date performance or percentage performance against an SLA.

The current level of capability is not sufficient and isn’t fit for purpose, so we are motivated to improve. In a traditional managed change initiative, we design a new process intended to achieve the higher level of capability – a level that is fit for purpose. The process may be designed or it may be tailored from a process catalog of defined processes. If we are highly mature, level 4 or above, we probably have models to predict the outcome from the new process. Otherwise, at lower maturity levels, we simply have a belief that the new process will deliver the outcome we seek. We may even consider installing the new process as an experiment but it is rarely one that is “safe to fail” as there is seldom an option to roll back to the old process, given the scale and magnitude of the change.

Once we start the change initiative usually with training and coaching and sometimes with new tools, the current level of capability falls, while our workforce absorb the changes. We can measure the depth of the drop as the negative delta in capability. If things go well then we start to see improvements. Gradually we reach a confidence level that the changes will stick, then we recover back to our previous level of capability, eventually we may achieve the results pay back the lost outcome with our new improved level of capability. We can measure the time to each of these events from the point where we started. The depth and length of the deficit incurred by the change initiative can be thought of as the pain of change. While we can visualize it as an area, we must also consider the depth and length as two separate parameters. It is the drop in capability and the eventual recovery that gives the concept its name, “the J-curve effect.”

The secret with change management is that the tolerance of our sponsoring executive leadership must be greater than the pain of change. If it isn’t or if our sponsors cannot accept the depth or the time to recover then they will lose their confidence, often panicking, misdirecting with a reorganization, and firing the change agent as a scapegoat.

There is a saying that “no one ever got fired for hiring McKinsey.” The root of this lies in the truth that the McKinsey firm invented this style of designed and managed change initiative. All good consulting firms know that their role and their fee is based on that fact that they will play the scapegoat and take the blame for failure. One of McKinsey’s rivals knows this all too well. During their bootcamp for new graduate recruits, they teach their business model is to “get to 60% complete and don’t get sued.” This works on the basis that the client is tolerant until 60% complete but if they haven’t reached the confidence point by that time then the initiative will be killed. So long as the consulting firm doesn’t have to fight a lawsuit then they will have a profitable business.

Criteria for Successful Managed Change

Despite the obvious success of large consulting firms practicing this style of change management, the success rates are poor. Typically, about 30% fail and are aborted or reset with a new initiative. Jim Collins described this phenomena in his book, How the Might Fall, where they panic in the depth of the J-curve, cancel the initiative, misdirect with a reorg, fire some change agents and start again. This is yet further evidence that such changes aren’t “safe to fail” and aren’t reasonably rolled back. Some firms get into a death spiral in this fashion. Simply put, they are biting off more change than they can handle and each time they fail they double down by trying again, often with a different consulting firm leading the charge. Only around 10% of such large change initiatives succeed and actually deliver on expectations, the remaining 60% recover, often above the parity capability level but never actually deliver on expectations or produced the return on investment that was anticipated. So why is the failed and challanged rate so high? Why is it that only about 10% of cases succeed? What are the criteria for success?

I have seen large scale managed change work. There are five elements that consistently appear in the stories:

1. High Levels of Executive Tolerance (patient, thoughtful, reasoned, and knowledgale leaders)
2. High Organizational Maturity (typically level 4 or above)
3. Patient Capital (usually privately held companies)
4. Owner Managed (leaders with real skin-in-the-game both financially and emotionally)
5. Managers are domain experts (often with decades of experience of the business and a deep understanding of how it works)

So do you have these criteria present in your environment? What are your chances of your organization seeing a large change initiative through to completion and it delivering on its expectations? If they aren’t all that good, perhaps you’d like to consider an alternative, evolutionary change?

Evolutionary Change

The Kanban Method is an approach to change that is designed to work in lower maturity organizations with low levels of executive tolerance. It is the “start with what you do now” approach to change. The green line in Figure 2, is drawn to show a small J-curve initially. This represents the installation of a kanban system. The idea is to implement the most sophisticated kanban system design you can get away with without running into significant resistance to change. The judgment on this is taught in the Kanban Coaching Professional Masterclass, and any KCP (Kanban Coaching Professional) can be expected to have this judgment and skill. So called, proto-kanban systems, degenerate kanban implementations which feature visualization and workflow but without WIP limits, or a pull system, represent smaller J-curves with less impact initially. The idea is to install the mechanism for evolution, to add the evolutionary DNA to the organization then let it work. The series of small j-curves represent small, evolutionary changes, process mutations. These are known in Japanese industrial engineering as “kaizen events”. A Culture of Kaizen – a culture of continuous improvement – is an attribute of a high maturity organization. In a kaizen culture change is often experimental and the experiments are small enough to be “safe to fail.” Changes can often be rolled back if they prove unsuccessful and have a negative impact on capability. A series of evolutionary changes will often achieve more in less time than a large scale change initiative. It does so at lower risk and evolutionary change has a far greater chance of success across a much wider range of organizations.

Learn More

If you would like to learn more about coaching evolutionary change using the Kanban Method, take the Kanban Coaching Professional Masterclass from Kanban University.

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.