Agile software development is universally acknowledged to be a good thing… isn’t it?
Well… yes and no.
I’ve been delivering projects of all shapes and sizes for 15 years, and I’ve certainly seen the agile development movement bring a huge breath of fresh air to the industry.
However, in the last year or so I’ve become increasingly bothered by a couple of trends which together make a mockery of the intentions behind it: fake implementations and foolish implementations.
(Skip to the bottom if you’d like a quick explanation of what agile methodology actually means in software, versus the previously fashionable waterfall approach.)
Fake implementations and foolish implementations together create what I call fauxgile. One of the problems is that the word agile is often assumed to have its everyday meaning, the ability to move quickly and easily – which of course sounds a great thing for us all to aspire to – but in software it has a technical meaning, which needs to be well understood before usage can be distinguished from abusage.
Agile that means to move quickly, right?
Fake agile implementations occur when agile jargon is applied without anything of its spirit. Typically, a large bureaucratic organisation adopts the agile vocabulary (sprints, scrums etc.), perhaps as a selling tool, but then drowns it within a heavy, wasteful, overly formal culture that sucks any of the benefits out of it. Benefits such as quick response to change; inspiring creativity in developers; and avoidance of rework. Fake agile ends up being exactly the same old inefficient wasteful approach translated into a new language.
If agile is being applied meaningfully on your project, you will really see it and really feel it throughout. It will be engaging, refreshing, and perhaps disruptive (in a good way). If not, it is fake.
Foolish agile implementation occurs when agile is applied ruthlessly to every project as a standard dogma. Typically, a large bureaucratic organisation that previously applied waterfall to every project as a ‘best practice’ now does exactly the same with agile. The reason this is foolish is that delivery methodology needs to be adapted to each project in a much more nuanced way.
If agile is being applied to the right projects, you can expect to see the benefits for which it is celebrated. Forcing it on wholly inappropriate projects can lead to mayhem.
When it comes to project management, it’s essential to assess where on the spectrum your project lies and then decide which approach is most likely to provide a secure framework for effective delivery. Just because an approach is fashionable, doesn’t make it the best option. Let’s avoid the fake and foolish thinking that leads to fauxgile and provide effective agile delivery methods.
Read my next post for 10 Questions to Consider for Effective Agile Delivery.
What is agile development? In a nutshell, it’s an incremental approach in which the requirements for a system and the solution to meet those requirements evolve through collaboration. It embraces change, acknowledging that many details of what new software should do and how it should work can’t be decided up front, but only become known as work progresses.
It focuses on rapid delivery of tangible chunks of work – building up the solution piece by piece in short ‘sprints’ lasting no more than a few weeks – that stakeholders can try out and discuss, shaping the solution step by step as they see how it is progressing. The whole team gets together at the start of each sprint to look at progress so far and decide on the priorities for the next period.
The intention of agile is to make the best use of resources by avoiding the wasteful rework that can be caused by trying to pin everything down for the whole project in advance, only to need huge changes later when assumptions turn out to be misguided or business priorities change. It encourages the team to keep collaborating and thinking creatively throughout the project.
What is the waterfall model? In contrast, this approach involves a series of clearly defined separate project stages which are completed and signed off by stakeholders before progressing to the next. First a specification is completed, then wireframes, then visual designs, and only then coding begins, followed by a test phase.
The focus is on achieving complete clarity at each stage, so that the experts involved in the next stage have all they need finalised and ready to do their work with confidence. E.g. developers have complete final designs before they start coding. The project follows a linear sequence with different team members involved as time progresses.
Handling changing requirements can be difficult with this method, but it’s important to realise that, in its own way, waterfall is also aiming to avoid wasteful rework, by forcing people to decide up front what they want in some detail and make commitments to that in writing.