Tuesday 12 May 2009

Control / Capability Charts on a Kanban Software Development Project

Corey Ladas and David J Anderson have recently spoken about how lots of software/IT teams using Kanban board have created Cumulative Flow Diagram but few of them have done control (or capability) charts or histogram.

On the software development project I'm the Project Manager of we have started using control charts for several reasons:
  • To better understand the variation over time in a number of key areas (how many things we deliver to production each fortnight and how many days it takes from a developer starting for a story to be ready for production.
  • To better understand how we can improve our process by separating common cause problems from special cause problems.

Control Chart 1: Features Released to Production

The first control chart we've used is the number of Jiras (think Story) we have delivered per iteration length and number of available developers.




I've split the periods on the charts to reflect pre- and post-Go Live.

What this chart shows me is that the system is in statistical control. None of the points are outside the Upper Control Limit. There is currently a slight downward trend in the number of Jiras we deliver (six consecutive releases are under the mean).

As the Project Manager I'd like to achieve two things. First, I'd like to increase the amount of value we deliver to our end customers. The first point is tricky since count of Jiras has a very rough correlation with end customer value. I don't want to encourage the team to focus on the numbers (e.g. I don't want lots of small stories instead of larger ones, if the larger ones have value). Second, I'd like to reduce the variability over time. I'm puzzling over whether a sizing metric on the stories would help reduce some of the noise in the variation.

Given that the chart shows me that we're in control and if we want to make improvements on the amount that we deliver each fortnight, we probably need to look for common cause / system-wide influences, rather than a special cause, such as asking the developers to "just work harder". A lot of the delay recently has been having to deal with other teams within the IT department who have longer lead times than we do. From a systems perspective, improving our ability to work with other teams is where I think we'll gain more throughput improvements than focusing on improvements within our team.

Cycle Time: From Development to Ready for Release

The second area we have used Control Charts is looking at the time it takes for a Story to progress through the following states in our process (and on the Kanban board):
  • Developer Design (Technical Design Discussion, How to Test written)
  • Development Underway (Including Code Review if it wasn't developed by pairing developers)
  • Functional Testing (this is where they wait for Test to test them)
  • Acceptance Testing (this is where they wait for the BA to test them)

We started out with a histogram to understand the range of times it was taking tasks to cross these columns on the board.

The histogram gives a good overview of how long the tasks are taking, but it's more interesting to see this in a Control Chart since the Upper Control Limit helps highlight which tasks took excessively long and are likely to be due to special causes that are worth root cause analysing. I prefer the timeline view of the control chart to the histogram since it shows if things are changing over time as well as more clearly illustrating the outliers.

Here we can see that there are two tasks which were excessively long. These were special causes since one was due to working in a new way with another IT team, and the other was due to a "pile up" of work in progress with one developer who was tasked with performance and scalability testing the application (which required co-ordination with other groups to access the testing infrastructure). Removing these two outlier shows some other tasks to investigate, again, mainly around working on tasks that involve co-ordination with other teams.

The charts and histograms in these two areas suggest that the most productive improvements in our development system are going to come from working out ways of working better with other teams.

24 comments:

Unknown said...

Hi, this is really interesting and I have come across it before.

I suggest customer value is best focused on by helping the business only put high value stuff into the development stream. Developers tend to abdicate on this as not their responsibility and therefore allow poor material in. The way to do this may be to analyse the problem as part of a complete system, rather than from the purely functional / silo perspective of Marketing, Finance etc. Working on a problem from these 2 different viewpoints (systems v. silo) you often get very different answers. It may be too late to worry about value once the functionality is accepted and under development.

For variability, I suggest that what is of interest is how often work in the stream is returned upstream as it has errors in it. i.e. specs not clear or design flaws. The key to lean is to reduce work in process so that any process errors are immediately apparent and root causes can therefore be addressed. A record of whenever a spec, design, code was returned to its author for revision would give data on how the process is functioning and allow rapid improvement.

Anonymous said...

What are you using to generate your control charts?

Benjamin Mitchell said...

@cromwellryan: I'm using the Vanguard CapChart tool (you can do them in Excel it's just more work to calculate the Upper and Lower Control limites). There's a free online version at:
http://www.vanguardcapchart.com/

Benjamin Mitchell said...

@Belfast.

I agree that we can improve the system by ensuring we only put in high value work (I particularly like Arlo Banshee(sp?) view that the optimal development portfolio is a mix of short- and long-term high value work).

Kanban is useful for this as we only take on new work when we have capacity to start it. This means if there is more work than we're capable of finishing the work queues, which makes it visible and puts more pressure on the sponsors to decide which task is most important.

We do track how many tasks reflow back up through the stages of the workflow (we put a red dot on each post-it note on the board with the name of the stage where the tasks was rejected). We review these periodically (I have a poster where we put all the completed tasks in a histogram so we can see which ones were rejected).

I think the idea of improving the criteria for accepting work into a stage of a workflow is also good. We're currently talking about whether we need to set higher standards for analysis in order to improve the cycle times.

Neil Mosafi said...

@Belfast re: developers allowing poor material in, that's possibly true, but I think it depends on your team. In some teams the developers are quite close to the business and understand the priorities as well as the product owner. Other teams are more shielded and therefore need guidance from product owner or PM/ScrumMaster/Whatever

Unknown said...

Hi, on developers allowing poor material in to the process, the issue is the one pointed out by Deming. That Product Owners are often in a management silo and therefore are unable to see their organisation as a complete system. Being blind they therefore specify IT that chronically suboptimises and damages their organisations. John Seddon has reported IT systems frequently needing to be removed as unnecessary and damaging once a systems as opposed to silo analysis was done. I have also observed this and the waste caused by silo blindness is remarkable.

Barry Boehm makes a similar point. Software people should therefore grow their roles to ensure the strategic and business analysis is definitely done is an overall customer driven systems analysis rather than the normal silo perspective.

Kimberly said...

Great information about how we should lead a software project, and I also liked the graphics that are displayed on the blog. I have a casino called free casino and want to create a program that meets all my expectations

Anonymous said...

Another consideration that must be taken into Louis Vuitton Monogram Canvas account is the proper usage of faces when setting a longs blocks of type. Choosing louis vuitton have an outlet the proper size and leading and line length are also very important and vary depending on the face.louis vuitton ankle boots One could very easily choose a pleasant looking typeface but use it in a very unpleasing way.

Joshua Smith said...

Thank you for sharing with useful information. It was nice to read the review. Try to use outsourcing software development company thats allow you to get customized software development to upgrade your business.

Joshua Smith said...

Very good and useful review. Thanks for sharing with useful tips here. Nowadays it becomes easy to compare home insurance quotes by zip code and get the cheapest home insurance policy.

Joshua Smith said...

Thanks for some useful info about capability charts. But it needs to use some ways to successfully develop these products and use software performance testing solutions. For mobile apps software developing we use ipad application developers.

Joshua Smith said...

Also you may turn your attention on outsource asp.Net development or Java development.

Joshua Smith said...

A lot of thanks for this great tips. Casino affiliates always search for casino affiliate programs to increase their revenue income from best casinos or poker rooms.

Joshua Smith said...

Thanks for mentioning this great review. For auto owners who is looking for new autos, compare auto quotes from top auto insurance companies

Joshua Smith said...

Thanks for mentioning this great review. For auto owners who is looking for new autos, compare auto quotes from top auto insurance companies

Joshua Smith said...

Thanks for mentioning this great review. For auto owners who is looking for new autos, compare auto quotes from top auto insurance companies

Joshua Smith said...

Thank you for sharing with us. Let me tell you something about home insurance rates by zip code to save your money on house policy.

Joshua Smith said...

Thank you for posting this great posts. You have great possibility to get info about casino affiliate programs. The most common gambling programs such as go wild affiliates and great poker rooms such as party poker affiliate.

Joshua Smith said...

I'm glad to read this great review. Here we are willing to share with instant auto insurance that is supported by top home and auto insurance companies. Customer could save on cheap homeowners insurance quotes which allow you to get cheap affordable policy.

Joshua Smith said...

I'm glad to know more and read about this. Let me share with instant cheap insurance that is supported by top insurers. You may save on cheap life insurance quotes which allow customers to obtain cheap policy.

tabaco123 said...

Excellent work item. These are great topis I really appreciate it. Exchange of information in these great minds of thought. thanks. Home Insurance Discount

Unknown said...

I love the precious information you be offering on your articles. Building contents insurance

Unknown said...

Excellent work did on this post, thanks a lot!!

regards
Work Comp Insurance Fort worth

Unknown said...

The Project Management Software are the driving force that makes a business successful. It helps to know everything associated with your project whether it is a logistical problem like supplies and money, or whether it is a time tracking issue. A business can grow more with proper project management.