Lean Thinking

Dave Martin  

Dave Martin

16 September 2014

Agile Patterns

Last post I briefly mentioned a patterns based approach to agile adoption within enterprises. I should probably spend a little time explaining what I mean by that. The first question, of course, is what do I mean by a pattern?

Back a few years, when things were still made by hand, a craftsman who wanted to make a set of things that were the same each time would make one reference piece, measured and constructed very accurately, and use it to create more pieces that looked the same. That reference piece would be carefully labelled with instructions on which way to align wood grains (or whatever was appropriate) and which techniques to use to construct it. This reference piece was called a pattern. There was even a specialised skill within workshops called patternmaker, with its own set of specialised (and very accurate) tools. So a pattern is a template or a guide to doing something. It's a way to reliably and consistently make copies of something.

02 September 2014

SAFe SPC Course

Published in Agile 8 comments

A few weeks ago, I went on the SAFe SPC course, and passed the exam which means I'm a fully qualified, newly minted SAFe Program Consultant. I thought I'd give you a quick rundown of the course and my impressions of SAFe now that I'm apparently some kind of SAFe Jedi master.

For those who have been living under a rock for the last few years, SAFe (Scaled Agile Framework For Enterprises) is, as the name suggests, a scaling methodology for enterprise agile adoption. It is, to put it mildly, somewhat controversial, with many deeply in love with the methodology and some very strongly against it for many reasons. In the interests of full disclosure, I should say at the outset that I went into the course as someone pretty much on the anti-SAFe side. There were many things about the methodology that I didn't like, but I'm a big believer in giving things a fair go, so when the chance came up to go on the course, I figured I'd give it a go and let the other side have its say. So... what was it like?

19 August 2014

Control Charts

A couple of posts ago I promised you a post on Control Charts. Here it is. For those of you who have never come across these before, they are come from the field of Statistical Process Control (no... really... don't go...stay with me here... it's worth it, I promise). They provide a means of charting process data in a way that answers the single most important question you should be thinking of when looking at a chart of process data. No it's "not when can I go home?", or even "I wonder whether stabbing myself in the eye with this pencil will be more interesting?". It's – "what's normal?". When does the chart show normal variation and when does it show something I should be concerned about? Is this spike in the data something I need to investigate, or is it normal?

There are about a dozen different types of control chart for different types of data and you can use the various types to build a chart for just about any metric you choose, but for an agile project the most useful ones to chart are Velocity and Lead/Cycle Time. Even better, these two metrics use the simplest possible type of control chart – the IMR chart or Individual & Moving Range chart.

05 August 2014

Personal Kanban

I know I promised you guys an article on Control Charts but I have had a bunch of people ask me about my use of Personal Kanban over the last few weeks so I thought I'd take a break from agile metrics and talk about that instead. Fear not though, definitely control charts next time.

One of the questions I get asked a lot as an agile coach is whether agile applies to non-IT projects. I will explain that yes, agile works really well with non-IT and at this point I usually mention that I use Kanban at home for my things to do around the house. At this point people tend to look at me strangely. Then I mention that we have a Kanban board in the kitchen for the kids to do their chores on, and my son has a Kanban board in his bedroom to do his homework on. This usually makes people start to back away slowly. I thought I'd take a few minutes and explain how it works.

Published in Agile 5 comments

Last time we looked at the most common question we get from management -

What metrics will I get?

And saw that our usual answer - velocity - really isn't very good at answering that question. It's really only designed to be an internal measure for a single team. You can't use it to compare teams. I mentioned that Cycle Time is a much better metric to use for this sort of question, so let's take a look at Cycle Time. We will also look at its cousin - Lead Time.

Cycle time is essentially, the time a team spends completing a story - the clock starts when they start work on it, and it stops when it's done. So if a team starts a story on Monday and it's done Friday, the cycle time is 5 days. Individual cycle times are fairly meaningless (like individual velocity measurements) but over time the team will establish an average cycle time. Lead time, on the other hand, counts from when the story enters the team's backlog to the time its done. Lead time - cycle time = the time the story spent sitting around in a queue waiting to be started. Together these two metrics can answer management’s burning questions and even better, we can use them to drive some helpful behaviours.