Do unto others...

Ron Jeffries enigmatically once said of the XP practices, "they're only rules". What I think he meant was that the practices are a social contract within the team - everyone is expected to abide by the contract, but the team is also free to change the contract when that's appropriate. What we don't want on an XP team is someone unilaterally deciding that the rules don't apply to them. Instead, we want them to raise an issue in a retrospective so the team can hear why some rule isn't working for that person, so that the team can provide advice, support, suggestions, or possibly change the rule.

Developers understand this in the development team context, and also with regard to the rules covering the interactions of the customer management teams with the developers, but I find that they are rather more tolerant of the rules covering the interactions going the other way. In particular, I regularly hear people suggesting that although the customer/project man ager wants to do things a certain way, the developers have decided to do something else "in the interests of the project". What's worse, I feel the urge to do this sort of thing myself!

This pattern appears mainly in two contexts - priorities, and quality. When developers know better, the choose to implement features in an order different to the order requested by the customer, usually because it will be "more efficient". This is fine when everything gets done but if there are some hiccups the customer may be left with features they didn't really need while also missing features they think are more important. While one order may truly be more efficient, that may not be the most important thing from the business perspective and if there's disagreement the final decision on priority rests with the customer.

The equivalent behaviour regarding quality is harder to detect. Sometimes the developers decide to implement lower quality than the customer requested, but more often I see the developers decide to implement higher quality. The context is usually that the developers have two approaches - one can be implemented quickly but hard to change/maintain, and the other is slower to implement but easier to maintain - and the customer prefers the "quick and dirty" approach. In spite of this, the developers decide to implement the "nice" approach. Once again, this is fine if the developers can somehow do it in the same timeframe (overtime perhaps?), but not if it's done at the cost of other features.

Developers need to recognise (intellectually and emotionally) that they are in a service industry, and when push comes to shove they take direction from the business, represented by the customers and management. Developers have a responsibility to present their views and recommendations, with all the supporting information, and then let the business make the business decisions, which include how to spend time/money. When business and development don't agree there are two main reasons - development haven't presented their position in a way that the business understands, in which case the developers need to improve their presentation and influence skills, or business understands the development position quite well but it isn't the most critical factor in the outcome. Sometimes developers don't have the big picture! In neither case the problem that "the business is stupid" or "the business made the wrong decision", though they certainly may make decisions that the developers don't agree with (it undoubtedly happens the other way around as well!).

Of course, none of this applies when people are trying to make decisions that they aren't actually responsible for - in that situation everyone needs to say "thanks very much for your input, but I don't think you're responsible for the final decision". It's common for this to happen with estimation, when the business tells the developers what needs to be done (their responsibility) and how long it's going to take (the developer's responsibility). Sometimes the lines are blurred though - the business is making "draft" decisions, fully expecting them to be reviewed by developers, rather than final decisions - and the situation needs to be clarified.

So if you're a developer who interacts with the business then you have a responsibility to respect the decisions of others, and you'll probably benefit from honing your influence skills as well as your technical skills.