How to Break Agile

When any school of thought, way of thinking or approach to a problem becomes significantly popular and widely adopted then a counter culture starts to grow to oppose it.

Often it is to the benefit of all of us that perceived wisdom is challenged, however I believe most of the criticism of Agile is actually misdirected, in that it actually relates to flawed implementations of its principles rather then making a killer blow against the entire philosophy.

Agile is not a procedural approach to development it is a way of thinking, a mindset to use to maximise the output of a team.

When Agile is seen to not be working it is usually because of a failure to adopt this mindset.

Fix Time and Scope

When trying to manage a software delivery there are two levers that can be pulled to adjust the outcome, we can make changes to the scope of the release or we can change the date on which software will be delivered.

Changes in scope can either increase or decrease the effort required to complete the delivery, and changes in deadline can either increase or decrease the amount of available effort we can spend prior to releasing.

What we have to realise is a relationship exists between those two things, the fact being that they cannot both be fixed at the same time.

To do so either leads to inefficiency that delays the release of working software or tries to arrange a situation where software is delivered without effort being expended.

Deadlines are a fact of life and it would be foolish to imagine a situation where they don't exist, but as soon as a date is fixed then scope is the only lever left to adjust the teams trajectory towards hitting that target, if that isn't an option then the difficult decision of moving a deadline must be faced.

Failure to Iterate

Although not expressly mentioned, an Agile mindset leads to a certain acceptance that software development is an unsolvable problem.

Your product will never be finished and it will never be perfected.

Once we've learnt that lesson then we can gradually come to the realisation that the next best thing is to try and ship frequent incremental updates to ensure the product is the best it can be right now.

The delivery of this incremental change may be imperceptible to users but allows for a direction of travel to be established.

When the apparent big bang of a new feature is discovered by a user this is actually just one more small delivery, providing the cherry on the cake of several previous unseen steps forward. 

A failure to iterate is often the result of a failure to properly prioritise.

A priority is a singular entity that stands alone, to pluralise prioritises is to admit to a lack of vision for the direction the product should move in, it leads a strategy akin to throwing around features and seeing what sticks.

Speed becomes of the essence as we increasingly fear that users will leave us without the next big thing, when actually users are often happy to have something that works that receives regular attention to ensure that remains the case.  

Breakdown of Trust

Many would find it quite shocking to be asked if they trust their development teams.

But actually it is not uncommon to observe behaviours that indicate that trust has broken down.

First and foremost this is seen during the estimation process, too often there is seen to be a right and wrong answer to providing an estimate.

Development teams shouldn't be asked to estimate as a courtesy, it is because they are experts in there field. 

Repeating estimation without any conversation around scope leads to the madness of asking the same question over and over until the calculation yields a different result.

Trust can also be eroded when a development teams warnings about potential bumps in the road are not heeded.

Too often this is seen as engineers obsessing about technical detail, while on occasion this may be true, this comes from people who understand all the moving parts of the code base and therefore can also envision the areas where the machine may start creaking.

There is more to being Agile then simply adopting its ceremonies and ticking the boxes of its various implementations.

Agile is a philosophical viewpoint on how the unenviable task of software delivery can be approached.

It isn't a formula that can be solved to produce a proof for success.

Many teams start off with good intentions and want to do the right thing but they eventually encounter the pitfalls of allowing their minds to drift to more attractive ways of viewing the problem that promise a solution that will never be delivered.

Learn to recognise the signs of these mindsets creeping in to your team and use these opportunities to re-affirm your commitment to keeping an Agile mindset.

This will inevitably lead to giving up some perceived control over a situation, the first step towards a transition to Agile from more traditional methods is to realise this control is an illusion, the world simply isn't like that.