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, nevermind 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 Enteprise 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. These classes are running in Israel and Ireland in May and June. Details at services.leankanban.com/training. 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 leadin 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 behavior – 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 rudamentary 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 indidvidual 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 regrression and iternative mathemetical modelin 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 behavior 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 behavior 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 curernt 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 attriubte 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 Lean Kanban University. Classes are coming up in the spring in Israel and Ireland. See listings for details…

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]

This is part 3 of at least 4 parts in a series studying kanban system and board designs and relating these to organizational maturity as a core coaching tool. If you need to catch up, read Part 1: Organizational Maturity & the J-Curve Effect and Part 2: Patterns of Kanban Maturity. In part 3 I take all the kanban board and system designs from part 2 and map them to the organizational maturity assessment framework from part 1. The value of this is that a quick and effective method of assessing organizational maturity and a small pattern catalog of deepening maturity kanban board and system designs, provides Kanban Coaching Professionals with a consistent set of starting designs likely to be successful. In other words, we’re matching the sophistication of the design to the sophistication of the organization. In Part 4, I will look at what it takes to move up the organizational maturity ladder with evolutionary change.

Mapping Kanban Designs to Organizational Maturity Levels

Throughout this post the mapping is shown at the lowest viable level. An example of a board design will work at higher level of maturity. In some cases it may be necessary and the only available design. For example, if we create an Executive Kanban to encourage executive leadership to take actions to help with service delivery or evolutionary change then that would be a personal kanban system but most likely implemented in a level 4 or 5 organization. It may also be true that while we can implement some designs at higher levels, the effectiveness is diminished because the board and kanban system is a sufficiently powerful stressor to catalyze further evolutionary change. This is discussed in detail in part 4.

Personal Kanban

Figure 1 maps Personal Kanban to its lowest viable level. In a nascent organization with no discernable structure or processes, personal kanban will still help individuals get work done and have an impact on organizational effectiveness. It may be the only viable option at such a low maturity level.

Figure 1. Personal Kanban & Organizational Maturity

Aggregated Personal Kanban

With aggregated personal kanban we see the emergence of collaboration, or at least some value in knowing what others in a team are doing. So we see some organizational behavior emerging and hence the organizational maturity is a little higher. Figure 2 shows that aggregated personal kanban kicks in a little higher up with maturity level 1. It is likely to be a starting kanban choice in very low maturity organizations – very emergent or chaotic circumstances and where there is an inability to form a wider service-oriented view of operations.

Figure 2 Aggregated Personal Kanban & Organizational Maturity

Team Kanban

Team kanban demonstrates that we have overt collaboration happening at a team level – typically 2 to 6 people but perhaps up to 12 people. The team may provide a discrete service, but more often than not they are part of longer workflow. There is typically a lack of service orientation at this level. Team kanban systems remain inwardly focused providing relief from over-burdening and are typically task focused rather than customer-valued work centric. When the tickets do represent customer-valued work and a customer is identifiable then it is a sign that the team provides a discrete service and some service-oriented thinking is emerging in the organization. Figure 3 shows that team kanban emerges in maturity level one as we start to see a transition from a focus on individuals to a focus on group collabobration. Team kanban is likely to be successful even while there is a reliance on individual heroics and some amount of luck in delivering within customer expectations.

Figure 3. Team Kanban & Organizational Maturity

Emergent Workflows

What separates an emergent workflow kanban form a team kanban is the overt understanding that there is a workflow and hence the provision of a service. There is by defintion a customer making service requests. The tickets on an emerenty workflow board tend to be customer requested and hence represent customer-valued work. With this design we see the emergence of service-orientation. While the workflow isn’t (yet) well understood, there is a customer focus. More of the values and principles of the Kanban Method are evident. For this reason, emergent workflow boards are shown as requiring greater organizational maturity than team kanban boards. We are still very much within the scope of maturity level 1, as shown in Figure 4, as we can’t define a service delivery workflow but the seeds of growing maturity have been planted.

Figure 4. Emergent Workflow & Organizational Maturity

Per Person WIP Limit

With a “per person WIP limit” board, we have a defined workflow for the first time. We are now border line on maturity level 2, as shown in Figure 5. The organization is ready for the stress of a pull system with end-to-end WIP limits but we do have service-orientation, a defined workflow and a board visualizing customer-valued work items. We arre seeing a deeper implementation of the Kanban Method with more of the values and practices present.

Figure 5. Per Person WIP Limit & Organizational Maturity

CONWIP & Decoupled Cadences

The ability to decouple the cadence of planning, committing or selecting work, from the cadence of delivery shows growing organizational maturity and an ability to coordinate activities with selective audiences. It is unusual for the audience at a replenishment meeting to be the same audience required for a delivery planning meeting and hence, decoupling these in terms of invited participants and frequency of occurence is a sign of growing maturity. In addition, having the ability to allow work to continue in-progress while a delivery is being made shows some additional technical capabilities – for software development, it requires a capability in confirguration management with an ability to use relabeling or branching in a version control system, or to embed code for dynamic code switches (or toggles) to render partially complete features inactive on delivery. Configuration management is a maturity level 2 process area in the CMMI. Together with a defined workflow and an actual pull system, we are now solidly in maturity level 2 territory. This style of board is shown as borderline maturity level 2 in Figure 6 as the workflow may be shallow. We may be dealing with a team kanban that has been decoupled or a team level batch process such as Scrum which has been decoupled. It is not essential that a board of this design is part of a customer-focused, service-oriented workflow and hence there may be fewer of the Kanban Method values and principles present in an organization adopting a CONWIP as shown in Figure 6 than a “per person WIP limit” as shown in Figure 5. I’ve chosen to show it as slightly higher maturity because of the emergence of a proper pull system for the first time and hence it is a borderline proper kanban system. We are leaving proto-kanban behind with this design.

Figure 6 CONWIP with Decoupled Cadences & Organizational Maturity

Aggregated Team Kanban

We are solidly in maturity level 2 territory, as shown in Figure 7. We have a defined service-oriented, customer-focused workflow. We have team level kanban systems with localized pull and relief form overburdening. The quality delivered to the customer will almost certainly improve even though other aspects of service delivery such as lead time and predictability may still be suffering. The organization isn’t ready for the stress of a proper pull system. The concept of a workflow level replenishment meetings and delivery planning meetings may not yet have occurred. We may have a push system from the customer perspective with localized pull at each team level. It is likely there is no customer involvement in pull decisions and very little collaboration between the service delivery workforce and the customer. So collaboration is still local to the service delivery organization but the emergence of a board like this shows that there is value in transparency, visualization and collaboration between teams within the workflow. This is evidence that there is some focus on customer service and delivering to customer expectations. The work will reflect that and the tickets will be customer-valued work items rather than team level tasks.

Figure 7. Aggregated Team Kanban & Organizational Maturity

Physical Space Kanban Boards

At this point, we have a kanban pull system. It is likely, though not essential, that we have customer involvement in replenishment meetings, and that delivery planning meetings are also emerging as necessary element in the process. We are now beginning to manage flow as we focus on shorter lead times and improved predictability. The WIP limits are now the overt stressor in the system and we will see the emergence of behavior to manage the flow of tickets and some effort to optimize the liquidity within the system. As shown in Figure 8, we are moving up towards maturity level 3. We probably haven’t reach level 3 as we are choosing a kanban board designed to work with less disciplined organizations. We would expect a solid level 3 organization to have the discipline not to abuse WIP limits and to understand when to break them for tactical reasons and when to change them as a systemic adjustment.

Figure 8. Physical Space Kanban Boards & Organizational Maturity

Physical Token Kanban Boards

With the adoption of a physical token style kanban board, where the tokens such as magnets on a magnetic white board are now the kanban in the system and represent the WIP limit, we have matured to level where we trust ourselves to manage the flow through a defined workflow. The organization doesn’t panic under slight stresses such as hitting a WIP limit. It holds its discipline and reacts by attempting to improve when given slight stress. We are solidly maturity level 3 as shown in Figure 9. We have the discipline not to abuse the WIP limit by adding tokens in response to tactical challenges and slight discomfort from enforcing the workflow. We have a customer-focused, service-oriented, full workflow, kanban pull system. We have well and truly left the world of proto-kanban behind us. At this level we would expect replenishment meetings to involve the customer, delivery planning to involve the downstream recipients of the product or service, and for service delivery reviews to emerge along with metrics for quantitatively managing flow. If these attributes of the Kanban Method are present then we are on our way to maturity level 4.

Figure 9. Physical Token Kanban Boards & Organizational Maturity

Virtual Kanban Boards

As shown in Figure 10, we are now mid-level 3 on our maturity ladder. The organization has the discpline to stick with WIP limits and respond to slight stresses with improvements. We like virtual kanban boards because they lend themselves to rapid and easy changes. We have a customer-focused, service-oriented, full workflow, kanban pull system. We have well and truly left the world of proto-kanban behind us. At this level we would expect replenishment meetings to involve the customer, delivery planning to involve the downstream recipients of the product or service, and for service delivery reviews to emerge along with metrics for quantitatively managing flow. If these attributes of the Kanban Method are present then we are on our way to maturity level 4.

Figure 10. Virtual Kanban Boards & Organizational Maturity

Classes of Service

There is now an overt understanding of customer needs, expectations and emergence of an understanding of the risks the customer is managing. To facilitate better customer service and service that is appropriate to the risks the customer is managing, we offer classes of service, separatin out lead time and predictability expectations by class and allowing the customer to request an offered class of service based on a business risk justification. Replenishment meetings must now involve the customer directly. We would also expect delivery planning meetings to involve customers and stakeholders responsible for using the delivered item. We may also see emergence of risk hedging capacity allocation by class of service and hence, emergence of maturity level 4 quantitative management techniques. Figure 11 shows that service delivery workflow kanban systems with classes of service are borderline maturity level 4.

Figure 11. Classes of Service & Organizational Maturity

Aggregated Service Kanban Boards

Figure 12 shows a larger system which provides multiple services, or services multiple work item types using the same pool of people and flowing the different types of work through an indentical or almost identical workflow. Aggregation provides greater liquidity and provides the ability to manage flow as demand for different types of work ebbs and flows. By utilizing a capacity allocation, creating a WIP limit on the rows of the kanban board, we can shape the demand for a given type of work and also regulate the averae delivery rate of work of a given type. We are showing the ability to manage flow and the introduction of some quantitative techniques to insure customerr expectations are met consistently. We now have the discipline to shape demand across different types of work. This is solid maturity level 4 behavior as shown in Figure 12. It is also possible to include the use of classes of service within the provision of each service and hence, demand can be shaped in two dimensions and the kanban pull signal is now 3 dimensional. It is possible to decouple the replenishment and delivery planning cadences for different types of work (rows on the board) if this is desirable. The level of sophistication of collaboration and risk management is improving all the time in comparison to lower maturity, shallower kanban implementations.

Figure 12. Capacity Allocation Across Aggregated Services & Organizational Maturity

Liquidity Optimization Kanban Boards

Figure 13 shows that by adding a workforce layer to our kanban board, we take it up a notch in maturity. We are now mapping customer concerns such as having a consistent collaboration interface and integrating our need to manage flow and utilize a flexible workforce to adjust to ebb and flow in demand for work of a given type. We have now integrated staff development and training into our explicit policies and our own risk management strategy. These behaviors will tighten the social cohesion of our workforce, improve collaboration and help us manage flow at the most effective of levels. Kanban systems such as these are likely to be larger and involve greater numbers of people – typically 25 to 50 though as many as 75 has been observed. If most other aspects of the Kanban Method are now present such as quantitative metrics togethert with Operations and Risk Reviews then it is likely we have an emerging maturity level 5 organization. If Strategy Review enters the mix and metrics in use are explicitly fitness criteria based on understanding what makes our services “fit for purpose” in the eys of the customer then we have a solid maturity level 5 organization that is now optimizing its economic performance and insuring its survivability through a continual focus on fitness for purpose and customer satisfaction.

Figure 13. Liquidity Optimization Kanban Board & Organizational Maturity

Conclusions

So what have we learned from understanding how kanban board and system designs map to organizational maturity levels?

The first observation is that with the publication of the Kanban Method in 2010 based on work from 2007, we started with maturity level 4 designs. Even though I and others described how to implement Kanban in an incremental fashion and to start with simpler designs, the simpler versions were still borderline maturity level 3.

The reality is that most of the adopting audience is at a much lower level of organizational maturity, and many people adopting were not the middle-manager target audience similar to me or Mike Burrows. When we saw lower level, grass roots, bottom-up adoption, it was inevitable that this was at a lower level of organizational maturity. It was therefore inevitable that proto-kanban emerged in the market. It is a tribute to the deliberate choices that I, and others made, to define the method in somewhat loose and ambiguous terms, such as “limit WIP” rather than the explicit and unambiguous, “implement a virtial kanban system,” that we got an explosion of diversity and mutations of kanban implementations – an entire ecosystem of variants emerged from Personal Kanban upwards. Had the method been rigorously defined in unambiguous terms then we wouldn’t have this diversity and we wouldn’t have solutions capable of helping significant portions of the market.

The leaders of the Scrum community have liked to position Kanban as “only for experts” and “only for high maturity organizations.” Many have advised their clients that they “aren’t ready for Kanban.” This is because they’ve viewed Kanban through their own lens. A lens where the method is rigorously and unambiguously defined. Ken Schwaber makes it quite clear that Scrum is a defined method designed to be implemented as written. Scrum works – and of this I have no doubt – in a particular context, and your challenge is to change your context so that Scrum works for you. Kanban has always been the antithesis of this. Kanban has always been about “starting where you are now” and evolving. If you are going to promote an evolutionary method, you cannot promote a rigorously defined method and defend its definition overtly. It is necessary to label “Scrum-but” and, in Ken Schwaber’s case to label those deviating from the precise prescription as “Scrum-butts” when you take a “change your context approach” to improving service delivery outcomes. When you take the opposite approach, a tune your workflow processes to enalbe better customer satisfaction, within your existing context, then you have to embrace variation and mutation.

When people started asking, in 2008, “are we doing Kanban or not?” my answer was always to say, it isn’t a question of practice adoption, it is a question of intent. If you have the intent to “start with what you do now” and improve in an evolutionary manner using visualization and WIP limits as the catalysts for change, then, “yes, you are doing Kanban!.” If you mere have some boards on the wall, with sticky notes visualizin tasks and there is no intent to drive evolutionary change then “no, you are not doing Kanban.”

In part 4, I will examine, what it takes beyond a kanban board and system design to enable evolutionary change and improvement inorganizational maturity. For now, it is important to understand that Kanban coaches embrace proto-kanban and shallow implementations as a necessary tool to fit Kanban implementations to existing levels of organizational maturity. In a method that is truly focused on “start with what you do now,” we need to embrace techniques that enable us to do that with minimal resistance or disruption to existing processes and practices.

Figure 14. Benefits of Improving Maturity

Not only is the Kanban Method designed to enable evolutionary change in your organization, it was defined in a manner that enables evolutionary change of the method itself. As such, we’ve seen a lot of diversity and mutation over the past 9 years. This has enabled Kanban to address a much wider set of circumstances. It isn’t true that “Kanban is only for experts,” or “Kanban is only for high maturity organizations.” Kanban is flexible enough, that in the hands of a professionally trained coach, it can be for any organization, at any level, and it has been shown that again in the hands of a professionally trained coach, Kanban is capable of facilitating accelerated improvement in organizational maturity with the corresponding benefits or better customer satisfaction and better economic performance through consistency of outcome and quantitative risk management for consistency of economic results. Figure 14 shows that organizations at maturity level 1 benefit from relief from overburdening. This has the effect of making the workforce happier and generally leads to improved product or service quality. Customer satisfaction does improve to this degree. At levels 2 and 3 we see a switch to a focus on flow and improving the service delivery and meeting customer expectations for lead time and predictability. At level 4, there is a focus on risk management both internally and servicing the customer in a way that facilitates their own risk management. We see risk hedging strategies emerging as a way of improving the consistency of economic outcomes. With a full implementation of the Kanban Method and achievement of level 5, the benefit is continual fitness for purpose, survivability in the face of fickle, uncertain market, political and economic conditions.

Learn more…

If you would like to know more about becoming a kanban coach take a look at Lean Kanban University and consider attending our Kanban Coaching Professional training. See listings for details.

Read more…

Part 1: Organizational Maturity & the J-Curve Effect

Part 2: Patterns of Kanban Maturity

This is part 4 of my series looking at Kanban, organizational maturity and evolutionary change. If you haven’t yet read parts 1 to 3, you can catch up here: Part 1: Organizational Maturity & the J-Curve Effect; Part 2: Patterns of Kanban Maturity; Part 3 – Kanban Patterns & Organizational Maturity.This series is intended to highlight the skills and expertise of Kanban Coaching Professionals (KCPs) who have completed their education through the Kanban Coaching Professional Masterclass, then completed a period of field experience, submitted an essay describing their experiences and change initiatives in which they’ve played a leadership role, finally, they’ve submitted to a panel interview of existing KCPs in order to complete the program and be nominated as a new KCP by their peers. We correlate strong improvement results and successful change initiatives with the involvement of KCPs. Success isn’t an accident, KCPs deploy a number of models in their engagements with clients and have access to the broad community of peers through online forums and face-to-face events such as the Kanban Leadership Retreat global series of consultants’ camp format conferences. If you seek to improve your organization in an evolutionary fashion consider training your change leaders as KCPs or bringing an existing KCP into your team to coach your change initiative.

Introduction

So far in this series, we’ve sought to understand how to assess organizational maturity, different styles of kanban boards and kanban systems, and we’ve seen how different styles of proto-Kanban or Kanban systems are more suitalbe for different levels of organizational maturity. From this understanding, it is evident why we have so much diversity in the market and how initial Kanban implementations were at maturity levels 3 through 5 while much of the market is at levels 1 and 2. This explains the 80%+ of market adoption at, in some cases, very simplistic levels of proto-Kanban. We also looked at why organizational maturity matters and its benefits – predictability, risk management, rorbustness and anti-fragility. This post looks at how you move up the maturity ladder and how you deepen your Kanban implementation in order to gain the benefits of higher levels. Like anything worth achieving, gaining higher levels of organizational maturity requires a little stress. The coaching skill is to know how much stress and of which type to produce effective results. Each time we invoke a little stress we invoke a small j-curve effect. The trick is for the stress to be enough to motivate the change without it being too much to result in a regression. Figure 1 is taken from the first post in the series and acts as a remind on the 5 levels of organizational maturity.

Figure 1. Organizational Maturity Model

Catalyzing Evolutionary Change

Figure 2 shows the cartoon form the cover of Kanban: Successful Evolutionary Change for your Technology Business. The cartoon was intended to communicate the essence of the Kanban Method in a single picture. It contains all the elements required to catalyze improvements.

Figure 2. “Kanban In Action” from the cover of Kanban: Successful Evolutionary Change for your Technology Business

In the cartoon, in figure 2, a team is meeting in front of their Kanban board. It is evident from the conversation and the image of tickets on the bboard behind them that not everything is going well for them. Something is creating stress for them, the meeting is a means for them to reflect together on what is happening, and the fourth character shows an act of leadership and suggests that they “do something about it.” The cartoon contains all three elements we require for evolutionary improvement: a stressor; a reflection mechanism; and leadership.

Formula to Drive Evolutionary Improvement

Figure 3 shows the organizational maturity model, together with the formula to drive evolutionary improvements and some indications of how the elements manifest differently as the organization matures and their Kanban implementation deepens.

Formula to drive evoolutionary change:

1. a stressor
2. a reflection mechanism
3. leadership

Figure 3. Driving Evolutionary Change Across Maturity Levels

The most commonly understood concept of a stressor with Kanban is a WIP limit which causes stress when workers find themselves idle, often for many reasons beyond their own control, reasons that can by systemic and just chance, or reasons that are external and assignable to a specific root cause. Regardless, idleness, or “slack”, creates stress.

The most commonly understood concept of a relfection mechanism is the Kanban Meeting. Kanban meetings are as a default recommendation held daily in front of the board. The specific cadence of the meeting is contextual. The frequency affects the number of opportunities for process changes and hence evolutionary action. What is not material to the mechanism of evolution. It is that the meeting happens at all that matters. The effectiveness of evolutionary change will be affected by frequency and it is important to tune it to the environment – often enough to make a difference – seldom enough to insure new information is available since the last meeting.

The 3rd Change Management Principle of the Kanban Method is to “encourage acts of leadership at every level.” It is important that acts of leadership can and do happen at reflection opportunities. A Kanban Meetin where there is no leadership because the attendees do not feel empowered to make changes is a poorly designed meeting – a poorly designed reflection mechanism. It falls partly to the coach to encourage acts of leadership and to work with middle and senior management to insure that reflection mechanisms are adequately designed so that leadership can and does happen.

As a general rule, if improvement suggestions are not coming out of your reflection mechanims then they are poorly designed – consider working with a Kanban Coaching Professional to improve them.

Driving Up Organizational Maturity Through Evolutionary Change

The choice of stressor and reflection mechanism must be tuned to the organizational maturity and the context.

Maturity Level 1

In the depths of maturity level 1, where you essentially have little organization, or collaborative effort, individuals can use both the visualization of their personal kanban boards and their WIP limits as their personal stressors. It is important individuals take time to reflect on how well things are working for them and consider personal improvements.

Often, for many low maturity organizations and contexts with difficult political situations, visualization and increased transparency is a stressor. There is no need for a WIP limit to create stress – just shine a light on the current issues with visualization. This will create stress, engage people emotionally and motivate changes.

What if and form of visualization will create too much stress?

There are circumstances where visualization is not an easy or possible choice. This can happen in more mature but dysfunctional organizations. We have seen examples of Vice Presidents of PMOs rippin down Portfolio Kanban boards in a rage. Some insecure middle-managers do not appreciate transparency. Often their self-esteem is rooted in the power of controlling information. Too much transparency weakens their power base, diminishes their self-esteem, attacks their self-image, and fills them with fear that things are out-of-control. They exist in a personally-framed world where controlling information flow, represents the concept that things are under control.

For Kanban coaches facing the circumstance where visualization represents too much stress, the recommendation is to start with other aspects and practices of the Kanban Method. Specifically, the recommendation is to starrt with “make policies explicit.”

Are there known side-effects of “making policies explicit?”

Not every organization is ready to have their policies made explicit. Sometimes making a policy explicit is a matter of visualizing it. If they aren’t ready for visualization then they aren’t ready too many policies becoming explicit. Explicit policies are also an enabler of empowerment. In general we want this. Explicit policies raise the social capital of the organization. There is a trust dividend: more explicit policies, more empowerment, faster, better decisions, less delay, avoided cost of delay, better economic performance. However, again some managers, view empowering subordinates as dangerous, or an outright attack on their own identities that diminishes their self-esteem and undermines their self-image. There are counter-measures for this: encourage senior leadership to intervene as mentors for managers who must create more empowerment; crreate a culture where reward comes from “work yourself out of a job”; balance empowering explicit policies with metrics and feedback loops demonstrating that things are working within agreed boundaries.

“Making policies explicit” is also known, from some results in behavioral economics, to encourage diversity of opportunity. Explicit policies are a social leveling mechanism. In any social structure, where there is a hierarchy, even if implicit, more explicit policies will create a leveling. There will be winners and losers. Gneezy and List have shown that employers with more explicit policies on pay, benefits and obligations, have greater diversity or opportunity – for example, fairer, more equal pay for women, and more women in higher positions. So when you play with a mechanism that creates broader, more equal opportunity, it is inevitable their will be losers. Those who lose out socially may not buy into the greater goals enabled by equal opportunity and diversity of contribution. If you run into this level of resistance, we have to view it as beyond the scope of the Kanban Method and venturing into broader cultural issues most likely beyond the parameters of the individual firm or employer into the broader society it is part of.

It is always difficult to give broad coaching guidance on Kanban and change leadership for a global audience because of societal variations. Some elements of the human condition are invariant – if someone may lose social status from a change, they are likely to resist. This is a global truth. However, whether a particular attribute of an existing system or culture gives someone an advantage is a starting condition which needs to be assessed on a case-by-case basis, by the coach, in situ.

The case, of the VP of PMO in a rage pulling down a Portfolio Kanban board, happened in an otherwise extremely liberal rapidly growing startup on the West Coast of the USA. Knowing the company culture, you wouldn’t predict the outcome and the resistance. This was a matter for the individual and not the wider business. It’s really impossible to give coaches a universal toolobx for avoiding and overcoming resistance to change.

Visualization, Kanban Meetings & Personal WIP Limits

The most common stressor and reflection mechanisms at maturity level 1 are the use of a board to visualize work and workflow, a Kanban meeting often at a team level, though perhaps at a wider, workflow level, in the higher reaches of maturity level 1, and the use of per person WIP limits. To be honest, I am not convinced the per person WIP Limits are a stressor, in fact they have the opposite effect, the provide relief. The relief from overr-burdening creates the opportunity for reflection. So at maturity level 1 we are relying mostly on visualization and perhaps explicit policies to create stress, while a regular meeting in front of board, coupled to per person WIP limits creates the reflection necessary to drive improvements.

Maturity Level 2

At maturity level 2, we now have predictability of process. We have a concept of a customer, customer requested work, and a workflow. We now have a chain of knowledge workers collaborating on a series of activities. The stressor is now the kanban system – the WIP limits on the columns on the board. While the Kanban Meeting continues as a core element of the method and is clearly a reflection mechanism and feedback loop, we now see direct interaction with the customer and the people who take delivery and perhaps operate the finished product in a production or field environment, as part of the process. The replenishment meetings and delivery planning meetings now act both as stressors and reflection mechanisms. We should start to see improvement suggestions and process changes happening as a result of these meetings. This becomes even more true as we move up through maturity levels 3 and 4. However, even at maturity level 2, we have a pull system for the first time. This creates a positive tension with the requesters – the customers. Now, they must decide what to work on now, what to leave until later, how much later, and what should be discarded altogether as their isn’t sufficient bandwidth to do everything. Equally our ability to deliver frequently should start stressing the downstream operations. We should see external changes being catalyzed as a result of our choice to adopt Kanban on our service delivery workflow.

Maturity Level 3

At maturity level 3, metrics become much more important. We now have a formal understanding of customer expectations, and perhaps formal agreements on delivery expectations such as SLAs. We will see the emergence of classes of service in the kanban systems. There is a strong argument that customer expectations, expressed as SLE (service level expectations) or formal SLA (service level agreements) now become a stressor. They will certainly affect, day-to-day operational decisions, on what to pull and where to assign workers and other resources. If you have specific stories describing where you saw metrics drive process evolution, we’d like to hear them. The reflection mechanisms begin to get more advanced with the use of service delivery reviews looking at externally facing capability metrics, and risk reviews looking at things that affect delivery and capability internally. The scale tends to be at the level of independent service delivery workflows thought we may begin to see the use of coupling of service workflows as a new form of stressor.

Maturity Level 4

Typically two workflows where one services dependent items from the other are decoupled with an unconstrained buffer, or parking lot. As an organization matures and the Kanban implementation scales, these unconstrained buffers are constrained with WIP limits. This creates stress between Kanban systems and necessitates the use of an organization level feedback and reflection mechanism, the Operations Review.

At maturity level 4, buffer sizing on dependent workflows and capacity allocation across work item types and classes of service becomes the important stressor driving organizational improvements and overall improvements in customer service and fitness for purpose. Risk hedging strategies chosen for quite sensible reasons will create stress. For example, there will be pressure to pursue many tactical opportunities at the expense of strategic initiatives. It becomes important for the organization to hold its nerve on row WIP limits. Being able to do so, is an indication of the instuitutionalization of maturity level 4.

Maturity Level 5

At Maturity Level 5, to provoke further and grander evolutionary change at the business level, we begin to move beyond the scope of the Kanban Method and utilize elements of the Enterprise Services Planning body of knowledge and class curriculum: the comparison of strategy with capability; and the use of strategy reviews as the reflection mechanism to drive change.

At this level, the stressor is a combination of business strategy and business goals. It is important that startegy is balanced to capability and stretches it only just enough that it acts as a positive driver of change, improvement and innovation, rather than simply breaking the organization. Military leaders have understood for centuries that you pick a strategy based on your capability if you wish to be successful. If their is gap between the desired outcome, the strategy required to achive it, and current capabilities, then they invest in capability first. They do not allow politicians to set them up for failure by recklessly pursuing strategies that cannot be achieved with existing capability. Corporate leaders often do not have this training. They often choose, “big hairy audacious goals”, and believe that doing so, acts as a stressor to drive change. These moonshots are generally never as well resourced and supported as the Apollo program, however. It is much more likely that the operational level management are left clueless as to how they might achieve the requests from their senior leadership. So they simply crack the whip, expect more from an organization not capable of it. What follows is over-burdening, over-reaching, and over-stretching. The result is often a catastophic failure and perhaps a regression back to maturity level 1 or 2.

Currently, coaching corporate goals and strategy as a reflection of service delivery capabilities is beyond the scope of the Kanban Coaching Professional program. If you are interested in how we use Enterprise Services Planning and the concept of “continually fit for purpose” with our clients, please inquire to Lean Kanban Services for direct consultation and private training.

How far can a coach take us?

A Kanban Coaching Professional (KCP) perhaps working with an Accredited Kanban Trainer (AKT) can take you from mid maturity level 1 all the way to maturity level 5. The higher reaches of maturity level 5 require familiarity with Enterprise Services Planning and specifically the strategy and fitness for purpose subjects in the curriculum. At this time, there are only a small subset of KCPs with this knowledge and experience.

How far can our local Agile coach take us?

Based on the evidence we see in the market, where an Agile coach has not had any specific Kanban training but has some exposure to the method through the community, Agile conferences and perhaps has read some books – most typically a very thin, free book published in 2008, which offers little depth and carries a number of myths and inaccuracies in it – then our observation is that such an Agile coach can start you at the depths of maturity level 1 with Personal Kanban, and take you up to mid maturity level 1 with Team Kanban. Some Agile coaches are capable of taking you to Maturity Level 2 with an Aggregated Team Kanban, proto-Kanban implementation, perhaps exhibiting a few attributes of level 3 or 4 implementations such as rudimentary classes of service and some metrics.

Agile coaches who can take you further will have specific training and experience and are likely to share that with you as part of their marketing materials. They will view themselves as Kanban Coaches.

When evaluating a Kanban coach, ask them what training or certificates they have explicitly in Kanban. Ask them which Lean Kanban conferences they have attended and whether they have ever been a speaker. Ask them which Kanban Leadership Retreat events they have attended and what they learned from the experience. Ask them to show you their community contributions, whether articles on line or in print media or community organization such as Limited WIP Society or Lean Coffee organization in their region. Kanban coaches who can deliver results, can show you this material. Agile coaches who are bluffing and won’t be able to take you where you need to go, will not.

Conclusion

Achieving the benefits for higher levels of organizational maturity, can be achieved using the Kanban Method as an approach to improved service delivery and evolutionary change. Someone leading a Kanban initiative needs to be cognizant of the organizational maturity level when choosing the mechanism to drive evolutionary improvement. As the organization matures and the Kanban implementation deepens, the important stressors and reflection mechanisms needed to take the organization further will change. The scope and the scale will change. The personnel involved will change and the pay grades of those affected will rise until eventually we are all the way at the top. Kanban Coaching Professionals are trained to have the skills to design kanban systems and boards that are tuned to the level of organizational maturity and have the correct stressors to catalyze improvement without overstressing the organization and causing a failure of the kanban system and a regression in organizational maturity.

There is a lot of subtelty to coaching Kanban and using it to drive change. There is a reason why there is 10 to 15 days of training plus months or years of field experience required to become effective as a Kanban coach. If you want to succeed at evolutionary change, work with a professional – choose someone with a history of involvement in the Lean Kanban community, someone who has attended the Kanban Coaching Masterclass, someone who is a speaker at Lean Kanban conferences, and someone who attends Kanban Leadership Retreats to share and learn from their peers. We correlate successful results with knowledge and experience.

Learn more…

If you would like to know more about becoming a kanban coach take a look at Lean Kanban University and consider attending our Kanban Coaching Professional training. See listings for details.