Posts Tagged ‘Project Conversations’

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.

Kanban and Conversations

Posted on June 1st, 2010 by Dennis Stevens  |  2 Comments »


Kanban and conversations seem to be a hot topic recently. Jared Richardson with Pillar Technology had a nice post last week to remind us that a key to Agile is individuals and interactions over processes and tools. The next day, I had a twitter conversation with @paul_boos about how Kanban can facilitate these conversations. Pascal Pinck published a nice post that summarized our email exchange on the role that Kanban plays in influencing conversations and relational flow. Finally, @ronjeffries had this tweet on Friday,

“@alshalloway almost all well-coached "agile style" methods work consistently. at base i think it’s because [wise] inspect and adapt works.”

This recent flurry of activity confirms the core basis of my focus on Project Conversations for the last decade – Getting better at software product development is about getting better at the right conversations.

What conversations?

Knowledge work projects require inspect and adapt by everyone on the team. And not just inspect and adapt on the software we are delivering. We have to Inspect and adapt around every aspect of the project like; the technology we are are applying, the processes we use to perform the work, what our customers want, how people work together, and how we gain a better understanding of the delivery of business value.

Inspect and adapt takes place through conversation. Conversation is the use of language to exchange thoughts, ideas, and information. Knowledge work projects, like software product development, are performed through conversation. The three primary things we need to converse about to accomplish a project are Understanding, Forming, and Doing.

Understanding conversations include:

  • conversations about the purpose, goals and targets of the project;
  • sharing and resolving concerns about the nature and direction of the project;
  • investigating the background, risks, and current conditions surrounding the project;
  • and analysis of ways to achieve the goals and targets. 

Forming conversations include:

  • establishing or ascertaining the enrollment of stakeholders on the project;
  • exploring and evolving situation specific solutions to achieve the goals of the project;
  • planning the activities and responsibilities required to implement the solutions;
  • and coordinating the flow of activities.

Doing conversations include:

  • assuring the team or promising to stakeholders to work toward accomplishing something;
  • communicating the status of our ability to meet the promises of our work;
  • declaring something complete and accepting that something is completed.

Conversation Flow

Think about the flow of conversations through a project. Then apply Lean values to this flow of conversation: Reduce Waste, Improve Flow, and  Reduce Unreasonableness. Not having the right conversations in the right order at the right time leads to challenges on the project. For example, you can’t make a promise on doing something until you have had appropriate understanding and forming conversations. This will lead to waste in the form of rework (not to be confused with iteration) and it is unreasonable to expect people to make promises without having already addressed understanding and forming.


You also can’t have some conversations too early in the project. By the time the team gets around to applying an early understanding or forming conversation to a doing conversation, it is likely that what was learned in the understanding or forming conversation is outdated. This is waste in the form of excessive ideas in process which lose value with excessive waiting – waste that reduces flow and leads to unreasonableness in the project.


Gordon Pask, whom the Pask Award is named after, developed Conversation Theory. One of the key ideas in conversation theory is how our internal conversations and way we are participating impact the way we make meaning in a conversation. We create barriers to conversation flow when we aren’t paying attention or when we hold other participants in an unflattering light. For example, I have seen teams that will reject all input from the project manager assigned to support the project because of the feeling the project manager is meddling – she isn’t view as a part of their team.

imageKanban and Conversations

One of the things that I find frustrating in the “we need better communications” solutions offered to many teams is the lack of pragmatic application. Improving conversation flow is a pragmatic way to deliver on better communications. A solution to improving conversation flow has to meet three criteria. First, create an environment for effective conversation. Second, scale that environment beyond the small team to larger programs, even to the enterprise. Third, clearly couple conversation flow with the flow of work. Kanban (or as @ronjeffries points out, potentially any wise implementation of inspect and adapt) helps address these aspects of conversations flow.  Kanban’s daily standup and the after meetings is an approach that accomplishes all three criteria to establish effective conversation flow.

The Daily Standup and the After Meetings

In the Daily Standup the focus is on the work. So we don’t ask every person the three questions – we talk about the work. By walking the board right to left the team identifies blocks, next steps that need to be coordinated, and other opportunities for conversations. We have someone scribe the conversations that need to take place – trying to keep our focus on just those conversations that need to take place to improve the flow of work. I like to use a white board at the back of the room to list these conversations during the daily stand-up. Then have everyone bring access to their calendar to these meetings. The team takes responsibility for either having the conversation in an after-meeting, putting the conversation on their calendar, or setting up time to have the conversations. As conversations are performed or scheduled they are erased from the white board at the back of the room. Within a few minutes following the after meeting the list of meetings have been erased and the team is back at work – having optimized the conversation flow in the context of the work flow.

So Kanban helps deliver on all three criteria. First, Kanban helps us hold each other in a appropriate light – the focus on the system and the work in the system changes the way we participate. Holding each other in the light of a common interest with a clear outcome in mind results in an environment for effective conversation. Second, the Kanban board itself scales horizontally beyond the small team up stream and down stream – as well vertically up to the program and portfolio level. Third, Kanban helps with the flow of conversations by helping make it clear when we need have each conversation in the context of the current work in progress.

Kanban helps us get better at software product development by helping us get better at the right conversations. Combining the visualization of work provided by the Kanban  board with a Daily Standup and the After Meetings that are focused on the work – and not on individuals – are a pragmatic way get better at the right conversations.

Project Conversations-Shared Understanding

Posted on December 28th, 2009 by Dennis Stevens  |  No Comments »

Most of the studies that discuss failed software development projects find misunderstood requirements and inadequate change management among the leading causes of failure. These failures can’t be adequately addressed just through more rigorous documentation or web based tools. Generating shared understanding is a social act – therefore, one of the elements of improving requirements is through improving the related social interactions or conversations.

But how do we go about improving conversations? Where are the engineering practices or process improvement techniques we can apply to consistently achieve improved performance? John Searles has written several books that break down conversations into a series of speech acts and even has a notation for describing a conversation. I found Searles work on Speech Acts to be very interesting. There is value in classification and understanding of patterns in conversations. But I am not sure this translates to an easily digestible approach. I also believe that conversations have flows and states, but I am also not sure that a process flow is an effective way to represent a conversation. image

I can’t break the process of the flows and states a cake baking in the oven goes through down to detailed steps. I can tell you when it might be appropriate to bake a cake, when we are ready to put the cake in the oven, what happens during the baking process, and I can tell you how to check to see if a cake is done. So the approach I am advocating here is to be able to know when a specific conversation is called for, what it takes to be prepared for a conversation, how to approach the conversation, and how to check and see if the conversation has been performed.

Conversations for Shared Understanding

A conversation for shared understanding often involves one person on the project learning something new from someone else on the project. Conversations for shared understanding are important between different functional groups and when defining expected outcomes. For example, requirements documents define what needs to be done on a project. The requirements documents by themselves are typically not adequate. The gap in understanding leaves room for the development organization to build something that is not optimal either from a development or a requirement standpoint.

I love college football. One Saturday when I first got married, I was watching a game on TV. I planned to head over to my friend Steve’s house later in the day to watch the afternoon game. My wife called down from upstairs to ask me to take out the trash. I agreed to do it, thinking I could grab it out of the kitchen on the way out the door after the current game before I went over to Steve’s house. Her context was very different from mine. She meant, right now – all the trash in every room of the house – and clean the bathroom’s while you are at it. So, while I agreed to her requirements, we didn’t have a shared understanding of the request.

When is a Conversation for Shared Understanding called for?

Anytime a lack of shared understanding slows down the project or creates rework or other waste. A lack of shared understanding happens all the time in projects – particularly between functional groups and early in a project. So a conversation for shared understanding is important early in a project. Typically, these early conversations should be around the overall context and objectives of the project. A conversation for shared understanding is also called for with each specific feature or request. On software development projects it is important everyone involved in delivering, verifying, or accepting a feature or project deliverable has a shared understanding. Conversations for shared understanding should be at the outcome and context level. They are not intended for the technical implementation details to be explained to business stakeholders. The point is to establish context and understanding of the outcomes necessary to optimize the performance of the project performers.

What does it take to be prepared for a Conversation for Shared Understanding?

The mood and perspective of the participants in the conversation will impact the ability to successfully perform these conversations. So each participant must have an intention to have a conversation that results in a shared understanding. They should be willing to put in the effort to review or understand any artifacts produced to seed the understanding. They must bring a belief that the other person’s context matters. Additionally, participants need to put some thought into the boundaries of the conversation. The performer will want to think about what they need to understand to be most effective in delivering this request. The requestor will want to consider what parts of the context, what outcomes, and what language is particularly important to ensure they get what they intended to ask for.

How do we approach a Conversation for Shared Understanding?

  1. The participants present their expectations and boundaries for the conversation.
  2. Each participant explains their understanding of the context, targeted outcomes, and significant language. The other participant(s) will note where their understanding varies.
  3. The discrepancies should be discussed, evaluated and resolved. Sometimes, the details of one participant will not be important. Sometimes, more specific discussion is necessary to gain clarity.
  4. The participants will agree when they have a shared understanding.

How can we check to see if the Conversation for Shared Understanding has been successful?

At the end of the conversation the participants should be able to present an understanding of context and outcomes in common language. As soon as either participant identifies a gap in understanding they should revisit the conversation. Over time, the participants establish a common background that reduces the effort required to establish a shared understanding.

Today, when my wife asks me to take out the trash I understand what she wants. We also have identified when it may be important to have a conversation for shared understanding. For example, when she sends me to the store for milk I ask her to take a minute and think about what else I should get while I am there. My experience is that she has a lot of background information that I am not aware of. If I go to get milk and don’t get the eggs and butter she needs I will be heading back to the store. Taking the time to have conversations for shared understanding will almost always accelerate the effective pace of the project.

Project Conversations-Overview

Posted on December 3rd, 2009 by Dennis Stevens  |  No Comments »

Knowledge based projects, like software development,  are performed by people.  So the way people learn, collaborate and interact is more impactful in knowledge based projects than in traditional projects like building a bridge or a satellite. If Agile software development and Project Management 2.0 have introduced anything new, it is an explicit focus on the social aspects of performing projects. Traditionally project management methods focused explicitly on the processes, tools and techniques of projects.

The traditional tools and processes are still important to the success of projects. We still need to clearly define scope, coordinate project resources, and manage commitments and acceptance of work. But these are social endeavors – and they can’t be accomplished with tools and processes alone. They require an intentional focus on the social aspects of the project. The shift toward the social focus is reflected in the Agile Manifesto’s first value, “Focus on individuals and interactions over processes and tools”. This shift in explicit focus is not an abandoning of processes and tools – rather an intentional focus on achieving these purposes to include people and interactions.


Project Conversations

How do we manage these social aspects? It is through conversation. Conversations are the use of language to exchange thoughts, ideas, or information. Understanding, Coordination, and Commitment within the team arise through conversations. John Searles wrote about how conversations can be defined with clear outcomes and broken into specific series of acts. Gordon Pask wrote in Conversation Theory about how understanding arises based on our interpretation of another person’s behavior.

Using these approaches we can construct ways to improve project performance through improving conversations. But, this isn’t a touchy- feely effort. For each specific conversation there is a specific set of outcomes and a specific set of “speech acts”. Intentionally deciding what conversations need to occur, when they need to occur, and what they look like when they have been completed will  improve the performance of interactions on Agile teams. Over the next week I will be discussing various conversations around understanding, committing, and coordinating. I will present a starting point you can use within your teams to have the meta-conversation to improve these conversations. Then I will build on each of these conversations at each order of scaling (small team, multi-team, program, enterprise).

The Role of Conversations in Projects

Posted on March 4th, 2009 by Dennis Stevens  |  1 Comment »

This is a slightly updated presentation of a talk I gave at Atlanta’s Project Developer Days a few years ago. After attending a two day training session with Jeff Sutherland, I believe that this concept is relevant to the Agile and SCRUM Project Management conversation.  From my experience, improving the performance of the conversations on your projects greatly improves the performance of the project team. When we say we want to get better at communications, I believe we want to improve the quality and effectiveness of the project conversations. The project managers job in leading projects requires us to be good at recognizing what conversations need to take place, and facilitating them to a successful conclusion.