Technology · Agile delivery

Scrum Is a Prescription, Not a Religion

By Marvis Huff · 2026-10-10 · Part II

Part II — Measure without dehumanizing, lead through service, and preserve agility over ceremony

Part I argued that responsible transformation begins with diagnosis rather than doctrine. It examined opposition as information and the importance of a credible champion. But a transformation cannot live on sponsorship and good intentions alone. It needs evidence, leadership, enough structure to create clarity, and the judgment to abandon a prescription that does not fit.

Use analytics as a mirror, not a weapon

Analytics can convert a debate about feelings into a conversation about systems. But metrics become dangerous when they are used to rank people, manufacture certainty, or punish transparency.

Begin with measures connected to the diagnosed problem. If work takes too long, examine cycle time and aging work. If delivery is unpredictable, compare commitments, completed outcomes, blocked time, and the causes of interruption. If quality is suffering, study escaped defects, rework, and time to recovery. If stakeholders are disengaged, measure review participation, decision latency, and how quickly feedback changes the product.

Velocity may help a team understand its own planning patterns. It should not be used to compare teams or convert human effort into a performance quota. Story points are a local forecasting aid, not a universal currency.

The purpose of analytics is not to prove that Scrum works. It is to reveal whether the system is becoming healthier.

Pair quantitative measures with qualitative evidence. Ask team members whether priorities are clearer, whether ceremonies help them make decisions, whether dependencies are discovered earlier, and whether they feel safe enough to expose risk. Numbers show patterns; people explain them.

When the data contradicts the transformation narrative, believe the data long enough to investigate.

Lead by serving, and serve by leading

Servant leadership is sometimes misunderstood as passive facilitation: schedule the meeting, take the notes, remain agreeable, and hope the team self-manages. That is neither service nor leadership.

To serve a team is to create the conditions in which it can succeed. Sometimes that means listening. Sometimes it means teaching. Sometimes it means confronting a leader who continually breaks the team’s focus. Sometimes it means challenging the team to own a problem it has learned to externalize. Service removes dependence; it does not make the team dependent on the servant.

Leadership provides direction, protects values, and makes difficult truths discussable. Service ensures that power is exercised for the growth of the team and the value delivered to stakeholders. The two ideas are not opposites. Mature Scrum leadership stands where they meet.

The Scrum Master should gradually become less central to routine coordination because the team becomes more capable of inspecting and adapting for itself. Success is not measured by how many ceremonies require the Scrum Master’s presence. It is measured by how much healthy behavior continues without it.

Create structure without creating bureaucracy

Structure answers a necessary question. Bureaucracy often preserves an answer after the question has disappeared.

A Sprint has structure because a stable timebox creates a meaningful opportunity to focus, produce value, and learn. A Daily Scrum has structure because Developers need a frequent moment to inspect progress toward the Sprint Goal and adjust their plan. A Definition of Done has structure because shared quality expectations reduce ambiguity and hidden work.

The trouble begins when every useful conversation becomes a mandatory ceremony, every exception requires a form, every metric requires a dashboard, and every dashboard requires a meeting to explain the dashboard.

Before adding a process, ask:

1. What decision will this help someone make?
2. What risk will it reduce?
3. What value will it enable?
4. Who must participate—and who does not?
5. How will we know when this process is no longer needed?

If those questions cannot be answered, the process may be organizational scar tissue rather than governance.

Scrum’s boundaries should be respected if an organization claims to practice Scrum. Yet the framework leaves room for teams to choose techniques that fit their context. The objective is disciplined adaptability: enough consistency to create transparency, enough flexibility to respond intelligently, and enough courage to remove practices that no longer serve a purpose.

Scrum is not the answer to every problem

Scrum is designed for complex work where solutions emerge through learning, collaboration, and iterative delivery. It may be poorly suited to a stream of unrelated service requests, highly interrupt-driven operational support, simple repeatable work, or environments in which the essential accountabilities cannot be established.

Kanban may provide a better system for managing flow. A predictive approach may be appropriate where scope is stable, change is expensive, and the work is well understood. A hybrid may be necessary where product discovery, engineering, regulatory gates, and physical deployment operate under different constraints.

Choosing another approach is not a failure of agility. Forcing Scrum onto the wrong condition is.

The professional question is not, “How do I prove that my framework is right?” It is, “What form of work management gives these people the clearest path to value, learning, quality, and responsible control?”

A physician who prescribed the same treatment to every patient would not be admired for consistency. A project professional should not mistake methodological loyalty for professional judgment.

Agility is the outcome, not the costume

An organization can perform every Scrum event and remain deeply unagile. It can hold Daily Scrums while concealing bad news. It can run Sprints while changing priorities hourly. It can conduct retrospectives while refusing to change anything. It can measure velocity while delivering little value.

Conversely, a team may not use Scrum and still demonstrate agility through short feedback loops, transparent decisions, empowered collaboration, reliable quality, and continuous improvement.

The ultimate goal is not to make an organization look like the Scrum Guide. The goal is to help it sense reality sooner, learn more honestly, decide more responsibly, and deliver value more consistently.

That transformation begins with humility. We diagnose before we prescribe. We use analytics without dehumanizing people. We meet opposition with compassion and courage. We build enough structure to support disciplined learning, but never so much that the structure becomes the work. We choose Scrum when Scrum fits, and we choose differently when evidence demands it.

Frameworks are instruments. People are not.

Our responsibility is to treat operational dysfunction with honesty, competence, respect, and care—to leave the system healthier than we found it, and the people inside it more capable of improving it after we are gone.

That is more than implementing Scrum. That is leadership in service of change.

A question to carry with you: If the framework disappeared tomorrow, would the organization still know how to inspect reality, adapt responsibly, and improve—or had it only learned how to perform Scrum?

Return to Part I