Lean Thinking

05 August 2014

Personal Kanban

Written by Published in Lean

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.

Written by Published in Agile

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.

Written by Published in Agile

When implementing agile in an organisation, one of the first questions management will ask is “what metrics will I get”. This is not an unreasonable question. They are financially responsible for their part of the business and are used to dealing with a particular set of metrics that let them assess the performance of their teams and take action if action is needed. RAG (Red Amber Green) status on projects, schedule variance, earned value, actuals vs estimates, risk profile, and so on.

When agile comes on the scene, those measures go away and management feels like they have lost control. So a question about agile metrics is perfectly reasonable. How do I, as a manager, see that my process is working well? How do I tell when things will be delivered? How do I tell how much stuff will cost? When answering this sort of question, the answer we most frequently turn to is velocity. Most agile systems have some concept of velocity – how much a team can produce in a given time. The problem is that velocity is a very poor way to measure those things at any scale beyond a single team. Velocity just wasn’t designed to answer this sort of thing. Why? Well to see why velocity isn’t a good measure for these questions, we need to look at what velocity is designed to measure.

24 June 2014

The Black Economy

Written by Published in Lean

When you work in a large company, one of the things you hear quite often is “we have to follow the process”. Large companies, for very good reasons, have a need to standardise their processes. If you have 50,000 staff, having one way to do things makes a lot of sense. No matter where someone goes in the organisation, the process for ordering a new pen, or whatever, will be the same. The problem with defined processes though, is that unless they are regularly reviewed and cleaned up, they tend to accumulate complexity. Each time something happens that is just outside the normal way the process works, someone will add some extra checks into the process to make sure that that situation is now covered. Over the years it will collect enough of these extra checks that your carefully considered and streamlined pen ordering process now requires a 10 page form, 15 signatures and about 4 hours (and in some companies a pint of cockerel’s blood). The end result is that everyone spends all day looking for pens.

Our teams are stuck following these complex processes (which for the Lean folks out there equate to waste number 7 – Extra Processes) and the delays caused can significantly impact agility. How can a team release every 2 week sprint if following the release process will take 2 months? But the process is the process… we have to follow it. Or do we? Look closer at your teams. Sure, on the surface the process is being followed, but look under the surface.  How did Fred manage to get that test environment set up weeks ahead of schedule? How come Joe always has enough pens when requisitioning a new one takes weeks? Welcome to the black economy.


« January 2018 »
Mon Tue Wed Thu Fri Sat Sun
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31