Is Quarterfall the new agile?

You are not alone if you notice a hint of derision if you say that you are agile, but do not do quarterly PI planning. In many organisations that are still in early stages of agile maturity, the methodology unfortunately resembles incremental waterfall. There's nothing wrong with incremental and waterfall, so I decided to give it a new identity - Quarterfall!

What is Quarterfall?

Quarterfall is incremental waterfall delivery with 3-month planning cycles, scrum teams and sprints. It may look like agile from both inside and outside because of all the agile 'processes' and 'tools' in place.

What does Quarterfall look like?

These are some of my observations around Quarterfall:

1. Initiatives are projects and span two quarters or more.
2. Prioritisation is done is at the project level.
3. Quarterly planning involves mostly recalibrating timelines, aligning dependencies across teams or portfolios and replenishing the backlog of projects. This is because prioritisation is already done at the project or program level.
4. Delivery is purely incremental with largely upfront design.
5. The organisation has teams based on an asset ownership model. Upfront solution design allows the definition of what each team would need to do towards the project.

Making the most of Quarterfall

In the physical world, bulk is a factor that determines natural agility - the lion is more agile than an elephant. A speedboat is much more agile than an aircraft carrier. So it is not surprising that large enterprises struggle with agility.

If your organisation is indeed in Quarterfall mode, there is one step which will do wonders for your agility. That step is moving away from prioritising work at the project level.

To achieve this, projects need to be broken down into smaller end-to-end lean initiatives that can be collaboratively delivered across all teams. There are two ways to do this:

As smaller business features
The project will be delivered as lean business features rather than as a single big project. In an ideal scenario this can be done much earlier in the project lifecycle as it is based on requirements. Prioritisation and quarterly planning will be done based on these lean business features.

Design and solutioning is done per lean-initiative. So this approach could be considered as being more iterative.

As smaller end-to-end technology features
In the second approach, the breakdown is done after the architecture and solution is known. This kind of breakdown is possible later in the project delivery cycle because it based on the solution. Some organisations may find this approach beneficial to involve the right teams as part of the delivery of the lean initiatives.

Similar to the first method, the quarterly planning is still based on lean initiatives.

Challenges

Since prioritisation is done at the lean-initiative level across multiple projects, some project requirements may not even make it to delivery depending on priority and the team capacity.

Dependencies will need to be managed at the initiative level. This will simplify delivery, however teams may not be used to this way of working.

The same impact from having to do granular planning would be felt for managing project budgets and people resourcing. It may be easier to embrace the concept of Pym-teams to manage fluctuating people capacity.

Success factors

The ability to prioritise lean initiatives across projects allows delivery of most valuable initiatives first.

The key factor that influences agility is the size of the initiative. Ideally initiatives should be tiny enough to be delivered within a quarter. When initiatives are larger than 2 quarters, then the value of quarterly planning becomes questionable for the teams involved.

To Quarterfall or not?

I feel Quarterfall is here to stay. For most organisations it would be the first step towards scaled agility. While it isn't truly agile, it may still be possible to get much out it in a way that enables business agility.

Photo by Daria Nepriakhina on Unsplash

Posted under: Business Agility, Agile Thought Leadership