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.

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

- via Bob Sutton

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.

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.

Think back to the Agile Manifesto.  At the moment, we seem to have:

Roy Osherove helps to redress the balance in his recent recent series of posts on unit testing  – why insist on tools so advanced that the typical individual won’t use them?

But my concern isn’t just about making the tools approachable. The much bigger issue is simply that we should devote attention to the "individuals and interactions" side of the equation.  Never mind the tools; let’s talk about the people.

How can we interact more successfully with our colleagues?  How do we maintain a positive and supportive social fabric in our teams?  How can we encourage openness, even from the bearers of bad news?  How do we both encourage and resolve differences of opinion?  How can we get non-threatening feedback about our people skills?  How do you even ask for feedback, if your team isn’t used to giving it?

There are so many relevant and important questions on the people side of the equation.  Yet I don’t see much written about them.  The vital social elements are often dismissed as "emergent properties", expected to take care of themselves as long as we follow the right processes.  They deserve more attention than that. 

As geeks, we find it easy to talk about processes and tools.  Most of us entered the profession because of our technical skills, and didn’t necessarily have (or even want) strong interpersonal skills.  But, like the man who searched for his keys beneath a lamppost – not because that was where he dropped them; but because that was where the light was best – we’re looking in the wrong place.  The prime ingredients for success are not in tools; instead they are over in that unfamiliar place called interpersonal interaction.  We don’t understand that place so well, and our usual techniques won’t help us (you can’t attach a debugger to an errant colleague’s head!)

Fortunately, there is a lot we can do to improve our people skills.  I’m going to be posting some ideas over the next few months.  But I’m no expert.  I’m just a geek who likes to venture away from the lamppost, so I’m very interested in hearing from you.  Which ideas and resources have you found helpful?

We need to give this topic the attention it deserves.  If we do, it won’t seem so unfamiliar after all.  In fact, it might be fun.

How should we reach wise agreements?  How should we reach agreements that create good outcomes for both parties?

There are excellent answers to these questions.  The answers stem from extensive research and apply to all kinds of negotiation, from buying used cars to nuclear disarmament.  They were documented by Roger Fisher and William Ury in their classic book, “Getting to Yes”.  (It still sells over 3000 copies per week, 25 years after it was first published).  Fisher and Ury have applied their findings in many areas, from industrial disputes and corporate mergers to the highest levels of international politics.  They have personally facilitated peace talks in war zones around the world.

Fisher and Ury call their approach “principled negotiation”.  It contains four key elements:

• Separate People from the Problem
• Focus on Interests, not Positions
• Invent Options for Mutual Gain
• Use Objective Criteria

Each is explained in “Getting to Yes”.  Here, I’ll discuss just one – Focussing on Interests, not Positions.

Focus on Interests, not Positions

Kent Beck claimed that customers don’t have requirements, only wishes.  The technique of “Focussing on Interests” offers a theoretical basis for that claim and shows us how to apply it in practice.  “Focussing on Interests” shows how to negotiate requirements, for the benefit of both customer and supplier.

We often think of negotiation as something like this:

Tourist:             How much?

Shopkeeper:     100

Tourist:             I’ll give you 50

Shopkeeper:     90

Tourist:            60

Shopkeeper:    80

Tourist:            70

Shopkeeper:     75

Tourist:            It’s a deal!

That’s “positional bargaining”.  The emphasis is on stating clearly defined positions and splitting the difference in a series of compromises.

In “Getting to Yes”, Fisher and Ury show that we should focus on interests, not positions.  An interest is the underlying need, while a position is just one particular way to satisfy it.  Here’s a real-life example:

In 1978 Egypt and Israel negotiated over the Sinai Peninsula, which Israel had occupied a decade earlier in the 6-day war.  Their positions were completely opposed: they wanted the land and could find no mutually acceptable way divide it between them.  The answer lay in focussing on their interests.

“Israel’s interest lay in security; they did not want Egyptian tanks poised on their border ready to roll across at any time. Egypt’s interest lay in sovereignty; the Sinai had been part of Egypt since the time of the Pharaohs.”

(Fisher and Ury, 1981, p. 41)

While their positions were completely incompatible, their interests were not.  So the Sinai was returned to Egypt (meeting Egypt’s interest in sovereignty) but with large areas demilitarized (meeting Israel’s interest in security).

In software development, we need to identify the interests that lie behind positions. A customer may state their position as, “We must upgrade the system to a 3-tier architecture.”  What is the underlying interest?  Perhaps users complain about slow performance and the customer expects the 3-tier architecture to speed the system up. The stated position isn’t necessarily the only way to satisfy the interest.

I think this is why Kent Beck said “There are no such things as requirements, there are only wishes.”  (Quoted in Crystal Clear)  Explicitly-stated requirements are usually positions.  As such, they are merely one possible way to satisfy the underlying interests.  Software engineers can, and should, seek better ways to satisfy the customer’s interests.

For example, I worked with a customer who insisted their new system needed a web front end.  Having considered their particular requirements, I realised we couldn’t build a web client within the available budget.  It would be cheaper and less risky to run a rich client on each user’s desktop.  Our positions were incompatible: the customer’s wanted a web client and my (unspoken) position was the opposite.  But consider our interests.  The customer’s interest was in minimising the cost of administration.  They knew a web client would allow low-cost central administration.  (In other words, they didn’t actually need a web client, what they needed was low cost of ownership.)  My interest was in minimising the cost of development.  I knew a rich client would deliver more “bang for buck”.   Having identified our interests, we decided on a rich client with browser-based deployment.  It met the customer’s interest in easy deployment and my interest in faster development.  The project was a great success.

Conclusion

Focussing on interests, not positions, is a powerful tool for creating project success.  Software development guru Alistair Cockburn wrote about it here:

“I think I was in the industry 20 years before I ever saw someone renegotiate the requirements the users gave him. I was astonished, because he had turned a large nasty convoluted set of requests into one that we almost had ready. Just by showing up and suggesting to the users they maybe didn’t need what they asked for.”

Why did Alistair wait 20 years to see this?  Why don’t we re-negotiate requirements more often?

Firstly, we omit these negotiations because we are unaware of the difference between interests and positions.  We say “the customer is always right” when we should say “the customer is always right about their interests“.   The customer is not always right about their positions.

Secondly, we omit these negotiations because traditional waterfall processes discourage them.  Consider a traditional software purchase scenario in which the customer issues an RFP (Request for Proposal) to several competing vendors.  The customer states their position (as a set of requirements) and the suppliers reply with their positions (as a price and schedule to implement the requirements).  Each party states their position once.  It’s “one shot” positional negotiation.

Both parties would be better served to engage in dialog about their underlying interests.  Such dialog is encouraged by agile processes.  They promote discussion, provide better opportunities to explore interests, and avoid premature “lock in” of positions.

Fisher and Ury’s style of negotiation is not about winning and losing.  It’s about everybody winning.  It works in family feuds, industrial disputes, corporate mergers… and software development.

Make sure you read their book.

• building trust through visibility, honesty and competence
• Jeff Patton’s Requirements Considered Harmful.
• Jerry Weinberg gives a nice example here (notice how the best outcome meets interests rather than positions)