Actually, no.

1. I’m interested in people who are not managers improving their people skills.
2. I’m interested in busting the myth that “people skills” is a topic exclusively for managers.
3. I’m interested in busting the myth that improvements in people skills must be initiated by managers or trainers.  I want them to be initiated by   people who actually want to improve their own skills.

If you’re interested in the same things, please comment below or email me (address on About page).

PS If you spot any problems with the email subscription, please let me know.  I’ve never used this particular email plug-in before, so I don’t know how it will work out.

Thanks to the folks at work for making this freely available.

• Link to online copy. As of 27 June 2011, you can purchase just the EV article (without having to buy the whole encyclopedia.) 
• Hard copy of the whole encyclopedia (about 120 articles on other topics, in addition to my one on Earned Value.  Each article is about 30 pages and all are peer reviewed by experts in the relevant field.)

I’m sorry but I cannot provide copies of the article here, since the copyright is held by the publisher.  By the way, I make no money from the sale of the article, so I hope you’ll consider me reasonably unbiased when I say that it’s well worth reading.  (Well, OK, about as unbiased as an author can be about his own work!).

To those who’ve seen my Earned Value talk with the animated interactive charts, this article does include some important details which I could not fit into the talk – in particular how to obtain objective "progress" numbers, and a discussion of how Earned Value relates to the critical path on software projects.

The article also forms a “bridge” between the purely graphical approach, which I use throughout my talk, and the numerical/mathematical approach which is the norm in the EV community.  As such, I believe it is one of the few pieces of writing on Earned Value which brings together all four of the following viewpoints:

• Agile project management
• "Traditional” (non-agile) project management
• An intuitive graphical “feel” for the subject
• The standard mathematical formulae of Earned value

I hope you find it to be balanced, reasonably comprehensive and, most  importantly of all, useful.

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

Updates

June 2011: another interesting one from Glen Alleman, on the relationship between the ANSI standard criteria and simple/agile EV.

July 2011: A nice burn chart example from the folks at Atomic Object.  It doesn’t include the cost line, and I’d prefer if it did, but it does offer a clean solution to some of the challenges of charting change.

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

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

The video is an edited extract of my talk at the AgileRoots conference, at Salt Lake City in 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)

(Update 2011: I now have an expanded version of this talk, prepared for a recent APN meeting. The new talk goes into detail about some concrete actions that we can take to improve our people skills. Hopefully I’ll find time to write blog posts about some of the details… Here’s one.)

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.