[Context: This post is a quick copy/paste from a post in LinkedIn, but I wanted to save it. There may be some quality issues in this text, too. I hope to expand on this idea, with some images to help the understanding, in the near future.]

Most people don’t seem to understand the true difference between Agile and traditional software development.

Waterfall is based on the idea that we take something we want to do, and break it down into subitems – actions or sub-components – and then deliver them separately – often by separate people who are experts in the activity or subdomain – and handing over those items to each other as needed. E.g. someone first needs to spec the requirements, then another person designs the UI, third person looks at architecture and technical design, before passing it to a fourth (UI programmer) and fifth persons (BE programmer) for coding. Then yet another person runs (often manual) tests on it and complains that it doesn’t work. Yet more people might be involved in deployment, documentation, etc.

In this approach, it truly is difficult to break things down small enough.

Now, Scrum, being properly of Agile mindset, challenges this approach, by expecting people to complete items to a “potentially shippable” quality within each Sprint. “Coded but not tested” doesn’t cut it, nor does “works on my machine”. Each PBI is an independent capability that doesn’t have to be returned to in the future, unless we specifically want to extend or modify that capability.

Enter “vertical slicing”. Each slice contains all the activities needed to take an idea/need/desire from 0% to 100%. A little bit of spec, a little bit of architecture, a little bit of coding, a little bit of testing, a little bit of this and that, and at the end of the slice, that small things works in the product.

It can therefore be shown to someone, if we desire to hear feedback. Or it can be given for use if it’s useful for some external purpose (not all vertical slices result in end-user valuable feature level). Or, we can simply see that we were able to make something work and we can inspect how well it works or how long it actually took us to do it.

Now, this approach poses some problems. The most obvious one is that within each vertical slice, we have to be able to confirm that we didn’t break any earlier functionality. If we have a larger product, this can mean a lot of testing. Manually done, it’s impossible for speed and cost reasons. So we will need high levels of automated testing that can also be executed rapidly and often. This can effectively only be achieved by some test-driven development approach.

Another problem is that the different levels of the architecture – UI, BE, integrations – must be developed in sync. At each point in development, we should be able to compile them against one another, and test them together. In traditional terms, this would mean e.g. that FE and BE devs have aligned tasks, and that they perform them at the same time, but that’s a ridiculous expectation because the tasks are often of different duration and it’s a massive coordination nightmare. Especially if there are separate FE and BE teams.

So we need a different development approach. We need something like eXtreme Programming (or its modern evolutions). We need new team structures and collaboration models that extend over multiple skill sets and structural layers.

This has proven to be very difficult for a lot of people and organisations. I’m currently working with one organisation that proves this point.

Note, I’m NOT saying that all orgs have to do proper Agile – they certainly don’t, and it isn’t always even a smart choice in some environments. I’m just saying that a lot of people don’t know the difference, and are still doing waterfall when they think it’s Agile.