Lean Thinking

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.

Written by Published in Agile

Over the last 6 posts, I have been looking at estimation. First, we looked at why we estimate, then we looked at some of the pitfalls in traditional estimation methods - the way we mistake accuracy for precision. Then we looked at some of the Agile estimation techniques - story points and T-Shirt sizes and the way they are designed to overcome the accuracy vs precision problem. We saw that while they generally do a good job, they also have some fairly serious pitfalls of their own. In the last two posts, we looked at taking T-Shirt sizing one step further and allowing only two sizes - small and extra-large (too big). By doing this we saw how the main pitfalls in the agile estimation techniques were overcome. We also looked at some of the main objections to story counting and my arguments on how these objections can be overcome.

I'm not the only person to come up with this technique. It's doing the rounds at the moment under the name "No Estimation Movement". Apparently I'm part of a movement. Cool.

Written by Published in Agile

In the last post, we looked at estimating by essentially not estimating. To do that we broke down stories into two categories - small and the rest. Small stories were ready to be accepted into the team's backlog, the rest were too large and need to be broken down further. By doing this, velocity becomes just a count of stories completed and all the hassles involved with story point estimation just go away.

To me, this is a real no-brainer. Why wouldn't you estimate this way? But whenever I mention this in polite company, I tend to get some uncomfortable silences, strange looks and the inevitable - "but....". These buts, tend to come in three types -

Calendar

« April 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