Posts Tagged ‘Change Management’

Kanban, Mental Models, and Double Loop Learning

Posted on July 14th, 2010 by Dennis Stevens  |  1 Comment »

DoubleLoopLearningBack in September of last year I wrote about The Fifth Discipline and the Agile Enterprise. In that article I connected mental models and double loop learning with Agile. Mental Models are a way to describe a person’s intuitive perception of the world around them. How we act on that world, our decision rules, are based on  our mental models. In single loop learning, we may change our decisions, but we leave our underlying mental models and decision rule unchanged. In double-loop learning, we change our underlying mental models and decision rules to better serve us in the real world. I talked about how Agile, when done well, inspires us to explore our mental models and improve our decision rules. When our mental models go unexplored, we won’t change our decisions and so we won’t get new results.

Theory in Use and Espoused Theory

Recently, I have seen several references to Chris Argyris in the Agile community. Argyris is an American business theorist who developed a way of explaining organizational behavior called Action Science. In Action Science he describes two simultaneous mental models that make it difficult to create change in an organization. The first is our Espoused Theory. Our Espoused Theory describes the model we say we use to describe how we act (or how we would like others to think we act). Our Theory in Use is one we actually use to make decisions. From a personal standpoint, the Theory in Use is complicated for a number of reasons. It is shaped by how we are participating in the situation. I might respond differently to my brother (who I work with on clients) then I would respond to a client. It is shaped by the threat we feel in the situation. I might respond differently when the situation is under control then I do when I feel threatened. This becomes even more interesting when we are dealing with organization’s and changing the mental models that shape organizational behavior.  Making changes in the stories we tell about why we behave the way we do won’t change our decision. A key to making change is to intervene at the Theory in Use.

Model I-Inhibiting Double Loop Learning

Argyris tells us that when human beings deal with issues that are embarrassing or threatening, their reasoning and actions conform to a model called Model I. Trying to make change in a Model I organization is difficult because you are dealing with their Espoused Theory. It is neither rewarding nor safe for them to explore or actually change their mental models and decision rules – so there is a wide gap between their Espoused Theory and their Theory in Use. The defensive behavior in Model I organization’s create a vicious make this divide even greater. Model I organizations have the following values and supporting behaviors.

  1. Define goals and try to achieve them. Participants rarely develop mutual definition of purposes – nor are they open to altering their perception of the task. Participants plan actions secretly and  and manipulate others to  agree with a their definition of the situation.
  2. Maximize winning and minimize losing. Participants feel that once they have decided on their individual goals it is sign of weakness to change them.
  3. Minimize generating or expressing negative feelings. Expressing or permitting others to express feelings is a bad strategy. Participants unilaterally protect themselves.
  4. Be rational. Interactions are objective discussions of the issues.Participants withhold the truth, suppress feelings, and offer false sympathy to others.

Model I behavior results in organizational defensive behaviors that block exploring underlying mental models and the resulting maturity that arises. Most organizations exhibit Model I values and behavior most of the time.

Model II-Encouraging Double Loop Learning

Argyris describes a much more productive type of organization that he calls Model II. In a Model II organization, it is safe and rewarding to the participants to explore underlying mental models and decision rules. Model II organizations have the following values and supporting behaviors.

  1. Valid information. Participants design environments where accurate information is shared and underlying assumptions can be openly explored.
  2. Free and informed choice. The participants jointly control tasks and focus on collaborative problem solving.
  3. Internal commitment. The participants jointly protect each other in learning and risk taking. Mental models and decision rules are jointly explored.

Model II behavior results in organizational behavior that enhances underlying learning. High maturity organizations exhibit Model II values and behavior.

Kanban and Action Science

So, if we want double loop learning (and we do), we want to promote Model II values and behavior. That means we need to create an environment where:

  • valid information is apparent
  • it is safe to explore underlying assumptions
  • participants are actively involved in controlling their tasks and collaborative problem solving
  • the participants are focused on a bigger goal
  • we can compare the result of our change actions with the actual outcomes

Kanban explicitly creates this environment. The board, the tasks on the board, and the metrics make valid information readily available. The visualization of the work helps make it safe to explore underlying assumptions. You are no longer looking to cast blame, you are looking for an understanding of the system – it is depersonalized. The participants are involved in defining the board, the policies, and participate in problem solving on the board. The board and the focus on reducing lead time, reducing defects, and the policies changes the focus of the team to the bigger goal. Finally, the data available to us helps us make sure the improvements we attempt are achieved and sustained.

Kanban and Maturity

Chris Argyris’s intervention method for developing Model II behavior is simple. Map the system, internalize the map, test the model, invent solutions, intervene and study the impact. Kanban puts a simple, actionable model of this in place. Even better than the single cycle intervention model, the Kanban cycle supports continuous learning that the team internalizes. Argyris’s model gives us some insight into why Kanban teams are consistently achieving double-loop learning and rapid maturity.

Further Reading

Argyris, C. and Schön, D. (1996) Organizational learning II: Theory, method and practice, Reading, Mass: Addison Wesley.

Argyris, C. (1993) Knowledge for Action: A guide for overcoming barriers to organizational change, San Francisco, CA: John Wiley & Sons, Inc.

How is the Kanban board different then a normal Agile board?

Posted on May 24th, 2010 by Dennis Stevens  |  7 Comments »

In comments on my recent post, What’s Deming Go To Do With Agile, I proposed that Kanban brings an easy to implement – low friction implementation of Deming’s philosophy. Daryl Kulak disagreed – it turns out that this was based on the presumption that implementing Kanban included a prescribed implementation of TPS, TQM, and other Lean tools. We sorted it out and then Daryl made an excellent point – a normal Agile board can be used to learn from the system in the same fashion the Kanban board can. I believe this is true. In fact, I believe that the Agile board and the conversations and ceremonies around it are key to the success of Scrum teams. So, how is the Kanban board approach different then a normal Agile board approach?

No Role Changes Involved

Whether you are currently doing Agile or not, putting up a Kanban board to visualize your system requires no other changes. At the onset you don’t change any roles, ceremonies, artifacts, or measurements. You do need to go through the effort of defining the board collaboratively – involving performers, management, customers, and suppliers.

Just start with what you have. Establish a system boundary for your board. Identify the states your work goes through inside the boundary (i.e., Analyze, Develop, Accept, Release) – especially reflecting hand-offs or a shift in approach (i.e. talking about it, unit testing and coding, starting acceptance test, preparing for release). Put these states as columns on the board. Then define the various work item types that go through your system. Write up all the Work in Process on cards and place them on your board.

Use the board to understand what you have and think about it. As Daryl points out, Deming says “study your system THEN find tools to fix the problems you see.” This board will create an opportunity to create a shared understanding of your system among all the stakeholders. That’s it. In about a day you can have your board defined and within a week you will have your work moving across the board.This may not seem powerful, but in my experience this effort is extremely valuable. I have seen productivity dramatically increase just from this exercise – no role changes, no engineering changes, no changes in how we do requirements. Just making the work in the system visual and talking about it once a day.

A Broader View of the Value Stream

A normal Agile board is focused on the team, typically development. Even when you are running Scrum in other sections of the business the typical Agile board doesn’t show the broader value stream.  A Kanban board can cover all aspects of the business – from product conception to implementation. Put up the columns that help you understand your system. A common pattern I have implemented is using a Program or Portfolio level Kanban that feeds into various organizational units such as development, training, process, marketing, and HR. The point of this view is to show the broader system to everyone and how each area fits together in the broader view of delivering value to the customer. You can also cascade boards to show a comprehensive view of the complexity in the organization.

Limiting of WIP

Once you get work showing on your Kanban board you will see where work is piling up.  Excess work in process raises a number of challenges. It increases the time a new item will take to travel through the system. It indicates the likelihood of an overburden on the current performers or the next performers. For example, in Scrum iterations when there is a lot of work in development that all moves to test at the end of the iteration – this is undesirable.  You can limit WIP in a number of ways.  In Scrum, we limit WIP at the iteration boundary and some teams limit WIP by limiting the number of work items that can be active at any one time. The Kanban board calls for explicit WIP limits and also recommends buffer columns to mitigate the impact of variation to keep work flowing through the system. You can certainly explicitly limit WIP and include a buffer or buffers on a normal Agile board. Here is a essay from Lean Software Engineering showing ScrumBan.

Classes of Service

Kanban also introduces a concept of Classes of Service. Classes of Service are a mechanism for typing of work item types. Rather than treating each item homogenously, Classes of Service may let the team establish different prioritization policies for each class of service. Prioritization policies come into play when someone is looking to pull the next work item. For example, one class of service might always move the work item to the top of every queue. This would expedite it through the system. Another class of service might be even higher priority – with the team violating WIP limits and stopping what they are working on to pick up the item. Classes of Service can also help with the allocation of performers. For example, WIP limit policies may be established so that one new feature, three defects, and one technical debt feature will be active at all times.

Kanban boards are different then a normal Agile board

I agree with Daryl that a normal Agile board can be used to learn from the system in the same fashion the Kanban board can. There are some differences. A Kanban board can be implemented without changing any thing else and then making changes to fix the problems we see. Kanban can provide a broader view of the value stream. Kanban provides for limiting WIP and using buffers to facilitate pull and flow. Kanban supports classes of service. So, what stops a team doing Agile and using a normal Agile board from adding some columns, limiting WIP, and adding in classes of service? Nothing – except perhaps a lack of understanding. Part of uncovering better ways of developing software is to continue to learn and do what makes sense in each specific situation.

The Agile Bargains

Posted on December 2nd, 2009 by Dennis Stevens  |  No Comments »

There is a nice summary of Kanban at It shows Feature Requests going into the Software Development Pipeline and Improved Software coming out.The article does a great job of showing how Kanban helps improve the flow of software development. Getting better at software development is important and Agile methods have been helping teams achive this goal. This is the first bargain of Agile-delivering software faster and with much higher quality then ever before. In most organizations however, this is only a small part of the business equation. Even when development is successful, a narrow focus on software  development narrows the value an organization will achieve. We also need to align of development with the most important needs of the business, balance development with adoption, and ensure improved business performance is achieved.


Feeding the Software Development Pipeline

Unless a company is a software development service provider, its business is not about software development. Software likely enhances the businesses ability to create value for it’s customers. So, while Agile development helps teams get better at software development – the goal is to get better at creating value for it’s customers. The focus of Agile software development is upside down. The focus should be on the capabilities of the business. Aligning development with the needs of the business requires understanding  which business capabilities will benefit from improvement and prioritizing these needs based on business value.

After using a business capability approach to need identification and prioritization, the business needs must be appropriately scoped and communicated to development. Over the last month I have been writing about Making Agile Requirements Work. need to make sure the requests that go into the Software Development Pipeline are clear and appropriately defined. Following the six principles of Agile Requirements That Work help with this feeding of the Software Development Pipeline.

  1. Articulate Purpose and Outcome
  2. Establish a Shared Language
  3. Provide a Stable View of the Business
  4. Support Progressive Elaboration
  5. Testable
  6. Prioritized and Reflect Business Value and Risk

Gaining Business Benefit

The other part of the equation is to ensure the organization adopts and supports the improved software. Once the Software Development Pipeline has produced Improved Software, it still isn’t valuable until the Business Capability has achieved the intended performance improvement. Just as the elicitation and analysis of requirements has to match the cadence and needs of Software Development. Software Development has to match the cadence and needs of the organizations ability to adopt and support Improved Software. Part of the overall feedback to the organization includes ensuring the capability improvement is achieved.


At every step in this equation different risks may exist. identifying, prioritizing, and scoping feature requests have risk associated with a lack of understanding. Software Development has risk associated with the Ability to Execute and Verify the delivered software. Benefit realization has risks associated with achieving adoption and being able to sustain and support change in the organization. These risks should be explicitly managed and feedback mechanisms should be in place to recognize the realization of risks. Failing to understand and manage risks in an integrated fashion will also diminish the organization’s ability to maximize benefit from it’s investment.

The Real Agile Bargain

The real agile bargain is the maximizing of economic outcomes by increasing the speed and focus an organization can improve and respond to the market. The Agile Business Value Equation is solved at the Business Capability Level. The ability to rapidly develop high quality software moves Technology from a change obstacle to become an change enabler. This happens at the intersection of Feeding the Software Development Pipeline, Developing the Software, and Gaining Business Benefit. Solving any of these parts independent of each other does not result in optimizing business agility.

Creative Solution Finding and Big Agile

Posted on September 16th, 2009 by Dennis Stevens  |  No Comments »

The Model I am looking at today is from “Creative Solution Finding: The triumph of Breakthrough Thinking over Conventional Problem Solving” by Gerald Nadler, Ph.D. and Shozo Hibino, Ph.D. I used a lot of these concepts as I laid the initial capability analysis input to Microsoft’s Business Architecture offering. The concepts support rapid development of a strategically-aligned and situation-specific solution road-map. The focus on solution context and including people in the design also encourages adoption by the end users. I believe the application of these concepts were instrumental in several successful transformations I have led.

Creative Solution Finding

There are seven principles in the model. These principles build on and support one another. Like the other models, none are complicated – but all are difficult to apply. In this case, you are stretched to think in some new directions. First, thinking about purposes in the context of the system. Secondly, thinking about creating solutions and not on studying problems.

Uniqueness: Every problem is unique. You can’t just copy a solution from somewhere else. Take time to understand the context of the solution.

Purposes: Always and continually ask the purpose of solving the problem. Expand the purpose question as far as possible. Focusing on purposes within purposes will high light the uniqueness of the problem.

Solution-after-next: Find solutions today that achieve the focus purpose, based on what might be the solution after next. Working backwards from some ideal target solution can stimulate innovation and high-light larger purposes.

Systems: Understand the elements and dimensions that comprise a solution so you can determine in advance the complexities you must address and the actions you must take in implementation.

Limited Information Collection: Before gathering and analyzing extensive data determine what will be achieved from the data. “What do we need to know to accomplish our purpose” is a powerful question to focus data collection on the solution. The goal is not to become an expert on the problem, but to study the solution.

People Design: Let everyone affected by the solution to take part in the development. People are interested in exploring purposes and solutions-after-next. The people involved will also make sure the system is addressed and the critical details are attended to.

Betterment Timeline: As you are building today’s solution, build in and monitor a program of continual change. A sequence of purpose-directed solutions and knowledge of the solution-after-next are bridges to successful adoption and a better future.

Creative Solution Finding and Enterprise Agile

This model is interesting because it gives guidance on how to create strategically-aligned situation-specific solutions. This is very relevant to implementing Agile – whether in a small team or at any order of scaling. Combined, these principles provide some guidance for leading a company toward Big Agile.

An Irrational Approach to Change Management

Posted on September 10th, 2009 by Dennis Stevens  |  6 Comments »

In Leading Change, Kotter talks about four aspects that must exist for a successful change program: A Compelling Story – because employees must see the point of the change and agree with it; Role Modeling – because employees must see the colleagues they admire behaving in the new way, Reinforcing Mechanisms – because systems, processes, and incentives must be in line with the new behavior, and Capability Building – because employees must have the skills required to make the desired changes.

So many change management programs go about telling a compelling story about how great the business will be, they spend time enrolling champions of the cause and promote their successes, they align financial compensation and metrics with the change, and they launch massive training programs to support the change. And yet, in most instances, beneficial change is still painful and slow.

Resistance to Change isn’t Rational

That is because resistance to change is almost never rational. People are smart and they understand the benefit to the business immediately. What we have found is that resistance to change doesn’t have its roots in a lack of understanding regarding benefits. Resistance has its roots in fear, embarrassment, and loss.  These have their roots in people’s innate desire to be successful. They are probably built-in very deeply to our survival mechanisms from when being successful meant staying alive. For most of us, these deep motivators extend beyond ourselves to include the people we feel responsible for – our tribes. Our tribes can include our teams, our families, the company, our customers, and society.

Fear deals with uncertainty about the future. A person may realize that there is potential to do things better than they are currently doing it. But if the way they are doing it isn’t getting them fired and they aren’t completely certain they can be at least as successful in a new way, they will resist the change until their fear is addressed.

The important thing about addressing fear is that fear is in the perspective of the person who is facing the change that matters, not the people initiating the change. Historically, we keep doing what we have always done because it kept us alive.

Embarrassment deals with admitting that the way we have done things isn’t the best way to do it. People have a very strong drive to be right and to be appreciated. When you point out that they aren’t doing things the best way, they tend to become defensive. You don’t understand how things got that way. It sure is easy to come in after the fact and point out the problems. You must think they are stupid if you think they don’t understand the flaws in how they do work.

Embarrassment is dealt with by letting people tell their story. Let them know it is clear that they made the best choices they could over time. Its ok that things got the way they are because the got the way they are.

Loss is much broader. People have made an investment into developing the competence that they have been rewarded for and that gives them influence. Any of these points can be an emotional sticking point, loss of investment, competence, rewards, or influence.

Explaining how things will be better for the business on the new .NET platform doesn’t help the guy who spent the last 20 years becoming the absolute expert in the COBOL application. Explaining the focusing benefits of social marketing techniques doesn’t make the sales person who spent the last 20 years developing relationship more valuable. The manager who has thrived in chaos and been rewarded for it will resist the effort to put in stabilize the environment.

Everyone has Their Own Story

When we change the way we do things, we can’t replace the investment made by individuals in developing the competence that has led to reward and influence. We pull that out from under them. Loss is the most difficult challenge to deal with. We can commit to supporting a new investment, although it is difficult to replace 20 years of experience. People want to be valued. Try treating them with a great deal of respect and recognition for what they have accomplished. This will help with the transition, but won’t necessarily set them up for a complimentary level of success in the new way of things.

The bottom line is that overcoming resistance to change is critical to the success of most strategic changes. Typical change management approaches teach us to communicate, communicate, and communication again. But, notice how of the sources of resistance are all at a personal level. Explaining how the change will benefit the business, or the manager, or even the customer isn’t sufficient.

Next time you are facing resistance to change, don’t push – listen. The person resisting understands the benefit to the business. It is fear, embarrassment, or loss that is motivating the resistance. Often it is a combination. Often their fear, embarrassment, or loss extends beyond them to what they perceive as their tribe. Spending time understanding and addressing resistance at its root may seem like an unnecessary investment. However, the investment is almost always less than the cost of the resistance itself.

This article is an updated version of an April 2007 Synaptus entry. I was inspired to update and reprint this post based on this McKinsey Quarterly newsletter.

The McKinsey Quarterly-The irrational side of change management