Kanban University

Management Training, Consulting, Conferences, Publishing & Software

Agile

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

Kpillar

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

Figure 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?

Are Scrum & Scaled Agile Damaging Morale At Your Firm?

by

In 2008 I was scheduled to give a talk to the Bay Area APLN meetup group. The meeting was being held at the offices of The Gap in downtown San Francisco. The organizers arranged to meet up for a reception in a bar prior to the meeting. As the guest of honor some of the attendees naturally wanted to talk with me. Waiting patiently and quietly for her turn was Janice Linden-Reed. Janice’s story has become a familiar one. She was a project manager at a company where they had adopted Scrum a couple of years earlier along with the Rally tool for work tracking. They’d received training and coaching from Rally but for the last 6 to 9 months Scrum was proving very painful for them and morale was suffering. Meanwhile, the Rally consultants only had one song to sing, “you aren’t doing it right! If only you followed all the practices of Scrum then everything would be fine.” That company was Posit Science, a company pioneering the commercialization of brain plasticity science, and its staff were a combination of PhD neuroscientists and game developers. They were smart, highly motivated people, who believed they were bringing some good to society with their technology and yet Scrum was making them miserable. They simply refused to buy the argument that the problem was with them.

Over this recent holiday period, Grant Ammons lit up social media with his blog post, “Ditching Scrum for Kanban – the best decision we’ve made as a team.”

What makes Grant’s story interesting is that his is just the latest in a long line of similar stories – a thread that can be traced over at least 8 years since I first met Janice Linden-Reed and first heard about Posit Science and their challenges with Scrum.

Since 2009, the Lean Kanban conference in the United States, has been sponsored by Ultimate Software. Ultimate sponsor our conferences as a thank you and in recognition of what Kanban has done to maintain their corporate culture and enable them to thrive since they made a decision to ditch Scrum. In 2008, Steve Reid and Rafael Santos from Ultimate attended Agile 2008 in Toronto looking for a solution to the misery that Scrum was bringing to their workforce. Their story was similar to Janice’s and similar to Grant’s, Scrum had helped them for a while, it had worked for a while, but after a period of 9 to 18 months, it was clear that it was having an irreconcilable negative impact on staff morale. Ultimate prided themselves on their status in the best 100 places to work list. In the most recent survey they are ranked 21st best large employer to work for in the United States. In 2008, their status on this list was in jeopardy and Scrum was a key source of the dissatisfaction that was bubbling in the workforce.

Every story is a little different but there are clear themes. Perhaps half of our clients and half of the attendees at Lean Kanban training around the world are people looking for answers to challenged, painful or failed Scrum implementations. The first thing to realize is that these are real stories and the facts are what they are: people felt the way they did and they acted according to their situation. Wishful thinking or post hoc analysis that they could have done things differently doesn’t change the facts. So what are the common themes in these and so many other stories of challenged Scrum adoption?…

  1. Scrum worked and helped initially

With Posit Science and Pipeline Deals they were startups with smallish engineering teams and they simply needed some initial rigor, some process to follow and Scrum gave them that. With Ultimate, who were already larger, and several hundred engineers, Scrum helped them to focus on short term goals and to deliver more frequently. All of these were good things. So the initial reaction is nearly always positive. While I am only using 3 examples here there are many more such stories where people report, “Scrum helped us initially.” Here is another one by Charles Suscheck. You don’t have to look hard to find more like this on the Web.

  1. Morale starts to drop after 9 to 18 months of using Scrum

All of these stories report that following Scrum started to damage morale after a period of time. There are usually several stated reasons for this: missed commitments / trouble planning and estimating; estimation and planning are taking too long and seem random, error prone, or just plain nonsensical; urgent work arrives more quickly than our sprint cadence and there is pressure to reduce the sprint length but we don’t know how to do that given the current overheads and the existing problems planning and estimating; there is pressure to break the sprint boundaries and add urgent work; product owners show favoritism to one stakeholder over others; product owners have trouble balancing demands from multiple stakeholders; stories are being split over multiple sprints and actual customer service is very poor with long lead times and a lack of predictability and transparency; product owners are suffering anxiety because they are making up numbers to facilitate prioritization and planning activities.

Scrum as a process is engineered to use peer pressure to produce results. This is true at the daily Scrum meeting where individuals make commitments on what they will work on and complete today and have to report the following day on whether they made their daily Scrum commitment, while entire teams makes sprint commitments for the collective work they will complete in a single time period such as two weeks. The problem with this peer pressure, commitment-based approach is that it uses very deterministic mechanisms for estimation and planning, in what is actually a non-deterministic domain. Meanwhile, the social engineering in Scrum also uses peer pressure to drive conformance. It is well understood in sociology that pressure to be part of a group can be strong and can often override individual judgment or logic. So when things aren’t working, individuals are pressured into believing the fault is with them, when in fact the fault is the use of deterministic methods in a domain that has a non-deterministic natural philosophy. When the system is to blame, Scrum teaches its practitioners to blame the people and not the system. This is at the core of the stress and dissatisfaction practitioners feel with Scrum.

I am now seeing similar reports from the field with Scaled Agile Framework which has largely adopted scaled up versions of many Scrum practices. It uses similar deterministic approaches to planning, estimation and prioritization over longer time periods. This practice is known as quarterly release train planning. Some of the same complaints – anxiety that the numbers were guessed in order to follow the process, and that attempts to resolve dependencies in advance are error prone and just guess work, while everyone is being held accountable for their commitments. Once, again, the same problem is being repeated – a deterministic approach is being used to plan 3 month windows of work when the underlying domain is non-deterministic. The practitioners are being set up for failure and made to carry the burden of this failure as their own incompetence.

  1. When things go wrong the consultants always blame the people

In every one of these stories, when the people and organizations complain about the stress that Scrum is bringing to them individually and organizationally, they are universally told that the fault lies with them. Scrum works! Scrum is without flaws! The problem lies with them, if only they were doing it right everything would be wonderful.

As Ken Schwaber has said, “Scrum works! Scrum is designed to work in a context. Your job is to change your context so that Scrum will work for you.” And I truly believe that this is a genuinely correct statement. It, however, disguises the truly difficult bit, “your job is to change your context.” If we look at Grant Ammons story, or Janice Linden-Reed’s story (we use it in our training classes), or the Ultimate story (captured for a future book), or others on our web site such as Nemetschek Scia what we see is a pattern that these were all firms where the business they were in simply made it impossible for them to control their environment and to create a context in which Scrum would work. It wasn’t that they were doing it wrong, rather, in order for Scrum to work, they would have to have changed their business and their business model. Ultimately, canonical Scrum was poor choice for them. If it helped them initially, it should never have been intended as a final solution, instead it should be a first step on a journey of process change and improvement.

Earlier this week, Larry Maccherone shared this story and cumulative flow diagram via his Facebook page. If you read the comment thread you will see that Mike Beedle, one of the founders of Scrum posts his thoughts. Rather than look at the data and analyze it, he quickly jumps to the conclusion that neither Scrum nor Kanban could help these poor souls because they are evidently very poor at technical practices and need to shape up. Compare Mike’s response to mine, as someone seasoned in analyzing cumulative flow data and with a deep understanding of flow efficiency and lead time. This post and the comment thread deeply underscores the differences between Scrum and Kanban communities. With Scrum the practitioners are almost always belittled and blamed, with Kanban we seek to understand the underlying natural philosophy of the domain, understand how the system is operating within it, and seek to find the systemic problems. With Kanban the system is always the number one suspect, not the people working within that system.

Interesting phenomenon that I have seen many times in the past. I have to say though that all but one such example in my…

Posted by Larry Maccherone on Saturday, January 2, 2016

  1. Scrum failure stories often involve leaders in the community and professional certified trainers and coaches

There are many stories of failed Kanban in the market: sometimes the failure comes from inappropriate alignment with culture such as resistance to transparency that comes with adopting Kanban boards; sometimes the failure comes from a failure to install and this would generally be avoidable if the protagonists had taken Kanban System Design training; sometimes a proto-Kanban implementation would have been easier initially than a full Kanban and a trained coach would have been able to help the organization scale the depth of their Kanban to the current level of organizational maturity and leadership tolerance. In general, where we see failed Kanban in the market, the failures come in organizations where they had no training, and did not invest in qualified trainers or consultants with credentials from Lean Kanban University.

However, with Scrum the failure stories are often very different. Often large numbers of the work force have been given certified training from Scrum Alliance certified trainers. Often leading consulting firms are involved and all of their consultants had certifications and professional credentials from the Scrum Alliance or other similar bodies. Despite the available expertise, Scrum remains challenged or fails and the story follows the pattern described in 1 through 3 above.

At Posit Science all their Scrum training and coaching was conducted by Rally, the largest Agile consulting firm in the World. At Ultimate the Scrum training had been conducted by Jeff Sutherland and later by Mike Cohn. Despite having two of the leading 3 Scrum experts in the World, Ultimate were unable to make it work.

The conclusion I’ve come to during the last 15 years of Agile is that Scrum has been widely oversold. There is no doubt that it can and does work but the circumstances under which it can be effective are rarely considered. There has in this respect been a considerable amount of professional misconduct in the overselling and the failure to make any reasonable consideration of context when choosing to implement it. The standard practice of blaming the people in the organizations having Scrum forced upon them inappropriately is a practice that is both morally and ethically bankrupt.

The importance of context and appropriate application of methods

Kanban is not an Agile software development method or process. Kanban was deliberately designed as a mechanism that acts on existing underlying processes. There needs to be an existing context into which we apply Kanban. So fundamentally Kanban eliminates a whole class of potential mis-selling of Agile methods. Kanban is the “start with what you do now” method and evolve from there. Every Kanban implementation will have its own unique workflow and policies. As a consequence, Kanban is adaptable to your context and culture.

However, this is not to say that we haven’t learned a lot about applying Kanban in specific situations. We now have the Kanban Appropriateness Appraisal Framework and the Depth of Kanban Assessment Framework. Both of these coaching tools are part of the standard curriculum for Kanban Coaching Professional training. The appropriateness appraisal looks at both the appropriateness of use of pull systems and the cultural fit for an evolutionary approach to change and incremental improvement. Not every organization has a suitable culture or the appropriate level of organizational maturity or leadership tolerance for Kanban to work. We now know that specific styles of Kanban implementation, implementations at different depths, correlate with different levels of organizational maturity, and as a consequence of this we now train Kanban coaches to be aware of this and to initially apply Kanban practices at an appropriate level of depth. The Appropriateness Appraisal and the Depth of Kanban Assessment Framework go hand-in-hand to insure a much greater level of success with Kanban implementations. It is the use of tools such as these and the knowledge and experience that went into creating them that mean you truly get value when employing a qualified Kanban Coaching Professional (KCP).

And meanwhile, it is never the people who take the blame for challenges with Kanban implementations with the exception of instances where the protagonists quite clearly never received any Kanban training or coaching, and did not make any attempt to actually understand what it is or how it works before they attempted to use it. At some level there is no accounting for stupidity. When people stick a board on the wall and declare they are doing Kanban, if it fails to produce the gains they were hoping for then the fault is quite clearly with them. Meanwhile, our community has an extensive capability for learning, including formal events such as Kanban Leadership Retreats which have led to the development of specific consulting tools such as the Depth of Kanban Assessment Framework and the Kanban Appropriateness Appraisal.

If you are feeling the stress and anxiety or a challenged Scrum or Scaled Agile implementation and you are sick of being told that the fault is with you, then there is an alternative path to agility – consider Kanban in 2016 and see how far it can take you!

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.

servicedeliveryworkflowspansfunctions

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!

Is Agile Costing You Too Much?

by

For a decade now, Kanban has offered an alternative path to agility. At the time of writing my first book, Agile Management for Software Engineering in 2002, I believed that an alternative path was required because too many people were resisting adoption of Agile methods. After publication in 2003, I set about pursuing an alternative and Kanban is what emerged from that journey. So Kanban was for people and organizations who found Agile wasn’t a good fit for them, wasn’t suited to their culture or the nature of their business.

At the start of 2016, I’d like to take a closer look at why we need an alternative path to agility and identify the problems that are evident in the market with Agile methods and their adoption. The first in this series asks the question, “Is Agile costing you too much?”

In 2011, we collaborated on a conference in Finland called LESS. During a panel session which I facilitated, one question from the floor was “It seems to me, listening to the sessions at this conference that Kanban obviates the need for the Product Owner role in Scrum. I’d like to ask the panel, what would you do if you’d recently hired 400 product owners?”

Me, “I’m sorry, can I clarify that I heard you correctly, I thought I heard you say ‘400 product owners?'” “Yes, that is correct!”

“How many developers do you have?” “2,400. Our Agile consultants told us we needed one product owner for every six developers. So what should we do with these 400 new people we have hired?”

Last month, my colleague, Alexei Zheglov, was speaking with an Agile coach whose contract hadn’t been renewed. It is never nice to be laid off at Christmas. What had happened? Well, this coach responsible for coaching just six developers wasn’t renewed because there weren’t sufficient tangible benefits to justify the overhead. His contract was costing $150,000 every six months.

On December 24th, I met the CTO of a bank in China. This fairly mature IT organization was running a side-by-side comparison of Kanban against Scrum. The consultants and trainers for both methods were being supplied by the same firm in Shenzhen under a single purchase order. The Scrum coaching was requiring one fulltime Scrum coach for every twelve employees.

Late in 2014, I did some consulting for a large telecommunications equipment manufacturer here in the US. Specifically, I was advising a business unit based in sub-urban Boston. The general manager had brought me in because in his own words, “We’ve been doing Scrum for 6 years but we haven’t seen any improvements for at least the last 2 of those years.” The business unit had a Scrummaster for every 6 developers. I attended several retrospectives, usually facilitated by one Scrummaster and then each of the others in turn had an opportunity to speak up and report the Sprint for their teams. Later in the engagement I was discussing the need for someone to play the role of Service Delivery Manager for a kanban system. The GM asked me who should play that role. He suggested no one in his business unit had the skillset. So I innocently asked, “What do your Scrummasters do?” He replied that “they coach the practices of Scrum.” Since then I’ve come across many companies who describe their Scrummasters as Agile coaches and the ratio of coach to value-adding workers is in the range of 1:6 to 1:12.

The role of Product Owner is interestingly ambiguous in its definition. In some organizations, Product Owners are basically business analysts who write requirements. While in others, Product Owners have a role that is very specific to prioritization and they are the decision makers with respect to the sequencing of the work. Ken Schwaber described the Product Owner role as “the single throat to choke” and he clearly had decision making, responsibility and accountability in mind when he used that term. For many the Product Owner is an interface between multiple competing business stakeholders and the delivery organization (or Agile team.) The Product Owner is a curious addition for Agile. At the founding of the movement, Agile was in part about removing middle-men, eliminating signal attenuation and having direct contact with customers – conversations rather than documentation. It is strange, therefore, that to facilitate such a process we need a new form of middle-man, the Product Owner, to prioritize the order of the conversations. Regardless, of exactly what the Product Owner actually does in your organization, it does seem that often these product owners are new hires to the organization and again the ratio of 1:6 seems to be common. One of our own clients in 2015 made a decision to hire about 20 such Product Owners. While it goes against standard Kanban coaching guidance, the client had their own reasons and justification for the decision.

There is a question whether the product owner is a value-adding role or not? In many organizations it appears that it is not: The product owner is a middle-man with authority over prioritization. While sequencing and scheduling when done well will generate value, the act of sequencing one item over another, does not add value to the items themselves and from a Lean value stream mapping perspective it’s a non-value-adding role. Even more curious then that Agile requires you to create non-value-adding positions.

So in some extreme cases, Agile methods appear to have added 2 new people in non-value-adding positions for every 6 in value-adding positions. Put another way, after the Agile transition, 25% of the workforce is additional “Agile” overhead for operating the Agile method. While this is at the higher end of the range, I believe that it is typical for operating expense budgets for IT / product delivery teams to be increased by around 14% to cover the overhead of non-value-adding Agile facilitation positions.

What about Agile training? There are many 2-day, and in the case of scaled Agile solutions, 3 and 4-day training classes available. Many of these come with short examinations at the end and certifications for passing. However, what appears to be the case is that these training classes do not prepare the workers to behave in an Agile fashion or to deliver the promised benefits of Agile methods. The classes often contain abstract or metaphorical content and are filled with games which while fun to play do not teach specific actionable behavioral change in the workplace. All of this is okay, because the Agile transition purchase order includes coaching as well as training and the coaching is essential because the training did not contain anything actionable. The workforce, however, are now “certified”. Strangely this certification does not mean they know how to behave differently or how to produce better outcomes. It appears to mean that they are now certified to receive coaching.

Let’s imagine for a moment that Agile was producing twice as much value than what preceded it. If this were true would you spend 14% more on operating expense in order to generate that additional value? Rationally, you would say yes. It is an obvious and simple executive decision. The ROI is clear. And therein lies the rub with Agile. How many supposedly Agile organizations can show such benefits? The best and most popular Scaled Agile Framework appears to scale by offering quarterly release planning and using 3 month time boxes. The so called “release train planning” involves getting everyone in a room together in order to resolve dependencies between work and to devise a suitable schedule of six incremental 2-week sprints.

One company I know of in Central Europe, transports up to 500 people by plane, train or private cars, to a location near Frankfurt every quarter in order to conduct the scaled Agile release train planning. What is this costing? If we conservatively budget 800 Euros per person for transport, lodging, and catering, and assuming the company has a meeting facility large enough and isn’t renting a banquet hall from a nearby hotel, then we might have a budget of 320,000 – 400,000 euros per quarter.

Meanwhile, releases are only coming every quarter. How often were releases happening prior to the adoption of Scaled Agile? And how much functionality was getting released? Is there any tangible evidence that Agile is delivering the additional value it claims?

I hear other claims that Scaled Agile is leading to inefficiencies synchronizing teams with some teams having to take down time while others catch up. So the efficiency of Scaled Agile is being called into question by some of its practitioners. I haven’t seen this explicitly with any of our own clients, so it is hearsay, until I have some solid evidence.

Around 10 years ago I worked with a group of Agile coaches from Sabre Holdings, a firm which included properties such as Travelocity and Last Minute. They were under pressure to show an ROI for the Agile coaching team. The Agile coaching department was costing around $2,000,000 per year and the senior leadership wanted, quite reasonably, to know what they were getting for that money. After some period of time, the group was unable to show real tangible ROI and it was closed down. Some of those coaches found employment with other Agile firms such as Rally. After a period of time, Sabre was once again dabbling with Agile and the costs for consultants and staff augmentation were mounting up. A decision was made to create a new in-house team again. This time the justification was merely deferred cost against consultants and temporary staffing. It was no longer necessary to show an  ROI on value created, just enough to show that the internal cost was less than using outside help.

So there have been 15 years of Agile and yet we still don’t have very many case studies showing tangible business benefits and real ROI. Meanwhile, Agile consulting firms thrive on supplying the large numbers of coaches required to “go Agile.” Perhaps, it is time to ask, “Is there an alternative approach to agility that costs a lot less?”

Back to the CTO of the Chinese bank that I met on 24th December. He told me that in 5 months, he’d managed to scale Kanban to 2000 people across 5 locations in China. That the adoption had institutionalized and he’d been able to make a tour of the various locations and inspect many of the Kanban implementations for himself. He told me that Kanban was producing greater productivity and efficiency than Scrum. He, however, didn’t elaborate much, and isn’t ready to share his data. He wants more evidence before he is prepared to go public. What he was willing to share is that the Kanban implementation had been achieved with a total of 200 days of training and consulting. This is a ratio of 1 day for every 10 employees. Meanwhile, Scrum coaching is costing 180 days for every 12 employees, in the same half year time period. He also confirmed that Scrum is failing to institutionalize and is requiring constant coaching.

To put this in perspective, in terms of per employee adoption cost, Kanban is costing this bank 1/150th of the cost of Scrum, and producing better results. How might this huge cost saving be possible? Well, for starters Kanban doesn’t require you to add people to your organization as coaches or product owners, instead it provides existing workers with a means to frame and make better quality decisions. Kanban is empowering and enabling. Workers become more effective at doing their existing jobs in the existing process and workflow – no need for coaching in a new role as part of a new process. It’s simply more effective to stick with what you do now and get better at it, than it is to make grand changes.

We are inviting executives from this Chinese bank to speak at our Spring conferences in London and San Diego. We hope to have both cost and value/productivity data to report by that time.

A week earlier I was in India where I saw a case study presented by a young consultant who was acting for a large Agile consulting firm, advising a large Indian outsource firm, to a large financial institution based in New York. Because of the nature of the contracts between these firms, the actual details are covered by a non-disclosure agreement, so we can’t name names, or any specifics. The client had adopted Scrum largely enterprise-wide and had adjusted all their processes to facilitate a 2-week Sprint cadence. Despite this highly Agile sounding arrangement, actual customer lead times for changes to credit card processing systems were taking 130 days on average. With some courage, the consultant took it open herself to push through a single kanban system implementation. With no other changes, within 6 weeks, lead times had shrunk to just 12.5 days and the client was so happy they are pushing the consulting firm to implement more Kanban. This particular consulting firm is well known to be anti-Kanban and their sales people around the world actively dissuade clients from adopting it. So it took a courageous act from a single professional keeping the client’s best interests at heart to create a huge improvement in value delivery.

That same week in India I saw another presentation where the kanban system had produced a 30% increase in revenue by enabling the firm to process more service requests faster. This is real ROI. Now would you spend 14% on OpEx to get 30% more revenue? Probably not! Revenue isn’t margin or profit. If you only got 30% more revenue but Agile was costing you 14% more OpEx you’d be losing money. The thing is, how many Agile implementations could claim 30% more revenue? Meanwhile, this Kanban implementation cost a handful of coaching days over 6 months. This story was a strange déjà vu with a case study presented at Lean Kanban Benelux by Tina Dudenhoeffer, a consultant, and Marianne Lanting of Winkle. Again, they had increased revenue by 30% in only 5 months by servicing requests for market research surveys faster and more predictably using Kanban. The cost of this implementation was less than 20 consulting days from Tina plus training from Maarten Hoppen of our partner VX Company. Marianne is a manager at Winkle and there was no additional cost for her.

In general these results while extreme sounding isn’t surprising. We already know from surveys and reports post Kanban training that our training is more effective than typical Agile training. Lean Kanban training is specifically experiential and uses games, simulations and exercises that simulate or model the actual working environment. Students leave our classes with specifically actionable ideas and designs for changes many of which can be implemented immediately at no or very low cost. They don’t need any or much coaching. They come out of the class understanding what to do and why they want to do it.

For 5 years now, we’ve been selling Kanban coaching engagements that typically look like 2-4 days per month for organizations up to a product unit (or 150 people) in size. Kanban coaching is typically centered around coaching managers on metrics, reporting, and holding the various Kanban Cadences meetings such as Service Delivery Review, Risk Review or Operations Review. We have often found ourselves bidding against Agile consulting firms recommending coaches are on-site for 4 or 5 days per week and often at the ratios we’ve discussed here 1:6 -> 1:12 people. Bizarrely clients have often opted for the latter, usually for 2 reasons. We don’t quote hourly rates for our consultants, only daily rates, and if you do try to calculate an hourly rate, it will be higher than that for a typical Agile coach. We aren’t ashamed of this. We believe our coaching is far more effective because it focuses on high leverage activities that deliver more value, rather than on Agile practice adoption and behavior. Meanwhile, the quantity of consulting days and the number of consultants is dramatically less. Often clients are skeptical of this. Everyone else is advising them they need a lot of Agile coaches and a lot of coaching. They believe it is too risky to go with our model when we appear to be bucking the trend. It seems easier to follow the herd. It is common for us to be quoting less than 1/10th the cost of rival Agile consulting firms, typically, $30,000 – $50,000 against $300,000 – $500,000 and then to be told we didn’t win the business because, and to quote a VP from a travel technology firm, “You are too expensive!” This analysis was based on an hourly rate and not on a total contract cost. Sigh!

So, while we have a bank in China that is rolling out Kanban at large scale at less than one hundredth of the cost of Scrum, we have been and continue to be confident that Kanban, as your alternative path to agility, can be rolled out at only one tenth the cost of competing Agile and Scaled Agile methods. We are prepared to put our money and reputation where our mouth is on this, because we are more than confident with years of experience and real data that we can make it work. So, this month we are launching “The Kanban Challenge” – give us 10% of your Agile budget and we’ll promise to outperform the other 90% producing more and better results over a 6 to 18 month time period. Some conditions apply to this offer so do approach our sales team directly for full details if you are interested.

After 15 years of Agile, it is time that developing true business agility stopped costing you as much as 14% of your OpEx budget. So discover “the alternative path to agility” and take The Kanban Challenge in 2016. Let us show you how much is possible at just a fraction of the cost and impact of Agile methods. Watch out for the launch of The Kanban Challenge later this month. Until then please feel free to contact our sales team with any questions.

Kanban – The Alternative Path to Agility

by

The Kanban Method was conceived as an alternative path to agility – as a means to improve responsiveness and adaptability without any significant revolution or reorganization in your way or working or political structure of your business. Lean Kanban University has recently introduced a series of training classes developed and evolved from older, tried and tested curriculum to ease adoption of Kanban and communicate the full scope and scale of what is possible when you fully embrace Kanban as a way to manage your modern professional services business.

This table shows The Kanban Method and the alternative path to agility is a single graphic. From left to right you progress from basic introductory shallow kanban boards to full enterprise scale, Enterprise Services Planning.

kanbaninatable

In September our new training facility, the Anderson School of Management opens in Seattle conveniently located near Seattle Center at 200 First Avenue West. We will be offering the full suite of Kanban and Enterprise Services Planning classes every month. Browse our schedule via our training listings. Email our sales team for summer offers and promotions if you register before August 10th, 2015.