Cycle models are just hiding many small parallel and cascading waterfalls

Unpopular opinion: even in Agile we just work in many small waterfalls or V-models, in parallel, all the time. Scrum and Kanban in action feels more like my ADHD brain works. Doing all the things, all the time, and in parallel.

Don’t get me wrong. My brain is fine with working that way. But do you know what is merely impossible? Drawing a model that represents that complexity in a way that also neuro-typical people understand where potential problems might be.

I already hear the Scrum masters and Agile coaches facepalming hard how wrong this is. But this is my reality for over 10 years now. The 15 years before that I worked in waterfall/V-model. And my assumption – you know, I’m good at those – is that it is true for others as well.

The models look so sweet and clean. Circles, cycles, the DevOps ∞, and what not. Why do we choose these hamster wheel representations? I don’t want to start over with everything every two weeks.

We are working on features, epics, stories, tasks, you name it. We don’t have one of each. We have multiple of each. They are not in the same state. Tickets are being drafted, refined, estimated, planned, put in progress, are in code review, being tested, delivered, deployed, and a dozen other things that I forgot. All the time. In parallel we have these reoccurring meetings. Plannings, refinements, reviews, daily stand-ups, and some more. Every x weeks we increase the number of our sprint name. Sometimes we do, sometimes we do not also deliver a bunch of work. We don’t deliver for one task, story, epic or feature. We mostly deliver for parts of many. That doesn’t mean they are all complete by then.

The power of Agile is fast feedback cycles. Now that you get frequent and fast feedback, you need to bring the reaction to the feedback back into your work management.

Then there are these pesky dependencies. Task A can only be finished when Task B is ready. Task B relies on Epic C, but that is waiting for something from Feature D. And Feature D is waiting for production feedback from Task A. Have I mentioned timelines already? Oh, people want to get things delivered by certain dates.

All this means that we constantly manage dozens and dozens parallel waterfalls, that are in different stages of the waterfall, on many different levels. As a tester you have to keep up with a whole bunch of tickets that your developers are working on. You have to jump in before and after and be involved with all of them to provide fast feedback. Early feedback enables to save time later.

Depending on the complexity of your delivery process you add also the stress of delivering every now and then. What used to be once or twice a year is now every other week or every week. If you deliver daily I’d assume that your delivery process is as smooth and lean as it could be. All others have to deal with delivery stress and overhead 20-50 times a year now.

Sure, the impact on production is smaller when you mess up. Or is it? It depends, I would say.

And then someone comes and shows you a simple circular model how Agile works. That someone better runs for cover.