This page seeks to give you an idea what to expect from my talk on “The Real Difference between Agile and Waterfall”.

Most of the Agile I see in real life is more like mini-waterfalls (assuming I don’t see something that is not Agile at all). I get to see very little of what I consider as Real Agile. And the sad thing is, most people who think they are doing real Agile don’t know they aren’t.

This is, unfortunately, a by-product of the decision by its founders to focus only on the management flows, and subsequent success of Scrum as the Agile framework. It is not what Scrum was intended to be in software development.

Anyway, so what is the real difference? What is the point of this presentation?

Over the years I’ve refined the way to explain this key difference. Step 1 is to outline the basic essential appoach, from “horizontal” to “vertical” slicing. Here’s a slide from a training notes:

The key consequence of this approach is, obviously, that as we get further and further in the project, we start losing our ability to adjust scope, since more and more of the work has already been done but not finished. In the Agile, to the contrary, since every slice is also “100% Done”, any future scope is completely flexible.

Step 2 is to walk people through the normal epic to stories breakdown, how we take a big vague scope, and iteratively break it down into smaller and smaller stories, until we reach something that the team can finish in less than one Sprint, to a “potentially shippable” level, i.e. “100% Done”.

Many teams actually get to here, and while in many teams the “100% Done” isn’t quite 100%, we might call this “okay Scrum”. I’m going to ignore the many projects that are far below even this standard.

But now we start getting to the crux of the session – the transformation of this “ok Scrum” into mini-waterfalls, and what we should do instead.

A lot of teams take these small stories, and break them down to development tasks, like design this, code this, test this, document this, etc. What often happens is that different people are experts in different things, so the team members will likely only pick tasks they are good at, so coders code, testers test, designers design. And of course, you can’t test before you code, and you can’t code before design, so we get a workflow that looks something like this:

That’s waterfall. With all its trappings, like queues between people and work types, all back flows from errors discovered after a given step, slow actual delivery, incomplete work at the end of the Sprint, etc.

Yes, it’s smaller waterfalls than what we used to do, but it’s still waterfall.

This is where we get to step 3 of my narrative. How should we actually develop stuff in real Agile?

And of course, the answer isn’t a new one. Use XP-like practices all the way through. But what makes this session novel is the way I walk people through the process of understanding how crucial the XP-like approach is to really doing Agile right.

The key is staying with the idea of vertical slices, even within a development level story. If the idea of vertical slicing epics into smaller slices turns a big waterfall into “ok Agile”, the same idea turns mini-waterfalls into actual Agile. Story is sliced into, for example, acceptance criteria, which are sliced into acceptance tests, which are sliced into unit tests, which are then developed in a ATDD/TDD style flow into very narrow (5-30min) development sessions by a collaborative team. Drawn into an image, it might look something like this (from a training slide):

Step 4 is then explaining that the test automation, at a level that can be trusted, is a necessary condition for doing this. Not only because continually adding stuff and refactoring would be nigh impossible at some point, but also because the economics of software development force testing into larger and larger packages. The way I explain that is through the following diagram.

I will do better graphics for the session itself.

So that’s the session – its key ideas and flow. I would like to make the session a combination of ready made slides and drawing on an iPad, to illustrate the ideas as we talk about them. That’s how I do it in my training classes and it works wonderfully, reducing the “powerpointiness” of the talk dramatically. It also allows adjusting to questions, though I would not expect them during the conference talk.

Thank you for reading all the way through.

If you decide to accept my talk to the conference, here is a photo of me to use: