This Shitty Agile Compremise
This Shitty Agile Compremise
I think we all feel uneasy about compromise. And yet, so many folks make compromises so often, it also feels like it’s inevitable. Shakespeare noted how distressed folks can become when forced to consider compromise:
Bastard:
O inglorious league!
Shall we, upon the footing of our land,
Send fair-play orders and make compremise,
Insinuation, parley, and base truce
To arms invasive?~ Will Shakespeare, King John Act 5, scene 1, 65–69
Goldratt, father of Theory of Constraints, is uncompromising in his excoriation of compromise:
The common way to manage conflicts is to struggle with compromise. Yet all contradictions can be resolved without compromise – it’s our level of understanding and our assumptions that hold the contradiction in place. A compromise is not usually a win-win solution.”
~ Eliyahu M Goldratt
Goldratt goes on to describe “Evaporating Clouds” – his method for obviating compromise:
“The Evaporating Clouds method does not strive to reach a compromise solution, rather it concentrates on invalidating the problem itself. The method involves verbalizing the assumptions underlying the problem, and challenging them to find the invalid assumptions.”
Agile Compromise
The Agile Compremise (compromise) of which I write, here, are in fact several:
- There’s the tacit compromise made by business folks who don’t want to understand Agile, but neither want to demotivate their software folks so much that those folks stop making an effort, or quit entirely.
- Then there’s the compromise that developers make in adopting Agile within their own teams, without dealing with the conflicts and dysfunctions arising from their upstream and downstream partners not also adopting agile.
- And thirdly, there’s the compromise that whole organisations make in “adopting Agile” but not consequently changing their mindset regarding the world of work – a change that is essential if adopting organisations are to actually reap – sustainably – the promised benefits (e.g. x2, x4, x8 productivity uplift) of the Agile development approach.
Compromise #1: Management Allows But Does Not Embrace
Arrow 1a: In order to have A, we must have B.
Challenge: Will our developer productivity decline – or fail to improve – if we (the organisation) fail to accommodate our developers’ changed expectations?
Arrow 1b: In order to have A, we must have C.
Arrow 1c: In order to fulfil B, we must accept D.
Arrow 1d: In order to fulfil C, we must accept D’.
Compromise #2: Agile Remains a Ghetto
Compromise #3: Failure to Realise Any Significant Benefits
Lose-Lose
Like so many scenarios for compromise, the Agile world is compromising on its goals, ideals and principles, and in doing so is complicit in a lose-lose situation – for itself and for the thousands of organisations it is ostensibly committed to helping.
I posit that we in the Agile community have the responsibility to recognise our complicity in this lose-lose situation. And, given we have more awareness about the situation and its issues than the business folks, it behoves us to reach out and involve them in evaporating the clouds of invalid assumptions that underly these ugly compromises.
Think Different
During agile projects a lot of things that a scrum team cannot do such as cannot provide a thorough design before getting permission to start coding, because design and coding will be done concurrently. During any process team does not need to solicit a permanent change in governance policies and the change can be pitched as a onetime experiment.