Shorten and Reduce Variability in Lead Times using Kanban

Posted on June 30th, 2010 by Dennis Stevens  |  No Comments »

When I start talking about speeding up work and reducing variability in lead time to a group of software developers, the initial reaction is often, “We can’t do that. This is knowledge work. You can’t reduce variability in the work itself. The hard stuff just takes longer and the easy stuff is shorter.” This is often followed by, “You don’t want to take the creativity out of our work”, or “You can’t treat us like machines.” So, it is important to point out up front that I agree with all of these statements. So, why would you want to shorten and reduce variability in lead times and how can you reduce lead time and variability without inhibiting the creativity required to do the work.

Why Reduce Variability and Lead Times?

Lead time is the average time it takes for one work item to go through the entire process – from start to finish – including time waiting and time consumed by rework. In most cases, unless you are intentionally managing your lead time, you will have lead times that are highly variable and probably excessively long. Why would you want to reduce lead time duration or variability?

Increase Predictability

Reducing variability in lead time will allow you to consistently know and commit when something can be delivered. Delivering consistently will help to increase the trust within the system. One of the very beneficial outcomes from increasing trust in the system is that it leads to a dramatic reduction in expediting. Once the system becomes predictable, the business may be able to make new offers to customers based on the high level of predictability.

Faster Feedback

Reducing lead time duration results in faster feedback. Faster feedback can result in increased quality. There are number of reasons for this.  Less work is done based on work items that require rework. Shorter cycles result in better fit since the feedback can be gathered and applied frequently. Also, faster feedback means that the team can minimize the work required to meet the objectives.

Flexibility and Responsiveness

Shorter lead times and trust based on predictability increases options for flexibility. You can delay some decisions until very late – deciding just before you pull into the system the details of solution. Expediting now means putting an item into the queue as the next item. Also, you can make new promises to customers based on this increased level of flexibility and responsiveness.

Wimbledon

Okay, so there are some benefits to reducing variability and duration in lead time. But, how can you reduce lead time duration and variability without inhibiting the creativity required to do the work.

Wimbledon provides some insight into this. At Wimbledon, the games take as long as they take. The number of games played is determined up front – they have to play all the games. There are Men’s and Women’s Singles, Men’s and Women’s Doubles, Mixed Double’s and many players participate in multiple events. Games can’t play in darkness (except on center court). Games can’t be played in the rain. Players can’t overlap doubles with mixed doubles or with singles play.

Wimbledon has been played 142 times and the finals have been delivered late twice. That’s pretty amazing given the wide level of variation in the length of games and the other constraints that must be addressed.

How does Wimbledon accomplish this? They have policies that impact the timing of the games – for the most part without impacting the way the game is played.  For example:

  • A tie breaker in the first four sets. This tie breaker is open ended as it requires a player to win by two points – only the final set requires winning by two games.
  • Games can start earlier on a day if games are behind.
  • The gap between games can be shortened to get in additional play each day.
  • The tournament director may have players warm up on other courts to bring games closer together.
  • Additional courts can be opened for play as long as it doesn’t create a conflict across events.
  • They minimize the impact of rain by covering courts during rain delays.
  • They have added lights and a roof over Center Court to allow games to run longer and during rain.

Combined, these policies allow the games to take as long as they take – while allowing the tournament to deliver a fixed number of games in a fixed time.

Reducing Variability and Lead Time in Software Development

Just as software development isn’t manufacturing, it isn’t tennis either. What the example shows is that lead time duration and variability can be reduced without changing restricting the way the game is played and with minimal impact on the rules of the game. This concept can be translated to software development.

Reduce Waiting

How much time is a work item actually actively being worked on? If you pay careful attention to flow of work through your system you will likely find that a typical work item spends more time waiting to be worked on then being worked on. It is not unusual to find 5-10x wait time to work time. With wait time being a large portion of lead time, reducing wait time will have a significant impact on reducing lead time. Limiting WIP and pulling work are key techniques to reducing waiting.

Rework: Or Failure Load

Another big cost on lead time – and typically a huge impact on variability – is rework. Rework is the result of a defect that unintentionally escapes from one work queue and is identified in another. The result is that work moves backwards through the system – increasing lead time not just of the current work item, but of other work items. Leveraging techniques that minimize or eliminate rework are important to reducing variability and duration of lead time. Test driven development, automated test frameworks, continuous integration, and coding standards are methods of reducing or eliminating rework. Investing into reducing rework reduces lead time duration and variability.

Making Work Ready

One cause of variability and extended lead times is when work is pulled that isn’t ready to be worked on. This can happen when dependent work items aren’t prepared, required external resources aren’t standing by, or when the outcome (not the how) is not well understood. Making work ready requires understanding and aligning dependent work items. Minimizing dependencies during design helps reduce negative impact. Using scheduling methods like Kanban to schedule external (non-instantly available) performers helps coordination of external performers so work can continue to flow.  Feature injection, where outcomes are defined during analysis and presented as testable examples is an excellent method of understanding and clearly communicating the expected outcome. Extra effort put into making work ready often results in reduced lead time.

Relatively Small and Similar Size Work

Large work items – or high variability in size and complexity of work items will result in higher variability and duration of work items. Breaking work into relative small and similar size work is a good method for reducing variability and duration of lead time. Breaking solutions down into small work can also result in improved design, higher testability, and more flexibility in the solution. This doesn’t mean that work should be broken down arbitrarily. Work should be broken down to the smallest level that is reasonable and no smaller.

Swarming

Swarming is when team members work together on work items to move them forward faster. Sometimes this is increasing the number of developers doing development – often it involves having generalists work in areas outside of their specialization. You will want to have the performers work on work items that are in risk of being late against their  SLA.

Tracking The Data

To track lead time, track the entered day and exit day from the Kanban. Do this by having the performer who pulls the card into the first queue write the date it was pulled. When it is moved to the last queue, write that date on the card. Lead time will be the difference between the two days.

To track waiting time, put a blue dot on the card for each day it sits waiting to be pulled into any queue. Count the dots when you pull the card off the board to see how many of the lead time days were waiting days.

To track defect days, you can create a defect card when a defect in a piece of work is identified downstream from its source. Move the card back to the source location and move it forward through the system until it catches up with its card. Put the start date on the card when it is created and the end date on the card when it catches up with the original card. Defect days is the difference between the start date and the end date of the defect card. Track the cumulative defect days on the work item card.

Track blocked days when the card is blocked. This can be done by putting a red dot on the card for each day it is  blocked.

Reducing Lead Time Duration and Variability in Kanban

So, by tracking data related to Lead Time, waiting time, defect time, and blocked time, the team can identify where to act to reduce the lead time duration and variability. Then, identify and leverage strategies like reducing waiting, reducing rework, making work ready, defining small size work, and swarming, to improve lead time. Tracking causes of defects and blockages can help make decisions to focus these strategies appropriately. Reducing lead time duration and variability will result in increased predictability, faster feedback, improved flexibility and responsiveness.

Twitter Weekly Updates for 2010-06-27

Posted on June 27th, 2010 by Dennis Stevens  |  No Comments »

Powered by Twitter Tools

Kanban: Negotiating and Managing Service Level Agreements

Posted on June 22nd, 2010 by Dennis Stevens  |  1 Comment »

In my last couple of posts I have been talking about Measuring and Managing Flow in your Kanban system. With some simple tracking, you will pretty rapidly have an understanding of Classes of Service and how to produce reliable estimates using Kanban. One of the big wins in Kanban is to take this understanding and have the team collaborate with the external stakeholders and business owners to agree on the performance goals. The performance goals are built on the assumption of a long term relationship between the team and the external stakeholders as well as team commitment to system level performance.

The performance goals are articulated as Service Level Agreements (SLAs). These SLA’s define cycle time targets and WIP limits. For example, a cycle time target might be something like – we will deliver small sized Standard items in 11 days 80% of the time; the WIP limits for Standard items is 2 in design, 4 in development, and 4 in acceptance. You can establish distinct SLA’s for each class of service and even for different sizes of work.

Four Keys to Negotiating SLAs

It is not sufficient for management to establish SLAs and then communicate them to the team and the stakeholders. The SLAs need to be negotiated in a collaborative way. This builds understanding and interest in the system on the part of all stakeholders. This understanding and interest, paired with the team successfully meeting the performance goals, results in establishing / increasing trust in the team. There are four keys to negotiating SLAs.

1. Include both upstream and downstream stakeholders in the discussion to form the agreement. Their understanding of the system and their participation in the negotiation helps ensure the stakeholders will be willing to uphold their end of the bargain in prioritization and WIP limits. It also enables collaborative behavior later, when the system is put under stress.

2. Involve the team in defining the the classes of service and negotiating the SLAs. This will increase their commitment, which is a key to meeting the SLA’s. Additionally, their participation in defining the SLA’s, the supporting policies, and their decision making in applying the policies results in increased engagement on the part of the team members.

3. Make promises the team can keep. Use data gathered from the historical performance of the team. Understand the distribution of outcomes and apply standard deviations to make statistically appropriate commitments. Don’t get pushed into hopeful SLAs. Support the negotiations with data and be sure you don’t allow the team to over-commit.

4. Balance demand to your capacity. As you set WIP limits, focus on maintaining the lowest possible limits. Also it is healthy to have a mix of classes of service active. This helps to optimize value and distribute risk.  Don’t over-commit the amount of work that will be in progress at any one time. It isn’t about starting work – it is about finishing it. Remember, the lower the WIP the shorter the cycle time.

Cost of Delay

Everything is not of equal priority.  It isn’t necessary or helpful to expect perfect estimates on stochastic work (work types with a lot of variability) like software development. Human nature will cause the system to underperform if all types of work require a high level of precision in time commitment. Read the section on Decoupling Planning and Scheduling in Kanban and When Will This be Done? to understand this phenomenon. Use the concept of the Cost of Delay to establish effective SLAs on various classes of service. Cost of Delay is the cost that will be incurred when a work item is delivered later than promised. Understand the Cost of Delay of each Class of Service and set the SLA appropriately.

For example, a compliance requirement that has to be delivered on a specific date or the company will incur a large fine has a high cost of delay. You need to use your the Mean + 3 Standard Deviations for that work item type when you set the SLA. If you understand the probability of a series of tasks that need to be delivered by a certain date, each individual task won’t have as high of a cost of delay. You should probably set an SLA that says the work item type will be delivered in (Mean + 1 Standard Deviation) days about 80% of the time. If you have work that needs to be completed – but new value isn’t released when the work is completed – that item has a low cost of delay. Don’t set a time based SLA – but limit the WIP capacity of this work. Use the concept of Cost of Delay to set the most flexible SLA possible. This will improve the flexibility in your Kanban system and increase the ability to deliver value.

Managing Policy to Achieve the SLA

Once your SLA has been established, the Class of Service policies need to be shaped to ensure the SLA is met. This includes the impact this class of service has on WIP limits, the prioritization and swarming agreement for the class of service, and estimation requirements for the class of service.

As you are performing the work determine early if the SLA is in jeopardy. The team should work hard to arrange their focus to meet the SLA. This will mean making decisions that give them the best chance to  succeed without jeopardizing the SLA for other work items. When an SLA is in jeopardy, the team should communicate this to business stakeholders early. If the SLA is critical the business stakeholder may decide to elevate the Class of Service.

Continue to measure your performance against the SLA. During your operations reviews – look for opportunities to improve performance against the SLA. Over time, you may look for ways to reduce cycle time to increase the performance of the system.

Benefits of Negotiating and Managing SLAs

Using metrics, classes of service, and service level agreements your team can learn to make promises they can keep. Making and keeping promises increases trust in the system and reduces pressure from the stakeholders to demand artificially inflated SLAs. Negotiating the SLAs effectively increases the commitment and level of engagement of the team. It also engages the stakeholders in the success of the system. Using cost of delay in the negotiations helps set appropriate SLAs that optimize value while maintaining flexibility in the system. Thoughtfully defining your policies gives the team the best chance to successfully deliver on the SLAs. Establishing and communicating the policies create a set of simple rules the team can follow to deal effectively with the high level of variability in the work moving through the system. Using Kanban, capturing a few simple metrics, and negotiating some simple rules around cycle time and WIP commitments can dramatically improve the reliability and trust experienced by the stakeholders while improving the commitment and engagement of team members.

Twitter Weekly Updates for 2010-06-20

Posted on June 20th, 2010 by Dennis Stevens  |  No Comments »

Powered by Twitter Tools

Can Agile Learn Anything from the PMBOK?

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

One of the Yahoo groups I belong to, pmiagile yahoo group, is exploring whether there is any synergy between Agile and the PMBOK. Its is an interesting yet somewhat frustrating discussion. I think we should try to avoid platitudes and clichés. I understand that there are many project managers that have interacted with development teams in ways that were destructive. I understand there have been agile teams that were not responsible in their approach to development. This discussion should not about how individuals or organizations have behaved badly. It is about looking at an established body of knowledge, the PMBOK, to see if there is anything worth learning from there that could help us in uncovering better ways of developing software by doing it and helping others do it. Todd Little recently posted:

“It would be more productive to look at what problems exist that current agile implementations do not support well. Dennis is suggesting that there are gaps that agile does not answer. I’ll buy that there may be some gaps. What are those gaps? What are the user problems that need to be solved? What are the user stories and acceptance tests for those problems? Maybe then we can look at the PMBOK as a potential source of solutions to users that have those problems.”

I believe it is pretty important that the participants in this discussion have a pretty clear understanding of both Agile and the PMBOK if they are going to offer up opinions on one or the other. I have been involved in software development since 1985 (RPG2/3/400, C++, Perl, Java, C#). By the mid 1990’s I was leading development teams following an Incremental and Iterative development process. I purchased my version of Eliyahu Goldratt’s the Goal in 1994 and Critical Chain when it came out in 1997. I was busy reading and applying Larry Constantine’s Peopleware,  James Highsmith’s Adaptive Software Development, Kent Beck’s eXtreme Programming, and Alistair Cockburn’s Crystal methodology before I knew what the Agile movement was. I was explicitly applying value stream concepts, visualization, and limited WIP before 2000. I have always mixed and matched based on what made sense on my current project. I have actively been coaching and applying these ideas for over 15 years. I claim Agile chops.

I earned my PMP from PMI in 1998. I have produced hundreds of project artifacts including project plans, charters, and risk plans.  I was the Deputy Project Manager on the development of PMI’s Organizational Project Management Maturity Model (OPM3®). I have actually read through my PMBOK 4th Edition in detail. I am qualified to speak about the PMBOK.

The PMBOK

Let’s talk about the PMBOK for a few minutes. First off, the PMBOK describes good practices in project management that work for most companies most of the time. The PMBOK Guide also provides and promotes a common vocabulary within the project management profession for discussing, writing, and applying project management concepts. The PMBOK points out that the standard is neither complete nor all-inclusive. Additionally, the standard is a guide rather than a methodology. One can use different methodologies and tools to implement this project management framework. The PMBOK is not specific to software development – this language and this guide support all types of projects.

How The PMBOK is consistent with Agile

PMBOK supports self organizing. It is up to the organization and the team to determine what is appropriate for any given project.

PMBOK supports sprints and/or real-time planning. PMBOK doesn’t require big up front planning and then rigorous adherence to plan. PMBOK talks about iterations and progressive elaboration. Progressive elaboration is continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available as the project progresses, and therefore producing more more accurate and complete plans that result from the successive iterations of planning.

PMBOK supports continuous improvement. This is an iterative means of improving the quality of all processes, reduces waste, eliminates activities that do not add value, allows processes to operate at increasing levels of efficiency and effectiveness.

PMBOK supports overall adaptation of the product and the organizational processes. The Risk Management Section of the PMBOK calls for a continuous approach to identifying, monitoring and responding to risk. Technical Risks (including Requirements Risk and Quality Risk, External Risks (including Market and Customer Risk), Organizational Risks, and Project Management Risks.

How the PMBOK complements Agile

In many cases, software development takes place in a bigger context then just the software development team. This bigger complex can be messy, with lots of activities that have to be coordinated to deliver value to the customer. Here is a peak into that messy context.

In front of development this includes activities like market research, strategic planning, sales forecasts, budget forecasts, and making investment decisions.

During development activities need to be coordinated with development including procurement, vendor contracts, compliance research and documentation, legal evaluations, intellectual property protection, developing and implementing security, privacy and data protection controls, and designing changes to business process.

For each release of software, activities outside of development include, establishing sales and marketing readiness, updating customer service policies and procedures, updating business resilience procedures, updating impacted training and implementation procedures, updating customer service levels, re-aligning reward and recognition programs, and updating internal IT service level agreements. Then there are often launch activities around customer communication and product promotions and ICT coordination including licensing and production operations.

The importance of these activities will vary between contexts – but these are all real activities that I have had to handle on software development projects. In Agile, these are hidden behind the Production Owner or Onsite Customer abstractions. But in the process of delivering value to an organization or new product to a customer, these may exist, need to be coordinated, and aren’t particularly interesting to the software development team. This type of coordination needs to be done in a way that enables the Agile teams – to achieve the goal of delivery of value to the customer.

Barriers to Synergy

From the Agile perspective, barriers to synergy arise from the sense that PM’s will meddle in the performance of the team. This is based on historical experience and potentially a lack of understanding of real organizational constraints that result in obstacles for the team. The PM becomes the representative for these unreasonable constraints in a “shoot the messenger” fashion. The other big barrier to synergy is the prevalence of language in the PMBOK that is contrary to Agile values and principles. Make no mistake, from the definition of the project manager, through the use of words like directs, controls, and manages the language is an obstacle.

From the Project Management perspective, barriers to synergy arise from the primacy of developers and the development team in Agile talk. Project Managers also perceive the agile teams have a limited view of what “the product” is and what it takes to provide value to the customer. The project manager lives in that messy place behind the overly simplistic abstraction of the Product Owner.

How Do We Address These Barriers

Acknowledge that Agile and the PMBOK come from a different mindsets

Not regarding iterative and incremental development but from values and principles. We need to recognize this gap and start the discussion from the perspective that we are building on Agile values and principles.

Recognize that delivering value to the customer is often beyond the scope of the development team

The product is bigger than development. There is work to be done that isn’t best done by the development team. This becomes a bigger and more important deal when you are working in companies of any scale.

Acknowledge the Limitations of the Product Owner Abstraction Layer

Look back at How the PMBOK Complements Agile. That messy list of activities point out how big the set of issues are that the Product Owner is responsible for.

Distinguish between Project Management Practices and the Project Manager Role

The PMBOK is the Guide to the Project Management Body of Knowledge. It isn’t about project managers. In a small organization, with a limited number of products, with intimate access to customers, lots of automation, and a limited requirements for supporting infrastructure, the project management activities can likely be handled by a couple of people with very little coordination effort required. But in organizations of scale, the coordination effort will benefit from someone focusing on coordination. In both cases, the project management practices should be addressed – sometimes with a role and sometimes without.

Can Agile learn anything from the PMBoK?

Yes, by addressing the barriers. Start with Agile principles and values, look at the larger value stream from the customers perspective, understand the limitations of the product owner abstraction, and creating clarity about roles and authority regarding project management practices. Use the PMBoK as a placeholder for conversation about the Knowledge Areas and the purposes behind the tasks. As the PBMoK points out. the organization and/or team should decide what is appropriate for them for each project.

Here’s a starting point for the Ball in Court discussions

The conversation is about decisions rights and levels of authority. I have listed the PMBOK knowledge areas and some potential separation of authority as a starting point. I want to be clear about my perspective on this conversation. In a doubles tennis, everyone on the same side of the net is on the same team. Sometimes, the ball is in one person’s court and sometimes it is in the others person’s court. But when playing tennis the partners play the game to help set each other up for success and may back each other up if possible. I view these authority discussions as ball in court discussions.

Additionally, this starting point is going to be wrong for your organization. But making perspectives explicit helps start the conversation. This initial view is based on a discussion on the pmiagile board that I had with Ron Jeffries. I am not  claiming that Ron has endorsed this approach or these distinctions. What is important is that Ron Jeffries and Todd Little are willing to explore this line of thinking.

PMBOK Knowledge Area [potential authority]

Project Integration [development team inside development, project manager outside development]
Project Scope [product owner, project manager facilitation]
Project Time [development team]
Project Cost [product owner, project manager]
Project Quality [the development team, project manager facilitation]
Project Human Resource [project manager]
Project Communications [development team inside the team, project manager outside development]
Project Risk [product owner, development team, project manager]
Project Procurement Management [project manager]

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

Posted on June 14th, 2010 by Dennis Stevens  |  4 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.

Twitter Weekly Updates for 2010-06-13

Posted on June 13th, 2010 by Dennis Stevens  |  No Comments »

Powered by Twitter Tools

Kanban and When Will This Be Done?

Posted on June 7th, 2010 by Dennis Stevens  |  13 Comments »

A question that comes up a lot in Kanban is, “How can I know when this feature will be done?”.  First off, it is important to understand what makes estimating unpredictable – and then what steps Kanban presents to address this. Estimates are unreliable because the inherent variability work is compounded by the lack of flow in most teams and destructive behavior caused by fixed point estimates. Kanban, through a few simple techniques, a little bit of math, and the decoupling of planning and scheduling will give you the ability establish accurate estimates with minimal effort.

Cycle Time

The key metric we will use for estimating is Cycle Time. Cycle Time, in most Kanban and Lean contexts, is the time between when the team starts working on an item and when the item is delivered. imageCycle Time is what is interesting to managing (whether managed by management or self managed) the team. This metric becomes a key management metric to reduce variability in the system, make reliable commitments, and provide insight into whether improvement efforts are delivering expected results. We are going to talk about using Cycle Time to make reliable Due Date Performance commitments.

Cycle Time is easy to capture. When a card is pulled into the first work queue – enter the date on the card next to Start. When the card is moved to the last queue, enter the date on the card next to Finish. Cycle time is Finish Date – Start Date. At the end of the week, when you pull cards off the board, capture the cycle time for each card into a spreadsheet or whatever tool you are using for tracking.

Distribution Curves

What you will most likely find after you have captured a little data is that lead times fall in a distribution that is skewed to the right. This shows the variability in the work that you perform – there is some absolute limit on the shortest time the work can take – but there are a lot of ways it takes longer. imageTake the Cycle Time data and find the Mean and the Standard Deviation. Then set the expectation to the Mean + 1 Standard Deviation.

In this chart the work items are taking from 5 to 15 days. The Mean is 8.6 days and the Standard Deviation is 2 days. You can set a Due Date expectation 11 days and and be sure that you will hit this date about 80% of the time without changing anything you do. So that’s the policy, we will deliver work within 11 days with an 80% due date performance expectation. Over time, we hope to be able to improve the 80% and the 11 days.

There are a few nice things about this Cycle Time number. It takes a lot of complexity into account. Your Cycle Time calculation will have already incorporated the impact of rework while in the system, the typical impact of disruption from expediting, and the impact of waiting in the ready/done queues.

What about the 20% that will be late? There are a couple of things you can do. First, you will begin to be able to identify early which stories are going to be late. These will be ones that are more complex or end up with lots of rework. You can address these with capacity, prioritizing and/or communication to the customer. Addressing it with capacity means swarming on the task to bring it in closer to the due date. Addressing it with prioritizing might mean moving the card up higher in the stack then one that is likely to be done early. The cost of swarming and prioritizing means that another card might be delayed – but if you are thoughtful about prioritizing and swarming you won’t cause delay outside of the Due Date promise. For some cards, you will communicate to the customer that the card will exceed the due date performance expectation – while not optimal this is within your delivery commitment as long as it doesn’t happen more than 20% of the time.

T-Shirt Sizing

Many teams are dealing with work of various sizes. If you do a frequency analysis of your data you will probably see clusters of data. imageIn the picture below we have three clusters.  Rather than spending significant time in complex assessments to support estimating, the team can rapidly assign tasks into these clusters. We call this T-Shirt size estimating. Cluster like work into XS, S, M, L, and XL. You may decide that you don’t accept XL tasks without decomposition or require breaking them down. Then determine estimates for each size based on Mean + 1 Standard Deviation for each of the clusters. You can determine some simple process for assigning work into one of the T-Shirt sizes.

This won’t give you perfect estimates. Perfect estimates are almost impossible to determine. Additionally, Cycle Time Variability is probably impacted more by variation in the system like waiting and rework then anything else. It is impossible to determine the impact of the system by more deeply analyzing the task. With T-Shirt sizing and Cycle Time, you can get as accurate results in minutes as could you do in months. While not perfectly accurate – it’s as meaningful as anything you can do.

Schedule a Release

One of the interesting concepts in statistics is the concept of Regression Toward the Mean. What this means is that when you bring a lot of estimates together, you are likely to  have a final result where the average over time is close to the historical average. One example of this is driving to work. If you were asked to plan how long it would take to get to every stoplight on the way to work exactly, this would be impossible. But you have a pretty good idea what time you need to leave home each day to arrive at work at the right time.

Because of regression toward the mean and the actions we can take based on the visibility Kanban provides us, using T-Shirt sizes and cycle time to schedule a release will result in a pretty accurate estimate – and the cumulative estimate will be more precise than any individual estimate.

Decouple Planning and Scheduling

From a human nature standpoint, data can be a dangerous thing. The way we often couple planning with scheduling of resources is an example of this. With the way we have historically run projects, we put all the estimates together and then hold the team accountable to each individual estimate. This is unreasonable because we know that the estimate represents a range of possible outcomes. Five problems arise when we tightly couple estimating and scheduling of the work.

1. Bludgeoning: If we produce point estimates when outcomes are probabilistic – and then hold people accountable to hitting each individual estimate we are going get value destroying behavior. Bludgeoning people when they don’t hit 80% estimates means we are going to get 95% estimates. In most cases, the 95% estimate is about twice the duration of the likely outcome. This puts a lot of padding into the system.

2. Sandbagging: Another destructive management behavior when we couple planning and scheduling is accusing the team of sandbagging. This happens when the team delivers something in half the time of the estimate. Management will often want to go back and cut the “excessive padding” out of the rest of the estimates. First off, management drove the sandbagging behavior. Secondly, we know statistically that most work should be delivered earlier than an 80% or 95% estimate. The team learns not to deliver early because management charges them with sandbagging. So teams don’t deliver early and consume time that, on average, we need to accrue to the project.

3. Parkinson’s Law: Typical management techniques result in the team delaying delivery until the last moment. One outcome is that work expands so as to fill the time available for its completion. This is problematic because it leads to gold-plating of work that increases downstream efforts. It also ensure we don’t deliver a task that could be delivered early doesn’t get delivered early.

4. School boy Syndrome: The other behavior spawned by this is that the team doesn’t start as soon as possible because they wait until they think they need to start to deliver. This often means the team will start in time to deliver on the likely outcome – but deliver late when the task turns out to be more complicated or runs into a delay.

5. Murphy’s Law: If something can go wrong it will. We know that some work will take much longer than other work. This is Murphy’s Law. The behavior that arises from coupling planning to scheduling combined with Murphy’s Law ensures that projects will be delivered late – even against a 95% estimate. It is said that the losses accumulate and the gains are lost.

Kanban Helps Reliably Determine When Work Will Be Done

We can’t precisely predict how long work will take. Estimates represent a wide range of possible outcomes. In traditional project management, we ask for unreasonable estimates and then manage the work in such a way that we guarantee the project will be delivered late. Additionally, late delivery of work is as often driven by behavior that inhibits flow as the uncertainty around the work effort.

In Kanban we use Cycle Time data derived from the performance of the system to plan when work will be done. Then we decouple this planning effort from work scheduling – using the Kanban board to focus the team on flow. Kanban provides the team opportunities to make capacity and prioritization decisions that help address the innate variability of the work being performed to deliver within the policy. Cycle Time estimates, combined with limited WIP and a focus on flow, helps Kanban helps deliver predictable outcomes.

Twitter Weekly Updates for 2010-06-06

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

Powered by Twitter Tools

Kanban and Conversations

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

image

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.

image

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.

image

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.

« Older Entries
Newer Entries »