The dangers of compromise

The most chilling aspect of Animal Farm comes right at the end: “The creatures outside looked from pig to man, and from man to pig, and from pig to man again; but already it was impossible to say which was which.” It stands as a warning to anyone who accepts a temporary compromise on the basis of necessity. It came to me this morning after I posted on the need for theory yesterday. In that post I used SAFe as an illustration of a method, which if taken as stated, cannot handle complexity a priori. That reminded my that one of the most frequent defences from people I respect is that they know its not really coherent but (i) they will make it work anyway in practice by simply ignoring a lot of it and (ii) its a way to get the C level buy into Agile.

Now I criticised the first of those yesterday, now I want to handle the second. The thrust of my concern should be clear, compromise all to easily falls into conformity with the result that the revolution is lost and the rebels betrayed. Equally a purist attitude to the revolution results in expulsion, exile and death. It’s all there in Animal Farm and I really must work on taking the Agile Manifesto and playing with what Squealer would have done if it had ever been painted on the barn wall.

So what is the balance between purity and compromise? To some extend I think the answer lies in my argument from yesterday. If what you do is coherent with the theory you are propounding then its probably OK, if it largely contradicts it but you think you will be able to change things over time then it almost certainly is not. Now I have spent most of life trying to get new ideas into conservative organisations and I’ve had my share of success and failure. A range of strategies are available:

1. Accept reality, but be very very clear you disagree with it and wait to be proved right. This is remarkably successful by the way, you show you are prepared to play the game, but you don’t try and pretend it is anything other than a game. You may have to accept that someone else gets the credit when you are proved right but that just has to be lived with.
2. Focus on intractable issues that are poorly handled by the conventional approach and find ways to make a difference, but make sure you have the input/out definitions between new and old well defined. Way back when we set up DSDM we made sure there was a space defined for it in Prince II so that it was different but compatible. By a strange irony I am working with some of the Prince II community at the moment with Cynefin and some of the pre-SCRUM methods we have been creating within an Agile framework.
3. Change the game by approaching the domain area in a radically different way. For example by moving user requirements definition further up the chain so that you handle unarticulated user needs, current strategic issues and technology capability to make a major impact on intractable problems. In military terms, you fight on your own ground.  One way to do that by the way is to tackle the problems of the strategic and operational C level, not the comfort needs of IT Management.

Now there are others, but becoming enthralled to Mr Whymper’s academy of accreditation and training is not the solution.