Bringing You The Best Kanban Community Of Experts

AKT Materials

ALUMNI SIGN INSIGN OUT

Kanban University

Management Training, Consulting, Conferences, Publishing & Software

Agile

The Evolutionary Nature of Learning in Agile Environments 

by

Scrum Better With Kanban Blog Series

In the dynamic world of agile environments, learning is not a linear journey; it’s an evolutionary process. This path is marked by trial and error, constant adaptation, and evolution, particularly when using the Kanban Method. However, this evolutionary approach to learning and change is not exclusive to Kanban and can be effectively integrated by Scrum Teams as well. Let’s explore how this works.

Learning Through Trial and Error

Agile environments thrive on a learning approach that’s indirect and exploratory. Teams often face a series of experiences, each offering unique challenges and opportunities for growth. This process, a fundamental aspect of agile methodologies, demands patience, resilience, and an eagerness to experiment, where each setback paves the way to deeper understanding and improved practices.

Managed Evolutionary Change in the Kanban Method

The Kanban Method fosters this learning through ‘managed evolutionary change’, involving three critical stages: identifying stressors, reflecting and hypothesizing, and leadership in experimentation. This structured approach supports learning and adaptation, making it a key strategy in agile environments.

Applying Managed Evolutionary Change in Scrum

Scrum Teams can also harness the power of managed evolutionary change, particularly during retrospectives or daily Scrum meetings. By adopting managed evolutionary change, Scrum teams can develop and test experiments, leading to continuous improvement and learning.

Here are some ways Scrum teams might implement this:

  1. Integrating Unplanned Work: Allowing for unplanned tasks while completing planned Sprint work. This can help in understanding the team’s flexibility and adaptability. You can learn more about how to address unplanned work in our blog post “Unplanned Work – The Hidden Sprint Surprise.”
  2. Evolving the Definition of Done: Developing new agreements in their Definition of Done and trialing them before formal adoption. This iterative testing ensures that changes are practical and beneficial.
  3. Setting Work in Progress Limits: Establishing limits for one or more columns in their workflow to assess the impact on focus and quality. This can lead to more efficient workflows and higher quality results.

Leveraging Investment in Teams

Whether using Kanban or Scrum, the focus remains on leveraging the existing strengths of teams and personnel. Incremental changes, built on current capabilities, ensure that development is sustainable and aligned with organizational culture.

Further Learning and Training

For those looking to deepen their understanding of these agile methodologies, resources and training are available. Kanban University offers extensive information and courses, beneficial for Scrum practitioners. This includes our new Scrum Better with Kanban (SBK) course.

Conclusion

The evolutionary nature of learning in agile environments requires a mindset open to experimentation and adaptation. Embracing managed evolutionary change allows teams to address challenges effectively while fostering a culture of continuous learning and improvement.

FIND A SCRUM BETTER WITH KANBAN CLASS
LEARN MORE ABOUT SCRUM BETTER WITH KANBAN

Stay tuned for more from our Scrum Better With Kanban blog series. If you would like to be notified about other problems and potential solutions for Scrum Masters, please use the sign-up box below to join our Scrum email list.

Fixing Broken Agile Transformations with Kanban

by

Clean Up On Aisle 4! The image depicts a person with cleaning tools to represent fixing a broken agile transformation with Kanban.

“Clean Up On Aisle 4!” Fixing Broken Agile Transformations with Kanban

With a little over a month until we convene in San Diego, our Kanban Global Summit 2022 program is final! Start making your plans now for the sessions you’d like to attend. Will you choose our newest addition to the program? Scott Yankton and Chris Ring of IBM present “Clean Up On Aisle 4!” Fixing Broken Agile Transformations with Kanban.

Scott and Chris say they are not really Agile or Kanban evangelists per se or learned academics in these styles of working. What they are is much closer to “organizational consultants” who want to use the best techniques available for building “fit for purpose” organizations that can win in the marketplace.

In their experience, the best technique for a business side transformation or saving an agile transformation gone awry, is Kanban.

Hear from them and many more speakers at the Kanban Global Summit, August 22-24, 2022 in San Diego, California. Special discounts are available. Email us to find out what might work for you!

Register for Kanban Global Summit 2022

TALK

“Clean Up On Aisle 4!”
Fixing Broken Agile Transformations with Kanban

In our experience, especially over the past few years, we have seen less straight agile transformations of development teams and more of two specific trends:

  • A shift in interest and focus to apply agile to much more complex/difficult business organizations
  • Course corrections or turnarounds of poorly executed agile transformations

This session is not a deep exploration of Kanban theory, but rather is focused on the practical guidance for large scale, highly matrix’d, complex organizational transformations. This includes adopting an ecosystem approach to Kanban, and some key framework components that consistently generate progress.

In this discussion, Scott Yankton (former federal bank regulator/Chief Operating Officer/Consultant, and current IBM Program Director), and Chris Ring (IBM Senior Manager with 35 years experience navigating a highly matrix’d, highly complex Fortune 50 company) reveal key lessons on what works and what doesn’t in this environment, and the keys to their success to date.

scott-yankton-grayscale

Scott Yankton
Global Program Director
IBM

 

chris-ring-grayscale

Chris Ring
Enterprise Agile Consultant
IBM

Kanban Week 2022 will follow the CDC’s Covid safety guidelines, along with state and local guidelines for California and the city of San Diego, to ensure a safe event for attendees.

Modern Military Tactics and All Forms of Lean

by

Modern Military Tactics and All Forms of Lean: Full-Day Workshop with Chet Richards

Reserve your space by registering now as there is *limited capacity* for this workshop.

Wednesday, August 24
8:45 AM – 4:45 PM
Kanban Global Summit
San Diego, California, USA

Your Kanban is lean and your software is Agile. Great! Now what? How do you use these internal capabilities to win in the external marketplace? For one answer, you might look to another highly competitive arena — the military.

Despite what common sense might tell you, it is not unusual for the best equipped or largest army to fail to perform as expected against smaller or lower tech opponents. One example is currently happening in Ukraine. It’s pretty common in the commercial world, too, where today’s tech power house is tomorrow’s fading memory.

Chet Richards, a close associate of the late Colonel John R. Boyd, will present a full-day workshop at the Kanban Global Summit to introduce the common foundation that underlies both modern military tactics and all forms of lean.

Register Now for Kanban Global Summit

“Such ideas as agility, shaping the mind of the enemy, harmony among all levels, and perhaps most important of all, promoting—not just exploiting or responding to—uncertainty and disorder, were all either invented, re-discovered or inspired by Boyd.”

Colonel Frans Osinga
Dutch fighter pilot

Kanban’s Change Management Principles

by

In 2016, we are extending the Kanban Principles to specifically break out Service Delivery from Change Management as two sets of three. In the first of two posts on this I lay out the 2nd Edition of The Kanban Method, Change Management Principles.

Change Management Principles

Your organization is a network of individuals, psychologically and sociologically wired to resist change to their identities, social structures and means of deriving self-esteem and social status. Resistance to change in the workplace often stems from how the changes affect individuals psychologically and sociologically. Kanban acknowledges these human aspects with its three change management principles:

  1. Start with what you do now
    • understanding current processes, as actually practiced
    • respecting existing roles, responsibilties and job titles
  1. Agree to pursue improvement through evolutionary change
  2. Encourage acts of leadership at every level
    • from individual contributor to senior management

Kanban Pillar

These principles represent The Kanban Method’s approach to change. An approach which has been adopted as a response to the complexity of the modern professional services workplace where workers perform knowledge work, producing intangible goods – a workplace where people are paid to think for their living and make decisions as opposed to carrying out manual activities under direction and supervision of a manager. In a knowledge worker workplace, management responsibility simply communicates authority to make decisions containing greater risk. In a knowledge worker workplace everyone makes decisions regardless of any supervisory responsibilities. These modern workplaces are inherently non-deterministic in nature. The system is complex and the outcomes it produces are emergent. 20th Century deterministic methods are outmoded. Kanban provides one new approach to process improvement and management for 21st Century businesses.

Start with what you do now

Most change management is based on a model introduced by the McKinsey consulting firm. This model became prevalent in the 20th Century and has two main flavors: replace what you are doing now with a defined process, prescribed from a catalog; design a replacement process customized to the dynamics of your environment. There is a variant of the second type where the design is based off the existing process as a baseline. There are several variants of these including Value Stream Mapping from the Lean body of knowledge, and the Thinking Processes approach from the Theory of Constraints. The Kanban Method rejects all of these approaches on the basis that they typically introduce too much change all at once, and they suppose that the process designer is somehow smarter than the workforce and smart enough to understand all the complexities of the domain and the dynamics of the workflow. This approach of designing solutions or selecting them from a pattern catalog seems to have worked fairly well in deterministic domains and physical environments. The Kanban Method is based on the assumption that such an approach is problematic in complex, non-deterministic domains such as professional services, knowledge work and creative pursuits. In other words, 21st Century businesses need a 21st Century model for change management. This model should be based on evolutionary theory as it is compatible with and robust to the complexity, emergent and non-deterministic outcomes of modern work producing intangible goods.

Specifically, “start with what you do now” is intended to reduce resistance to change from the people involved. Resistance to change is rooted in the identities of the individuals and the social groups to which they belong. Identity has psychology, social-psychological and sociological components to it. Identity and social position are often derived from practices performed. When we change these, we risk resistance. When we change the role and responsibilities of an individual or group of individuals, we risk resistance. If our goal is to make changes in order to improve service delivery, then we wish to avoid resistance to change.

Strategies for change are beyond the scope of Essential Kanban but we should recognize that our first strategy for managing change is always to avoid it when possible. So Ideally no one gets a new (professional) identity as part of a Kanban initiative. There are exceptions to this, if we introduce Service Delivery Manager or Service Request Manager roles but these are exceptions, not the rule.

Agree to pursue improvement through evolutionary change

Because The Kanban Method’s approach to change is so different from the 20th Century approaches involving defined or designed processes and defined transition initiatives in order to adopt the new way of working, it is important to gain agreement and understanding of the decision to pursue an evolutionary approach and agreement on what that means.

Evolutionary change means that in terms of a process definition, we are never done! There is no concept of “we have arrived” because we have adopted a set of practices and people are now behaving according to new role definitions and embracing new responsibilities. Instead, things will change little-by-little in response to need.

We understand those needs by understanding what makes a service “fit for purpose”. We define meaning metrics with threshold levels to reflect what represents “fit for purpose” in the eyes of the customer. Fitness criteria metrics define our desired capability. A gap between our current capability and the desired capability represent a driver for change. We can use analysis and modeling of our current processes to suggest changes. In this way we view Kanban as a model-driven and scientific approach to evolutionary change. It is directed evolution rather than random mutation of existing processes.

The concept of randomly mutating our existing processes would be compatible with The Kanban Method and is likely to resemble lower maturity, opinion-based change where gut feel rather than analysis and modeling are used to suggest the changes.

With Kanban we evaluate whether a change delivered an improvement by comparing the outcome against the desired fitness thresholds. If our capability has improved towards the desired levels then the change was an improvement and we should stick with it and probably amplify it. If the change resulted in a step back in capability then may consider rolling the change back or implementing another change, a roll forward of our process, in order to get back on track.

Encourage acts of leadership at every level

Change doesn’t happen unless someone cares, unless someone stimulates it to happen. The cover of the book, Kanban – Successful Evolutionary Change for your Technology Business features a cartoon with a character saying “Let’s do something about it.” This is an act of leadership!

Fundamentally what drives Kanban is the value of Customer Focus and the resultant leadership that comes from caring about improved service delivery and the resultant improvement in customer satisfaction.

Just as Kanban adopts a 21st Century evolutionary approach to change, because the domains are too complex, emergent and non-deterministic compared to 20th Century physical workplaces, equally Kanban believes that to drive change you need leadership at all levels. Seeing the opportunities for improvements and holding dissatisfaction about current capability should rightly be everyone’s business. The complexities of modern workplaces mean that it is unreasonable to delegate responsibility for process design and change management to a single person, department or representatives of a consulting firm. The Toyota culture of “kaizen” meaning “continuous improvement” is achieved by creating a culture where acts of leadership are encouraged and rewarded at all levels.

To encourage acts of leadership at all levels, leaders must lead by example. They must suggest changes. They must show the courage to speak up and experiment with changes. The culture must become experimental. There must be tolerance of the notion that not all changes are improvements. And that each change is an experiment until its results can be observed and analyzed. Failed experiments are not failures if the organization learned from it. If people fear being held accountable for failure then they will not show leadership. So to encourage acts of leadership at all levels not only must you lead by example, but you must create a culture of tolerance, understanding and patient, thoughtful inquiry.

Changing the culture isn’t a pre-requisite of Kanban, it should be part of the emergent outcome from practicing Kanban. The value gained, depth and maturity of your Kanban implementation will be constrained by your ability to embrace tolerance of failure, through thoughtful, patient, scientific inquiry and the ability of your workforce regardless of pay grade to feel safe making acts of leadership. Ultimately, there needs to be collective responsibility and accountability for service delivery and customer satisfaction, if you are to reach the highest levels of Kanban and reap its benefits.

What We Know About Duration: Individual Activities

by

The latest fad in the Agile software development community is to promote the use of Cost of Delay for prioritization. Many readers will know that I have been an advocate of Cost of Delay style prioritization and my 2003 book, Agile Management for Software Engineering contained several Cost of Delay related algorithms. However, I feel there is a lot of misinformed, simplistic and potentially dangerous guidance floating around on Cost of Delay and it is time to provide some clarity.

Most of the Cost of Delay material in the Agile space has focused on referencing and modifying the WSJF (Weighted Shortest Job First) equation from Donald G. Reinertsen’s most recent book, The Principles of Product Development Flow: Second Generation Lean Product Development.

The essence of the WSJF equation is total lifetime profits divided by duration of the product development project.

In the first few posts in this series, I want to look at what we know about the denominator in this equation – the duration of the project. WSJF is also being applied in some frameworks to the prioritization of user stories, features and so forth. I don’t believe this is remotely appropriate and I want to start there by explaining what we know about duration of such user stories or features and illustrating why use of duration on the denominator of the WSJF equation is not appropriate for comparative assessment, sequencing and prioritization of fine-grained work items such as user stories.

What We Know About Duration: Individual Activities

On February 24, 2001, I first published my 5 point power law scale for assessing the size and effort of Features in the Feature-driven Development method, on my uidesign.net blog.

Comparing my data later with some well known XP advocates such as Tim McKinnon I realized that the London school of User Story writing was producing user stories of similar size and complexity. This scale appeared formally in my 2003 book, Agile Management for Software Engineering. I first used it on a project in Dublin, Ireland in the summer of 1999.

Figure 1 – Idealistic Normal Distribution for Features analyzed into 5 size & complexity categoriesFigure 1 – Idealistic Normal Distribution for Features analyzed into 5 size & complexity categories

Figure 1 illustrates the scale. It isn’t a random thing. It isn’t based on “estimation” or conversations. It is based on analysis. In other words, it is entirely deterministic. The controlled sentence structure for writing features in FDD enables someone skilled in the art to quickly assess how that feature will impact the code. The sentence contains clues to the method name, the class the method will be coded within and the return value from the method. Given knowledge of the return value, someone skilled in this technique, can almost at a glance make an assessment of how many classes will need to be navigated to produce the desired output. The assessor isn’t doing a design just using their judgment to assess what the design is likely to entail, in terms of classes accessed and method calls.

So I created a 5 point scale: features of sizes 1 through five. I assessed that the average level of effort for such features would rise in a power 2 function: 0.5 days; 1 day; 2 days; 4 days; 8 days or more.

Assuming we’ve made a correct sizing – which is a reasonable assumption as more than 90% of features are likely to be correctly sized using this technique, it is still unlikely that a task duration such as design and coding the feature – actually writing all the method calls and all the unit tests – will take precisely the average time. In fact, it is likely to be random and reasonably evenly spread.

If we had enough data points – a few hundred – and we have a situation where there is no multi-tasking, no delay or blocking on other dependencies and no disruption during the task, then we might expect a properly normal distribution with a scale of about 50% above and below the average. So Size 2 features taking on average 1 day should take something between 0.5 and 1.5 days to complete.

There is a degenerate case where multi-tasking does not skew the shape of the of the normal distribution. This is where the rate of task switching is twice or more as fast as the shortest possible task duration, i.e. if we have a 31 minute task and we switch tasks every 15 minutes then there is an equally random chance that all tasks will be interrupted and hence the distribution will remain Normal. Of course, such rapid task switching would mean the process was massively inefficient and the whole distribution would be right shifted and scaled to the right as a consequence. This is why it is a generate case: it exists in mathematical theory but in reality it never exists.

If we consider now that the smallest task might take 30 minutes (0.5 hours) and the longest might take 12 days (96 hours) we have a spread of variation for Feature effort that spans 200x the smallest duration. The 200 multiple is right in line with reports from Reinertsen. It is probably reasonable to assume that task completion times will span at least 50 times the minimum size regardless of the process used. Again this data is “level of effort” and is still assuming no task switching, no delays and disruptions in service.

Now let us consider the spread of variation of Feature sizes in a given project…

Figure 2

Figure 2 – Even distribution of  features and a more typical mix weighted to small and medium sized Features

Figure 2 shows how the distribution of task duration might vary as we sum the distributions for each feature size. In other words, if we treated all features, simply as features, how long might they take to complete? The upper diagram shows a multi-model distribution for an evenly spread distribution of features, i.e. we have approximately the same number of size 1s, as we do, size 2, size 3, size 4, size 5. I have never seen such an even spread. More typical is a skew towards small and medium size with size 2 being the most common. This produces a distribution more like the lower example.

What do multi-tasking, delay and disruption do to the distribution shape?

Figure 3

Figure 3 –  Multi-tasking, delay, and disruption right shape and left shape the distribution

If there is less than an even chance of something being delayed then the tail of the distribution gradually gets pulled to the right. Therefore, long duration tasks have more chance of being delayed and things which are delayed have more chance of being delayed further. This is what produces the long tail to the right.

Mathematically, as we pull the tail to the right, the shape parameter in the Weibull equation shrinks. We refer to this as left-shaping or left-skewing the distribution. The whole distribution has been physically shifted to the right. Note carefully that I have placed a scale on the x-axis. The mode|median|mean in the Normal distribution is at 4.0 while the lower curve has a mode of 11, a medium of approximately 11 and a mean of approximately 12. So the mean task duration has increased 3 fold because of delay and multi-tasking.

Averages are easily explained but it is the tail on the distribution which represents much of the risk. In the normally distributed ideal situation the task is being completed in a maximum of 8 while after we introduce multi-tasking, delay and disruption of service the maximum has grown to 38.

Figure 3 showed the skew in the distribution for a size 4 feature where some multi-tasking and delay due to dependency and disruption of service (i.e. unavailability of the worker through for example illness or jury duty) occurs. You can imagine when we model this for all five sizes and then roll it into a single distribution similar to figure two that we get an even more pronounced long tail effect.

All of this is a for a single activity. We haven’t even started to look at a workflow of multiple activities with delays waiting between activities in the workflow. I will cover that in the second post in this series.

So What Do We Know About Task Durations?

In summary then, if and only if you have a deterministic analysis technique to quickly and cheaply asses size and complexity you may be able to break your task durations into a taxonomy of categories.

As Jurgen Appelo pointed out in his book Management 3.0, Fibonacci series so beloved of Agilists does not in fact appear in nature. Also it’s index isn’t sufficiently sparse: a story assessed as a 3 on a Fibonacci scale is likely to be a 1, 2, 4, or 5, while the alternatives above and below are 2 and 5 and hence, it is quite random whether a user story is a 2, 3, or 5. If you use user story points as a proxy for duration there is a high likelihood that the assessed size is wrong. This makes it useless as a means of comparative assessment and prioritization in an equation such as WSJF. As a consequence of this there is little to know information value in the sizing and for the purposes of calculating duration we may as well assume all user stories are the same size. This would eliminate user story size as a usable parameter in the WSJF equation.

On the other hand, power laws and Weibull distributions including (k=4.0) Normal distribution and (k=1.0) Exponential distribution do exist in nature. So it is much more likely that sizing for user stories follows a power law. Jurgen discovered in 2009 that I had published such a power law, and the earliest online reference is February 24th, 2001. Even with a power law scale there is some, but less chance of the actual duration overlapping with an item of a different size or complexity. Hopefully, figure 1 was sufficient to persuade you that a point sizing scale assessing size and complexity is not meaningful in assessing task duration for the purposes of comparative assessment and prioritization? If not perhaps the second article in this series will get you to the conclusion that estimating duration for the purpose of using it as the denominator in the WSJF equation is not useful at the granularity of stories, features or epics.

We know from other reports that task durations typically have a spread of up to 200x and the FDD power law scale I developed demonstrates that quite readily – if we assume an 8 hour working day. In my 2003 book, I assumed only 5.5 productive hours in the day and hence we would have merely a multiple of 132 from smallest to largest feature.

So we understand that the problem of estimating task durations such as user story development is non-linear, but we also understand that it is non-deterministic. If we know for example, for certain, from deterministic analysis, that this feature involves 3 classes and 5 method class, we still cannot say with deterministic precision how long it will take. The duration is a Weibull distributed random variable.

So, in summary, for an individual activity in a workflow, the task duration to complete the activity, varies non-linearly, in non-deterministic, is approximately Weibull distributed with a shape in the range 1.0 < k < 4.0 and most likely in the range 1.3 < k < 2.0 and can have a spread from shortest to longest that can be up to 200 times the shortest value.

If you are trying to “estimate” the duration of a task such as designing, coding, testing a user story, you are basically guessing. You are rolling the dice, making a stab in the dark. The actual time-on-task duration for the activity is likely to be wildly different from your “estimate.”

In the next post in this series I will look at what happens when we have a chain of activities put together as a workflow. What do we know about lead time through a workflow?

Kanban Does Not Share Your Agile Team Agenda

by

In November 2013 the Kanban coaching community agreed that we recognized 3 specific agendas that come with Kanban implementations: sustainability; service-orientation; and survivability. The first of these three is shared with Agile software development methodologies. The other two are distinctly unique to Kanban and its focus on improved service delivery and evolutionary change. However, Agile software development methodologies come with a distinct cross-functional team agenda. Kanban does not share this, nor does it need to in order to produce exceptional process improvement results. The Kanban approach is to visualize, improve transparency and understanding, reduce coordination costs through the use of boards. Visualize, Don’t Reorganize!

Agile consultants like to talk about teams a lot. My Kanban book talked about teams a lot too. And that was a mistake. I was using team to mean “a group of people who come together to achieve a common goal.” However, in Agile vernacular a team is actually an organizational unit, albeit, one that has been constructed to have a common goal or purpose, such as delivering working software. Agile Consultants generally set about reorganizing you into “teams” and when the work has variation and variety in it that require multiple specialist skills then these teams are referred to as cross-functional teams – teams containing multiple functions. The goal is to eventually cross-skill people on the team so that they are generalists who can perform all and any function, or T-shape people, who have a broad skillset at a shallow level of competence while maintaining a specialization in a single narrow skill with a deep level of competence.

The Agile bargain is that the pain of the reorganization will pay off in the performance of the new cross-functional teams, that they will achieve high levels of efficiency by eliminating delay in hand-offs between functions and eliminate coordination overhead between different functional groups. If you contain everything you need in a single organizational unit then you don’t have to worry about external dependencies. If these organizational units can be small, say 6 people, then coordination overhead should be minimal to non-existent.

And let’s just say that it works. Let’s not even challenge that theory with any performance data or anecdotal evidence that Agile organizations actually spend a lot of time and coordination overhead resolving dependencies and negotiating for scarce skills and availability of shared resources. Let’s ignore that often there aren’t enough scarce skilled people to go around and that bickering, in-fighting and land-grabbing behavior becomes common during Agile planning. Let’s ignore all of that and assume it works.

What I would like you to consider in this post is this, how expensive in time, money, stress and anxiety is the reorganization into these cross-functional teams? I’d like to posit that a large amount of the pain of Agile transitions and the large amount of the coaching needed for new Agile teams is caused by the stress of reorganizing into cross-functional teams. In other words, one of the reasons Agile is costing so much, is because of the cross-functional team agenda.

Service Delivery Workflow spans functions

Kanban does not share Agile’s cross-functional team agenda. Instead Kanban solves this problem a different way. The diagram explains how. The upper half shows a simplified functional organizational hierarchy divided into 8 functions labeled A through H. Each of these functions is a functional team – a group of specialists in some skill or professional service.

The customer makes a request which involves provision of 7 of these services. The Agile solution to this would be to reorganize into teams with all 7 of these skills represented. Kanban takes a different approach. Kanban is the, “start with what you do now method” and that means you start with the organizational structure you have now. Instead Kanban asks us to model the workflow for the customer service request. We would do this using the STATIK (Systems Thinking Approach to Implementing Kanban) method taught in the 2-day Kanban Systems Design classes from Lean Kanban University. This would give us the Kanban Board displayed in the lower half of the diagram. The Kanban Board is said to be “service-oriented” because it models the required service from the customer’s perspective. The board enables members from all 7 teams to collaborate to deliver the service requests to the customer.

This diagram is simplified for pedagogical purposes. In reality the board design may not have a 1-1 mapping from functional team to column or state in the workflow. Some functions may happen in parallel or in an undefined sequence. We may choose to model activities to be performed using checkboxes on the tickets rather than columns on the board. There is a lot of subtlety and most of these nuances are covered in the training. A qualified Kanban Coaching Professional would be expected to provide guidance on when to model an activity on the board and when to model it on the ticket.

Kanban delivers on the definition of team, I envisaged when writing the Kanban book, “a group of people who come together to achieve a common goal.” The common goal is satisfying the customer request. It is a service-oriented goal. The board and the ticket design provide visualization and insight on the goal. We have plenty of case study evidence to show that this approach works. Many Kanban adopters report increased levels of collaboration at their firms and that this was achieved without painful reorganization, or allocating anyone a new role, responsibility or job title. Kanban improves collaboration through customer focused visualization and creating shared goals for dynamically formed teams of people drawn from different functional groups. With the right board design, it works for shared resources, shared services, functional silos, and of course, it will always work for existing cross-functional teams.

The results from Kanban have been impressive since the beginning. In 2005, the first kanban system spanned across three functional groups and resulted in 230% greater productivity, 90%+ reduction in lead times, and 0% to 98% improvement in predictability and on-time delivery performance. Since then these numbers have been shown to be somewhat mundane. 400% is often reported. 800% has been reported. 50%-90% drops in lead times are common. All of this is achieved without the pain of reorganizing into cross-functional teams; without the pain of Agile transition initiatives; without the cost of Agile transitions and the overhead of Agile coaching.

So even if the cross-functional team does deliver greatly reduced coordination overhead, and even if this does make them “awesome” and “hyper-productive”, and frankly that is a debate that really needs to be had, and if there was any reasonable data, it needs to be studied carefully, but let’s imagine it is all true, given that would it still be a lot faster, easier, cheaper and better to land 200-800% productivity gains, and 50-90% reduction in delivery times from starting with what you do now, and Kanbanizing it? Visualize, don’t reorganize!