You can't improve flow by committee

We had a pipeline nobody wanted. Scrumfall, a volatile shared dev environment, and a cost of change that ate morale.

This is how we changed it. Not with a transformation programme, and not by waiting for the wider organisation to agree. With the team, one piece at a time.

I could not just change everything in one day.

It was not my process to own on my own. I wanted the team to own it. If the team did not believe in the change, it would become my process, my crusade, my little delivery hobby horse.

That was not going to work.

But as I argued in why design by committee leaves engineering change unfinished, everything still needs a champion.

Someone has to care enough to keep pushing.

Someone has to hold the shape of the thing.

Someone has to be the dreamer, the awkward one, the person who says, "I know this hurts, and I think we can make it better."

That does not mean forcing change onto people. It means creating enough belief that people want to come with you.

So I started by drawing the process.

Not a polished architecture diagram. Not some official Agile transformation map. Just the actual journey of work as we experienced it.

From idea, to ticket, to branch, to review, to dev, to testing, to rework, to staging, to sign-off, to release.

When you draw it out, the pain becomes visible.

You can see the waiting.

You can see the hand-offs.

You can see the rework loops.

You can see where energy disappears.

I made it clear to the team that I knew what hurt. I was not coming in with a perfect answer. I was inviting them into the journey, except I did not fully know the path yet. I have written before about understanding the problem before you change the process. Drawing it was how we understood ours.

All I really knew was DORA.

Not as a buzzword. Not as something to bore people with. But as a compass.

Lead time mattered.

Deployment frequency mattered.

Change failure rate mattered.

Recovery mattered.

These were not abstract delivery metrics. They were a way of asking a much simpler question:

Are we getting better at shipping valuable change safely?

That was the point.

I did not start by giving the team a lecture on DORA. That would have killed it immediately. Nobody needed another framework thrown at them.

Instead, I focused on one piece at a time.

Make the pain visible.

Make the change relatable.

Make it something the team wanted, not something I wanted.

The first thing I wanted to knock down was the scrumfall line.

Before, work moved through stages. Product owners discussed the need. Engineers built the thing. Testers verified it later. Everyone was technically involved, but not always at the right moment.

I wanted everyone involved throughout.

We all owned the feature.

We all owned the change.

We all owned the goal of getting it shipped.

That meant more questions before we started. It also meant more questions while the work was happening.

The biggest change was for testers.

They had inevitably been left to work after the spec, trying to verify and translate decisions that had already been made. They may have been in the room, but being in the room is not the same as being genuinely involved.

I wanted them to understand the need earlier.

I wanted them thinking about testability before implementation.

I wanted their questions before a single line of code was written.

This sounds obvious when you write it down, but culturally it was hard.

Some of the testers were naturally reserved. Their culture, a bit like my Indian culture, could sometimes lean more towards being respectful and quiet than openly challenging people in a room.

I did not want to put people on the spot.

That would have been unfair.

So I worked with them.

I tried to understand their personalities. I tried to ask the questions they might have wanted to ask later. I brought those questions forward into the conversation before development started.

What would make this hard to test?

What would you need to see?

What data would help?

What would make you confident?

What would make this ambiguous?

What could go wrong?

By doing that before implementation, we could build what they needed into the work itself.

Not as an afterthought.

Not as a scramble at the end.

Not as another rework loop.

And I did not have to do this for long.

You could see the change.

You could see it in their faces.

They knew it was a game changer.

Their engagement gave us another valuable perspective. It also reduced the cognitive load later. When testers understood the intent, testing became more focused. They were not just checking acceptance criteria. They understood what mattered.

That meant better attention to detail.

It meant better questions.

It meant fewer surprises.

And as we will discuss later, it meant less rework.

This is the part that often gets missed.

DORA is not just about pipelines and deployment buttons.

It is about the system of delivery.

If you improve lead time by rushing people, you have not improved anything. You have just moved the pain somewhere else.

If you increase deployment frequency but quality drops, the system is not healthier.

If testers are only involved at the end, you have built delay into the process.

If feedback comes late, rework becomes expensive.

So we started moving feedback left.

Not because "shift left" sounds clever.

Because late feedback was hurting us.

We were ahead of the game before we touched the tooling, because we had engaged people.

That is the thing we often cannot measure properly.

You can measure lead time.

You can measure deployment frequency.

You can measure escaped defects.

You can measure failed changes.

But you cannot easily measure the moment someone starts caring more because they finally feel part of the work.

And that mattered.

The next big change was how and where we tested.

The shared dev environment killed joy. It slowed us down, confused defects, and made simple things feel difficult.

The committee answer was to wait.

Wait for alignment.

Wait for agreement.

Wait for the wider process to catch up.

But it was my team lead who said the thing I probably needed to hear:

"It is your project. Do what you want. You would not be where you are without full trust. Do not ask permission."

That changed everything.

We stopped waiting for the world.

We took the bet. As I have argued, engineering decisions are bets, not proofs, and this was ours to make.

This was back when feature environments were still early. They were not everywhere yet. They were not the default answer.

But for us, they made sense.

If the problem was a shared dev environment full of concurrent work, then the answer was obvious.

Stop forcing every feature into the same messy space.

Give each feature somewhere clean to live.

Give testers somewhere reliable to test.

Give product owners somewhere focused to review.

Give engineers a place where defects belonged to the work in front of them, not to a mystery soup of everyone's changes.

That changed the game for us.

It reduced confusion.

It shortened feedback loops.

It made defects easier to trace.

It made conversations clearer.

It helped us move from a pipeline of hand-offs towards something closer to flow.

And that is where DORA became useful again.

We were not chasing metrics for the sake of it.

We were changing the system so the metrics could improve naturally.

Less waiting improved lead time.

Cleaner testing reduced change failure.

Smaller, safer changes made releases easier.

Faster feedback reduced rework.

Better ownership improved the whole system.

We worked on the feature while it was in development. We tested it while it was in development. We reviewed it while it was in development. We got stakeholder feedback while it was in development. The cost of change dropped.

That took the pressure off heavily specced tickets. We could get started sooner. It was finite thinking instead of infinite thinking. It was lean. It took coordination and alignment up front, and after that the work was boring in the best way.

I cannot give you the exact cadence for when we deployed. Some days it was daily. It was never less than weekly. We deployed when we wanted, with full confidence, because the testing and the CI/CD pipeline were there to back us. Less rework. Fewer unknowns.

That was the real lesson for me.

You do not improve delivery by telling people to go faster.

You improve delivery by removing the things that make good people slow.

You remove the hidden queues.

You remove the late surprises.

You remove the environments nobody trusts.

You remove the hand-offs that make everyone slightly less responsible.

And you do it with the team, not to the team.

Because a process does not become better just because someone draws a new version of it.

It becomes better when the people inside it believe they can change it.