What Flavor of Scrum Are You Running?

Ask ten software teams whether they practice Scrum, and nine will say yes. Ask those same teams what their Scrum actually looks like, and you'll get ten different answers. Somewhere along the way, Scrum stopped being a single framework and became an ice cream shop. Everyone has a favorite flavor, management keeps adding toppings, and nobody orders plain vanilla.

"What flavor of Scrum are you running?" is one of the first questions I ask when I'm evaluating a company's development process. The answer from managers is almost always the same: "We're following a modified Scrum" — said quietly, a little apologetically, as if it were something to be ashamed of. My response is always the same too. Nobody truly follows Scrum. If someone tells you they follow it to the letter, I'd be skeptical. Scrum is meant to adapt to your team, not the other way around.

My argument is simple: that's fine. Scrum isn't the end-all of software process, and it was never going to work the same way for every team. The question that matters isn't whether you're doing Scrum correctly. It's whether your version is making your team better at delivering software.

The flavors

You'll probably recognize your team in at least one of these.

Some of those flavors are genuinely bad. But the bad ones aren't bad because they differ from the textbook. They're bad because they don't help the team deliver. And plenty of teams that would fail a Scrum certification exam are shipping reliable software every week.

Scrum was never meant to be the whole answer

The Scrum Guide itself describes Scrum as purposefully incomplete. It defines a handful of accountabilities, events, and artifacts, and deliberately says nothing about how to design systems, test software, deploy it, estimate work, or handle technical debt. A lot of what people treat as core Scrum isn't in it at all: story points, for example, are a convention teams adopted around Scrum, not a part of it.

That leaves every team to fill in the rest, and the rest depends on things Scrum can't know: whether you're maintaining a mature enterprise product or building something new, how much of your week goes to production support, what your compliance requirements are, and — most of all — who's on the team and how they already work. Scrum also doesn't fix poor communication, unclear requirements, or organizational politics. Those are leadership and engineering problems, and a methodology alone won't solve them.

The mistake isn't adapting Scrum. The mistake is treating Scrum as the solution instead of a tool for finding one.

What I learned moving a team from Waterfall at Jenzabar

I learned this most clearly at Jenzabar, where I was brought in to move an engineering team from a traditional Waterfall process to Agile. Agile is the broader philosophy; Scrum was the framework we used as a starting point. On paper, the goal was straightforward: shorter iterations, more visibility, and a process that could respond to change. The hard part wasn't choosing a sprint length or scheduling a standup. It was the people.

Several members of the team had been there for years. They knew the software, knew its history, and had ways of working that were familiar and predictable — and, for the most part, had worked. Now someone new was asking them to change all of it. Not everyone was enthusiastic, and that resistance wasn't unreasonable. When you've spent years getting good at one way of working, a stranger arriving with a new process can feel less like an improvement and more like a judgment on everything you've done.

I could have walked in with the Scrum Guide, introduced every ceremony at once, and declared that we were now an Agile team. That would have been the fastest way to make everyone hate Scrum. Instead, I adapted the process to the team and brought changes in slowly — small adjustments, one at a time, each one given time to become normal before the next.

Estimation is a good example. The team was used to thinking about work in time — how many hours, how many days. Rather than jumping straight to abstract effort estimates, I started there, with sizing based on time, because it was what they already understood. It wasn't where I wanted the process to end up, but it was a familiar starting point. Once estimating in time had become second nature, we moved to estimating effort instead.

That shift was more than a change of units. Estimating effort changes how a team talks about complexity and uncertainty, not just duration — the conversation shifts from "how many hours will this take?" to "what makes this hard?", and estimates stop being treated as promises of elapsed time. And because it came after the team was comfortable with the step before it, it landed as a natural next move rather than another thing being imposed. Over time, the team embraced the new process, and we saw real improvements in how we collaborated and delivered software.

Was that textbook Scrum? Not exactly. I wasn't there to help the team pass a certification exam. I was there to help them build software better.

Adapt the process to the team, not the team to the process

The lesson I took from Jenzabar is the one I've applied everywhere since. Meet the team where it is: existing practices aren't wrong just because they aren't Scrum, and the people who've been doing the work for years usually know things about it that a framework doesn't. Introduce change incrementally, so people can absorb one improvement before taking on the next. And care more about adoption than compliance — a team that genuinely understands and uses a few good practices will outperform one that mechanically performs every ceremony.

It also means your flavor should keep changing. The process that helps a Waterfall team make its first move toward Agile can become an obstacle once that team has matured. The same applies in the other direction: when I worked with a team stuck in a cycle of rework, the change that mattered was getting requirements written and approved before work started — not adding more ceremonies.

Estimation wasn't the only practice I learned to question. Even something as fundamental as sprint length needs to reflect the realities of the team. Scrum only says a sprint should last a month or less; the length is up to the team. In my experience, one-week sprints have generally caused more problems than they've solved. Every week becomes another deadline, putting pressure on developers to finish work rather than engineer it properly. That can raise output in the short term, but over time it tends to lead to burnout and lower-quality code. That doesn't mean they can't work for some teams, but I've found that longer iterations often provide more room for thoughtful development.

There's also a danger in assuming that adapting Scrum means every team should be free to invent whatever process it wants. Adaptation still requires discipline. If you're eliminating a meeting, understand what purpose it served. If you're changing how work is estimated, understand what problem you're trying to solve. If you're abandoning a practice, make sure you're replacing its value rather than simply removing an inconvenience. The goal isn't less process or more process. It's the right amount of process for the team and the work.

Stop asking whether you're doing Scrum correctly

If your team is delivering reliable software, responding to change, communicating well, and improving over time, it doesn't much matter whether a Scrum purist would sign off on your process. And if your team runs every ceremony by the book but keeps missing commitments, shipping poor-quality software, and talking past each other, it's fair to ask what all that Scrum has accomplished. The best flavor is the one your team can actually use — and it's allowed to change as your team does.

Scrum should serve the engineering team. The engineering team shouldn't exist to serve Scrum.

Engineering leaders who want to see more of the systems I've designed and built can find my engineering portfolio at josephrounds.dev.