Untitled

See the full gallery on Posterous

I’ve been thinking about this for a while. Imagine there was this tool that everybody said was fantastic – let’s say it was a wood chisel, let’s call it the Wonder Chisel. And all of the people from the Wonder company, who make the Wonder chisel claim that if you use the Wonder Chisel, your carvings will be totally awesome. And indeed, many skilled craftsmen who already understand how to use tools and know a lot about wood carving, achieve great things with the wonder chisel. But there’s a problem. Every amateur, not skilled in the art of wood carving, and I mean absolutely every one of them when they first pick it up, stabs themselves in the eye with this chisel. That would be a problem wouldn’t it? You would probably say that the wonder chisel has some design flaws. You would probably want to take it off the market until you’d fixed them. You might even want to brainstorm some other ideas and then try them out with amateurs before you release a literally blinding product like this on the market again.

This is how I feel about the Agile concept velocity. It is a massively powerful concept because in a very short space of time it can give you an answer to the question that people seem (we’ll come back to that later) the most desperate to answer in any project – when am I going to get my stuff? The concept is really simple. How do you manage a project?

1. Make a list of all the things that you’re going to do on that project – this is called your product backlog

2. Estimate how complicated those things are – give each of the items on the backlog a number indicating it’s complexity – if you’re going to get fancy, use the Fibonacci series. How big is your backlog at the end of this? Let’s say you add up all the complexity points on the different items and it comes to 500.

3. With your team, plan to do a small number of these in a short space of time – let’s say, two weeks. We call this an iteration. Each of these things has a complexity score – so, let’s say you plan 50 complexity points.

4. At the end of the two weeks, count up the total complexity points of all the things that you’ve completed: THIS IS YOUR VELOCITY. And, it’s normally less than you expect it to be, for this example, let’s say it’s 30 points.

5. Here comes the clever part. Take this number, your velocity, 30 and divide it by the number of points remaining in your backlog.

 

= iterations = 30 weeks

And Ta Da! You have your answer to supposedly the most important question in project management. You’re very pleased with this and you show it to senior stakeholders, customers, programme managers. Unfortunately this is the bloody, stabbing in the eye blinding part.

Your senior stakeholders, customers and programme managers say one of two things:

Eye stab 1. Oh, the velocity is 30 is it? Well then next time I want it to be 60.

Eye stab 2. Really? The velocity of this other team over here is only 15, I think we should fire them.

Actually, there’s also a “slasher movie version” of statement one, where both eyes get stabbed and blood spurts everywhere.

Eye stab 3. “It can’t possibly take 30 weeks, I have a deadline in 10, I need you and the team to work 19x7 (yes, that’s 19 hours, 7 days a week and yes, this really happens) and “re-plan” so you can do 90 points per iteration.

Why are these things so bad? Well, actually the eye-blinding Wonder Chisel is perhaps a better analogy than it might appear. All of these ways of using the velocity tool blind the project. Let’s take them one by one.

ES1. If the team is “set the challenge” of doubling its velocity, there are really only two options:

·         Do a really bad job on twice as much stuff

·         Inflate the complexity scores on the stuff they do so that it looks like they’re doing more.

Actually, there is a 3^rd more “healthy” option.

·         Pay no attention and carry on as before.

But the first two really are blinding. If the team doubles its output, but lowers quality, then there is going to be a disaster in the future, and it’s been totally hidden from view. If the team starts inflating complexity figures, it means that you literally don’t know where you are with progress in the project.

Something similar happens with “ES2,” word gets out that a team’s being evaluated on the size of the velocity! And lo and behold everybody’s velocity is stupendously high and everybody is blind to how the teams are actually performing, how the projects are doing and when they will actually finish.

Actually ES3 is even worse. ES3 is like turning the lights out and squeezing the trigger on a machine gun.

What’s the answer! Sadly I don’t have one. This one of those situations where I’ve shown you that I know a lot about the problem – but I really don’t, yet, know much about the solution. There is at least one conclusion to draw from this:

If a tool is this dangerous for amateurs and they always do the wrong thing with it, you probably shouldn’t let them anywhere near it. Velocity is one of those tools.

I do have some suggestions about directions that it might be worth exploring. Coming back to a book that I’ve been talking about and thinking about a lot I get two ideas from Daniel Kahneman’s book “Thinking Fast a Slow”. One is the over-arching rule that Kahneman calls WYSIATI – What You See Is All There Is. Basically this means that people reason from what they can see and imagine – not from what they can infer logically and certainly not from what might be statistically most likely. From the disastrous performance of velocity in field trials I think we have to conclude that velocity makes visible and imaginable the wrong things.

Related to this idea is a finding that comes out repeat-ably in Kahneman’s book – whether people do the rational thing or the dumb thing in response to a given proposition – e.g. a set of bets with certain odds that pay off certain amounts – depends hugely on how the proposition is presented.

Finally, I’d like to suggest some ideas from a field that I used to be involved in – usability testing. One method used for interface evaluation was something called “cognitive walkthrough”. Idea of cognitive walkthrough is that a team of experts can evaluate an interface quickly by asking a series of questions about the interface at each stage (I’m paraphrase slightly because the original questions are a bit strangely worded).

1. Will the user try to achieve what the task they need to do at this stage of the process?

2. Will the user notice that the correct action is available?

3. Will the user understand that the task they want to achieve can be achieved by the correct action?

4. Does the user get feedback on whether the action is completed?

What I think is fascinating about this is that “velocity” as an interface fails at the first step. Velocity is a useless interface, or certainly the way we report it is no help because it will not make the user – i.e. senior manager, stakeholder, customer, programme manager want do the “right” thing. And what’s maybe more interesting is whether the only way to get the user to want the right thing as an answer to question 1, is to present the right “correct” options to explore as answers to question 2. Food for thought, and maybe another blog post.

 

Posted via email from Agile Lab Blog

Try something new

The best way to hone your knowledge in exploring skills is to keep yourself honest.  You won't discover and invent anything unless you get used to taking risks and trying new things on a regular basis.  Make it a practice to try at least one new thing every time you gamestorm.  It will keep you honest, force you to continuously develop and improve, and keep things fresh and alive for you.  You won't inspire others unless you can stoke your own fires.

Gamestorming - Gray, Brown and Macanufo

Posted via email from What Stringer's Reading

Having a business meeting...

Having a business meeting without artefacts and meaningful space is like meeting blind-folded with your hands behind your back.  Yes you can do it, but why would you want to?

Gamestorming - Gray, Brown and Macanufo

Posted via email from What Stringer's Reading

Don't open and close at the same time

Don't open and close at the same time.  You can't be creative and critical simultaneously.  People's minds just don't work that way.  When you are exploring creative possibilities you need to shut down the critical part of your mind, and when you are making difficult choices, you should not try to be creative.  Keep them separate and do them in order.

Gamestorming - Gray, Brown and Macanufo

Posted via email from What Stringer's Reading

Opening, exploring, closing

Opening, exploring, closing are the core principles that will help you orchestrate the flow and get the best possibly outcomes from any group.

Gamestorming - Gray, Brown and Macanufo

Posted via email from What Stringer's Reading

The Stubby Pencil

A game has a shape.  It looks something like a stubby pencil sharpened at both ends.  The goal of the game is to get from A, the initial state, to B, the target state... In between A and B you have the stubby pencil - that's the shape you need to fill in with your game design.

Gamestorming - Gray, Brown and Macanufo

Posted via email from What Stringer's Reading

Industrial Work vs Knowledge Work

In industrial work, we want to manage work for consistent, repeatable, predictable results.  Industrial goals are best when they are specific and quantifiable. In such cases, we want to ensure that our goals are as clear and unambiguous as possible. The more specific and measurable the goal is, the better.  When we have a clear, precise industrial goal, the best way to address the challenge space is with a business process - a series of steps that, if followed precisely, will create a chain of cause and effect that will lead consistently to the same result.

But in knowledge work we need to manage for creativity - in effect, we don't want predictability so much as breakthrough ideas which are inherently unpredictable.

Game Storming - Gray, Brown and Macunfo

Posted via email from What Stringer's Reading

Amelia Bedelias

In the early 1960s, the celebrated children's author Peggy Parrish introduced us to Amelia Bedelia, an overly literal housekeeper.  Among other things, Amelia makes a sponge cake with real sponges, replants weeds when told to "weed the garden," and hits the road with a stick when she's told that the family is going to "hit the road" when leaving for a camping trip.  My children squeal with laughter when they read about her comical adventures.
I often find myself laughing along with my children, until I think of the Amelia Bedelias I've met at work.  Suddenly, the mistakes that people make while trying to perform their jobs aren't so funny...

Gamestorming - Gray, Brown, Macanufo

Posted via email from What Stringer's Reading

Estimating IT Projects - Taking it Outside (my take on Ch23 of Daniel Kahneman's "Thinking Fast and Slow")

This is just a short note about something that should be very exciting  for anybody who’s involved in project management (I know, I know, there’s something oxymoronic about that sentence).  I’ve just been reading a book called “Thinking Fast and Slow” by Daniel Kahneman.  It was recommended to me by my friend, writer and professor of history, Richard Toye.  Sadly, it took me about a year to get around to reading it.  And then it took me three or four weeks to get around to chapter 23, entitled “The Outside View.”  Seriously, if you have anything to do with project management, especially IT project management, you should be ordering this book right now instead of reading this blog post.  And of course, with the magic of kindle, you could be reading it within a few minutes.

Chapter 23, “The Outside View” outlines one of those concepts that is so forehead-slapingly obvious that people who don’t experience it every day as a problem will say “so what.”  This is the momentous thing that this article says:

The project that you’re working on will probably take about as long, cost about as much as similar projects.

That’s it.  Earth-shattering huh? No?  You’re not convinced?  Well this wouldn’t be earth-shattering if it weren’t for one thing: this is almost NEVER the approach which is taken to estimating projects, especially IT projects.  IT projects are almost all estimated in this way:

1. Write down all the things that you think you want to get done in this project

2. Estimate how long each of those things is going to take.

3. Add up all those estimates (possibly divide by the number of people in the project team) – this gives you a number, X.

4. X is how long this project will take (depending on how negative you’re feeling, you might add in a small, or a huge extra figure of “contingency).

This is what Daniel Kahneman calls “The Inside View.” There a few problems with this method, even though it is used all the time.

·         The estimates of how long things are going to take is usually an optimistic estimate, very close to the minimum time that a task might take.

·         You’ve forgotten some of the tasks, or many of the tasks, or nearly all of the tasks that are actually involved

·         Most importantly, this estimate does not include, what the great philosopher Donald Rumsfeld referred to as “unknown unknowns” (interestingly, the next chapter in Kahneman’s book is about why it’s a really dumb idea to start wars but people do it anyway).

When you think about these problems, you start to see the power of what Bent Flyvbjerg in this article (http://flyvbjerg.plan.aau.dk/Publications2006/Nobel-PMJ2006.pdf) calls “reference case estimation.”  This is what Kahneman calls “The Outside View.” Looking at other projects that are similar to yours, how long they’ve taken and how much they’ve cost, deals with all three of these difficulties.

·         Optimistic estimates, when looking at similar projects get replaced by how long things actually took.

·         Looking at other projects gives you an idea of how many tasks had been forgotten, how much extra work was discovered.

·         Although the “unknown unknowns” on another project may be different, you at least get an idea of the scale of the surprises that might affect your project (actually, from my experience, a lot the things that come as a “total surprise” that derail projects, tend to not to be that surprising – they’ve derailed a ton of projects before and everybody knows this!).

 One of the things that I find really interesting about “The Outside View” and “Reference Case Estimation” is that Agile/Scrum methodologies already kind of do a version of it.  I don’t know of an Agile method that specifically says that you should go and look at other similar projects and see how they fared as a strategy for estimation – now that Kahneman’s book is out there probably should be one, very soon. But within an Agile project the velocity for each iteration does give you an idea, very quickly, of how long a project is actually going to take.  You have an effort-estimated backlog.  You have the velocity from the previous sprint, or an average from a number of sprints.  Possibly, you have a graph showing how “discovered work” is getting added to the backlog as you progress with development. This gives you a very good idea of how long it’s going to finish the project and my guess would be it’s a lot longer than the “ideal figure” provided by an “Inside view”/traditional estimation.

OK, so once we get to development, Agile methods are doing something right.  Good.  But that shouldn’t stop anybody who’s involved with trying to estimate the size and cost of IT projects up front from becoming inordinately interested in the size and cost of other IT projects which are similar to theirs, within their organisation.  As a project manager, charged by stakeholders with coming up with an estimate, and probably being tempted by everybody around you to take the “inside view.” You should be doing everything that you can to “take the project outside.”

This is my feeble explanation of this.  But don’t believe me, please read Kahneman’s book (his story about he got fooled by the inside view, and discovered the outside view while writing a school text book, is pretty compelling).

Posted via email from Agile Lab Blog

The Planning Fallacy

These findings shed new light on the planning fallacy and other manifestations of optimism. The successful execution of a plan is specific and easy to imagine when one tries to forecast the outcome of a project. In contrast, the alternative of failure is diffuse, because there are innumerable ways for things to go wrong, Daniel Kahneman - Thinking Fast and Slow
Sent from my BlackBerry® wireless device

Posted via email from What Stringer's Reading