Orbital Development Cycle

That Tim Guy
3 min readDec 9, 2021

By this point you know the Agile ouroboros that seems only a spin cycle of neverending development hell. It is a never ending loop that should have had an entry and exit point. Eventually this collapses and becomes a “Kanban” platform when you fail to get clean info and timelines and are too much of a coward to admit failure and call it Scrummerfall, or Waterfall when you come to terms with reality. Toss a bowling ball in a washing machine… it’s exactly like that. Unbalanced, heavy on one side, and you by the time you realize it, you have to live with results because you can’t stop it now.

Today’s “iterative” is tomorrow’s “linear patch process” and “scalable” has always knowingly been self-delusion. Iterative has become “pack more s4!t in this one”… clearly not evolution.

There is a reason, we say progressive enhancement and not evolution, and it has a lot to do with never figuring out the definition of done and relying on good enough to ship as a way to just be over it and stop thinking about how it will never be what we wanted.

I’m talking about a heavy-lift of a new initiative here because launching is like a moonshot, it takes effort, and payloads to deliver and it seems corporate are hell-bent on lunar colonization. If you don’t get out of orbit fast, the rocket scientists on the ground will keep adding to your payload (iterative) while some of your contents get displaced or expire. You begin to break up and parts fall back down to earth as scope and requests change the shape of deliverables.

Orbital development cycles are as predictable as they are fatal. Jira is burned to the ground, every dev is micromanaged by an outside team member with an agenda, and the leads are crucified.

What is produced

Like Major Tom stranded in orbit above the moon with no way of landing or returning, we have produced space junk that you can’t readily reuse or repair, it knowingly becomes a legacy system at launch.

Simplified: You created something with useless dependencies that can’t scale and you have to build around.

Weak spots

The idea of launching any product comes with scope creep, and sometimes the product teams are a little more understanding but they ALWAYS say they don’t want to “see the sausage made” yet rely on us butchers to make something of it. They don’t give a s4!t about you, just getting their thing launched, and this is frustrating. You can try to plead your case but nobody understands, nor respects what you do, just that you press keys and get more money than they do, so they are inclined to not care about process, just that you follow through as they demand.

This is like doubling the heat in the oven to bake a cake in half the time.

What we plan for:


What Should happen:


What Actually happens:

A lot of tickets get swallowed up or slip by the process. Linear development.



That Tim Guy

Coder, photog, stick-shifting, animal lover, gardener, cook, comedian, from 11746 living in 90210.