top of page
Search
sweynmartin

Agile: The Fatal Slip

“The truth,” wrote Oscar Wilde “is rarely pure and never simple”. It’s a truism that has fallen somewhat out of fashion in recent decades, as the emergence of ever more complex challenges in a world of accelerating change has, paradoxically, driven an almost universal appetite for simple, easy solutions. In reality, any effective solution demands a pluralist approach that can embrace the nuance, compromise and complexity inherent in the challenge.


The answer is almost never singular, exclusive or simple.


I’ve seen so much money wasted by companies large and small that have sought to implement Agile. Too often these companies find, several years down the line, that they have to double down on their investment to try to fix an operation that has become opaque and tribal; the promised performance improvements on which the journey was sold, long abandoned.


Reading the Manual

There are many pitfalls and risks to an Agile transformation journey, but let’s focus on one that I believe to be possibly the most toxic because it happens so early and is so fundamental.

The most basic DNA of Agile has been publicly available for fifteen years. It’s the original set of beliefs set out by the “founding fathers” of Agile and is universally known as the Agile Manifesto. This sets out four premises for agile thinking. It’s worth reproducing it here in full:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools

  • Working software over comprehensive documentation

  • Customer collaboration over contract negotiation

  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”


It’s vanishingly rare to find an implementation of Agile that does not refer to the Agile Manifesto. It’s almost as rare to find one that gets its essential nuances right.

All too often the focus bores into the leftward items in each of the four clauses and ignores, or even excises, the items on the right.

This is an error that the original authors clearly predicted and attempted to protect against. The final sentence of the Agile Manifesto deliberately stresses the preservation of the rightward items. It’s almost as if they predicted their abandonment.


And we should not be surprised. There remains significant profit to be made in selling Agile transformations to companies based on the promise of a sunlit new operating model that will, by definition, reduce risk and maximise commercial performance.

If the company is struggling to respond fast enough to an accelerating and changing market, the Agile Transformation magic beans will sound terribly tempting. Too often an organisation’s appetite for a convenient and modern-sounding pseudo-answers is inversely proportional to the leadership team’s experience and aptitude.


Leaders with the most pressing need to work cheaper and faster - and who are therefore most ready to hear a sales pitch promoting an unethical agile transformation - are least likely to have the capacity to explore its full risk/benefit implications.


After all, when you’re under pressure to reduce the bottom line in steepening market conditions, what could sound sweeter that a prescription that enables faster value at lower operational cost ?

In order to fix the hook firmly in the unsuspecting customer, the Agile Manifesto is all too often spun to sound more like a pain free panacea.


Into the Abyss

Here is a real example taken from a consulting organisation that I will not name, that offers coaching and guidance for Agile. I pick it because it’s representative of the context that is often given when framing an Agile Transformation bid:

“The Agile Manifesto was created by software developers who were tired of working under rigid corporate rules that were holding back their creativity and making the process bureaucratic and predictable.

Therefore, they created the manifesto for Agile development, which preaches 4 premises that establish what should be really valued:

· Individuals and interactions rather than processes and tools

· Software in operation rather than comprehensive documentation

· Collaboration with the client rather than contract negotiation

· Responding to changes more than following a plan”


Did you see it? Three out of four times the author of this has replaced the “over” in the

original Manifesto with “rather than”


Pedantry ? Sadly not. Words materially affect outcome. This replacement fundamentally changes the meaning of the four principles to imply that it’s correct to replace the rightward item with the leftward one.


When this erroneous thinking forms the foundation of a new Agile transformation here is what happens:

1) Extraordinary effort is put into restructuring organisations, setting new roles and job titles, relabelling teams with fashionable (but often poorly defined) names resulting, paradoxically, in confusion and lack of transparency that actually impairs co-operation

2) Wholesale abandonment of documentation at best resulting in internal compromise with security and data functions, and at worst, complete amnesia over business decisions, where an organisation has become so “agile” – even anarchic - it’s systemically unable to remember which business decisions drove which technical changes for which customers

3) Contract quality is disregarded resulting in commercial and legal exposure if and when a carelessly drafted contract has to be enforced – well after the boosterish ‘collaborative partnership’ has soured

4) Planning horizons are drastically reduced owing to the perception that long term plans are a waste of effort. “Responding to change over following a plan” is used to justify the abandonment of long term planning when what is actually required is better, more intelligent planning and the apparatus to pivot those plans in response to emerging pressure


These outcomes are corrosive. The first of these feels like progress (It isn’t), while numbers 2 through 4 sow systemic problems that take a full business cycle - typically at least a year - to emerge. To top this off, they become more expensive to fix with every month they are allowed to continue without intervention.

Can this be avoided ? Certainly.


Recovery

The key is to stop seeing the sides of each measure as a zero-sum game, and have the focus and discipline to do enough – no more and no less - of both sides of each clause of the original manifesto


This can be difficult and complex work for organisations where habits and behaviours (and, it should be said, often careers and seniority) are heavily invested in the status quo.

So, to get a better grasp on what an agile transformation might mean for your organisation and whether it can deliver the improvements you want, you can ask some relevant questions like this:

· Can I first ensure that the organisation understands the way that people work together, in the context of a process that gives me value, and only after that add or change the procedures and tools they need ?

· Can I think differently about the documentation I really need ? Perhaps I could run an experiment to remove all documentation and add back only what I need.

· Can I ensure, through my procurement and sales channels that vendor and customer relationships are actively farmed ?

· Are my teams negotiating the most flexible contracts we can safely sign ?

· Are contracts understood to be an ‘in extremis’ backstop option, rather than a playbook for the relationship ?

· Can I be clear enough about the things I want from an investment in change in order to flexibly plan a reasonable outcome, without specifying every detail ?

· Do I need to make my investment in change process flexible and open minded enough to make mid-cycle adjustments to exploit better ideas or unforeseeable challenges?


By taking an engaged approach you increase the probability of a successful agile transformation that merges with the organisation instead of causing T-bone crash trauma and that has some chance of actually delivering the return on investment that sounded so attractive in the sales pitch.


Agile techniques are of well proven value, but they work best when tempered with operating methods that may even already be established, and so it’s possible to conceive this sort of business challenge as a melange of multiple symptoms and causes, that requires an articulated and balanced treatment, rather than a single patent elixir.

This may result in an approach that is not completely pure and almost certainly won’t be simple, but will have a much better prospect of success.


And that’s the truth.


4 views0 comments

Comentários


bottom of page