Introducing Agile to a Skeptical Team or Manager

If you are excited about agile and your team or manager is not, you are in good company. Skepticism is often reasonable. People may have sat through a rollout that added meetings and jargon without making work better, or they may simply be busy and wary of anything new.

The good news is that you do not need everyone to believe in agile before you start. You need enough agreement to run a small, honest experiment and let the results speak.

This guide offers a step-by-step approach that respects skeptics, uses the original sources instead of slogans, and keeps the risk small.

Step 1: Listen before you pitch

Ask skeptics what worries them, and write the answers down. Concerns you may hear include more meetings, loss of control, vague promises, being measured unfairly, or "we tried this before." Each concern points to something your experiment should address.

Resist the urge to argue on the spot. Thank people for raising issues and say you will design the trial with those concerns in mind. Listening first turns potential opponents into contributors.

Step 2: Start from a real problem, not a framework

"Let's do Scrum" invites debate about Scrum. "Work keeps getting stuck waiting for approval, and we never know where things stand" invites problem-solving.

Pick one specific pain your team already feels. Then propose one practice that targets it. For example, imagine a five-person team that complains about constant interruptions; a visible board and a limit on work in progress speak directly to that complaint. A team frustrated by shifting requests might try short, fixed planning cycles.

Step 3: Correct common myths with the original texts

Many objections are aimed at a caricature of agile. The primary sources are short and often more moderate than people expect.

• "Agile means no documentation or planning." The Agile Manifesto (2001) values "Working software over comprehensive documentation" and "Responding to change over following a plan," but it also says, "while there is value in the items on the right, we value the items on the left more." Planning remains. Scrum begins every sprint with Sprint Planning.
• "Agile is only for software." The Kanban Guide (May 2025) says Kanban "can work with virtually any workflow" and names finance, utilities, healthcare and software among the fields that have benefited.
• "Agile means chaos and constant change." The Scrum Guide (November 2020) says that during a sprint "No changes are made that would endanger the Sprint Goal" and "Quality does not decrease."
• "Agile means working faster and harder." The Manifesto's principles say agile processes "promote sustainable development" and that people "should be able to maintain a constant pace indefinitely."

Quoting the source directly lowers the temperature. You are not asking anyone to trust you; you are showing them what the method actually says.

Step 4: Propose a small, time-boxed experiment

Kanban University's guide to the Kanban Method opens its change principles with "Start with what you do now" and "Agree to pursue improvement through evolutionary change." That is a reassuring message for skeptics: nobody's job title or process is torn up on day one.

Shape your proposal like this:

1. The problem we are trying to solve.
2. The one or two practices we will try, such as a shared board with work-in-progress limits, or three two-week sprints.
3. The time frame, typically a few weeks to a couple of months.
4. What we will look at to judge it, decided in advance.
5. How we will decide whether to keep, change or drop it.

An end date matters. People agree to experiments far more readily than to permanent change, and a clear exit makes the proposal feel safe.

Step 5: Speak to what managers care about

Managers usually want visibility, predictability and fewer surprises. Agile practices can supply all three, if you describe them that way.

• Visibility: a shared board shows what is in progress, what is blocked and what is done, without status meetings.
• Predictability: the Kanban Guide's flow measures, such as throughput and cycle time, let you forecast from your own data instead of guesses.
• Early warning: the GOV.UK Service Manual notes that agile "allows you to spot problems early and resolve them quickly."
• Less reporting overhead: GOV.UK also warns that "Too many reporting requirements become counterproductive as the team has less time to spend on delivery work."

Offer the manager a regular, short look at real work, such as the Sprint Review or a walk of the board, in place of an extra status report.

Step 6: Be honest about costs and limits

Credibility comes from candor. Tell people that the first weeks may feel slower while the team learns. Say plainly which meetings will be added, and which existing meetings they might replace.

Be precise about names, too. The Scrum Guide states: "While implementing only parts of Scrum is possible, the result is not Scrum." If you are borrowing a board and a retrospective, say so rather than calling it Scrum. That honesty prevents later complaints that "Scrum didn't work" when Scrum was never tried.

Step 7: Make skeptics co-designers

Invite your most thoughtful skeptic to help design the trial or run a retrospective. The Kanban Method encourages "acts of leadership at all levels," and the Manifesto's final principle says that "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Skeptics are often your best quality control. They notice ceremony that adds no value, and fixing what they spot makes the experiment better.

If the experiment does not solve the problem, say so and adjust, or stop. Forcing a practice on an unwilling team rarely ends well. A trial that ends honestly builds trust you can draw on for the next idea.

Key takeaways

• Listen to concerns first and design your trial around them.
• Tie every practice to a specific, felt problem.
• Use direct quotes from the Manifesto, Scrum Guide and Kanban Guide to correct myths.
• Propose a small experiment with an end date and agreed measures.
• Be candid about costs, and invite skeptics to help shape the work.

Sources

• Agile Manifesto authors, Manifesto for Agile Software Development (2001)
• Agile Manifesto authors, Principles behind the Agile Manifesto (2001)
• Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2020)
• John Coleman and Daniel Vacanti, The Kanban Guide (May 2025)
• Kanban University, The Official Guide to The Kanban Method
• GOV.UK Service Manual, Core principles of agile
• GOV.UK Service Manual, Measuring and reporting progress