Agile – The Emperor’s New Clothes?

Well, the first statement that we’d like to make is that Agile was never meant to be a panacea to all problems.
Despite the close relationship between Agile and Lean, many of us have experienced the endless cycle of stand-ups, scrums, show-and-tells, sprint reviews and retrospectives. The antithesis of lean.
If you find yourself on a project where 80% of your time is being devoted to Agile ceremonies and there’s no time to code and test, We suggest you tell everyone to put down the Agile manifesto down, look up and do it differently.
There have been too many so-called Agile experts that have rocked in – with their playbooks – and try to take over. It’s reminiscent of how empires grew and, ultimately, fell apart by not taking everyone with them on the journey.
Unfortunately, the damage has been done and putting the genie back in the bottle is not a credible response to litany of app development projects that have failed to deliver.
As consultants, we have little choice. We have to do Agile, it’s what clients are asking for. However, here are some of our favourite questions that we ask ourselves in applying Agile to a job:
1. Is the ‘business’ asking to be Agile or is this coming from the tech teams? IT is notoriously poor at business change and communications – besides the CIO/CTO/CDO has enough of their plates than to lead an Agile crusade. Red flag number 1: if you don’t have a senior business sponsor as your Agile evangelist then Caveat Emptor.
2. Even if you have a senior sponsor, are the wider business processes Agile? Expecting business operations to contribute to a tech-led CI/CD process is, quite frankly, bonkers. Your common-old-garden Scrum master struggles to manage their team of coders, let alone a complex and matrixed business operations that is in charge of generating revenue and maintaining its reputation with customers and shareholders. Red flag number 2: your internal customer is anything but Agile.
3. Is this a big hairy project? Central to Agile is breaking things down into loosely-coupled outcomes. Sure, you can break anything down into 2-week sprints, but if they are tightly coupled then all you have done is created a gigantic spiders web of interdependencies that will bring the project down in an almighty crash. Before you start to throw Scaled Agile (SAFe) at us – go back to red flag number 2. Red flag number 3: the project is neither small nor simple.
4. Are any of the delivery team Agile jobsworths? One of the most destructive signs that we have seen are Agile purists that are self-serving, somehow better because they are able to quote the Agile manifesto verbatim. You know the kinds of people we mean, have all the gear but no idea. Context is everything, being an evangelist is more about coaching and mentoring than vocalising sermons from the manifesto. Red flag number 4: watch out for the crazies – Agile is not meant to be an ideology.
We’re a mixed bag and not afraid of having a toolbox of methods and approaches to fit the circumstance and culture of an organisation. Even if that means we have to mix things up a bit and be rather more WAGILE (Waterfall and Agile mixed). For example, we might run a core platform development as a Waterfall project and then once the core architecture is in place and embedded, move to Agile CI/CD for enhancements and new feature development.
What are your favourite Agile red flags?
We deliver services and solutions by applying our Digital, Data, Technology and Cyber capabilities.
Categories
- Application
- Capabilities
- Cloud
- Credentials
- Cyber
- Data
- Delivery
- Design
- Development
- Digital
- Live (Operations)
- Services
- Solutions
- Strategy