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.
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.
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 complete.
Before beginning a new sprint or other iteration, Agile teams often meet for a planning session. 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.
Standups 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 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 study 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 deployment.
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.
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:
Before each new sprint, the Product Owner recommends tasks from the team's product backlog 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 review with external stakeholders to update them on their progress. Finally, the team meets on its own for a sprint retrospective to discuss what went well and what they can improve on for next time, before the whole process begins again.
Though not as common today, Extreme Programming (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, 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 principles:
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 Kanban board, a tool that teams use to track their work as it moves through the software pipeline from planning to completion.
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, Scrumban.
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 cross-functional—team members need to have the skills 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.