Lean Thinking

02 September 2014

SAFe SPC Course

Written by Published in Agile

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?

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.

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 -

Written by Published in Agile

 

Last time we looked at T-shirt sizing and some of the benefits and problems that method has. We found that its greatest benefit was also its biggest disadvantage. The use of something completely abstract (T-shirt sizes) removes all our cognitive biases around numbers but by not using numbers we can’t really compare estimates against each other and make predictions except by converting back to numbers which of course brings our biases back.

We can use T-shirt sizes usefully if we make an adjustment to the scale we use. Rather than have Small, Medium, Large and Extra Large, let's just have Small and Extra Large. Now, this would obviously never work for clothing because people come in a range of sizes. Stories come in a range of sizes as well, so what gives? What makes this useful? The trick here is that unlike people where we can’t dictate what size someone should be (outside the modelling industry and certain trendy nightclubs), we can, and should, be pretty strict about what size a story can be before we accept it onto a sprint.

Written by Published in Agile

Last time we started to look at relative estimates and the most common method of relative estimation using story points. We looked at why they work well but also at some of their limitations. The biggest limitation is the fact that they are numbers and we have some built in cognitive biases when it comes to numbers. We mistake precision for accuracy and tend to agonise for ages over the story point numbers which turns story points from a fast, lightweight and accurate method of estimation into a slow, heavyweight and accurate method. It's still accurate but we waste a lot of time.

There is a way to keep the accuracy of story points but remove the cognitive biases we have around numbers. It’s a simple as not using numbers in our estimates. The usual way to do this is by using T-Shirt sizing – stories are small, medium, large or extra-large. Some teams go a bit further and add Extra Small and XXL but we’re getting into false precision there so I would recommend against that.

Written by Published in Agile

Last time we looked at the concepts of accuracy and precision and how getting the two mixed up can lead to all sorts of problems. We also looked a little at our cognitive bias, that has us assuming that precise numbers are also automatically accurate. The upshot of that is that we humans are absolutely terrible at estimation. We mistake precision for accuracy and our accuracy is really bad to begin with.

That last statement is only half true. We are really, really bad at things like guessing how many jelly beans are in a jar, or how tall that person is, or how much does that thing weigh. What we are bad at is absolute estimates. To make up for that, we are really, really good at relative estimates.

Calendar

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