“Agilefall” is a term used in the industry where an organisation claims to be using Agile methodologies but they are still in waterfall (e.g. Prince) mindset, mixing methodologies resulting in the organisation and employees getting in a bit of a muddle.
Understanding Agile
There are a number of Agile methodologies. Agile itself is not a methodology, it is a mindset, a way of thinking about delivering software to meet users changing needs.
Unfortunately, there are a lot of examples in the industry where companies and individuals think that by adopting processes, ceremonies and using terminology from Agile and its methodologies they are somehow going to transform their organisation or save projects from failure.
Before we start let’s be really clear.
Agile is a mindset, a philosophy. You don’t DO Agile you BECOME Agile – in your thinking, your culture and your following of its core principles.
This is fundamental. Without this, you shouldn’t be claiming you are Agile.
Here are seven red flags to help you spot Agilefall lurking in your organisation.
Agilefall – 7 Red Flags
1. The requirements are documented and fixed, each with target dates
In the software development space, defining your requirements upfront and locking them down is a bad idea for many reasons. Here are just a few:
- users don’t always know what they want if you ask them
- you’ll waste time building things that ultimately won’t get used
- you’re trying to predict the future – I’m not sure we have developed that ability yet
- the technical world changes so rapidly you’ll miss opportunities to adapt to customer needs and miss opportunities that could deliver you significant commercial benefit (this could mean commercial suicide)
To be Agile you need to be comfortable with the uncertainty of the future and see that as an opportunity to adapt and improve as you discover changes in user needs.
2. You have mapped out a series of sprints including what you’ll be doing in 5 sprints time – even worse you’ve just written sprint numbers at the top of your Gantt Chart
This is a big Agilefall red flag. If you know what you’re doing in 5 sprints time you’re trying to predict the future and work to a fixed plan (see red flag #1). This will end badly for a number of reasons:
- you’ll suffer from the points in red flag #1 above by locking yourself in, but in addition, you’ll…
- put your team under pressure to meet fixed requirements and fixed timelines, this will inevitably lead to comprising on quality, increased team stress and lowered morale (that’s not a good thing for anyone or what you’re trying to achieve)
- by trying to mix two methodologies but claim that you are only using one, you will likely confuse your teams, your customers and the organisation’s senior management.
3. The daily standup is treated as a progress update meeting with people being told to work faster by someone senior to them.
The daily standup is a time for individuals to make commitments to each other – they describe what they did the day before and what they plan to do today. They also say if there are any impediments to their progress.
Remember Agile requires self-managing teams that are driven and motivated to a common goal. A boss putting them under pressure fundamentally undermines this principle.
Here are some more common standup meeting mistakes.
4. You plan to do all your testing at the end
Agile encourages small but frequent releases of functionality to the customer in your regular work cycles, for example, a fortnightly Scrum sprint. This cycle should include testing.
You should also have a potentially shippable product by the end of that cycle. By releasing that to the customer you then get real-world data to inform what you need to do next to improve the product.
If you leave the testing to the end you run the risk of finding too many surprises and it is too late to make any changes. This is a classic waterfall approach.
5. People are walking around the organisation quoting a lot of Agile jargon
Alarm bells should ring here.
Remember Agile is about mindset and culture. Using jargon to try and change that culture will be a switch off and alienate your audience. In fact, jargon has been shown to reduce an organisation’s effectiveness.
By bombarding people with terms they don’t understand will make Agile adoption more difficult in your organisation.
Even worse you may find people are using the jargon but don’t fully understand what it means.
6. The development team are isolated from the customer and rarely meet them
Agile places an emphasis on collaboration between the team delivering the product and the customer who will be using it. Without this collaboration on a continual basis, the end product’s chance of delivering value to the customer is severely compromised.
“How can you build a tailored suit for someone if they never come in for a fitting”
7. Success is measured by volume of output and targets being met
Agile places its emphasis on delivering value to the customer. Providing a safe place for teams to collaborate, make mistakes and continually learn.
Traditional project industrial age thinking often places an emphasis on volume of output and can often fail to give much attention to measuring value.
If done correctly every item being worked on by Agile teams should have customer value attached to it, not to mention the highest value items being worked on first.
If value can’t be determined, why is the work being done in the first place?
I have explored this topic in another article.
Conclusion
Simply following techniques from Agile methodologies whilst not appreciating, respecting and embracing the core Agile principles does not make for an Agile organisation. It makes for an organisation that’s trapped in the dangerous no man’s land known as Agilefall.
Posted in: Agile