Marcin Niebudek wrote an article, in which he adds a budget line to an agile burn chart, measuring both in percentages.  Nice to see I’m not the only one doing that. (Even if he does draw the chart up the “wrong” way ;-)

I’m looking forward to being part of an interesting conference, and hopefully helping to lift the profile of EVM in New Zealand.

Link to presentation abstract

( The abstract’s reference to “Number 8 wire” may be unclear to overseas readers :-)  The phrase simply means “New Zealand ingenuity”, in this part of the world.)

This is particularly important when describing it to people outside EVM’s traditional strongholds of defense and aerospace.  Outside those areas, EVM is under-utilised, and I suspect much of the reason is due to its apparent complexity.  I’ve been an EVM fan for about 5 years now, and I still come across unfamiliar acronyms.  If EVM is to be more widely used, it has to be presented in a way that is accessible to a wide audience.

Here’s what I came up with:

EVM, Distilled to a Pair of Simple Rules

Expanding on Rule 1

We compare actual cost with actual progress because that is the only comparison which bears any relationship to the final actual cost of the project(*). In projects run without EVM, it is common to compare actual cost with planned cost instead.  That simply tells you whether you are spending money as fast as you planned – a fairly useless thing to know if don’t know how much progress you’ve achieved for your money.   Another flawed alternative is to compare actual progress to planned progress.  That can be misleading – you may be making enough progress, but overspending (e.g. on overtime) to keep up with the schedule.

We make the comparison numerically because that’s the best way to get an objective comparison, minimising the subjective bias that tends to creep into our personal assessments of project status.  Making a numerical comparison necessitates one of EVMs most distinctive features: cost and progress must be measured in the same units.  Traditional EVM solves this by measuring progress in dollars, which is counter-intuitive for the uninitiated.  In the ‘lite’ EVM approach which I advocate on this site, cost and progress are both measured as percentages so they can be compared easily.

Expanding on Rule 2

Rule 2 necessitates another of EVM’s distinctive features: to predict the future from the past, we must measure the size of past and future tasks in the same way.  Because estimated size is our only measure of size for future tasks, we must also use it as our measure of size for completed tasks.  I.e. our progress to date is calculated as the sum of the estimated sizes of all completed tasks (not their actual sizes).

But the biggest challenge with rule 2 is psychological,  not technical.  When a project is going badly, we want to believe that the future will be better than the past.  We instinctively convince ourselves that we can catch up.  Sometimes that’s true (as long as our corrective action is appropriate), but sometimes it’s not. The great thing about EVM is that it provides an objective measure, independent of our tendency to kid ourselves. That objectivity can feel uncomfortable at times — particularly on those occasions when we actually are kidding ourselves :-)

But look at it this way: the impartial prediction provided by EVM is actually a good thing.  How many times have you been on a project where you knew it was doomed, but those around you (or more likely, above you ;-) kept insisting it was going to be OK?   With their heads buried in the sand, the project probably got even worse(**).  But what would have happened if they had used EVM instead, and if they had followed rule #2? They may well have responded to the problem with something more productive than denial.

EVM actually helps you respond to problems in a productive way.  It gives you the bad news relatively early (e.g. approx 20% into the project).  If you get the bad news that early, you can usually do something about it.  After you’ve done so, EVM can show  how well your corrective action is, or isn’t, working.

My point with rule 2 is that  it’s not enough to simply wish, hope or believe that the future will go more smoothly than the past. For example, it’s not enough to hope future tasks will be completed at their estimated costs, if EVM shows consistent overrun in the past.  That’s just kidding yourself.  Instead, you have have to actually take meaningful corrective action.

If you’re serious about project management, you must be serious about obtaining an accurate and impartial assessment of project status.  Earned Value is the best way to get it.

Feedback Please

Do you find these two rules useful?   How could I explain them better?

If you are not currently using EVM, do these rules help to explain what all the fuss is about?

If you are using traditional EVM, do you feel these rules fairly represent the “heart” of what you are doing?  Or are they off-target, or merely stating the obvious?

Footnotes

(*) An exception would be if you really can cancel-after-any-phase.  In that case, you know what your final cost will be – it will be your pre-arranged project cost. (You just don’t know the final scope, unless you predict it with EVM.)  Another exception would be if you have linear planned progress and guaranteed constant team size. In that case, cost is directly proportional to elapsed time, so you can use your linear planned progress as a proxy for actual cost.  I believe that many Agile processes implicitly assume that at least one of these exceptions applies. It would be better to make the assumption explicit, to more readily detect cases when it doesn’t apply.

(**) To be clear, no, this paragraph is not a reference to any of my current colleagues or bosses. The now-historical situations that inspired it shall remain nameless ;-)

1. Important, and
2. Learnable (with time and practice)

The video is an edited extract of my talk at AgileRoots 2009.  For the benefit of people who, like me, prefer skim reading to watching videos, this post also includes a written transcript (below). 

(or click here to open at YouTube)

Transcript

(Transcript matches video, but has had headings added, and some minor grammatical tidy-ups)

My Own Story

I started off as the stereotypical shy nerd when I entered the industry [in 1995] and I had a realisation that, if I carried on like this, it wasn’t going to be very good for my career.  So I said to myself, “You’ve got to do something about this”.  So one of the things I remember doing was forcing myself, every morning, to say hello to the receptionist – and that felt like a challenge for me.  (I hope that most people in the room are starting from a less “challenged” starting point ;-)

Your People Skills are Changeable

The big thing that I’ve learnt from my personal journey, and from some of these fields that we’re going to talk about today, is the level of change that you can undergo personally, in your skills and enjoyment of this side of work.

…[As] Alistair [Cockburn] mentioned earlier, we should study psychology.  As best I can, as someone with a full-time job as a nerd, I have tried to study some of these things in my spare time.  And I’ve been really encouraged to find that this notion of, ah, these key skills and aspects of our personality,.. I’ve been very pleased to discover that they are far more changeable that I had ever thought they were.  And probably most people in IT don’t realise how changeable these things are.

Examples of “Personality Change”

One of the fields that touches on this area is this thing called Positive Psychology (which is this really seriously-cool thing, which I don’t have a lot of time to talk about today).  One of the foundation books in that field is a book called “Learned Optimism”.  It describes how you can permanently change your level of optimism.  Wow! Who thought you could do that?  Before the book was written, who thought that was a valid and useful thing for a person to do?  So the level of change in this area is potentially very large.

Now you can’t change everything.  The corresponding finding on happiness, from Positive Psychology, is that you can change about 40% of the happiness that you have in life.  The other 60%, you probably can’t do anything about.

The Agile Movement is Missing the Boat

In another aspect of my personal journey, not only have I had to learn the stuff I’ve just been talking about, but I’ve had some real ups and downs in the successes of my interactions with people at work.  Some have been very successful, and some have been just complete train wrecks.

So I thought OK, Agile says it’s about “Individuals and their Interactions” – surely the Agile movement can tell me how to do this stuff.   So I jumped on Google and I found Alistair’s wonderful collaboration page… and nothing else.  There are thousands of things on tools and processes, thousands of things that tell me how to do TDD – various factions of TDD – the mockists versus the classicists, and the factions of the mockists.  But when the agile manifesto was put together on the hills up there [above Salt Lake City], 8 years ago, it was saying “Individuals and Interactions” is more important than processes and tools.  I certainly agree with the person who said earlier in the panel discussion (Mike?), “Is Agile broken?”.  In this sense I think it is broken.  We’re not putting emphasis in the right place here.  We’re talking and talking and talking about processes and tools, when Individuals and Interactions is the thing that makes the difference, and we’ve always said it’s the thing that makes the difference [we just haven’t done very much about it!]

Who’s Not Missing the Boat?

So, I started to look elsewhere [outside Agile].  And I discovered this thing called Organizational Behavior, which defines itself like this: “the study and application of knowledge about how individuals and groups act in organizations”.   I read that definition and thought, “That’s individuals and their interactions.  That’s the thing I’m looking for.  That’s the thing that Agile’s not telling me about.”

There’s Positive Psychology [as I mentioned earlier] and there’s this very new thing where the two meet, called Positive Organizational Psychology [aka Positive Organizational Behaviour].  There’s not a lot of stuff out there yet, but it’s touching on some of what I’ve talked about today, these notions that you can learn all sorts of stuff that’s relevant to your ability to have a successful interpersonal relationship at work.

“Political Skill” at work is a fascinating thing.  Now, normally “political” has some kind of negative connotations but basically what these [researchers] are talking about is the “good side of the force”, so to speak, and the idea that you can learn how to influence people, for good, at work.  The interesting thing that they teach – and I was relieved to find it, because I wanted to tell you guys that it was true, so I had to find out whether it was ;-) – is that you can learn this stuff: being able to influence colleagues or managers more successfully than you do now, being able to sell an idea or interact is, by and large, a learnable skill.

A Wake-Up Call to the IT Industry

And yet, so much of the industry, including the part of the industry that we’re in, is not necessarily investing enough effort into it.  It’s perfectly normal for geeks to talk about doing their Microsoft certification, or their Java certification, but who ever talks about learning this stuff?  Who even knows that you can learn it?  If you don’t think you can learn it, of course you’re not going to talk about it, of course you’re not going to try.

And so one of the things that I hope comes out of this talk here today, is that when we go back to our various places of work, y’know, there’ll be people sitting on adjacent desks who are like I was 10 or 15 years ago – geeks who think they can’t do this, and don’t know its learnable.  If we can take some of this message back to them, I think that could be a really powerful thing.

What Does It Actually Mean to Learn This Stuff?

There’s this guy [Anders Ericson] who’s done a lot of research on expertise: what does it take to become an expert in tennis, in some other sport, in computer programming, or in interpersonal interaction?  And what he’s found is that there are several key notions.  The one I’m going to single out today is a thing called “Deliberate Practice”, which basically means not just accumulating a lot of years of experience, but learning. So, for example, if I go down to the tennis court, and I do the same bad serve 20 times in a row, I haven’t learnt.  If I do my bad serve the first time, and I reflect on how I could do it better, and I do it slightly better, and I keep repeating that cycle, that’s deliberate practice (at least, in my naive understanding of it).  The thing he finds, is that it does take time.  The same research said it takes 10 years to become an expert.  I’ve talked a bit about my journey in this area, and I’m not an expert yet, but certainly it’s taken me a number of years.

So this is not a thing you take away and “sha-bang” it’s wonderful!  This is a process you can take away, and start to put into place, and it will bear fruit over the course of months and years.

On Being Yourself

When I first started trying to learn this some time ago, I read a book on how to be a leader in a technical field, and I felt like it was saying, “John, you’re like this, and good technical leaders, well, they’re like that”. It was kind of offensive, to suggest I should have some kind of personality transplant, and it seemed unlikely to succeed.  So it really put me off, and I actually said, “Well, I don’t want to be a technical leader then”.

The interesting thing that comes out of the management research, completely independent from Agile, is that the best managers are not trying to conform to some stereotype of who a manager is. They are being themselves, more skilfully.  This is a learnable skill, known as Authentic Leadership.  It takes the pressure off.  If you say to yourself, and it’s true, that, “The goal here is to simply be a more skilful version of myself”, the pressure’s off, because you’re not trying to give yourself a personality transplant.  You’re not trying to conform to something that’s completely different.  You’re actually trying to do the thing that will work best for you, and happens to be the best way to lead and motivate anyway.

Who is this Message For?

This is not about the people who are on your org chart.  This is about the people who are not even on your org chart: people who sit cutting code, people who sit at their desks and don’t talk to their fellow developers, and people who sit at their desks and talk too much and push their opinions around.  (I’ve been in both camps, and I’m trying to learn to step out of them into more positive territory.)

This is about empowering the team.

Learning by Reflection

This is not necessarily about training courses.  The great thing about this deliberate practice stuff, is that you can learn it by yourself.  One of the interesting stories I came across was a CEO, 35 years old, in charge of this big company, and he got there on the back of his interpersonal skills.  They asked him, “How did you build those skills?”  And he said, “After every meeting, when I came out of the meeting, I’d come back to my desk, I’d get a notebook, and I’d write down lessons learned from that meeting (in terms of interpersonal interaction)”.  He basically never read this note book, but it was a mini personal retrospective thing (like we do in Agile at the end of each iteration). This was a little thing after each meeting and it took him to a point where he was in this very important position, on the back of his interpersonal skills.  For me, I haven’t gone down the notebook route, but I’ve certainly found that deliberate practice, even without a mentor or a buddy [to discuss things with] is a powerful, powerful thing.

So you can learn this.  Teams can learn this, individuals can learn this.  You don’t need high-flying consultants.  You don’t need team building courses with ropes and swings and bridges and stuff.

Conclusion

It does take time.  There’s an element of time and patience involved, but there’s a great, great payoff at the end.

By the way, this means commenting finally works properly again.

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:

1. 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.
2. 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.

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. [Done] 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.

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).