Scrumfall: the pipeline nobody wanted

I had the team. The right people, real trust, a charter we owned. From the inside it felt good.

It did not feel great. The collaboration was strong. The problem was everything that happened after the collaboration stopped, in the pipeline that moved our work to production.

We were in a good place. Work was getting specced, built, and shipped.

From the inside, it felt good, but not great.

The problem wasn't collaboration. Product owners and engineers talked properly. We understood the why. We knew what we were trying to build and why it mattered.

The problem was what happened after that.

Our DORA metrics were suffering. It took too long to get a feature out, and the quality by the time it arrived was shakier than it should have been.

Here's how it worked.

A feature branch was cut from main. Once complete, it had to pass review before the pull request could be merged into dev.

That sounds reasonable.

In practice, it caused chaos.

It was scrumfall, really. A bit of Scrum ceremony stretched over something that still walked like waterfall.

As soon as something was reviewed and merged, the shared dev environment unravelled. If Engineer A added new functionality and Engineer B accidentally turned all the text hot pink, tracing the fault became a miserable game of guesswork.

Testing several tickets at the same time was painful.

It did not bring joy.

The frustration ate into morale. That small rush you get from finishing a piece of work and showing it off was replaced by quiet disappointment, because the environment you were showing it in was untrustworthy and half-broken.

Worse, any rework meant dragging yourself through the same cycle again.

Rework could be anything: a change the business only just realised it needed, a design that shifted halfway through, an unknown that surfaced late, or a defect that needed fixing.

Textbook processes assume scope is controlled perfectly.

In real life, business needs come first.

We all try to limit scope creep. We all try to create follow-on tickets when that makes sense. But it is not always possible.

So a ticket that needed modification went round the same loop again.

Another review.

Another merge into dev.

Another attempt to unpick a shared environment that was already a tangle of concurrent work.

And this is where the real trouble sat.

Dev was not the same as main.

A pull request often needed extra changes just to land in dev, purely because dev was so volatile. That became another drain. Another place where energy leaked away.

It almost trained you to expect disappointment.

Because of this arrangement, a PR couldn't easily be killed.

Once it had survived dev, the next step was staging. That meant merging the feature PR into the RC branch, a two-week branch we eventually merged into main so it could reach production.

Staging was calmer, but it still needed another round of testing and a product owner sign-off.

Again, cumbersome.

I'd argue it was the opposite of inspect and adapt.

The opposite of show and tell.

The cost of change was huge.

If something was unfinished, what did you do? Ship it anyway because nobody wanted to drag a ticket backwards across a Jira board? Hold everything up? Rework it and loop through the same pain again?

To me, this wasn't agile.

It wasn't the fault of Scrum.

But it certainly wasn't flow.

It was a pipeline nobody wanted.

I remember keeping a Trello board like some frazzled air traffic controller, tracking which Jira tickets were linked to which PRs, where they had been merged, and where they needed to go next.

Unnecessary complication.

It didn't scale.

The only reason it survived was because people cared. It ran on effort, and actual love for the work, and a shared desire to realise the vision.

But that's the point.

A process should not work only because good people are willing to absorb the pain.