malvasia bianca

As a manager who is drawn to XP, one question that reading First, Break All the Rules raises is: how compatible are agile methods with the book’s recommendations? Let’s start by going through the questions.

1. Do I know what is expected of me at work?

This is a strength of XP (and other agile methods): work is broken down in to chunks, is explicitly prioritized, and there’s a clear mechanism for resolving questions (ask the Customer).

2. Do I have the materials and equipment I need to do my work right?

XP talks about this to some extent; Scrum highlights it.

3. At work, do I have the opportunity to do what I do best every day?

Hard to say about this one: if what you do best is a core part of XP, then yes, otherwise no.

4. In the last seven days, have I received recognition or praise for doing good work?

XP seems neutral on this one, too.

5. Does my supervisor, or someone at work, seem to care about me as a person?

XP is probably positive here: you spend quite a bit of time talking to other people, which increases the chance that they’ll care about you.

6. Is there someone at work who encourages my development?

XP is probably slightly positive here: everybody works on everything, which should tend to encourage development.

7. At work, do my opinions seem to count?

XP should do well here: any two people can modify any piece of code, and retrospectives are a frequent practice. Of course, the flip side is that other people’s opinions count, too…

8. Does the mission/purpose of my company make me feel my job is important?

XP tries hard to make sure that people are working on high business value stories at all times.

9. Are my co-workers committed to doing quality work?

XP is very focused on quality.

10. Do I have a best friend at work?

Everybody works (or at least should work) with everybody, for better or for worse; it should give scope for friendships to develop. (But you don’t want them to be too exclusive.)

11. In the last six months, has someone at work talked to me about my progress?

XP is probably neutral here.

12. This last year, have I had opportunities at work to learn and grow?

My answer here is the same as to question 6.

Okay, that’s not too bad; XP seems no worse than neutral on any question, and is positive on several of them. Which is, to be sure, nothing to crow about – most methodologies are going to avoid actively screwing these things up, and will focus on a couple of them. Still, it’s a start.

But what about the rest of the book? They recommend that, after specifying the desired outcome, a manager should give employees as much free leeway as possible in the methods that they use to accomplish their tasks; the expectation is that different employees will take different routes based on their different talents. And here, it’s hard to say that XP does so well: it places quite tight constraints on how you get your work done (TDD, pair programming, constant refactoring, collective code ownership, …).

The situation isn’t completely bleak, to be sure. For one thing, an XP has several distinct roles: the programmers, the Customer, the Coach, and even testers (who help the Customer translate needs into acceptance tests). So there’s some room to place people with different talents into different roles. And for another thing, XP doesn’t expect people to be “plug compatible programming units”; in fact, one of the benefits of pairing is that it acknowledges that different people have different experiences and strengths, and allows those different strengths to work together to effectively tackle a problem.

But it’s definitely the case that some people have talents that lend themselves more to XP’s demands, and other people don’t. And, given the range of strictures that XP imposes, a single person is unlikely to be talented in all the appropriate areas. I, for example, took to refactoring and TDD relatively quickly, but it’s taken me a while to get used to, say, pair programming and acceptance testing. I’m learning those latter skills, but I wouldn’t say that I’m actively talented in them.

Of course, this doesn’t mean that XP is bad because it works best with people who have certain talents: saying that makes no more sense than saying it’s bad to hire people to program because not everybody is talented at programming. It does suggest, however, that, as a manager, I should pay extra attention to the authors’ recommendation that a manager’s first job is to be very clear about the talents required for roles and to take that into account when hiring: while managers should avoid gratuitously imposing talent requirements, they should face up to the fact that they do require certain talents.

(I’m sure many people will claim that XP does, in fact, gratuitously impose talent requirements. That is not my opinion, but I don’t particularly feel like discussing the matter at the moment.)

This is a particularly urgent question for me right now. In the past, I’ve been cavailier about this when hiring (and my initial team I inherited rather than hired), but I’ve gotten extremely lucky so far: I have a great team, and one that is quite good at XP practices. (Don’t get me wrong, we don’t do full-out XP, but we’re fairly far in that direction.) Unfortunately, one of my team members will be leaving soon; I’ll have to talk this over with my boss and parallel managers, but I expect the conclusion will be that his departure leaves my team understaffed, so I’ll be hiring soon. Something else that I’m not particularly talented at; I’ll do my best…