Microsoft just turned 50. I also just themed XFCE running on the Ubuntu that powers my personal Surface Laptop to Chicago95. Don’t ask. I went the extra mile to make it do the start music.

I was talking about that with my buddy, and we started reminiscing the good old days, back when you deployed code to servers by copying DLLs manually. You were receiving a bunch of requirements in an Excel spreadsheet, a PM (project manager) would put stuff into a gantt chart, you started with specs, UML and a nice architecture diagram. Projects lasted a long time, a QA would validate stuff around, a support person would interact with the customers. And devs were deving.

Good ol’ days.

Thinking about it, the situation was not really worse or slower than the “Capital-A-gile” I’ve experienced in some places since. I think I was coding much more back then, and work was funnier. I’m fully aware that I’m looking at it through the prism of melancholy, and that 20y or so of experience are bound to give you different responsibilities that get you out from the fun stuff.

Back then, I didn’t see “waterfall” as an ancient or bad thing; it was how we were working. Waterfall became a derogatory term. If a place isn’t “doing agile the right way”, the project is automatically called “waterfall”.

That ain’t true. For all its negative aspects, waterfall at least has structure. And that structure was adapted to larger organizations where cross-dependencies, planning, predictability are important. I’ve been in a bunch of small and large organizations, the latter always envied the former. People want to be “agile”, go fast, be there first, use cool tech, etc. So the first thing they do is cargo cult: copy how they work, surely we’ll get there faster!

Truth is, being nimble doesn’t start with process but with mindset and organization. If your structure doesn’t allow for a lot of autonomy and the associated little scrutiny, reduced dependencies, and high tolerance for mistake, if you need 50 people in the room for a project to move forward, any attempt at “being agile” will fail.

The typical cycle goes through removing processes (planning is not agile! testing is not agile! ops are not agile, now you deploy!) and specs (specifications are ssoooo not agile, you should create a mental perspective of what you’re doing and just wing it!), setting up short cycles (“sprints”, typically without the customer feedback that was the entire point of said iterations…), sprinkle in some tools and some boards, and “YOU GO AHEAD NOW, AGIIIIILE!!! SHIP IT!!

Before we realize that we need other teams. And said other teams can’t accommodate the requests from everyone so they setup sort of a backlog. People get angry and ask to provide ETAs, so they setup a new planning process, and a formal intake process. Next thing you know you also need a planning process to ask other teams for their help. You need to provide specs that have 10% chance of seeing the light of day long in advance, and then fight for the other team’s attention. Your own hierarchy starts getting antsy and also asks you estimates (called tshirt sizes or SWAGs because estimates are waterfall) and dates. Or dates for dates. Or dates for dates for dates. Cross dependencies start breaking each other, and no-one is there to integration test, so instead we introduce bureaucracy and rubber stamping. “But we’re agile!” So we’re still expecting to go fast (be frantic), break things (please don’t), have impact (deliver tons of shit even if you don’t know if it’s valuable) and of high quality (even though no-one ever stops to look at the big picture).

In other words: something that people who never experienced anything else will call agile, something that people who experienced agile will call waterfall, but in reality something that is the very intersection of the worst of both worlds.

When you remove waterfall, you don’t get agile. When you remove agile, you don’t get waterfall.