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:

  1. 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.
  2. 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.
  3. 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.
I have drawn the Evaporating Clouds for the above three situations, showing the underlying (conflicting) assumptions and some challenges to those assumptions:

Compromise #1: Management Allows But Does Not Embrace

Arrow 1a: In order to have A, we must have B.
Assumption 1a1: People are (more) productive when they have a say in the way the work works.
Challenge: Will our developer productivity decline or fail to improve if we (they, the developers) don’t have a say in the way the work works?
Assumption 1a2: The existence and increasing adoption of Agile across many organisations means our developers have changed their expectations re: the “working contract”.
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.
Assumption 1b1: Management oversight and control contributes positively to developer productivity.
Challenge: Does management control over the way the work works really contribute positively to developers being productive?
Arrow 1c: In order to fulfil B, we must accept D.
Assumption 1c1: Adopting Agile is the only way to give developers a say in how the work works.
Challenge: Is Agile the only way to provide our developers with a say in the way the work works?
Arrow 1d: In order to fulfil C, we must accept D’.
Assumption 1d1: Management control over the way the work works is fundamentally incompatible with Agile software development.
Challenge: Is this really true? Could we adopt Agile and yet retain management control?

Compromise #2: Agile Remains a Ghetto

I leave this diagram and its assumptions as an exercise for the reader.

Compromise #3: Failure to Realise Any Significant Benefits

I leave this diagram and its assumptions as an exercise for the reader.

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.

– Bob
1 comment
  1. Cuthbert said:

    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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: