I really enjoyed Agile 2010 this year. My workshop, “Feeding the Agile Beast”, and presentation, “Using Lean and Agile to Lead Business Transformation”, were both well received. We found good interest in the Agile Extension to the BABOK. ICAgile was a topic of conversation and for the most part we found an appetite for a solid certification model. I also got to spend time with people I consider to be in my tribes. Just to name a few – note: if I fail to mention someone it is not intentional, just tweet me and I will add you to the appropriate clan(s)

• The Agile Project Manager clan: Mike Cottmeyer, Pat Reed, Michelle Sliger, Brian Bozzuto, including ICAgile visionary Alistair Cockburn
• The Kanban clan: Karl Scotland, Chris Shinkle, Eric Willeke, Mike Cottmeyer, and Brandon Carlson
• The Enterprise Agile clan: Alan Shalloway, Dean Leffingwell, Jim Highsmith, Portia Tung and Mike Cottmeyer
• The Agile Business Analysis clan: Pascal van Cauwenberghe, Shane Hastie, Kevin Brennan, Steve Adoph, Ellen Gottesdiener, and Mary Gorman
• The Agile Testing / Quality Assurance clan: Liz Hendrickson and Lisa Crispin

While some of these people, like myself, may have come from coding backgrounds, none of these people are primarily heads down technical resources. All of these people have spent years – some of us decades – improving our craft. All of these people bring deep experience, passion and knowledge to an area that is deeply necessary to deliver Agile projects to organizations.

It isn’t just about code

I was rankled by comments that came out at the end of the conference from people that I deeply respect that there wasn’t enough technical content at the conference. It wasn’t so much the comments as the context that they were delivered in. The troubling perspective was encapsulated in a post that said, “too much of the content was not technical. It was simple content that could be easily understood and digested.” I have tremendous respect for developers. I used be one – and I was pretty good. But about 15 years ago or so I realized that I could create more value in organization’s by removing the organizational constraints that create difficult environments for developers.

When you get beyond pretty small organizations, just writing code is not enough. In fact, without the capabilities practiced by my Agile Project Management, Kanban, Enterprise Agile, Agile Business Analysis, and Agile Testing clans, you can’t deliver value to customers. And the craft of being great at these in organizations is just as challenging, evolving, and important as any line of code anyone ever wrote.

Excuse me, but are you kidding me

Does anyone really think that the work of these clans is easily understood and digested? Getting organization’s to focus on strategy, then translate the strategy into work that can be developed, then coordinate that development across functions, then ensuring that what is needed is what is delivered, and then implementing the changes necessary to ensure the business receives value is not easily understood and digested. As a matter of fact, I think it is at least as interesting and difficult a problem as writing good code. And I think in the context of leveraging Agile software development in organization’s it is just as valuable and not as well understood.

My Job is Hard, Yours is Easy

A common bias in organization’s is the fundamental attribution error. This is also known as the self-serving bias. This manifests itself when people attribute different circumstances to their experience than they do to the experience of others. I see this all the time when coaching organization’s.  People devalue the contribution of others and overvalue their contribution. This attitude leads to bunkering down in silo’s, organizational conflict, and obstacles to improvement and flow of value.

I have written code in an organization. It is hard. But I have also been responsible for business analysis, project and program management, quality assurance, process improvements, training, organizational design, and change management aspects of projects. All of these are important, all of them are hard. Delivering value for the business requires cadence and flow among these disciplines. As you are making assessments of how simple and easily digestible non-technical content is remember this tendency. Just saying, “My job is hard, and yours is easy”, doesn’t make this assertion true. And it results in value destroying behavior.

Alistair Cockburn, in the Oath of Non-Allegiance, has issued a call to action for the software development community to stop bickering and calling out contending methodologies. He has called for “discussion about whether an idea (agile plan-driven impure whatever) works well in the conditions of the moment.” As someone who has earned his PMP, CSM , received certificates from the Lean Enterprise Institute, and who completed David Anderson’s Kanban Coaching workshop – I have had the opportunity to see this bickering up close. I have occasionally even as the target of it.  Here is Alistair’s call to action:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

This is becoming an increasing familiar theme. We see it in Laura Brandeburg’s Business Analyst Manifesto. It is expressed by by Liz Keogh, Jean Tabaka and Eric Willeke in “A Community of Thinkers”. I am involved in a PMI Agile team where we are trying to make sense out of the benefits associated with bringing together the PMI Body’s of Knowledge (Portfolio, Program, and Project) in the context of Agile. I am working with the IIBA’s Agile Business Analyst core team to express the Business Analysis Body of Knowledge in an Agile fashion. I also participate in various Yahoo and Google groups where we are working at having these kinds of conversations involving Kanban and Lean.

These teams and discussion groups bring together practioners and thought leaders from various communities working to understand and to share. Sometimes the discussions get heated. You have a lot of successful, intelligent people sharing their experiences and trying to make sense out of their successes while simultaneously trying to expand their world view. The awesome thing is that there is a lot of learning and connecting going on in these communities.

You may want to protect your turf -  but this is the future. The tools and resources that support software development have improved orders of magnitudes in the last two decades. It’s crazy to believe we don’t have a long way to go to figure out the best ways to deliver software – especially at the enterprise.  Tom Peters quotes General Eric Shinseki, Chief of Staff, U.S. Army – “If you don’t like change, you’re going to like irrelevance even less.” I choose to join the community who is looking for ways to honor the fundamental premise of the Agile Manifesto – We are uncovering better ways of developing software by doing it and helping others do it.

Back 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.

My last post, Kanban and When Will This Be Done? was about using Cycle Time to make reliable commitments to the customers of your organization. I talked about prioritizing and swarming as methods of helping meet your Cycle Time commitments. In most organizations, it turns out that not everything has the same level of value or time pressure. Some things need to move through faster than others either because they are needed to meet customer promises or because earlier delivery means more income for the business. Some have to be completed before a specific date due to market or compliance or integration reasons. Still others can be completed in the normal course of the flow of work.

So, we can’t treat everything in a homogenous fashion. But, handling the planning and scheduling to meet the differing levels of time pressure can consume a lot of time and energy. The key is to create a simple and transparent approach for the team to self-organize around the work to meet the needs of the business. This approach should address the inherent variability in the work. The way that we address these differing levels of time pressure is through Class of Service. Class of Service is a mechanism for typing work items and is used to inform team decisions about prioritizing and swarming.

Class of Service Policies

Each Class of Service will have its own policy to reflect prioritization based on the different risks and business value. Classes of service and knowledge of the policies associated with them empower the team to self-organize the flow of work to optimize business value. Used effectively this will result in improved customer satisfaction, elevated employee engagement, and increased trust. A Class of Service policy will include the following for the class of service:

• how to make the class of service visible,
• the impact this class of service has on WIP limits,
• prioritization and swarming agreement for the class of service,
• estimation requirements for the class of service.

You can use the use card color or a row to visualize the class of service. The row is particularly useful when you are reserving some performer capacity to the class of service. The WIP limit policy may allow for the work item to exceed the column WIP limit, could reflect that there is a maximum of a particular Class of Service, or require a minimum of a Class of Service. Prioritization can include FIFO, Pull Next, or Interrupt Current WIP. Estimation can range from no estimation to a detailed estimate.

Sample Classes of Service

These Class of Service examples are drawn from David Anderson’ book, Kanban: Successful Evolutionary Change for Your Technology Business and personal experience.

Expedite: The Expedite Class of Service can be very disruptive to flow. So I use a lane to protect some capacity against these disruptions and then limit the number of expedites was can have on the board at a time. This allows us to expedite while minimizing the impact on the other Classes of Service. In his Kanban book, David suggests swarming on blockers only. I believe you can swarm on delayed items and expedites, especially if you have left some performer capacity available when you set your WIP limits. This helps maintain the flow through your system.

Many organizations experience a large amount of expediting.This is a sign of low trust in the organization’s ability deliver reliably. So the emotional response is to expedite everything. In my experience, demonstrating an ability to make and keep commitments for the Standard Class of Service will establish trust that overcomes this emotional response. The pressure to expedite decreases dramatically when you are able to make and keep commitments to your organization.

Sample Expedite Class of Service policy:

• Expedite requests will be shown with white colored cards.
• Expedite requests have their own row on the Kanban board. The Expedite row has a WIP limit of one.  A limited amount of performer capacity is reserved for Expedites.
• The column WIP limit can be exceeded to accommodate the Expedite card.
• Expedite requests will be pulled immediately by a qualified resource. Other work will be put on-hold to process the expedite request.
• Expedite requests will be T-Shirt sized to set Due Date expectation.

Fixed Delivery Date: The Fixed Delivery Date Class of Service is used when something has to be delivered on or before a specific date. To accomplish this, you will pull the card from the first queue sufficiently in advance of when it needs to be delivered. In the previous post, we suggested you set the policy at the Mean + 1 Standard Deviation. This will result in an 80% likelihood of success. This is likely to be an unsatisfactory success rate. So you will want to do two things. First, increase the policy for Fixed Delivery Date Class of Service items from the Mean + 1 Standard Deviation to the Mean + 3 Standard Deviations. This will increase likelihood to above 99%. Secondly, you should do some more detailed analysis when making this work ready to mitigate the risk that you will deliver this late. If the item is large it may be broken up into smaller items and each smaller item should be assessed independently to see whether it qualifies as a fixed delivery date item.

There is a significant opportunity to misuse this Class of Service when dealing with an organization that is comfortable with a traditional plan driven approach to managing a project. There is a tendency to want to use the Fixed Delivery Date in the same fashion as the tasks on a Gantt Chart. The problem with this is that it will spawn the same destructive behavior that we discussed in my last post (losses accumulate, gains are lost). So only use the Fixed Delivery Date when you have an external due date constraint. Remember the concept of Regression to the Mean and use the Standard Class (discussed next) and flow to deliver to a plan.

Sample Fixed Delivery Date Class of Service Policy:

• Fixed delivery date items will use purple colored cards.
• The required delivery date will be displayed on the bottom right hand corner of the card.
• Fixed delivery date items will be given priority of selection for the input queue based on a the historical mean + 3 standard deviations of the cycle time for tasks of the same size.
• Fixed delivery date items will be pulled in preference to other less risky items. In this example, they will be pulled in preference to everything except expedite requests.
• Unlike expedite requests, fixed delivery date items will not involve putting other work aside or exceeding the kanban limit.
• If a fixed delivery date items gets behind and release on the desired date becomes less likely it may be promoted in class of service to an expedite request.

Standard: The Standard Class of Service is used for the typical work that goes through the system. The mechanisms of flow and focus will move the work through the system as fast as it can be done without disrupting the system. Large Standard Class of Service items may broken down into smaller items with each item queued and flowed separately. Standard Class of Service work should be pulled into each queue on a First in First Out basis. Estimating Standard Class of Service items beyond T-shirt sizing doesn’t add any value (although even t-shirt sizing could be argued is not adding value) – if it is work you are going to do then you should go ahead and do it.

Sample Standard Class of Service Policy:

• Standard class items will use yellow colored cards.
• Standard class items will be prioritized into the input queue based on their cost of delay or business value.
• Standard class items will use First in, First out (FIFO) queuing approach to prioritize their pull through the system.
• No estimation will be performed to determine a level of effort.

Intangible: The Intangible Class of Service is used for work that goes through the system that doesn’t directly deliver value to the customer. These are items like production bug fixes, retiring technical debt, usability improvements,or branding  and design changes. This is work that needs to be done – but for which it is hard to show an ROI. It is a good idea to have some Intangible work going through the system. It is better to set this aside when an Expedite comes through then work with an associated due date or cycle time expectation. I like to set a policy that at least one intangible item is moving through the system. Again, the Intangible Class of Service items may be broken down into smaller items with each item queued and flowed separately.

Sample Intangible Class of Service Policy:

• Intangible class items will use green colored cards.
• Intangible class items will be prioritized into the input queue based on their intangible business value.
• Intangible class items will be pulled through the system regardless of its entry date so long as a higher class item is not available as a preference.
• No estimation will be performed to determine a level of effort or flow time.

Why Do We Care About Classes of Service

Not all work has the same value as it moves through the system. Additionally, there are varying levels of time pressure on the items moving through the system. Planning and Coordinating all the possible impacts would be very difficult. Classes of Service create a simple and transparent approach for the team to self-organize around the work to meet the needs of the business. As each performer is looking to pull their next item into their queue, they scan the candidate items. In the sample above, they would first pull an Expedite if one existed. If not, and there was a Fixed Delivery Date item that needs to be started soon to meet the Fixed Date then they would pull that. If that doesn’t exist they could either pull a Standard Class of Service item or, if there aren’t any intangible class of service items active on the board, they would pull an intangible on the board.

Using Classes of Service to prioritize pulling and swarming results in an easy to sustain system that self levels risk and value optimization. It inspires flow behavior, empowers the team, increases employee engagement and optimizes the value produced by the system. Classes of Service also create transparency into the promises made to the customers and increases the reliability of promises being kept resulting in higher trust across the organization. So, we care about Classes of Service because, for a minimal investment, they increase value, balance risk, improve reliability, increase employee engagement and increase trust within the organization.

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.

When I show the Kanban board, a tool that is borrowed from Lean,I hear,

“Well, software development is an artistic process – you can’t apply manufacturing principles to it.”  

Or, “I was involved in a Six Sigma (or TQM) project that was devastating – Lean doesn’t translate to software development.” 

Or, “Analysis, Development, Acceptance, Production – that looks like waterfall, haven’t we gotten past waterfall yet?”

So let me be clear up front – some amount of software development is creative, you can’t directly apply manufacturing principles to software development, applying Six Sigma and TQM to software development like it is a production line is destructive, and in most cases waterfall doesn’t make sense in software development.

Deming is About Culture – Not Manufacturing and Not Process

But Deming is not about manufacturing. He is about showing management how to create an environment for success. Deming is about culture – and his System of Profound Knowledge creates an environment that is especially effective for knowledge work. As I discussed last week, Deming’s System of Profound Knowledge has four points: 1. Understand the System, 2. Understand Variation in the System, 3. Have a Theory of How to Act on The System, and 4. Understand Human Psychology. How does Kanban help us inform the context and culture of the team performing development to achieve the benefits associated with Deming’s System of Profound Knowledge?

What Does it Mean to Understand the System?

By understanding the system, participants can operate in a way that everyone (management, performers, customers, and suppliers) benefits. Understanding the system is difficult – typically everyone views the system from their own siloed perspective. Understanding the system requires that everyone rise above their siloed perspective to understand the system goal, what the organization does to achieve this goal, the boundaries and constraints, and the sensing and  feedback mechanisms.

Kanban helps participants understand the system by making the goals, capabilities, and boundaries explicit. The participatory nature of developing and interacting with the board changes everyone’s perspective from a siloed view to a focus on system level success. The board itself, metrics such as the CFD, the establishing of policies and tracking of.performance against those policies provides feedback on the system.

How do we understand the impact of variation?

Variation is inevitable. The size of work that needs to be done isn’t uniform. The complexity of work has high variability – not just between work items – even between the types of work to be performed on each work item. For example, one item may be hard to analyze but turn out to be easy to build and test. Another may be easy to design and build but very difficult to test. It is common on teams for there to be a significant gap between the most skilled developers on the team and the less skilled developers. So the work is of various sizes, with various levels of complexity, being worked on by various levels of performers.

Kanban helps with this in three ways. First, limiting WIP reduces the overall impact of variation on the system. Second, the Kanban board makes the impact of variation explicit. One a daily basis the team can work together to allocate themselves to adjust to variation in real time by swarming or influencing what they pull. Finally, by managing the average lead time – and not trying to manage exact lead times of every item – Kanban helps smooth the impact of variation on the promises (SLA’s) make to the business.

Theory of Knowledge or “What are you prepared to do about it“?

Using the information you gain from your understanding of the system and insight into variation on the system you apply PDSA. You will see this expressed as PDCA (Plan, Do, Check, Act) or PDSA (Plan, Do Study, Act). I like to use Plan, Do, Study, and Adjust. Plan-Do is typical management – this means take specific actions that you hope will achieve a specific result. An expectation of Study-Adjust allows the organization to learn rather than blame.  A culture of continuous improvement emerges where PDSA is practiced.

Kanban delivers a platform where the organization can practice PDSA. Through metrics, operations reviews, the Andon, and potentially retrospectives provides the ability to make a hypothesis about the system (Plan). Then they can make policy, process or organizational changes with the intention of achieving an improved outcome (Act). The system will expose whether the desired outcome is achieved (Study). Then the team can learn alter their theory of knowledge and adjust their actions. The transparency of Kanban helps develop our theory of knowledge and gives us courage to act on the system.

How does Kanban impact Human Psychology?

Employee engagement is a key to the successful performance in organizations. Organizations with high employee engagement have a much higher rate of employees who show a strong passion for their work and a commitment to their co-workers. Therefore it is not surprising that organization’s with higher levels of employee engagement also have higher levels of employee productivity. Employee engagement arises when employees believe they positively impact the quality of the organization’s products.

In knowledge work, where products are invisible, impact can be difficult to demonstrate. Kanban clearly shows progress and demonstrates the contribution of each person to the delivery of value. Additionally, PDSA provides opportunities for everyone to contribute to improving the quality of the organization’s capabilities. By breaking down silos and creating insight that results in employee engagement, Kanban leverages human psychology to help organizations transform and mature.

Kanban supports Deming’s System of Profound Knowledge

If you equate Kanban with manufacturing you won’t be successful. You need to understand what Deming has to say about knowledge work and how management is responsible for creating an environment for success. Kanban brings an easy to implement – low friction implementation of Deming’s philosophy.  Implementing Deming’s System of Profound Knowledge through Kanban is a proven method for achieving higher levels of maturity and improved performance.

Knowledge work, such as software development, is becoming a critical element of the success of every business. It follows that getting better at knowledge work is important to improving the performance of those businesses. There is a powerful model that has been broadly applied to achieve success in knowledge work. I believe it gets overlooked because of its association with manufacturing and TQM.

A Little History

In 1960, the Prime Minister of Japan awarded Dr. Deming Japan’s Order of the Sacred Treasure, Second Class citing Deming’s contributions to Japan’s industrial rebirth and its worldwide success. Deming is widely credited with improving production in the United States during the Cold War, although he is best known for his work in Japan.

Deming did not teach statistical process control. Upon arriving in Japan to present to the Japanese Union of Scientists and Engineers (JUSE) (His first talk was July 10, 1950) Deming introduced an eight day course with these words “The Control Chart is No Substitute for the Brain”. He had assistants teach the statistical control of quality portion of the course. Deming taught the theory of the system and cooperation (The World of W. Edwards Deming by Cecelia Kilian).

He taught 29 seminars between 1950 and 1951, reaching essentially every essentially every single top manager in Japan. He taught his four-day course to over 200,000 American executives between 1980 and 1991. Again, he didn’t teach statistics – he taught how to derive knowledge about the system from data and how management should act on the organization as a system. He didn’t teach manufacturing at all – his goal was to transform the management of organizations. He believed mis-management was solely responsible for the dysfunction in organizations.

TQM is not The System of Profound Knowledge

Deming is often associated with TQM. And while TQM claims Deming, Deming did not claim TQM. From Deming’s biography:

It is very common, and sadly, very wrong, to hear comments on Deming’s work that sound like “It’s SPC,” or “It’s about the 14 points.” Others think about it as team and teamwork. Some think of it as some sort of humanitarian stuff. The one that upset Deming the most was “It’s about TQM,” referring to Total Quality Management. He did not want his name to be associated with TQM, as aware as he was of the risk of “guilt by association.”

The Japanese applied his teaching to manufacturing. He taught the same information in the 80’s in the US. A critique of US adoption of these techniques was that our objective was to replicate the Japanese manufacturing success and all we heard was statistics and process control – we missed the points about how understanding creates knowledge and how to manage human nature – therefore we missed the transformative nature of his message. TQM embodies these shortcomings. TQM fails because it is time consuming, generates a level of detail that is not stable or valid, is not organizationally sustainable, and is very expensive to implement. The focus of TQM is data – Deming’s focus was on effective management.

Deming’s System of Profound Knowledge

Deming believed that generating a shared understanding of the system, taking actions that optimize economic outcomes, and aligning the beliefs of the people within the system were keys to a sustainable ongoing improvement effort. Deming taught this as the System of Profound Knowledge (SPK). There are four points to SPK:

1. Appreciation of the system: For Deming, the organization is a system – a network of interdependent components that work together to try to accomplish the aim of the system. The system includes management, staff, suppliers, and customers. Without an aim there is no system. Understanding the system and the aim of the system helps us rise above complexity.

2. Understand how variation impacts the system: Understand the intrinsic capacity to supply the output required in the face of variation. Deming understood that variation was a phenomenon common to all human activities – particularly in knowledge work. Understanding variation equips us with the conceptual basis for correct management of performance and the improvement of capacity.

3. Theory of Knowledge: A theory of knowledge explains how a combination of methods, people, and environment produces a foreseeable change. Knowledge isn’t data. Knowledge is the ability to interpret and act on the system – by management, by the staff within the system, by suppliers, and by the customers. Knowledge of the system arises from within the system itself. Deming taught management how extract knowledge – not how to perform statistical process control.

4. Psychology: Psychology helps to understand people and their behavior and to appreciate their natural inclination toward success, learning and innovation. People respond based on the norms and rewards in their environment. When we make organizations hierarchical people act to defend their space in the hierarchy. When we create a system wide understanding people act to improve the system’s performance.

Impacts of SPK Thinking

Deming felt that managing to cut costs almost always decreases performance and increases costs – while managing the system to allow quality to emerge will reduce costs and increase performance. This is because a focus on cutting costs locally creates a toxic and competitive environment. Deming believed that workers have nearly unlimited potential if placed in an environment that adequately supports, educates, and nurtures their sense of pride and responsibility. He stated that the majority of a worker’s effectiveness is determined by his environment and that the malfunctioning of an organization is almost entirely due to the misunderstanding of the system by management. The System of Profound Knowledge dramatically shapes the way we think about work and workers.

This post is going to go back over the past month’s posts and bring them together into a model I can use to discuss Big Agile. I took me a while to noodle this out so I haven’t posted in over a week. This approach is based on over two decades of improving performance in development organizations. The last decade has been spent working to explicitly articulate what I’ve done to consistently deliver results. It is amazing how much you learn when you take concepts practiced unconsciously and write them in a (relatively) concise format.

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.

In 1984, Eli Goldratt first published The Goal: A process of ongoing improvement. The book describes the Theory of Constraints, a method for managing systems. It is based on the concept that at any time in a system there is one (of very few) bottleneck(s) slowing down the performance of the system. Performance is measured based on three variables. Throughput measures the units delivered to the consumer of the system. Operating expense is investment into the system to ensure its operation on an ongoing basis. Inventory is investment into the system to produce.

The Goal is to make more money now and in the future in order to meet the expectation of stakeholders and ensure the business continues to operate.  You increase profit by combinations of increasing throughput while decreasing the ratios of operating expense and inventory against throughput. A key first step to accomplish this is to reduce inventory – or work in process. This will improve cash flow of the organization. Reducing WIP has the added benefit of exposing the bottlenecks in the system. Exposing these bottlenecks is the key to implementing POOGI (Process Of OnGoing Improvement). Goldratt provides five focusing steps to follow to help achieve the goal.

Five Focusing Steps

Identify the limited number of current constraints: At any point, there is a single point in the system that is the current bottleneck. For example in Agile development teams, it may developer productivity or a testing person.  The way that you will identify the constraint is that it is the person where work is piling up in front of them and where downstream resources are starved for work. In the figure below the constraint is B. Work can only get through B at 3 units per unit of time. Since A is more productive work will pile up in front of B and C will be starved for work.

Two important concepts need to be presented here. The first is that the team of ABC can’t produce work any faster than the bottleneck, B. So the consumer is only receiving 3 per unit of time. The second really important concept is that A, B, and C don’t have to be different people, they can be state transitions of a piece of work. In an Agile team, A might be understanding the requirements, B might be develop and unit test the code, and C might be integrate and acceptance test. On an Agile team, everyone is involved in all the states, it is the work that is moving through various states.

Make sure output from the constraint is not compromised. The second step in the five focusing steps is to recognize that the work done at the bottleneck is precious and must be exploited. So focus on making sure that none of B’s work is wasted. In our Agile example that means improving the quality of how work is communicated in the transition from A to B. It also means focusing on quality at B so that C is able to use everything produced by B.  Doing this step will result in improved performance of the system.

Subordinate the system to the bottleneck. This means slow down the work at A. While this might seem counter-intuitive B can’t work any faster than it can work. Often, manager’s focus on improving utilization rather than throughput and this focus actually exacerbates the problems. Producing more and more inputs to B creates stress on the people in the system, makes the system more difficult to manage, and increases the likelihood of waste at B. In our Agile example, A can spend more time clearly communicating what needs to be built and less time producing more detailed stories. A may consist of meetings where stories are communicated, estimated, and prioritized. On our Agile team, it is consuming time from the team that could be spent at A. So do less detailed estimating and prioritizing in each cycle. The effort is better spent at B.

Elevate the constraint. In many organizations, when the effort is to elevate performance of a system (or team) investment is made to elevate the entire team.  In our example above, that may mean adding more subject matter expert resources as well as more testing resources. But the only benefit to improving throughput of the team in our example is to increase at B. Elevating the constraint can happen through improving the capabilities at B or shifting more manpower to B. In our Agile example above, it may be better to shift one of the testing people to focus on development. Even if they are initially not as productive as the top developers, they will contribute to elevating the constraint without damaging the throughput of the team.

After the system has stabilized go back to the beginning and identify the constraint. The final step is really to not let inertia become the constraint. Remember, this is POOGI – a Process Of OnGoing Improvement. You don’t go through the process once – you go through it continually.

Theory of Constraints and Big Agile

This model is very interesting because if provides a thinking process for focusing efforts on the next most important problem. If our Agile team example above, if this model is not kept in mind by the team, they may spend time putting in a cool new CI environment – but unless that environment raises the constraint at B it will not result in an improvement. So it isn’t the next best place to focus. The other interesting thing about this model is that it scales up through the organization through the orders of scaling. If you haven’t read The Goal and Goldratt’s other writings you need to get this model into your thinking toolkit.

Today, I am looking at the Learning Organization model Peter Senge presents in “The Fifth Discipline”. This model is interesting because there are strong corollaries between the way effective Agile teams form and the Learning Organization. The book is called the Fifth Discipline because it describes five disciplines that build on each other: Personal Mastery, Mental Models, Shared Vision, Team Learning, and the Fifth Discipline is Systems Thinking.  I am going to briefly describe each discipline and how they apply to the Agile Enterprise.

Personal Mastery

Senge says Personal Mastery “goes beyond competence and skills…it means approaching one’s life as a creative work, living life from a creative as opposed to a reactive viewpoint.” In Agile, this means being very good at what you do. If you code, you should aspire to be a great coder – but not just a coder. Great Agile teams depend on Generalizing Specialists.  This means that you have one or more specialties, you have general knowledge of product development, you have general knowledge of your  business domain, and you actively aspire to improve your specialization while broadening you general knowledge.

Personal Mastery doesn’t just apply to development. It applies to all aspects of the business. Seeking personal mastery improves the performance of the team in two ways. First, each individual is competent to perform their job. Second, they are better able to understand and meet the needs of the people they work with.

Mental Models

Mental Models are a way to describe a person’s intuitive perception of the world around them.  We make decisions in order to achieve some result from the options we perceive based on our Mental Models. Learning occurs when we observe the result of our decision in the real world. If we don’t get the result we want, we will try something different. In Agile we call this Inspect and Adapt. Because you can represent this as a cycle it is also known as single loop learning.

One of the key challenges to successful adoption of Agile is changing Mental Models. This is because many Agile principles aren’t intuitive or are counter to traditional management approaches. Some of these initially counter-intuitive principles include:

• Starting more stuff faster means you will finish more stuff later.
• Striving for perfect definition up front is going to slow down delivery.
• Don’t build everything that might ever be needed right now – only build what you will need today.
• More testing speeds you up.

Changing Mental Models creates new possibilities and allows us to make better decisions. We allow the results to influence our Mental Model and not just the next decision. When learning influences our Mental Model we call this Double Loop Learning. Personal Mastery can bring in outside influences and open our eyes to improvements in our Mental Models.

Shared Vision

Shared vision describes the common understanding the team has of where they would like to be and how they would like to interact in getting there. This shared vision exists whether the team makes it explicit or not. It can just be assumed from the larger organization or it can be intentionally managed by the team.  Intentionally developing a shared vision, or shared Mental Models, about how to work together effectively and what needs to be delivered to the customer is a powerful approach to improving team performance.

In Agile, many of the practices support creating an effective shared vision. The product vision, release schedule, and backlog create a shared understanding of where the team is going.  Frequent delivery, continuous integration, daily sprints, focus on quality, co-location, and constant customer interaction all support a shared vision of how to deliver.

Team Learning

Team Learning is the next step after Shared Vision. In Team Learning, the team works together to improve their ability to achieve the Shared Vision. Individual Skills may have to be developed. Mental Models regarding how teams perform may have to be changed. The Shared Vision may be updated as the team acts and responds to feedback based on their efforts.

Agile has a number of feedback tools and learning opportunities built in. Burn-down charts, Swarming, Transparency, Sprint Reviews, and Retrospectives represent things Agile teams use to learn how to improve their collective abilities. In Agile we call Team Learning self-organization.

Systems Thinking

Systems Thinking is a framework for understanding that the component parts of a system can be better understood in context with each other, rather than in isolation. A core concept of systems is interdependence, the concept that the actions of any component have the potential to impact other components.

In Agile, the concept of interdependence is used to overcome the linear nature of Waterfall and over-specialization.  Rather than isolate requirements, design, development, and test into separate functional teams, Agile recognizes the interdependence and brings all the skills and competencies necessary to deliver product onto a single team.

Systems Thinking and the Agile Enterprise

Systems Thinking and the Agile Enterprise is very interesting. First, because it gives a model to follow for developing individuals and then teams into a functioning Learning Organization. Unlike software development models, Learning Organization efforts are written by people specializing in change management. So there is a substantial body of knowledge about creating this type of change up to the Enterprise level.

Secondly, development is just one component of the larger Enterprise system. Getting better at software development doesn’t always result in an improved delivery of value to the customer. There is a lot to learn through applying Systems Thinking as a problem solving tool in establishing the Agile Enterprise.