You have joined an agile team as a Scrum Master, coach, or team lead. Start by learning the team’s context, then earn enough trust to run one small experiment.

What You’ll Learn

  • What is agile, and what problem does it solve?
  • Where does agile fit, and where does it fit poorly?
  • Which few practices give you most of the value?
  • Why do capable Scrum Masters and coaches fail, and how can you avoid it?
  • What should you do in your first weeks in an agile role?
  • Where can you go to learn more about agile?

The Basics

Agile uses values and principles to build software in small, frequent working pieces, adapting processes as work progresses.

In February 2001, 17 practitioners wrote the Manifesto for Agile Software Development at Utah’s Snowbird ski resort, according to the manifesto’s own history page. Drawing on Extreme Programming, Scrum, the Dynamic Systems Development Method, Crystal, and other “lightweight” methods, they sought an alternative to documentation-heavy processes. Today, Scrum, Kanban, and Extreme Programming (XP) express those values through distinct frameworks.

This guide covers the 20% that delivers most results: four values, short cycles, visible, limited work, retrospectives, and spotting fake agile. It also addresses the human side through Cliff Hazell’s 10 uncomfortable truths every Agilist needs to hear. Further resources cover Product Owners, coaching, XP, and flow-metric forecasting.

Primary Use Cases

  • Building products where requirements change as you learn from users.
  • Teams that ship usable software every few weeks or sooner.
  • Work where customer feedback is cheaper than upfront planning.
  • Teams seeking steady workflow improvements.

Less Suitable Use Cases

  • Work with fixed requirements and no flexibility.
  • Organizations want the vocabulary but choose their teams’ process, often through a top-down “go agile” mandate.
  • Projects lacking feedback from software users.

When to Use Agile

Use agile when shipping teaches you more than planning. It suits new problems with accessible users and safe, incremental releases. If contracts fix scope and changes are costly, choose plan-driven methods or a blend. Antonio Nieto-Rodriguez argues for blending in It’s Time to End the Battle Between Waterfall and Agile in Harvard Business Review.

The 20% That Does 80%

Each practice ends with an observation prompt. If you’re new to the team, record what you see first. Apply the findings in Put It to Work.

Anchor on the Four Values

Every agile framework traces back to four value statements from the manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The Manifesto for Agile Software Development says, “While there is value in the items on the right, we value the items on the left more.” Agile retains documentation and plans but prioritizes working software and adapting to change.

The twelve principles turn those values into behavior. Three resolve most arguments:

  • “Working software is the primary measure of progress.”
  • “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
  • “Simplicity, the art of maximizing the amount of work not done, is essential.”

Review the four values. Identify which your team’s habits honor least, then raise it when they ask for help (Step 5). Use it to assess the practices, tools, and meetings your team adopts.

Deliver a Working Increment Every Cycle

Scrum gives agile a fixed rhythm. The 2020 Scrum Guide defines a team with a Product Owner, Scrum Master, and Developers, “typically 10 or fewer people.” Work happens in Sprints, fixed-length events “of one month or less,” each producing a usable Increment.

flowchart TB A[Product Backlog] --> B[Sprint Planning] B --> C[Sprint Backlog] C --> D[Daily Scrum, 15 minutes each working day] D --> E[Increment that meets the Definition of Done] E --> F[Sprint Review with stakeholders] F -->|adjusts| A F --> G[Sprint Retrospective] G -->|improvements feed the next Sprint| B

The Definition of Done shows whether a Sprint produced anything. The 2020 Scrum Guide says work that doesn’t meet it “cannot be released or even presented at the Sprint Review.” Document yours so everyone agrees on what “done” means.

## Definition of Done

- Code is reviewed and merged to main.
- Automated tests cover the change and pass in CI.
- The change is deployed to the staging environment.
- The Product Owner has seen it working.
- User-facing docs or release notes are updated.

Ron Jeffries, a manifesto author, sets a simple target in Developers Should Abandon Agile: “Produce running, tested, working, integrated software every two weeks, every week.” If your team can’t meet it, take on less work per cycle.

After your team asks for help (Step 5), compare its Definition of Done with the example, identify a missing item, and raise it at a retrospective. The team then delivers working software each Sprint for review.

Make the Work Visible and Limit Work in Progress

Kanban enables continuous work without fixed cycles. The Kanban Guide (May 2025) outlines three practices: visualize workflow, manage work items, and improve workflow. It requires four flow metrics: WIP, throughput, work item age, and cycle time.

The most useful move is a WIP limit: when a column is full, stop starting work and help finish what’s already there.

flowchart TB subgraph Ready["Ready (no limit)"] F[Story F] G[Story G] end subgraph InProgress["In Progress (limit 3, full)"] C[Story C] D[Story D] E[Story E] end subgraph Review["Review (limit 2)"] B[Story B] end subgraph Done["Done"] A[Story A] end Ready --> InProgress --> Review --> Done

In Progress is full. Before pulling Story F, help move C, D, or E to Review.

Count items in your busiest column. At the retrospective (Step 6), propose a two-week experiment with a WIP limit one lower. This reduces unfinished work, steadies flow, and reveals bottlenecks.

Inspect and Adapt in Retrospectives

The Scrum Guide says the Sprint Retrospective “is to plan ways to increase quality and effectiveness.” Martin Fowler makes the same point in The State of Agile Software in 2018. The format matters less than “the notion of thinking about what we’re doing and how we can do better,” a reflection the team doing the work should lead.

End each retrospective with an experiment, owner, and check-in date. Steps 6–7 explain the experiment, creating a process the team regularly improves.

Spot Faux Agile

In 2018, Martin Fowler called it “faux-agile: agile that’s just the name, but none of the practices and values in place.” Ron Jeffries calls it “Dark Scrum.” Watch for these signs:

  • A process imposed by consultants or managers rather than chosen and evolved by the team.
  • Developers never spoke with users. Fowler describes six developers and four users communicating only through a Product Owner.
  • No focus on automated testing, refactoring, or continuous integration to make frequent changes safe.
  • Ceremonies that run on time while nothing ships.

Compare your team with these four signs, then bring the closest match to your next retrospective for discussion. You get vocabulary for naming the problem when “agile” makes a team’s work worse.

The Human Side: 10 Uncomfortable Truths for Agilists

Knowing Scrum and Kanban may get you hired, but earning a team’s trust takes more. On October 17, 2023, Cliff Hazell shared 10 uncomfortable truths every Agilist needs to hear on LinkedIn, exposing the gap between knowing practices and helping a team.

Written for agilists, he added, “I think this applies regardless of your role.” The five groups of truths align with steps in Put It to Work, helping you apply them in your first weeks.

Model the Focus You Preach

Truth 1: “You can’t preach focus while having a calendar that blocks every pixel of daylight.” He adds, “You’re the role model. Act like it.” Juggling six initiatives while coaching WIP limits teaches the team more through your calendar than your slides.

Truth 2: What you work on matters more than how hard you work. Hard work alone can cause burnout. Focus on high-leverage options one at a time: the manifesto’s sustainable-pace principle applied to you.

Earn Trust Before You Suggest

Four of the truths make the same point from different angles:

  • Truth 3: Your CEO hired you to do your job, not fix the company. Deliver results, and leaders may consider your broader ideas.
  • Truth 4: Two weeks isn’t enough to understand the problems. Help, but avoid overconfidence; talk to the team and learn their context.
  • Truth 5: Seeing an issue doesn’t mean others want help. Offer, wait for consent, and, as Hazell says, “Stop inflicting help.”
  • Truth 7: Making suggestions before building trust is “a recipe for disaster.” Without trust, people doubt your motives; support their goals first.

Comments sharpened the point: Nigel Thurlow said most agilists are hired to “support a team,” not “change a team” or transform a company. Heather Stephens summed it up: “if you don’t have credibility, there’s no point in working on anything else because you can’t get anything done without it anyway.”

Prefer Practice Over Dogma

Truth 6: “A practical approach beats dogma. Every. Single. Day.” Hazell adds, “Enter a religious war, and you’ve already lost. Focus on the doing, not the theory.”

The Scrum Guide permits partial implementation but states, “the result is not Scrum.” Instead of debating frameworks, let shipping teams shape and evolve their process. Dropping disliked events while retaining the Scrum label is the faux agile described earlier. Fowler calls team-owned process “a fundamental agile principle.”

Truth 8: Courses and books can fuel confirmation bias, making every new idea seem true. Test ideas against your team’s context before selling them; “people will get tired of your shiny toy syndrome.” The “Shatter Bias” habit in Learn How To Prioritize urges you to prove yourself wrong first.

Take the Agreement You Can Get

Truth 9: Sometimes, overlook the best idea. Perfection stalls progress; seek agreement and move on. As Hazell says, “Don’t get distracted looking for silver bullets.”

Commenter Andrei Branescu objected: “If it has to be ignored, then it’s not the best idea.” An unsupported big idea loses to a smaller one the team will adopt now. Revisit it after small wins build trust through truth 7.

Make Peace With Imperfection

Truth 10: Product development is never perfect. Accept it, or stay demotivated.

Agile embraces change and incompleteness; expecting perfection disappoints every Sprint.

Use these core practices to spot improvements. The next section offers a safe way to apply them in your first weeks on a team.

Put It to Work: Your First Weeks in an Agile Role

Use these steps when joining a team as a Scrum Master, agile coach, or team lead. They assume the team tracks work and holds regular retrospectives; otherwise, see Troubleshooting. Each step identifies the truth it applies to.

Prerequisites

Required.

  • Access to the team’s board and backlog.
  • Your own calendar.
  • A one-on-one slot with each team member.
  • Familiarity with Scrum or Kanban, or the sections above.
  • A few weeks of patience before you propose changes.

Step 1: Do the Job You Were Hired For

Confirm two or three expected outcomes in your first week; save company-wide ideas for later.

What you get. A clear scope and early results to point to (truth 3).

Step 2: Listen Before You Diagnose

Meet each team member individually, ask open questions, and take notes without making proposals.

1. What's working well on this team that you'd want to protect?
2. What slows you down most often?
3. What have people tried before to fix it, and what happened?
4. What do you wish someone in my role would do, or stop doing?

What you get. The team’s context, and the start of trust (truths 4 and 7).

Step 3: Audit Your Own Calendar

Count next week’s meeting hours and schedule daily focus time. Use freed hours for Step 1 outcomes (truth 2).

Before declining a recurring meeting, ask the organizer what they need; early on, they may see it as a verdict on their work (truth 7).

What you get. A calendar that matches the focus you’ll ask of the team (truths 1 and 2).

Step 4: Read the Board

Count each person’s in-progress items and find the oldest unfinished one. Share what you observe and let the team interpret it. If the team is shipping, don’t debate frameworks (truth 6). Before sharing a pattern, ask if it fits this team or only reflects your latest book or course (truth 8).

You’re done when you can name the oldest unfinished item and its time in progress.

What you get. A fact-based picture of flow to bring to the next retrospective.

Step 5: Offer Help, Then Wait for a Yes

When you spot a problem, ask before you act.

I noticed three stories have been in Review for over a week.
Would it help if I looked into what's blocking them, or would you rather handle it?

What you get. Help the team wants, and a reputation for respecting their call (truth 5).

Step 6: Run One Experiment Where There’s Agreement

At the first post-Step 2 retrospective, help the team choose a widely supported small experiment, even if it isn’t yours. Assign an owner and check-in date. Note your preferred change and revisit it once trust is established.

What you get. Momentum, and proof that you’ll back the team’s choices (truths 7 and 9).

Step 7: Inspect the Experiment and Repeat

At the next retrospective, assess the experiment; keep, change, or drop it, then choose another. Expect imperfection and aim to improve the next cycle (truth 10).

What you get. A team improving on its own schedule, with your support.

Check Your Progress

The first pass is done when all five are true:

  • Your hiring manager has confirmed your outcomes.
  • You’ve met every team member one-on-one.
  • Your calendar has daily focus time.
  • You can name the oldest unfinished item on the board.
  • The team ran and inspected an experiment it chose.

Practice these seven steps on a simulated team before you try them on a real one. The team is simulated, and each consequence comes from the sources this article cites.

Practice your first weeks on an agile team, in a short story with a live board. Nothing downloads until Start (about 90 KB).

Chapter 1: Hiring manager
Chapter 2: One-on-ones
Chapter 3: Calendar
Chapter 4: Read the board
Chapter 5: Offer help
Chapter 6: Experiment
Chapter 7: Inspect

The story needs JavaScript. The seven steps it practices are in Put It to Work above.

Troubleshooting

“My hiring manager can’t name the outcomes” 

Suggest 2–3 outcomes based on the backlog and Step 2 team input; ask your manager to choose or revise them.

“Leadership wants a company-wide transformation now”

Choose the two or three Step 1 outcomes that move you toward the goal and deliver them first. Keep the broader plan in your notes until you have results.

“Team members decline a one-on-one”

Ask the four questions in writing or after a retrospective, and keep listening in meetings you already attend.

“The team has no board”

Ask where work is currently tracked, such as in a ticket system, spreadsheet, or chat channel, and read from that source. Build a board only if the team asks for one.

“The team said no to my offer of help”

Accept it and note the issue. Reoffer only if it grows or the team raises it.

“There’s no retrospective to run the experiment in”

Ask the team lead, or the team if you are the lead, for 30 minutes at the end of the next cycle to try one as a single trial.

“The experiment failed”

Drop it at the check-in if the agreed measure did not improve or the team no longer supports it, then pick the next experiment. Dropping an experiment means the loop is working.

“The team is shipping and doesn’t want changes”

Repeat Steps 2–4, skip Step 6, and wait for the team to identify a problem to solve.

Conclusion

Agile values working software and change: ship usable increments, make and limit visible work, and improve through retrospectives. Hazell explains why teams struggle: they neglect trust, preach focus they don’t practice, and debate theory while teams ship. Start here, then explore the resources below.

Learn Agile - Beyond the Basics

Watch a short overview, read the Scrum and Kanban guides, then choose a role-specific book.

Video

  • Agile Product Ownership in a Nutshell by Henrik Kniberg (YouTube): an overview of the Product Owner role, backlog, and stakeholders.
  • Agile is Dead by Dave Thomas, GOTO 2015 (YouTube): A manifesto author on how “agile" lost its meaning and how to reclaim agility.

Audio

Books

Online

Related Content

References