Saturday, 12 March 2011

Compose, Conduct, Compromise or Cultivate?

So far I've seen four types of Agile coaches, those that compose, those that conduct, those that compromise and finally those that cultivate. Those that compose, are skilled coaches of great experience. They instinctively inspect and adapt, and constantly experiment with the process. Working on a team like this is electrifying. It generates it's own energy and momentum. Nothing seems impossible, and yet it's unsustainable. The team and its success are too reliant on the composer, who becomes a single point of failure. When they move on, the energy will dwindle. If you're lucky a partial clear out, and injection of some new blood can reinvigorate things. If you're not the project will become a shadow of it's former self, serving only as a reminder for how good things used to be.

The next type of coach conducts the project according to the dogma of a prescribed methodology even in the face of common sense. When I was less experienced there were several Scrum practices that I didn't like, but assumed this was because of my lack of understanding. It turns out however that at lot of them are unnecessary or wasteful. Take the practice of public commitment. Just what is the team committing to? If scope, then if you estimate badly, the only way to deliver within a fixed iteration is to drop quality. If quality what's the point of committing at the start of each iteration, since quality should always be high? Working on a prescribed project can be demotivating, but isn't anywhere near as bad as working on a compromised one (although If you choose to argue I will concede the point that prescription is a form of compromise).

A compromised project is one in which some fundamental value or principle is disregarded (usually because it doesn't fit with what the customer wants to hear). A great example of this is off shoring. Communication is one of the original XP values, and frequently makes the shortlist for things companies say they do badly. So why insist on making it virtually impossible by separating the development team and business people, not just by distance, but by language and culture as well? If the aim is to reduce costs, follow John Seddon's advice. He says when you attempt to manage costs, you invariably increase them, but when you manage value, costs automatically decrease. The way to manage value, is to ensure your product team can ship needed and high quality code without inhibition. This is only possible if the developers can effectively communicate with the product owner.

The final category of coach doesn't coach at all. Instead they cultivate, encouraging the team to compose for themselves and to understand and influence the greater business ecosystem they operate within. Only then will they be able to adapt and survive, without compromise, and thereby become self sustaining.

No comments:

Post a Comment