{"id":12,"date":"2009-05-12T16:38:00","date_gmt":"2009-05-12T16:38:00","guid":{"rendered":"http:\/\/benjaminmitchell.wordpress.com\/2009\/05\/12\/control-capability-charts-on-a-kanban-software-development-project"},"modified":"2009-05-12T16:38:00","modified_gmt":"2009-05-12T16:38:00","slug":"control-capability-charts-on-a-kanban-software-development-project","status":"publish","type":"post","link":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/control-capability-charts-on-a-kanban-software-development-project\/","title":{"rendered":"Control \/ Capability Charts on a Kanban Software Development Project"},"content":{"rendered":"

Corey Ladas<\/a> and David J Anderson <\/a>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.<\/p>\n

On the software development project I’m the Project Manager of we have started using control charts for several reasons:<\/p>\n

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.<\/li>\n

To better understand how we can improve our process by separating common cause problems from special cause problems.<\/li>\n<\/ul>\n
Control Chart 1: Features Released to Production<\/strong><\/p>\n
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. <\/p>\n
$\"\"$ <\/a><\/p>\n
I’ve split the periods on the charts to reflect pre- and post-Go Live.<\/p>\n
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).<\/p>\n
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.<\/p>\n
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.<\/p>\n
Cycle Time: From Development to Ready for Release<\/strong><\/p>\n
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):<\/p>\n