The word ‘agile’ has become synonymous with two things in the past 5 years:
1. A management tool that can be used to deliver digital products iteratively, ensuring user feedback is taken into account in real-time.
2. A meaningless term which companies use to describe themselves when trying to sound ahead of the curve. Usually accompanied by diagrams.
A more ubiquitous buzz word hasn’t seen the light of day since Mr Toyota (probably) opined: ‘By jove! There’s something in this lean production, after all! For today’s Monday musings, I’d like to explore what makes a company truly agile – and share some of pitfalls presented by the perpetrators who purported to practice agile.
First things first: what exactly is agile? At the risk of losing readers and ostracising friends, I’ll provide an abridged definition:
“Agile project management is an iterative development methodology that values human communication and feedback, adapting to change and producing working results”
In layman’s terms – agile is a method of software development in which the emphasis is upon involving the client throughout, instead of simply taking the specification, building it and hoping:
a) the specification hasn’t changed in the interim.
b) the understanding you initially gleaned of the client’s requirements was accurate.
c) for the best.
It sounds fantastic and, when executed correctly, it truly is. Companies – big or small – that follow the principles and pillars of agile typically develop better pieces of software. Better insofar as it is more in line with what the end user envisioned at the outset. It (normally) provides such good results, in fact, that organisations everywhere will fall over themselves to describe their working practices as agile, with the assumption that the sheer magnitude of buzzwords will outweigh any investigative impulses on your part. But, dear reader, don’t be fooled! Look at for the following:
1. People vs processes
Agile prioritises people over processes. At its essence, agile is a management tool – and people, not processes, are the better managers.
People learn from mistakes and adapt to their surroundings.They use the experience they have gleaned from their experiences as to what works and what doesn’t. They conduct retrospective investigations into past projects and put forward better ways of working.
An agile organisation is one in which its personnel are empowered to make decisions about how they work – and to contribute suggestions as to how it can be tweaked. Processes can still be in place, but these should be malleable guidelines instead of immovable dictates.
Watch out for swathes of downtrodden developers grumbling about how they wish they could work a different way. Unless they are perennial malcontents (certainly possible), this could indicate that they, as people, are subservient to the didactic processes put in place from above
2. Responding to a change in the plan
We all love a plan. For some, it’s the homely comforts of married at 30, children at 32. For others, it’s a fervent desire to give a TED talk before the hands of time strike forty years old. Developers love a plan too. A comprehensive set of requirements is mana from developer heaven. Yet, as detailed above – things change.
‘Sorry but that wasn’t in the original specification’. Words that should set off nearby smoke, fire and intruder alarms. Requirements change. They evolve. An agile company must have the flexibility to adapt in tandem.
Alright, if the client initially wanted an e-commerce site and has now decided they instead want a replica of a 1930s boat, that’s perhaps a sufficient diversion from the original remit so as to warrant a robust rebuttal.
Short of that, however, new requirements should be a discussion point, used to help arrive at a means of delivering working Software. Yes, these changes may (on occasion) incur additional costs, but an agile company must respond with a desire to meet the ever-changing needs of the client. Intransigence is tantamount to ignorance.
3. Working software over everything else.
Let’s save the most obvious – and most crucial – point until last. The software simply has to work!
If your development partner spends more time apportioning blame to third parties than it does working to fix unexpected problems, it may be time to buy them the agile handbook (seriously, there is one). Software must work. You can be provided with reams of documentation and user handbooks but it’s all for nothing if the software does not work. Look for the problem solvers – not the problem shifters. An agile partner will adapt to ensure that the software always works – ABOVE ALL ELSE!
There are, of course, countless other signs that a company is not quite as agile as it claims. The above are three of the main pitfalls; knowledge of them should help you break through the management speak that can permeate the software development industry.