More of a Guideline Than a Rule

Published October 14, 2026

“We can't take that on, we're in the middle of the sprint.” “The story isn't defined yet.” “That's how agile works.”

I hear some version of these a lot. Sometimes that's the right answer. More often it's an easy way to say no without thinking the request through, or having a conversation about scope.

Agile is where I see it most, but it happens with other frameworks and processes too. Most of what's in them should be more of a guideline than a rule. Someone takes a guideline and enforces it like a rule, often without understanding why it's there or how much flexibility it has.

The person who asked usually takes it as resistance. It makes people uncomfortable, and nobody walks away feeling like the team is on their side. The request just sits in a backlog.

Which agile?

On a project I was on, someone would ask the tech lead for something and he'd say we can't do that, we're in the middle of the sprint. Or we can't, we're about to be at the end of the sprint. He'd also say that's how sprints work, or that's how agile is supposed to work.

Agile is a lot of different frameworks, practices and mindsets, so there isn't one way it's supposed to work. Even Scrum, where most of the sprint rules come from, is more flexible than people make it sound. The 2020 Scrum Guide gives each sprint one objective, the Sprint Goal, and says scope “may be clarified and renegotiated with the Product Owner as more is learned.” (The Product Owner sets the team's priorities.) The Guide does rule out changes that “would endanger the Sprint Goal”. It doesn't mention user stories at all. The Agile Manifestosaid it more simply back in 2001: “Responding to change over following a plan.”

Where the rules come from

In a lot of the scaled agile transformations I've worked in, people with no background in agile get sent to training and then handed a bunch of new processes. Most of those companies never decided what they wanted out of it. Lower costs? More throughput? Better communication? A clearer view of where work gets stuck? Without an answer, they buy an approach and hope it works. People learn what to do without learning why, and do it in places it doesn't fit. That's cargo-cult agile.

I don't think packaged frameworks like SAFe are all bad. They make sense for a lot of large companies, and some would never have tried agile without one. If you're a heavy command-and-control organization, a command-and-control rollout feels like a good fit. There's a playbook and a plan, and people treat the transformation like a software install. That gives leaders a false sense of certainty. It also makes it easy to blame someone when it doesn't work. It must have been the teams, or the people who rolled it out. Hardly anyone asks whether it was the right framework for them.

Shu-Ha-Ri is an idea from the traditional Japanese arts, including martial arts, about how people learn a craft. In Shu, you're a beginner, so you follow the rules exactly as you were taught. In Ha, you understand why the rules are there, so you can flex them. In Ri, you're making up your own rules and trying experiments. Alistair Cockburn brought the idea into software. Stuart and Hubert Dreyfus, who studied how adults learn skills, found something similar: beginners follow rules that are the same in every situation, and experts work from the situation in front of them. Stuart Dreyfus wrote in 2004that “merely following rules will produce poor performance in the real world.”

A beginner following the rules is fine. That's what Shu is for. But those big rollouts put a lot of people in Shu at once, and some of them end up running the process for everybody else. They only know how to do it by the book.

I've been on the receiving end of this a lot, as the person with the most agile experience in the room. Someone who learned agile in one of those rollouts tells me how it's supposed to be done, a little passive-aggressively, like it's obvious and someone with my experience should already know. But every company does this its own way. An expert would ask a lot more questions and assume they don't know how things work here yet. Usually it seems obvious to them because they've only seen it done one way. (I wrote about the risks of knowing a framework like SAFe only at the surface in an earlier field note.)

In 1944 the Office of Strategic Services, the CIA's predecessor, wrote a manual on sabotage. Its tips for disrupting organizations include “Insist on doing everything through 'channels'” and “Never permit short-cuts to be taken in order to expedite decisions” (OSS, Simple Sabotage Field Manual, 1944). A lot of teams follow that advice today without realizing they're sabotaging themselves.

The say/do ratio

Leaders do it too, on a bigger scale. The one I'm going to pick on is the say/do ratio: what did the team commit to, and how much of that exact thing did they deliver?

A team's plan can stop being right a few weeks after they make it. The market changes, priorities change, a dependency nobody saw turns up, or something new comes along that matters more. Sometimes the plan was bad to begin with. When leadership holds teams to the ratio anyway, teams game it. They commit to less than they could do. They make stories so small that each one gets done but doesn't add up to much. They say no to urgent work because it would hurt the number.

Nothing in that number shows what the team learned. If they delivered something valuable that wasn't in the plan three months ago, it doesn't count, even if it was the right call. Marilyn Strathern, an anthropologist, gave Goodhart's Law the wording most people know: “When a measure becomes a target, it ceases to be a good measure.” Say/do is fine as a way to learn how well a team plans. Once teams are judged on it, they plan around the number.

When teams can't change course, some work never gets done and they can't respond fast enough. They miss opportunities, and sometimes they ship features that were already out of date. It's also draining for the people on the team, who can see what needs to change and aren't allowed to act on it. Christina Maslach and Michael Leiter's researchlists six areas of work that predict burnout. Two are lack of control and a clash between a person's values and the organization's.

Protecting the team

Sprints and backlogs do protect teams. A sprint gives people time to focus, and new requests go into the backlog instead of interrupting it. If a team is always pivoting, it's hard to get anything done. The 2015 State of DevOps Report, a large survey of software teams, found that “Unplanned work and constant firefighting contribute to high stress and feelings of lack of control.” Constant pivoting takes control away from people too, just like a plan nobody can change.

If a team knows the work well, it can plan a sprint and focus on it. If there's a lot it doesn't know yet, it probably needs more flexibility, and more of its time should go to learning than to doing. As things get clearer, it can shift back toward doing.

So there's nothing wrong with “we'll pick that up next sprint” when the person saying it explains why, and what it would take to do it sooner. Somebody also has to own that decision, instead of pointing at the process.

When it's done well

The teams I've seen handle this well plan for unplanned work. They build in slack time instead of filling every hour. When something new comes in, they talk it through: okay, we can do that, and here's what moves to make room. If the whole plan has to change, they change it and write down why, so they can tell the story later.

As a consultant, I don't always get to push back. Often the client decides, and we do it their way. When I can push back, I try to keep it curious instead of turning it into a conflict. I ask questions. What about this case? What happens if that comes up? Or I go along with it and point out the likely impact. I wish more people would just say “this is how we do it here.” When someone says “this is how it's done,” they're acting like it's the only way and everyone does it.

A framework should be a scaffold for thinking, with enabling constraints, not handcuffs. You still have to think and make decisions. You can't just let the framework do it for you.

Asking first

I get most frustrated when people act like they have all the answers. The person quoting the sprint rules does it, and so does the leader holding a team to a plan from three months ago. When you act like you know everything, you stop being curious and you stop learning, and curiosity and learning are a big part of what agile actually is.

If you're the one saying no, try asking a question before you quote a rule. You might still end up saying no, but the person asking will know why. If you're a leader tracking say/do, ask your teams what they delivered that mattered, and why the plan changed.

Back to Field Notes