One of the most common rebuttals I often hear during an Agile transformation is “Oh, we’re already doing all this stuff. We just don’t call it Agile.” When I hear this, I try to stay as open-minded as possible, so I nod and find the first chance to observe. Usually my observations confirm very quickly that there’s an awful lot of cargo culting going on.

You see, the ceremonies and practises of a framework like Scrum aren’t difficult to explain or understand, at least at face value. No-one would argue that a stand-up every morning is a complicated affair. No-one grapples with the concept of putting the whole team in the same co-located space. Doing work in short increments or sprints seems to get nods of agreement from most people.

The ceremonies and practises are valuable and they work – Scrum wouldn’t be such a successful framework if they didn’t – but they are just some of the operational manifestations of an underlying way of thinking that is fundamentally different from the waterfall or project-based way of thinking. Waterfall is the ‘chalk’, Agile is the ‘cheese’.

Probably the most fundamental difference is that

Waterfall strives for certainty, Agile embraces uncertainty.

The implications of this are profound but are generally not understood very well. Let me try to explain by highlighting 3 comparisons that people make.

1) “A Feature Release Roadmap (Release Plan) is just another name for a project plan.”

The Waterfall mindset is rooted in Industrialism – we’re all resources building a machine and all we need to do to get it right is a detailed blueprint and a clear plan. It may be complicated, but it’s not complex. As long as we follow the plan we’ll be ok

The Agile mindset accepts that we are part of a larger complex system and we cannot be sure of the impact our actions and therefore our software will have on the overall system. So instead of planning to the nth degree, we create a rough order of features that we think might work and then release work into the wild as often as possible, gathering as much regular feedback as we can from our real customers to see if we’re on the right track. The Feature Release Roadmap changes based on the feedback and other inputs, such as changing market trends.

“Our Waterfall teams are cross-functional too!”

Co-locating everyone needed to achieve the business outcome is a good thing. Keeping working in silos inside the team is not. The whole team needs to get involved in all parts of the process. If the members of the team are still handing off work to each other and only focusing on their function, all that’s happening is mini-Waterfall over a 2 week period, which I must admit is better than Waterfall over multiple months or years! The hand-off is another example of the flawed notion of certainty –  that the work can first be clearly and completely documented, then designed and developed based on the specifications, then tested according to the same specification.

Agile teams understand how powerful face-to-face communication can be and instead use documentation only as a supporting act to facilitate discussions during the process. This means that team members interact with each other throughout the course of the Sprint and gain a good appreciation for the input and skills of the other team members.

2) “Isn’t a User Story just another phrase for functional specification?”

No. A functional specification is again about certainty, about believing that a single document can detail exactly how a system should function. The reality of this fallacy starts hitting home as soon as development starts and the first change needs to be made. Keeping a document up to date with the code becomes completely unmanageable, as well as extremely costly and it invariably drifts out of sync.

A User Story, on the other hand, doesn’t try to be the definitive truth of anything. It is simply a narrative that is used to facilitate the discussions that happen during the development of the code. If it turns out that the Story didn’t deliver the value it intended, a new Story could easily be created to change the implementation. Seen this way, it’s clear that a list of all the Stories will not provide the details of exactly how the system should function – it was never intended to do so. That honour is left to the code and the test suite.

A Story is also framed from the perspective of the value that is provided to a User of the system rather than from the perspective of the system, an important point to remember.

3) “We have daily stand-ups too!”

This is often the first ceremony that is adopted  by teams wanting to “go agile” and, let’s face it, it’s better to have the team gathering daily, rather than weekly, or (perish the thought!) monthly!  When a Waterfall project adopts a daily stand-up, the Project Manager will usually be running it and requesting status updates from everyone in the team, usually marking off the responses on a project plan against the planned deliverables. The Project Manager will usually also allocate work to the team members if someone is finished with their previous task. If they have a visual radiator (aka a kanban board), it is usually either just a replica of the project plan, or a kanban board with a column for each phase: analysis, design, development, testing and deployment. The goal is usually not to get the work through the entire pipeline in one Sprint but rather through a specific functional area, for example, this Sprint will involve getting the design finished so that next Sprint the developers can start coding.

Contrast this with a high-functioning agile team, where anyone in the team may facilitate the stand-up, or indeed, no-one needs to facilitates at all! The team focuses on getting the work on the board through to done and in priority order. They use the stand-up to recalibrate and plan the day ahead, taking into account anything that may have changed. When there is an issue, they don’t try to solve it in the stand-up, rather planning a quick huddle afterwards, fully aware that others need to continue with their work to keep the flow happening. Optimising the flow of work through the pipeline is key to improvement.

Not so different

There are a number of other examples that abound but I think you get the point. On the surface there are similarities  but when you probe a bit deeper you will find that they’re fundamentally different. You can’t effectively superimpose Agile on Waterfall. If your mindset doesn’t change, your way of working won’t, and this is when people usually proclaim “We tried Agile and it didn’t work for us.” They may have put a few ceremonies in place and changed the name of a few documents, but they certainly didn’t change.