Before You Change the Process, Understand the Problem

Strong opinions should be earned, not borrowed. If you want to propose a change, do the work first.

Understand the trade-offs before you walk into the room.

I see the same pattern again and again in software teams. Someone reads a blog post, watches a conference talk, picks up a new buzzword, or sees how a company like Spotify talks about working, and by the next meeting they are proposing that the whole team change how it works.

The idea often sounds compelling at first. But the moment you ask about the trade-offs, the case falls apart. There is no real research, no serious risk assessment, and no clear plan for what to do if the change creates new problems rather than solving the old ones.

That gap between enthusiasm and understanding is where teams get into trouble.

The real-world test

When I returned to University Press as principal architect on a project called Higher Education, my team lead, Clare, and I had to make a foundational decision on day one.

How should the team work?

The team had grown up inside a Scrum process that had become rigid and overly ceremonial.

All the artefacts were there, but the collaboration was not. In practice, the work moved in sequence. Design finished and handed over to development. Development finished and handed over to test. It was Scrum in structure, but not in spirit.

That was the real problem.

The answer was not to throw out Scrum and replace it with something fashionable. It was to understand why the team was struggling and improve the way we worked within a process people already knew.

Clare asked me a simple question: "You're the principal. What do you think we should do?"

I told her I wanted to come back with a proper answer.

Clare and I were not best friends, but there was trust and respect between us. She had brought Agile into University Press and had given talks about it, which helped me enormously. She challenged my thinking, gave me honest feedback, and I learned a huge amount from her. I will always be grateful for that.

So I went back to first principles. Back to what I had learned during my degree, when we studied Agile, Taylorism, Denning, and the different ways of thinking about work. I went back through lean and agile articles, books, and talks, and grounded myself in a simple truth. Process should reflect the nature of the work.

What we were doing was not repetitive factory production. It was creative, uncertain, collaborative product development. That kind of work depends on fast feedback, shared ownership, and people working together early, not passing work between silos.

So when I came back to Clare, I was not proposing a new methodology. I was proposing a better way of working.

The case was simple. Keep the parts of Scrum that were helping, remove the behaviours that were creating walls, and increase collaboration across the team.

In practice, that meant changing how we planned and delivered features. When it came to planning, we brought together the stakeholders, the engineer, and the tester, and used a Three Amigos approach to discuss the change. We started with the business outcome, then planned a verifiable, incremental way of delivering the feature.

Testing did not sit at the end waiting for development to finish. It happened during development. We made sure testers had what they needed to test the way they wanted. Everyone on the team could draw the same high-level picture of the services involved and the data needed. We talked through the happy path and the known knowns up front.

That did not remove uncertainty, but it changed how we dealt with it. The mindset became simple. Unknowns will happen. Problems will happen. Our job was to design and communicate in a way that made reproducing, identifying, and resolving issues faster when they did.

Day to day, the work no longer felt disconnected. Everyone felt involved. Everyone knew the context. By the time we came into meetings, people were already aligned. The ceremony was naturally reduced because less time was spent catching people up or reconnecting work that had been split apart. Time wasted dropped. Communication increased.

Just as importantly, I was clear about the risks. The team was used to working in a certain way. More collaboration would feel uncomfortable at first. It would require people to communicate more openly, share ownership more actively, and adjust habits they had built over time.

But that honesty strengthened the proposal. I was not selling a silver bullet. I was showing the team where I thought this would help, where it might be difficult, and how we would know whether it was actually improving things.

That is what made the conversation credible.

What most people miss

Too often, people frame process change as a choice between named methodologies.

Scrum or Kanban. SAFe or no SAFe. Estimates or no estimates.

But most team problems are not solved by picking a new label. They are solved by understanding the actual constraint.

Sometimes the problem is too many handoffs. Sometimes it is weak communication. Sometimes, it is unclear ownership. Sometimes it is a process that has become disconnected from the people doing the work.

If you misdiagnose the problem, even a good framework will be applied badly.

Something is not right for your team just because it sounded good in a book, looked good in a case study, or became famous because a company like Spotify talked about it. Many teams copy labels, rituals, or structures without understanding what made them work in the first place. That is how people end up cargo-culting someone else’s model instead of solving their own problem.

The difference in practice

The anti-pattern

“We should switch to Kanban. I read that it works really well for high-performing teams.”

The standard

“Our problem is not Scrum itself. Our problem is that work is moving through silos. I think we should keep the useful structure, reduce the handoffs, increase collaboration, and review in two weeks whether flow, communication, and delivery have improved.”

That is a much stronger proposal because it is rooted in the team’s reality rather than borrowed from somebody else’s context.

What I took away

1. Start with the problem, not the framework.

Teams get into trouble when they inherit solutions before they understand the issue. Diagnose first. Change second.

This happens in sports all the time. Football teams do not choose one strategy in August and stick to it until May, no matter what. They adapt game by game based on the opposition, the conditions, injuries, and the strengths and weaknesses in front of them. Teams at work should be no different.

1. Improve before you replace.

You do not always need a new methodology. Often, you need to remove friction, reduce handoffs, and help the team collaborate more effectively within the process they already understand.

1. Present the risks as clearly as the benefits.

Anyone can sell the upside. Credibility comes from being able to say, “Here is where this may be harder than it sounds, and here is how we will know if it is working.”

1. Process should serve the team.

If a ceremony helps, keep it. If it creates a delay without adding value, challenge it. If someone is blocked, they should not have to wait for tomorrow’s stand-up to get help. Good process supports communication, ownership, and flow. It does not replace them.

The standard worth aiming for

The best proposals do not just answer the question, “What should we change?”

They answer, “What problem are we actually solving?” and “How will we know if this is better?”

That is the difference between borrowing an opinion and earning one.

That mindset led to a lot of changes that were a first for University Press. We were the first team to use TypeScript and Tailwind. We introduced feature branches. We focused on DORA metrics and on delivering value to the business, rather than obsessing over velocity points.

Each time, I said the same thing to the team: “Let’s try it. If it is not working in a month, we will remove it.”

We never had to remove a single thing.

And in leadership, that difference matters.