Technology · Agile delivery

Scrum Is a Prescription, Not a Religion

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

Part I — Diagnose the system, understand the opposition, and find the right champion

The hardest Scrum transformation does not begin with a backlog, a ceremony, or a new set of roles. It begins in a room where people have already survived several transformations.

They have seen frameworks arrive with new vocabulary and familiar problems. They have attended mandatory workshops, filled out new templates, and watched yesterday’s bureaucracy return wearing tomorrow’s terminology. When another change leader arrives promising agility, their opposition may not be ignorance. It may be memory.

That distinction matters.

Resistance is often treated as a defect to eliminate. In reality, resistance is information. It may reveal that people do not understand the purpose of the change. It may expose an incentive that rewards the old behavior. It may point to a genuine mismatch between the proposed framework and the work. Sometimes it is simply the nervous system of an organization protecting itself from another badly managed intervention.

If we want to introduce Scrum into a non-Scrum environment, we should not begin by asking, “How do I make everyone comply?” We should ask, “What is this organization trying to protect, what is preventing value from flowing, and what is the smallest responsible change that could help?”

That is the beginning of agility.

Diagnose before you prescribe

A responsible physician does not begin with a favorite medication. The physician begins with the patient: symptoms, history, context, evidence, and risk. Only then does treatment become appropriate.

Project and delivery professionals should bring the same intellectual discipline to organizational change.

The diagnosis is the problem statement. It should name the operational condition clearly enough that people can recognize it: priorities change without decisions being communicated; work remains hidden until late in delivery; dependencies surface only when deadlines are threatened; teams begin too much and finish too little; customers wait too long for feedback; ownership is unclear; defects return because learning is never built into the process.

The prescription is the solution approach. Scrum may be part of it. So may Kanban, a hybrid delivery model, stronger product management, clearer governance, better engineering practices, or simply the removal of one unnecessary approval. The prescription should follow the diagnosis—not the consultant’s preference, the leader’s latest conference, or the organization’s desire to appear modern.

The prognosis is the technical and organizational roadmap to a healthier state. It explains how improvement will occur, what evidence will indicate progress, which risks may complicate recovery, and when the approach should be reviewed. A credible prognosis does not promise instant transformation. It establishes a direction, a learning cadence, and measurable signs of improvement.

This is where integrity enters the profession. The World Medical Association’s modern Physician’s Pledge, contained in the Declaration of Geneva, centers service, dignity, conscience, competence, and the well-being of the patient. Project professionals do not take that medical pledge, and organizational dysfunction is not a literal disease. Yet the ethical principle behind the analogy is worth carrying: the method must serve the people and the outcome. The people must never be sacrificed to the method.

Do not install Scrum; reveal the need for it

Scrum is described in its official guide as a lightweight framework for generating value through adaptive solutions to complex problems. It is intentionally incomplete. It creates a small amount of structure so that teams can make work visible, inspect reality, and adapt.

That is very different from installing a complete operating system of meetings, templates, approval gates, status reports, and new titles.

In a non-Scrum environment, begin with the pain that people already feel. If stakeholders complain that nothing useful appears until the end of a six-month effort, demonstrate the value of a shorter feedback loop. If the team is overwhelmed by competing demands, make the work and its priorities visible. If leaders cannot see whether delivery is improving, establish a small set of honest measures. If quality problems appear late, create an agreed definition of done and bring testing closer to the work.

People rarely oppose shorter waits, clearer priorities, fewer surprises, or a genuine opportunity to improve their own work. They oppose rituals that have not been connected to those outcomes.

Lead with the problem. Let Scrum earn its place as part of the solution.

Meet opposition with curiosity, not conquest

When someone says, “This will never work here,” the easiest response is to label that person resistant. The more useful response is: “What have you seen that makes you believe that?”

The answer may reveal more than a maturity assessment ever could.

Perhaps the team tried two-week Sprints, but executives inserted urgent work every day. Perhaps a Product Owner was named but given no authority to make priority decisions. Perhaps the Daily Scrum became a roll-call for management. Perhaps velocity was converted into an individual productivity target. Perhaps retrospectives produced action items that leadership ignored. In each case, people did not reject agility. They experienced its language without its protections.

Compassion does not mean avoiding accountability. It means understanding the human cause of behavior before deciding how to respond. A compassionate change leader can say both: “I understand why you distrust this,” and “We still need to confront the condition that is hurting delivery.”

Opposition should be explored, categorized, and answered proportionately:

• Confusion needs clarity.
• Skill gaps need coaching and practice.
• Past disappointment needs evidence and consistency.
• Incentive conflicts need leadership intervention.
• Legitimate operational constraints need adaptation.
• Persistent obstruction that protects dysfunction needs courageous escalation.

Not every objection is correct. Every objection is data.

Find a champion—but do not manufacture a mascot

A transformation needs sponsorship, but a title alone does not create a champion. The right champion has enough credibility to influence decisions, enough proximity to understand the work, and enough courage to protect the experiment when pressure returns the organization to old habits.

Look for the person who is already disturbed by the problem. They may be a senior leader frustrated by unpredictable delivery, a product leader seeking faster feedback, an engineering leader tired of recurring defects, or a respected team member who quietly connects people across silos.

Then make the partnership concrete. A champion should be willing to explain why the change matters, remove impediments beyond the team’s authority, protect stable priorities, attend reviews to see evidence rather than demand additional status theatre, support transparency when the first data is uncomfortable, and defend experimentation without creating blame.

Do not turn the champion into the smiling face of a transformation campaign. Give the champion decisions to make, barriers to remove, and behaviors to model.

Part I has taken us from diagnosis to the human architecture of change. Part II turns to analytics, servant leadership, proportional structure, and the courage to admit when Scrum is not the correct prescription.

A question to carry with you: When people resist a transformation, are they rejecting improvement—or protecting themselves from another solution that was never designed around their reality?

Continue to Part II