Quick Start. This guide covers essential agile practices and people skills for earning buy-in. Read it in 20 minutes, then use the end-of-guide steps during your first weeks on an agile team.

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.

Seventeen practitioners wrote the Manifesto for Agile Software Development in February 2001 at Utah’s Snowbird ski resort, according to the manifesto’s own history page. From 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) apply those values through distinct frameworks.

This guide focuses on the 20% that delivers most results: four values, short delivery cycles, visible work with limits, retrospectives, and spotting fake agile. It also covers the human side, drawing on Cliff Hazell’s 10 uncomfortable truths every Agilist needs to hear. Further resources explore the Product Owner role, coaching, XP practices, 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 you learn more by shipping than by planning. If the problem is new, users are available to talk with you, and you can safely release small changes, agile is a good fit. If the scope is fixed by contract and changes are very costly, a plan-driven approach may serve you better, or a blend of both. Antonio Nieto-Rodriguez makes the case 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 a Do this step. If you’re new to the team, observe and note each one for now. Put It to Work explains when to raise your findings.

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 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.”

Do this. Review the four values. Note which your team’s habits honor least, and raise it after they ask for your help (Step 5).

What you get. A shared yardstick for judging any practice, tool, or meeting your team adopts.

Deliver a Working Increment Every Cycle

Scrum gives agile a fixed rhythm. The 2020 Scrum Guide defines a team with one Product Owner, one Scrum Master, and Developers—“typically 10 or fewer people.” Work occurs 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 determines whether a Sprint produced anything. The Scrum Guide states that work that does not 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 each cycle.

Do this. Compare your team’s Definition of Done with the example, note one missing item, and raise it at a retrospective after the team asks for your help (Step 5).

What you get. A team that delivers working software each Sprint for review.

Make the Work Visible and Limit Work in Progress

Kanban supports continuous work without fixed-length cycles. The Kanban Guide (May 2025) outlines three practices: define and visualize workflow, manage work items, and improve workflow. It requires four flow metrics: work in progress (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.

Do this. Count items in your team’s busiest column. Propose a WIP limit one lower as a two-week experiment at the retrospective (Step 6).

What you get. Fewer unfinished tasks, steadier flow, and a board showing 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.” The team doing the work should do that thinking.

Do this. End each retrospective with an experiment, owner, and check-in date. Steps 6–7 explain the first.

What you get. A process the team improves on a regular schedule.

Spot Faux Agile

In 2018, Fowler called it “faux-agile: agile that’s just the name, but none of the practices and values in place.” 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.

Do this. Compare your team with these four signs, then bring the closest match to your next retrospective for discussion.

What you get. The 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 it’s only part of earning a team’s trust. On October 17, 2023, Cliff Hazell shared 10 uncomfortable truths every Agilist needs to hear on LinkedIn, highlighting 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 map to steps in Put It to Work, helping you act on them during 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.” If you coach WIP limits while juggling six initiatives, the team learns from your calendar, not your slides.

Truth 2: What you work on matters more than how hard you work. Hard work alone can lead to burnout. Identify the high-leverage options and work on them one at a time. This is 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 listen to your broader ideas.
  • Truth 4: Two weeks isn’t enough to understand the problems. You can still help, but avoid overconfidence; talk to the team and learn their context first.
  • 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 the 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 allows partial implementation but says, “the result is not Scrum.” Rather than debate frameworks with a shipping team, let them shape and evolve their process. Dropping disliked events while keeping the Scrum label is the faux agile described earlier. Fowler calls team-owned process “a fundamental agile principle.”

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

Take the Agreement You Can Get

Truth 9: Sometimes, ignore the best idea. Perfection stalls progress, so pursue agreement and keep moving. 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 this week. Revisit it after small wins earn trust through truth 7.

Make Peace With Imperfect

Truth 10: No matter how hard you work, things will never be perfect. That’s the nature of product development. Accept it, or you’ll remain demotivated.

Agile embraces change and incompleteness; expecting a perfect process disappoints each Sprint.

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.

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

List two or three expected outcomes and confirm them 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 one-on-one, ask open questions, and take notes without proposing anything yet.

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 block daily focus time. Use the freed hours for Step 1 outcomes (truth 2).

Before declining a recurring meeting, ask its organizer what they need from you; early on, declining may seem like 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 identify the oldest unfinished one. Share your observation; let the team interpret it. If the team is shipping, avoid debating frameworks around it (truth 6). Before sharing a pattern, ask whether it fits this team or just the last book or course you finished (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 retrospective after Step 2, help the team choose a small experiment most people support, even if it isn’t your choice. Assign an owner and check-in date. Record your preferred change and revisit it once the team trusts you.

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 four 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.

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 and pick the next one. 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 means valuing working software and change, shipping usable increments each cycle, making work visible and limiting it, and improving through regular retrospectives. The practices are simple; Hazell explains why teams still struggle: they neglect trust, preach unfollowed focus, and debate theory while teams try to ship. Start with these steps, 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