AgileKiwi

Does our intuition fail us?

noreply@blogger.com (John Rusk) — Sat, 23 Jan 2010 02:48:00 +0000

Why do so many projects seem to be OK, but, when you get near the end, they turn out not to be OK after all? Everyone thought you were going to make the target date, but at the last minute… well, no you couldn’t.

I’d like to suggest an answer. Let’s illustrate it with an example. Consider an agile project that’s been estimated at 375 points in size. (To my non-agile readers, “points” are just a relative measure of task/feature size. So for instance, a 20 point feature is estimated to require twice as much work as a 10 point one. In this project, all the features add up to 375 points).

Also, imagine that our sample project is scheduled to take 12 weeks and we are now half way through the project. After 6 weeks, the team has completed 132 points’ worth of work. The team leader reports that they are a little behind, since by this time they should have finished 187 points (half of 375). After speaking with everyone on the team, he is confident that they can make up the lost ground.

Question: how much faster will they have to work, if they are to finish the project on time? Will they have to work 10% faster than they have so far? 20% faster? 30% faster?

Get your own gut-feel for the answer, then scroll down.

The answer is eighty four percent. To deliver on time, the team has to produce 84% more output, per week, than they did in the past. That’s almost double.

Most teams, I suspect, don’t realise just how much faster they need to go. We look at the status, and think,”Well, we’re a little behind, but it’s not too bad.” We might even crunch some numbers. In this example above, the team should have completed 50% of the work, but they have only done 35%. You look at the figures, see 50 and 35, do the subtraction, and end up with 15%. That doesn’t seem to bad. 15% is not very much, and seems well within our abilities to compensate for – perhaps with a little extra work, and good intentions to “work smarter”.

But we’re fooling ourselves. We are forgetting two things:

The gap is not 15% of the project, it is 15 percentage points out of the 50 percentage points we are supposed to have by now. 15 / 50 is actually a 30% deficit. So we are further behind than we think.
Not only are we further behind than we think, but catching up is harder than we expect. We look at the remainder of the project and think, “We just have to go a little faster than we planned”. That’s true enough, but we forget that “faster than planned” really equals “much, much faster than we have actually been going”. After all, we do not have to achieve an improvement relative to the plan, we have to achieve an improvement relative to reality!

It is these two factors which mean that it requires an 84% speedup to compensate for a “15%” gap.

An example to do in your head

In the example above, I deliberately used numbers than were hard to manipulate in your head. (Well, at least, they were hard to manipulate in mine ;-)

So here’s a really simple formulation of a similar problem, just so you can convince yourself than I’m not talking rubbish:

Again, imagine a project at the half-way point. This time, the team has done exactly one third of the work, i.e. 33%. Think of it this way: in their progress to date, they have done one on third of the work in half the time. To finish on schedule, they must now do two thirds of the work in the other half of the time. They must do twice as much work in the same amount of time – a 100% increase in speed.

Conclusion

Teams can’t speed up by 84% or 100%. It just doesn’t happen. (At least, not when holding costs constant – and generally, not even when spending extra.)

When projects fall behind, our intuition lets us down. We have to rely on sound data and analysis instead. I believe the best answer is to use Earned Value analysis. A simple Earned Value chart like this goes along way to correcting our faulty assumptions.

Agile Roots Presentations Online

noreply@blogger.com (John Rusk) — Tue, 14 Jul 2009 08:40:00 +0000

Presentations from the Agile Roots conference are now online.

My full presentation is here, although sometime I hope to isolate the middle section (on workplace interpersonal skill) so it can be viewed as a stand-alone 15-min presentation. As it stands, the presentation is 30 minutes on these topics, with 5 mins of questions at the end.

Virtually all the presentations are up now. If you're wondering where to start, I can recommend Kay Johansen's excellent session on Agile Testing, which I learnt a lot from; and Jeff Patton's two-part workshop on story mapping, because story mapping is such an important idea. (And Jeff made it so interesting, it didn't seem like it was 3 hours long.) I thoroughly enjoyed the whole conference, and can recommend every session that I attended. Now that the videos are up, I'm looking forward to seeing the ones that I missed.

References from my Agile Roots presentation

noreply@blogger.com (John Rusk) — Sun, 28 Jun 2009 01:03:00 +0000

At Agile Roots, I promised to post references for my talk "Better Agile Through Stealing". Here are my faviourite references on the topics I talked about. For each of the books, the main link is to a "dead tree" version of the book, with a secondary link to an e-Book version (if available).

Evidence-Based Management

All the key resources can be found at evidence-basedmanagement.com. The site gives an overview, links to books by Jeff Pfeffer and Bob Sutton (the key authors in the field), and also contains some podcasts that make a great introduction to the ideas. Note that their focus on adapting to your particular situation is similar to "situationally specific processes" in agile’s Declaration of Interdependence.

Principled Negotiation

The classic book is Getting to Yes by Fisher and Ury (eBook). I’ve described here how it relates to negotiating scope, and defining a situationally-specific process.

Qualifications-Based Selection aka Competitive Tenders without Prices

I’ve written an overview in the second half of this page, and find this FAQ very relevant (even though it is written about architecture and engineering rather than software).

The Winner’s Curse

I’ve posted an overview here, which includes links to the (few) resources that I’ve been able to find on how the Winner’s Curse relates to Software

Individuals and Interactions

In the talk I tried to break this down into four key themes, as follows:

1. Important

My favourite book highlighting the importance of these issues is In Good Company by Cohen and Prusak, which focuses on the topic of Social Capital.

2. Learnable

The "learnable" theme is supported by a collection of different resources.

On the general notion that we can change more than we might realise, I’d cite the literature of Positive Psychology as an example – even though it focuses on topics like happiness and optimism rather than workplace interaction. (E.g. Learned Optimism by Seligman and The How of Happiness by Lyubomirsky)

On the particular topic of changes in personality, either "real" or "indistinguishable from real", check out Personality Trait Change in Adulthood (pdf) by Roberts and Mroczek (particularly the section on individual changes), plus a couple of podcasts which I'll post links to shortly. (The podcasts contain the examples I cited in my talk, but I've temorarily misplaced the links!)

And for learnabilty of sensitivity to interpersonal dynamics, see a brief section in the middle of this podcast from Rob Goffee.

Admittedly, of all the themes in my talk, learnability-through-practice is perhaps the least supported by research and literature. I suspect this reflects a relative lack of interest in learnability on the part of academics, particularly in those courses which emphasis the traditional HR skills of screening people at recruitment time and then training them with short, focussed training courses. The process that I talked about, which consists of gradual self-directed learning over months and years, seems to have received less attention.

3. Deliberate practice

This was the key learning technique that I focused on in the talk. My views are inspired by the work of Anders Ericson, who coined the term "Deliberate Practice".

4. Authenticity

The concept of Authentic Leadership can be summarized as "Be yourself with more skill". That description comes from the book Why Should Anyone Be Led By You? by Goffee and Jones (pdf eBook).

It’s also worthwhile to make particular mention of political skill, which is one aspect of workplace interpersonal skill. "The" book on the subject appears to be Political Skill at Work by Ferris, Davidson and Perrewe, although I also found some of the chapters in Positive Organizational Behavior by Nelson and Cooper (ebook) to be helpful and relevant.

Finally, Alistair's post on collaboration is an excellent resource (and a topic worthy of more attention, both from academics and the agile community).

Speaking at Agile Roots

noreply@blogger.com (John Rusk) — Fri, 22 May 2009 07:56:00 +0000

The Agile Roots conference is on, next month in Salt Lake City. If you haven't checked out the conference web site, hurry over there now!

If you like this blog (and presumably you do, since you're reading it ;-) I think you'll love the conference. It's a new and different kind of agile conference, focussing back on the core principles of the agile movement. In one respect, it's like a giant retrospective for the agile movement as a whole -- but it's also much more than that. For details, see this page on the conference blog. I strongly encourage you to attend if you possibly can.

By the way, I'm presenting a session with the deliberately strange title of "Better Agile Through Stealing". (Thanks to Bevan Arps for the idea for the title.) The talk is consistent with the material on this site, but most of it is brand new material which I haven't blogged about yet.

Hopefully, I'll see you there!

Detailed article on burn charts meet EVM

noreply@blogger.com (John Rusk) — Sat, 16 May 2009 03:49:00 +0000

I recently wrote an article on burn charts as a simplified version of Earned Value Management. It is much more detailed than my previous page on the subject.

You can download the article here.

Fallible estimates + Competition = Winner's Curse

noreply@blogger.com (John Rusk) — Mon, 30 Mar 2009 08:41:00 +0000

Some time ago Steve McConnell and I had an interesting debate, via his blog. I suggested that when we combine estimates such as those we have in software (which have high uncertainty early in the project) with a competitive market containing price-sensitive customers; then market forces conspire to bias customers' choices towards those supliers who have accidentally under estimated.

It turns out the concept has a name, "The Winner's Curse", and it's been known to economists for over 200 years!

I've updated my original post with details and a link to an excellent article from the Simula Research Lab in Norway.

Target Cost Contracts

noreply@blogger.com (John Rusk) — Tue, 17 Feb 2009 08:30:00 +0000

I've just posted an article on one way to formulate target cost contracts for agile projects. I've used it myself on a small number of projects.

Please comment here, since comments are not supported on the article itself.

People Over Process: the Importance of Social Capital

noreply@blogger.com (John Rusk) — Sat, 03 Jan 2009 00:30:00 +0000

I recently enjoyed reading In Good Company. The book is addressed to a general business audience, but I found it very relevant to agile software development (particularly agile's emphasis on people and their interactions). I recommend it to anyone interested in that side of agile.

From the back of the book:

"In Good Company is the first book to examine the role that social capital -- a company's "stock" of human connections such as trust, personal networks, and a sense of community -- plays in thriving organizations."

As the authors readily admit, some of it seems like common sense -- but it happens to be the kind of common sense that is too commonly ignored! And it's not all common sense, I learnt some important things which I'd never noticed before.

Great Video From James Bach

noreply@blogger.com (John Rusk) — Tue, 30 Dec 2008 03:40:00 +0000

I've just watched this on YouTube.

For those who don't know, James Bach specializes in testing, but most of what he says is applicable to agile in general. He covers the "people over tools" point very well. As I've written before, the importance of people over tools is incredibly important, but seems to have been overlooked by much of the agile community. (Perhaps that's because it requires on-going effort and learning, in an area that doesn't come naturally to many of us geeks, and so it doesn't look like a silver bullet.)

James' own blog post on the video is here.

Switched to blog format

noreply@blogger.com (John Rusk) — Tue, 30 Dec 2008 03:13:00 +0000

I've finally switched over to a standard blog engine for this site, so most new material will be in the form of blog posts.

Old material will remain as is. The most important old pages are listed here on my homepage.

The reason for the change in technology is convenience - it's just quicker and easier to post in the blog format. That's partly for technical reasons, but also because blogging is an excuse to give up my attempts to impose hierarchical structure on the site ;-)