Reflecting on the end of another year, I feel that the interesting challenges in Agile are not about process, but instead about people.

Promoting and Enhancing People Skills

This has been a theme of this blog for sometime. The challenge for 2013, to myself and to anyone else who’s interested in the Agile community, is, “How can we encourage the development of better skills in this area?”  It’s one thing to highlight the fact that the Agile community seems to have forgotten its original value of “People over process”, it’s another to actually put the people-first approach into practice.  I see a lot of potential in the ideas of Chris Argyris, and in the techniques described in Crucial Conversations.  But how do we translate those ideas into our day-to-day work?  How do we encourage and help other people to use those ideas?  And, what other ideas should be be also taking on board? 

Knowledge vs Skill

We tend to think that, if we can just know the “right” thing to do – the right way to unit test, the right way to plan an iteration etc – then the problem will  be solved.  But much of human performance is not just about knowledge, it’s also about skill.  On an intellectual level, I “know” how to play tennis – but I seldom translate that knowledge into a winning performance on the court. 

When we look at the way we, and our team, are performing on a software project, it’s tempting to treat any deficiency as a deficiency of knowledge – something that could be addressed by training.  But really there are at least 5 different aspects to performance:

1. Knowledge.  You can get this through training, or you can follow a defined process.  I think we put too much of “agile” into this bucket.
2. Short-term skill: skill that can be developed, through practice and experience, during the course of the project.  Investing in such skills early in the project will pay off during the course of the project.    But it’s hard to draw the line between this and the next….
3. Long-term skill development.  This is deep expertise, which takes about 10,000 hours to develop.  You need at least some of your team members to have such expertise,  since without it your project will be much more difficult.  But since this kind of expertise takes years to develop, they can’t get it during the project.  They must have it before you start.  (However, just because a person is experienced, that’s no guarantee they have this kind of expertise.  Some experienced people do, some don’t.  Simplistically, its the difference between learning from one’s mistakes, versus merely repeating them.)
4. Innate general mental ability: this is the “RAM capacity” and “CPU speed” of the person’s brain.   To suggest that these qualities differ between people is both politically incorrect and self-evidently true.
5. Conscientiousness – the personal, internal motivation to work carefully and produce a successful outcome.  Research suggest conscientiousness plays a significant role in job performance.

For agile coaches, I hope this list poses a challenge to you, to extend your practice into the longer-term aspects of skill (#2 and #3).

For team managers, I hope this list underscores the importance (and difficulty!) of recruiting well.

For all of us, I hope this list reminds us that #3 on the list, expertise, is something that we must take individual responsibility for developing, within ourselves. It’s important because it has more impact on our success than short-term knowledge (#1) and skill (#2).  It is worth investing in because it is probably easier to to change your level of expertise than your level of intelligence (#4) or your personality (#5).  But, we must take responsibility for it ourselves, because the 10,000 hours it takes to develop will probably span many different jobs, and so can’t be left to any one employer.

Expecting and Accepting Individual Differences

When a doctor gives medication, she expects that different patients will respond to the same drug in different ways.  Some may require higher doses than others.  Same may have an adverse reaction to the exact same drug.

So why then, do we fall into the trap of one-size-fits-all agile?  Individuals differ greatly in their mix of the above 5 factors that contribute to performance.  Furthermore, the projects we work on, and the organisations we work in, also differ greatly.  So a given “prescription” for how to build software may be appropriate for some but not others.

The easy part here is to recognise the project context.  It’s easy to look around and see that projects are different.  The hard part is to recognise the differences within us.  When I read code, what goes on in my head may be very different from what goes on in my colleagues head – but of the two brains working on the problem, I only get to look inside one, my own.  It is naive (but common!) to assume that my colleague’s brain experiences the problem in a similar way to my own.  (By the way, I’ve found Advocacy and Inquiry helpful here.  It’s helped me to enquire not just into what other people are thinking, but into the data and evidence that underlie their thoughts – data and evidence that I might not have seen.  This can be as simple as asking questions like “Could you give me an example?” or “What happened when you tried this in the past?”)

Conclusion

So, these are the issues that I find most challenging and relevant as 2013 dawns.  Can you suggest any relevant links, resources or thoughts?