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.

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.

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.

Risk

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.

Enterprise Agility

Many companies are dependent on technology to be competitive. Either because they deliver technology as their product or because technology enables the processes they depend on. For those companies it is important to be able to operate faster than their competition.  This requires not only the ability to rapidly deliver technology – but the ability to adapt their organization.  This is the concept of operating within your competitors decision cycle. The model I use to demonstrate this concept is John Boyd’s O-O-D-A model.

This is Enterprise Agility, when the enterprise has learned to leverage technology and change management to develop an energized workforce frequently delivering value that meets the emerging needs of the customer.

Three Concepts for Achieving the Agile Enterprise

I am going to build on three concepts in showing how to build Enterprise Agility.

1. Theory of Constraints. You can’t get there all at once. It is necessary to decide where to focus. You have to develop the underlying capabilities from the bottom up. If you can’t produce quality product, the best ideas in the world will run into problems. The way of thinking about problems covered in the management system the Theory of Constraints provides the method for deciding where to focus. Identify the current constraint, get the most out of the capability that is the constraint, subordinate the system to the constraint, elevate the constraint, and then continue to pursue this cycle. This “Process of On-Going Improvement” is applied to the flow of value to the customer.

2. Creative Solution Finding. Once we understand where to change we need to understand what to change to. We have to apply a method to lead the overall adoption effort that supports aligning the capabilities with the overall goals of the organization. The stages of Creative Solution Finding are useful for identifying the situation specific approach to developing this road-map. There is no magic sauce for developing this road-map. By applying the seven principles, along with a knowledge of applicable best practices, a useful road-map that fits both the process and social context of the Enterprise can be developed.

3. The Learning Organization. Technology development efforts are knowledge based efforts. As such, they are performed through a social construct. To improve the performance of software development we have to not only improve the methods of development, we have to improve the performance of the social construct. First the individuals on the team must be willing to change. While the People Design principle in Creative Solution Finding will help prepare individuals for change, their personal fears and concerns must also be addressed. Once the constraint is identified and a road-map for improvement is developed, the learning organization concepts in the Fifth Discipline are relevant. The right individual competencies must be developed on the team to do the job (Personal Mastery and Mental Models).  The team has to be functioning well together (Shared Vision and Team Learning).  And the Team has to be functioning in a way that is aligned with the goal of the overall system (Systems Thinking).  The primary tool used to influence a social construct to create change and to improve performance is the conversation.

Discussing Big Agile

So the approach is to take the Big Agile capabilities, (1) provide insight to identify when a specific set of capabilities at a level of scaling are the current constraint, (2) leverage the solution finding model and best practices to define/refine the roadmap to move toward,  (3) and then identify the competencies to develop and conversations that are necessary to execute the change.  Then continue the cycle continuously.

This is the Big Agile improvement approach. It takes a model that I have been applying for two decades implicitly and evolving explicitly for the last decade. Clear direction combined with appropriate best practices and an effective adoption approach. All that’s left now is to build out the details of the capabilities, when they are a constraint, how to select appropriate best practices, and the conversations and change approach at each level of scaling for the model.

I have gone to dictionary.com to gain clarity on what it means to scale.  I pulled eight definitions to determine which one we intend.

Scale (skeyl)

1. one of the thin, flat, horny plates forming the covering of certain animals, as snakes, lizards, and pangolins
2. a balance or any of various other instruments or devices for weighing
3. a succession or progression of steps or degrees; graduated series:
4. a succession of tones ascending or descending according to fixed intervals
5. the proportion that a representation of an object bears to the object itself
6. Australian Informal. to ride on (public transportation) without paying the fare
7. Dentristy scal•ing. The removal of calculus and other deposits on the teeth by means of instruments
8. a certain relative or proportionate size or extent

We don’t mean what comes off fish, what we weigh things with, a way of measuring temperature, a musical construct, making a model of something, riding without paying the fare, or cleaning teeth.

So we must mean taking Agile to a proportionate size. That’s to point of the different orders of scaling. That Agile will be expressed differently at each order. But what are we actually taking to a proportionate size? Do we want to have an Enterprise wide stand-up with thousands of people? Do we want to have every job done by two people? What are we scaling?

Small team agile, as guided by the Agile Manifesto for Software Development, is a set of values and principles. Agile, as practiced in many development teams, is a set of management, leadership, and engineering practices resulting in an energized workforce frequently delivering software that meets the emerging needs of the customer. For other definitions of Agile, I went back to dictionary.com.

Agile (aj-ahyl)

1. quick and well-coordinated in movement
2. marked by an ability to think quickly

Well, we aren’t hoping that every person in the Enterprise learns to write code. It isn’t the specific practices that we want to see scale. It is quick and well coordinated movement we see in small team agile. It is the ability to think quickly and respond to emerging customer needs.

What do we mean by scaling agile to the enterprise? We are scaling the benefits of agile – the benefits of an energized workforce frequently delivering value that meets the emerging needs of the customer. We want to take this up from small development teams  so that the entire organization can be more adaptive and responsive.

It turns out that the capabilities (not the specific practices) that make the benefits of small team agile possible can be expressed at each order of scaling. And when layered together, the benefits of agile can be scaled to the enterprise level. Over the next few weeks, I am going to go through the management, leadership, and engineering capabilities of small team agile and discuss how the capabilities scale to deliver benefits at the different orders of scaling.

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.

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