Agile lipstick on a waterfall pig

Over the past couple of weeks I’ve had a few conversations about a variety of issues at different organisations, but the one thing they all had in common was the feeling I had that their “Agile transformation” was really just Agile lipstick on a waterfall pig. It might sound harsh, but the descriptions of the various problems could almost have been taken verbatim from a book of Agile anti-patterns. (I didn’t have time to dig in deep enough to do any root cause analysis so the only suggestion I provided was they should consider getting experienced Scrum Masters/Coaches to help their groups.)

“Our QA team can’t keep up with the developers”

One person was concerned that their QA team, consisting of three people each assigned 50% to the project, were swamped by the output of their six person (fully assigned) Dev team. They were told they were Agile and so there had to be a release every two weeks; the code changes were pushed to a test environment and the testers were told which backlog items were included. The product owner continued to push the dev team to deliver more, to the point that changes were pushed to production even if they hadn’t been tested, or if the testing had identified significant issues.

“We don’t have time for automating tests”

A tester told me that they are involved in an Agile project that is rushing to deliver updates to a business-critical system in order to meet legislative changes by an imminent deadline. They were told there isn’t time to create automated tests; the developers are busy writing code, and the testers are busy writing & running test cases, so there is no capacity for automation. They also mentioned that many bugs are simply deprioritized and added to the backlog to be fixed after the deadline, although their expectation is that the project will be terminated at that time and the team members will be reassigned to other projects.

“The customer hates what we’re building”

A team member described how they had worked on a project for over a year without releasing or even demonstrating anything to their customer. It sounded like the end-users may not even have been aware of the features that were being developed. When they discovered how the intended changes would impact their roles, the end-users escalated their concerns and the project was put on hold.

“We need to start planning 2025”

Talking with a project manager recently, they were concerned how they would find time to implement Agile practices and events because the plan for 2024 was already fixed (including funding, staffing and delivery dates). They were already being asked to create a similar plan for 2025, so the PM was considering whether to inflate the estimates in order to “make room” for retrospectives.

“Will SAFe fix our problems?”

A senior manager asked for some advice: their organisation is just about to start their Agile journey but they want to (or have been told to) create a plan with a timeline for rolling out across multiple teams. After a conversation with some consultants the manager was planning on bringing them in to “implement SAFe” because they could provide a playbook and implementation schedule.

So is Agile dead?

It might seem like these are outliers but I see and hear too many instances of organisations claiming to be Agile and yet describing similar challenges. It’s no wonder there are so many blog posts about the demise of Agile when you see these problems… but Agile is the toolkit that can be used to identify the issues and fix them. If those organisations don’t have the experience internally to recognise that and follow through, then I know some coaches who are available to come in and help you!