Archive for the ‘Systems Thinking’ Category

kanban and the perfect job

Posted on January 16th, 2011 by Dennis Stevens  |  2 Comments »

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

This is the 5th principle behind the Agile Manifesto. The way this often gets translated is “take the top 10% of developers – put them in a room – and get out of their way.” This is great for the small groups of people that can build teams of entirely top 10% developers.  The question is, what do the other 90% of organizations do?

I believe this is a little chicken and egg. Do we build projects around motivated individuals – or can we design the work environment so that we end up with motivated individuals to build projects around? In the book, Understanding and Managing Organizational Behavior (George, J. M., and Jones, G.R. (2005). Understanding and managing organizational behavior, (4th ed.). Upper Saddle River, NJ: Prentice Hall.) there is a chapter entitled “Creating a Motivating Work Setting”. This chapter discusses the models and research associated with answering this question.

The Job Characteristics Model

In the 1970’s Richard Hackman and Greg Oldham attempted to identify which job characteristics contribute to intrinsically motivating work and what the consequences of these characteristics are. The thought process is that, when employees are intrinsically motivated, good performance makes them feel good – so they strive to achieve at a a high level and good performance becomes self-reinforcing.  Their model, called the job characteristics model, identifies five core dimensions that affect intrinsic motivation:

  • Skill Variety: The extent a job requires an employee to use a number of different skills, abilities, or talents.
  • Task Identify: The extent a job involves performing a whole piece of work from beginning to end.
  • Task Significance: The extent a job has an impact on the lives and work of other people in or out of the organization.
  • Autonomy: The degree a job allows an employee the freedom and independence to schedule work and decide how to carry it out.
  • Feedback: The extent performing a job provides an employee with clear information about his or her effectiveness.

There has been significant research done around this model. It turns out that jobs that are high in these characteristics have the psychological effect of increasing the experienced meaningfulness of work, increasing the experienced responsibility for work outcomes, and increasing the knowledge of results. In return, these psychological states have a high correlation with the job outcomes of high intrinsic motivation, higher job satisfaction, lower absenteeism and turnover, and higher job performance.

This is exactly what we want, highly motivated individuals to build projects around. While the psychological states and the job outcomes are emergent outcomes that we can’t cause directly, Hackman and Oldham have shown that when we design jobs based on the job characteristics model we can improve the likelihood these psychological states and the resulting desirable job outcomes with emerge.

The Motivating Potential of Kanban

When implemented well, Kanban creates a work setting where the job design delivers on the five core dimensions of the job characteristics model.

  • Skill Variety: In Kanban, the team members are involved in the daily planning of their work, engage in discussions around how to get the work done, perform their specific work, and may swarm on other related work.
  • Task Identity: In Kanban, the entire focus is on the flow of work. The team members see the work flow from start to end.
  • Task Significance: One of the focuses of Kanban is to improve the lives of the team members themselves.  The focus on flow of value also helps the team understand how they are improving the the work of the customer and/or the people their organization.
  • Autonomy: Kanban allows teams to schedule their work through the pull mechanism. The self-organizing nature of the work also helps them decide how to care it out.
  • Feedback: Managing Cycle Times, explicitly tracking defects, and the rapid feedback cycles associated with the limited WIP create feedback on effectiveness at multiple levels.

Kanban inherently results in job design that improves intrinsic motivation and the resulting high levels of performance.

Kanban and the Perfect Job

Hackman’s and Oldham’s job characteristic model provides insight into how the work environment can increase job performance. We tend to focus on the benefits that Kanban delivers by improving the flow of work. In addition to improving the mechanics of flow, Kanban also has the potential to result in job designs that are high in all five job characteristic domains.  These result in psychological states that correlate with desirable job outcomes including higher job performance. 

There is a risk in implementing Kanban that we end up focusing on just the mechanics associated with the flow of work. Forgetting that software development is knowledge work would be problematic. But, by leveraging the work environment of a Kanban implementation we can create an intrinsically motivating work environment. Combing improved flow with an intrinsically motivated work environment results in a much more productive organization. Focus on the human and work environment aspects along with the benefits of flow when we implement Kanban to create the perfect job for team members.

Standing By My Agile Claims

Posted on November 25th, 2010 by Dennis Stevens  |  2 Comments »

I recently posted a presentation, Agile Foundations and Agile Myths, at My goal in the presentation is to juxtapose destructive behaviors arising from a predictive approach and destructive behaviors from an agile approach. This is a deliberately provocative presentation – finding flaws with the common interpretation of both sides of the discussion. Glen Alleman over at Herding Cats responded to my presentation in his post More Agile Claims. He took offense to my “strawman” arguments against the predictive approach.

Predictive Approach to Improving Software Development

What I am calling the Predictive Approach addresses the “mental scaffolding” or underlying assumptions I see everyday in companies practicing what they believe they are guided to do in the PMBOK®, OPM3®, CMMI and DoD . The Predictive Approach describes the practices that arise from the overzealous and misguided belief that the following approach is the best way to improve software delivery.

  • Standardize processes
  • Optimize resource utilization
  • Perform rigorous up-front design
  • Produce comprehensive documentation
  • Get up front commitment to a definitive Scope, Cost and Schedule
  • Enforce strict adherence to the detailed plan

This is where Glen takes offense. He points out that nowhere in the PMBOK®, OPM3®, CMMI or DoD literature are we instructed to apply these in the value destroying way that I discuss. In fact, he charges that I am just “making it up.” But, Glen misses the point. I am not arguing about the literature – I agree with Glen’s interpretation. And I am not making it up. Every day I go into companies that are applying this approach in value destroying ways. In the last year I have been in multiple companies whose documented methodologies prescribe:

  • linear-document driven "over the wall" process thinking
  • assigning resources to multiple projects
  • comprehensive upfront design with detailed documentation
  • commitment to definitive scope, cost, and schedule, and
  • strict adherence to precise start and stop dates for individual tasks

I am not debating the literature – it is an issue of practice. Glen suggests in our discussion in the comments to his post that even the government sometimes exhibits this value destroying behavior.  My points aren’t straw man arguments against the literature – they are attacking a common set of misguided underlying beliefs that the value destroying practices arise from.

In fact, the Agile Manifesto itself arose as a response to common practice – not as a set of new practices. As of the writing of the Agile Manifesto, the writers (and many others including Glen Alleman and myself) had been practicing software development in an “agile” way for a decade or longer. Read the agile manifesto as a response to value destroying practice that is trying to bring attention back to what is necessary to successfully deliver software projects.

The Agile Manifesto

  • Individuals and interactions over process and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Approach to Improving Software Development

And now, … the rest of the story.

The Agile literature rails against too much planning, non-value added documentation, misguided change control, de-humanizing linear process, and layers of bureaucracy.  There is clear recognition in this faction that these are value destroying. But the overzealous and misguided application of these beliefs lead to the other common set of value destroying practices I frequently run into.

  • No Planning
  • No Documentation
  • No Estimating or Commitments
  • No Process
  • No PM, BA or QA

Again, I don’t see the core agile literature advising these practices either. Alistair Cockburn, Jim Highsmith, Mike Cohn, Jeff Sutherland and Kent Beck all prescribe effective practices that support appropriate and progressively elaborated planning, documentation, commitment, and process. They all support the roles of project management, business analysis, and quality assurance when they aid in managing complex products. So the second part of my presentation addresses these misguided practices and presents finding a responsible and situation specific approach to delivering software that focuses on responding to change, enhancing flow and delivering value to the customer.

The Core Discussion

Glen’s response highlights an interesting challenge. My suggestion that current project management practices are value destroying brought out a strong response against agile. I have had the same response from the agile community when I suggest that agile beliefs result in value destroying behavior. Businesses need to be able to make informed business decisions – so we need predictability and planning (Check out Glen’s immutable principles). At the same time we need to manage the work in a way that protects and optimizes value. What is missing in many organization’s is a way to have the responsible discussion exploring underlying assumptions. Companies need to finding ways to make the situation specific changes necessary to balance predictive planning and agile execution.

Linked to Strategy

Posted on September 7th, 2010 by Dennis Stevens  |  1 Comment »

What is keeping corporate executives up at night? Is the CxO laying awake wondering if her company is good at project management or software development? Probably not. AMA says that the top issue facing executives is executing their strategy.

“The practice representing the largest difference between higher and lower performers is demonstrating the ability to quickly and effectively execute when new strategic opportunities arise.”
~ AMA, The Keys to Strategy Execution, 2007

So what are the keys to executing strategy? Recent research from PMI shows that when we align projects with the business strategy and clearly communicate the strategy to the team, then projects are delivered at a much higher rate.

“The single most important factor influencing project success is the project’s link to the organization’s business strategy and the project manager’s understanding of how the project supports the business strategy.” 
~ CIO Magazine-November 2009: Business Strategy: The "Best Determinant" of Project Success

So it sounds easy, we need to focus on executing the projects that advance our business strategy. And we need to communicate this strategy across the organization and the project team. How well do the ways that we select projects and communicate their strategic significance accomplish this?

How Do We Select Projects?

So how do most organizations decide where to invest? Projects are selected for the portfolio based on local ROI’s calculated by business managers, or by spreading investment across the organization based on head count like peanut butter, or by charging IT organizations to run IT like a business with departmental reimbursement. Are these the best ways to handle this? Probably not. None of these connect the projects to strategy – and none of these make the connection between strategy and the project explicit.

ROI’s are almost impossible to estimate. Local ROI’s don’t equal organization level benefit. For example, one organization spent $10 million implementing an automated solution to allow them to scale for seasonal demand. The $10 million was justified through service improvement and reduced labor in the department but it shifted significant costs from departmental budget to the IT department for customizations, maintenance, and ongoing licensing. In addition, ROI’s don’t provide an effective way to communicate the underlying assumptions about how the project supports the business strategy.

Spreading investment based on head-count assumes that all improvements are equal or that we can do enough in each area to raise the whole ship. The is no way we can make all the improvements in the organization, there is a limited amount of capacity for change and there is a limited amount of resource to invest. It is extremely unlikely that all problems will result in the same benefit to the business. In fact, this approach, while extremely common, ends up being destructive. It spreads limited resources too thin, it creates excessive demand for the enabling functions (IT, training, project management, support). And it obfuscates business strategy.

Running IT like a business sounds great, but it is another case of local optimization. IT is an enabler of business value. Some of the investments the business needs to make will have short term costs but they will return long term value for the business. When IT is run from the view of short term profitability you will often miss out on the most important investments. In this case, IT’s strategy – making profit from its resources from the business – it not aligned with the business strategy itself.

Based on numerous studies, the leading obstacles to project success are related to scope creep and shifting requirements, inadequate and/or disappearing resources, and a lack of effective executive sponsorship. All of these are related to organization’s trying to execute strategy without a clear alignment between strategy and the projects in the portfolio. Local ROI’s, equal distribution of investment, and local optimization of IT don’t solve these problems. They don’t clearly connect project efforts to the business strategy. And they aren’t resilient to the real changes in the market that businesses have to be able to adapt to.

So What Do We Do?

We need a way to reflect the business model and the where the strategy impacts the business model. We need to be able to clearly articulate what changes need to take place to deliver on the business strategy. And we need to be able to adjust this model rapidly and communicate the real shift in strategy to everyone in the organization easily.

We use capability mapping to achieve this. A capability map, as discussed in an article I co-authored June 2008 Harvard Business Review "The Next Revolution in Productivity" addresses these challenges. It clearly articulates the business model in a stable way, let’s you directly connect the business strategy to the business model, and let’s you connect project efforts to the capability map. This provides traceability from project to business model to strategy in a powerful visual management tool.

Five Steps to a Powerful Capability Map

1. Articulate the Near Term Business Strategy.

We frequently use a model we have developed based on Patrick Lencioni’s “Silos, Politics, and Turf Wars” called a Thematic Goal Model. It is straight forward, powerful, and communicates clearly. We can provide input to this from a SWOT analysis, a balanced score card, or multiple empirical methods like QFD to determine strategic themes. The outcome is a clear statement of a limited set of the near term strategic themes. The next set of “big rocks” that need to move to advance the business strategy. The important thing here is to make it visible and to get buy-in from the organization.

2. Decompose the Business into its Constituent Capabilities.

Decompose the business into the activities or functions of the organization. The activities are performed for a purpose, to achieve some outcome or transformation the business needs to accomplish.  Then, interpret activities as capabilities. Capabilities are independent of how they are done, who does them, and the organizational structure. They are named in a “Verb-Noun” form and express the underlying business purpose. A common mistake is to treat a process, or a “how”, as a capability. For example, “Produce Invoice” is not a capability. The business purpose is not to produce an invoice. The purpose of producing an invoice is to “record a customer charge”  and to “request payment from the customer”.  You can decompose the capability map to whatever level is interesting for your particular situation. We will do a limited drill down to start and then build out a more detailed view as the business strategy dictates. This can keep you from getting stuck in an analysis paralysis. Develop the map collaboratively, you will want buy-in from the organization when it is time to make the tough calls about what to invest in.

3. Evaluate the Capability Map in the context of the Business Strategy.

For each capability you can ask a few questions determine the strategic significance. Is this capability directly related to the business strategy? Would a significant change in this capability directly help the business execute its strategy? This can be an interesting exercise because different people will have different perspectives on what is important. Be rigorous in the assessment. Everything in a business is connected at some level. You are looking for direct relationships between capabilities and strategy. When you get down to determining how to address any interesting capabilities you will get a chance to explore the other related capabilities. Keep bringing the focus back to the strategic connection – not to individual functions. Rank the capabilities on a scale of 1-5 with 1 being directly and 5 being not at all. The capabilities that end up being a 1 or a 2 are strategically interesting.

image4. Determine Performance Gaps at the Strategically Interesting Capabilities.

Now, look at the strategically interesting capabilities. Determine the performance gaps you would need to close to achieve the business strategy. You are not looking to identify every potential improvement at the capability – you want to be specific about what improvement is needed at which capability to achieve the specific business strategy. Again, you have to be rigorous. The goal is to identify the smallest subset of changes needed to achieve the business strategy. Remember, this is a focusing effort.

5. Determine a Road Map to Achieve the Strategy.

Now, you have a very clear set of improvements to focus your improvement efforts on. Drive your portfolio decisions from here. Articulate these as a specific performance improvement, at a specific capability, to achieve a specific strategic outcome.  Initially, all of this is done at a relatively high level. Once you have your specific initiatives you can do more detailed discovery about the best way to accomplish the objectives. Lay these initiatives out across all the enabling functions. You want to balance the efforts against capacity to optimize time to strategic value.


Now we have a way to reflect the business model where the strategic impact is explicit. We can clearly articulate what specific changes need to take place to deliver on the business strategy. This model can keep us focused when we start to get pressure from multiple directions. But we can also adjust this model rapidly and communicate the real shift in strategy to everyone in the organization easily. Better than ROI approaches, better than a bottom up local optimization model, better than running IT as a business, we can focus our efforts on executing the projects that advance our business strategy. We can synchronize efforts across the various enabling functions to optimize time to strategy. And we can communicate this strategy across the organization and the project team. Each activity on every project can be clearly linked to strategy.

My Job is hard, Yours is easy

Posted on August 30th, 2010 by Dennis Stevens  |  1 Comment »

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)

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.

I Signed the Oath of Non-Allegiance

Posted on July 18th, 2010 by Dennis Stevens  |  2 Comments »

I signed the oath of non-allegiance 300dpi.png

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.

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.

Kanban: What are Classes of Service and Why Should You Care?

Posted on June 14th, 2010 by Dennis Stevens  |  6 Comments »

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.

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.

What’s Deming Got To Do With Agile?

Posted on May 21st, 2010 by Dennis Stevens  |  6 Comments »

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.

Deming and the System of Profound Knowledge

Posted on May 10th, 2010 by Dennis Stevens  |  5 Comments »

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.