Agile Guide

Agile in Action

Agile teams are united in their shared goal—developing better
software—and the values they use to get there. They all prioritize
effective collaboration and communication, put a premium on working software,
and focus on becoming flexible as a way to respond to inevitable change. But
where they differ is in implementation. Different Agile teams may use very
distinct practices and frameworks to
achieve the goal of creating better software. This is a good
thing—being Agile is about results, not the process you use to get
there. What works for one team may not work for another. There are no
cookie-cutter solutions or “best” processes. Every team has to
determine what works best for them.

Agile Practices vs. Frameworks

An Agile practice is a tactic people can use to support
an Agile mindset, such as daily
standup meetings
, while an Agile framework is a
defined software development approach, which provides guidelines on how
teams should prioritize tasks, plan their work, and execute projects.

That said, there are a number of popular frameworks and practices that
Agile practitioners may find helpful. We'll provide an overview of these
below, beginning with practices, since many of the same practices are
shared across different frameworks.

Agile Practices

Here are some of the most common Agile practices, used across a variety of
different Agile frameworks. While these practices alone won't make your team
Agile, they can be useful tools to support your Agile journey.


A sprint, sometimes called an “iteration,” is a timebox for
development, usually one to four weeks in length. Before the sprint, teams
select a limited number of tasks from their backlog to focus on, with the
goal of completing them all by the end of the sprint. (Non-development teams
can also use sprints to prioritize and execute their tasks). The short,
iterative nature of the sprint makes it easy for teams to adjust their
direction and prioritize new work as needed, allowing them to be flexible.
Working in this fixed, consistent, rhythm can also make it easier for teams
to make accurate estimations about how long new projects will take to

Planning session

Before beginning a new sprint or other iteration, Agile teams often meet
for a planning
. This planning session typically has two parts: Scoping and
planning. During the scoping part of the meeting, the team forecasts
the number of tasks they think they can reasonably manage and chooses a
limited number of priority tasks from their backlog to complete over the
duration of the sprint. Then, they switch to planning—they
determine how they're going to complete the tasks they selected and assign
responsibilities to different team members.


are short, daily check-in meetings—typically no more than 15 minutes in
length—where every team member reports their progress. As the name
implies, standup meetings are often conducted standing up to promote
alertness and quick meeting resolution. Standups are an opportunity to catch
up, resolve issues or blocked tasks, and identify ways that team members can
help and support one another.

Test-driven development

Test-driven development flips the traditional software development life
cycle on its head. Typically you would write code, then create tests to
verify that the code is functional, reliable, usable, and secure—but in
test-driven development, you start by designing tests and then writing the
code to pass them. A Cal Poly
found that software developers who use test-driven development “write
software modules that are smaller, less complex, and more highly tested than
modules produced by their test-last counterparts.” This is important
because smaller units of more heavily tested code generally have fewer
defects—programmers catch issues and resolve them well before

Pair programming

Pair programming is a style of programming in which two developers share a
monitor—one person, known as the “driver,” writes code
while the other, known as the “navigator,” reviews it. While they
work, they explain their thinking to one another (this is why pair
programming is sometimes also referred to as “programming out
loud”). Every few minutes, the driver and navigator switch roles,
ensuring they spend equal time on writing and review. In the process, the two
developers learn from each other and gain a better understanding of their own
programming habits.

Agile Frameworks

Below, we've described some of the most important Agile frameworks used in
software development. While not exhaustive, this list should nonetheless give
you a good overview of common Agile frameworks and help you determine which,
if any, may be right for your team.


Scrum is the most popular Agile framework. Used by over
12 million people
worldwide, it's no wonder that in many peoples' minds Agile is synonymous
with Scrum. “Simple to understand, difficult to master,” the
Scrum framework
is centered around “sprints”—defined work periods of
anywhere between one to four weeks—with an emphasis on frequent, small
deployments. A Scrum team has three main roles:

  • The Product
    : Acts as the voice of the customer and prioritizes tasks
    from the product backlog to be completed each sprint
  • The Scrum
    : Acts as the team's coach and facilitates teamwork by
    ensuring everyone understands the process, removing obstacles, and helping
    to maintain good relational dynamics
  • The Development Team: A cross-functional,
    self-organizing group who both plans and executes their tasks over the
    course of one sprint
The Scrum Process Diagram

Before each new sprint, the Product Owner recommends tasks from the team's
to focus on and the team plans their sprint. For the duration of
the sprint, the team has daily “scrums”—brief meetings to
discuss progress and resolve any issues or blocked tasks. At the end of the
sprint, they host a sprint
with external stakeholders to update them on their progress.
Finally, the team meets on its own for a sprint
to discuss what went well and what they can improve on for next time, before
the whole process begins again.

Extreme Programming

Though not as common today,
(XP) is one of the oldest and most disciplined Agile
frameworks. Started at Chrysler in the 1990s, the framework emphasizes a high
quality of software alongside a high quality of life for developers. In XP,
one team member, designated “the customer”—typically a
business representative—provides requirements, sets priorities, and
directs the project. The team cultivates a “whole team” mentality
in which members sit together, use collaborative practices like pair
programming, and are encouraged to become generalists, not specialists. The
goal is to create seamless code, as though it was written by a single, highly
competent, individual.

Lean Software Development

Software Development
, established by husband-wife team Tom and Mary
Poppendieck, applies the principles of lean manufacturing—pioneered by
Toyota factories in the 1950s—to software. As product development,
whether physical or digital, became more closely connected with software, it
made sense to treat them as parts of the same process. In the words of the
Poppendiecks, “Today, most software development is not a stand-alone
process, but rather a part of developing products or services. Thus lean
software development might be considered a subset of lean product
development.” Lean teams abide by the following seven core

  1. Eliminate waste
  2. Amplify learning
  3. Decide as late as possible
  4. Deliver as fast as possible
  5. Empower the team
  6. Build quality in
  7. See the whole


An offshoot of Lean Software Development, Kanban also applies lean
manufacturing theories to software development (and any kind of knowledge
work). But it goes a step further, creating a defined process for teams to
follow to plan, track, and optimize their work—which you can read all
about in our Kanban Guide. The most
iconic feature of the process is a
, a tool that teams use to track their work as it moves through the
software pipeline from planning to completion.

Kanban Board

This board acts as a mirror, allowing teams to visualize their work,
identify blocked tasks, and optimize their throughput. In the words of David
J. Anderson, who codified Kanban as a process for knowledge workers,
“Kanban is an approach that drives change by optimizing your existing
processes.” Kanban can also be combined with Scrum to form a hybrid,

Agile Teams

Yet practices and frameworks pale in comparison to the most important
component of Agile—your team. Like the manifesto says,
“Individuals and interactions over processes and tools.” But,
outside of any given framework, what should an Agile team look like?

The most important quality of any Agile team is that it's self-organizing.
The eleventh principle from the Twelve Principles of Agile Software states
that “the best architectures, requirements, and designs emerge from
self-organizing teams.” That means the same group of team members
should scope, plan, and execute their projects. This applies whether the team
is collocated, i.e., in the same physical space, or
distributed, i.e., remote.
In order for a team to effectively self-organize, it needs to be
members need to have the
and expertise
to take a project from initiation to completion. Ideally,
as team members work together, they will become generalists and learn to
perform multiple functions. In the next section, we'll delve into how to
create an Agile team and set it up for success.