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]