Share
Explore

Agile project management guide [+ templates]

A doc to help you decide if agile is right for your team.
At Coda, we believe in designing meetings like you would a product, with intention around both the user and the outcome. And the same is true with project management. The key is contemplating the end goal and then working backward to map the steps to achieve that goal.

While there are many project management methodologies to guide project managers through this design process, agile’s focus on iteration provides the flexibility to adapt to the goals and stakeholders. In this doc, I’ll talk about agile project management generally before providing a few examples of Coda docs and templates to get you started quickly. (I hope you love a list. 😉)

What is agile project management?

Agile project management is a software management framework that prioritises iteration, continuous improvement, and feedback loops with each sprint. Agile works in short sprints and releases that incorporates feedback with each launch.

Similar to Coda’s principle of designing meetings, agile project management prioritizes the needs of the end-user by incorporating the voice of the customer whenever possible.

An overview of the agile methodology

Humor me a moment while I set a scene. It’s February 2001, the Snowbird ski resort in Utah’s Wasatch mountains. And instead of relaxing, 17 leaders of software development (self-dubbed The Agile Alliance) are hashing out what we now know as the
—a document that continues to influence the way we manage projects and eventually spawned countless other methodologies.

The Agile Manifesto

Like the Declaration of Independence or even the Declaration of Rebellion, the Agile Manifesto is meant as a formal statement of dissent. The authors were dissatisfied with traditional software development strategies, particularly inefficiencies caused by documentation and red-tape. After all, at the turn of the century technology, software development, and the internet were all evolving at breakneck speed. And the processes to support each weren’t keeping up.

So, like most manifestos, the Agile Manifesto was meant to empower software developers—and eventually project managers—to avoid the navel-gazing of past methodologies in favor of a more customer-first approach centered around quick response to feedback.

4 values of agile

Much of the Agile Manifesto details
and
(which I’ll discuss in a bit). The values are simple and were originally written with software development in mind, but they also serve as the foundation for the agile project management methodology.

Individuals and interactions over processes and tools.
The first value is one that I’ve mentioned already, and it bears repeating. The Agile Alliance saw the need (and benefit) in prioritizing customers and feedback over standard processes. Coda embraces a similar value when comparing
: right over familiar.
Working software over comprehensive documentation.
Another value that empowers people to look forward instead of inward. Instead of spending months spinning up documentation and delaying launches, agile methods streamline the documentation process into something more intuitive: user stories with context.
Customer collaboration over contract negotiation.
Customers are of course heavily involved in other project management methodologies, like Waterfall. However, many offer collaborative moments before and/or after the project. Because agile processes value individuals over process, the method ensures customer collaboration throughout—and feedback received is integrated immediately instead of holding off until the next project.
Responding to change over following a plan.
Goals change. Customers change. Products change. But we’re often resistant to changing the
plan
to achieve those goals, meet the needs of the customers, and build the products. As I mentioned above, agile provides the flexibility to adapt whenever necessary. And because tasks and timeframes are in small increments, adaptation can happen quickly.

12 principles of agile project management

Where values are subjective, principles are objective—they highlight a truth that transcends industry, culture, and preference. And while the
, as read in the quotes below, certainly reflect their values, they also work to
necessary to do the software development agile was originally intended for.

Take a customer-first approach
.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Unsurprisingly, the first principle mirrors the first agile value and is essentially a working definition of agile generally. Without the burden of writing documentation and bureaucratic red-tape, projects can be executed quickly. And the quicker the project development, the quicker customer needs are met—which hopefully positively impacts ROI as well. In other words, faster project management means happier developers and customers that are happy to pay for your product (and tell their friends to do the same).

Adapt, whenever.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

If it’s better for the customer then it’s better for the project, even if that means making adjustments at the 11th hour. And although there is a constant risk of scope creep, the short iterative approach of agile should make even late-stage changes possible.

Keep iterative cycles short.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Whether it’s customer feedback or an online purchase, everyone likes a quick turnaround. This principle speaks directly to the definition of
agile
: to be nimble. Projects that focus on small amounts of work without being blocked by documentation and overly complicated planning processes are completed faster, which
and also allows the team members to move on to the next project.

Cross-functional collaboration is key.
Business people and developers must work together daily throughout the project.

I’ll talk more about the roles in an agile team below, but agile project management (or agile software development, for that matter) goes beyond a single department. When successfully applied, agile requires individuals from across the company as well as external stakeholders, like customers, to provide input, share product knowledge, guide the development process, and execute the plan.

Empower your team.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Trust the team you built. Although agile does use specific roles, the hierarchy is relatively flat and decisions are collectively owned. Empowering every person on your team keeps them engaged throughout the project. People who
want
to work on any given project, who
believe
in their company’s missions and goals, will produce higher quality work—all that happiness and quality positively impacts customers. Happy teams make happy customers.

Synchronous communication is more effective than async.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Although face-to-face can mean something slightly different now than it did in 2001, the principle remains. Communicating synchronously, whether in a conference room or Zoom, can often be more effective in moving projects forward. Questions can be answered, action items can be clarified, and blockers can be addressed—all in real-time.

Customers can’t use broken or incomplete code.
Working software is the primary measure of progress.

At face value, this principle is a reminder that QA matters. But it also implicitly reinforces the first principle, to be customer-first. Buggy code isn’t useful to anyone. If happy developers make happy developers, the inverse is surely also true: frustrated developers make for frustrated customers.
Optimize workflows.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

No matter which type of agile methodology you choose, agile project management batches tasks into small segments that allow for quick work. And the reduced need for documentation and approvals makes for more streamlined workflows so that the team can get back to working on what matters.

Do a good job.
Continuous attention to technical excellence and good design enhances agility.

Agile’s ninth principle reminds me of the first of
The Four Agreements
: be impeccable with your word. In this context, the Agile Alliance is asking us to pay attention to detail, to do things right the first time. Avoiding mistakes and re-doing work optimizes our workflows (see above) and promotes working software (see above, again).

Do the least.
Simplicity—the art of maximizing the amount of work not done—is essential.

Your customers, and even some of your stakeholders, don’t care to know how long it takes to complete a project. They don’t even care about the steps or other details—they just want to know that it’s done, that it meets their needs. Save your time and effort by doing
only
what you need to do to achieve your goal or finish your tasks. And then use that saved time and effort on the next.

Let teams emerge organically.
The best architectures, requirements, and designs emerge from self-organizing teams.

If you’re truly empowering your team (and following principle #5), you’ll trust them enough to self-select. Teams that form organically are more likely to be genuinely interested in what they’re working on. Maybe they’ll even enjoy work more. You might have heard about the reflection of team morale on that of customers?

Commit to continuous improvement.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile’s final principle is a call to ritualize reflection. Most commonly done in retrospectives, agile encourages teams to analyze exactly what went right, what went wrong, and how to improve during the next iteration cycle.

Roles in agile

Developing and launching products takes a village (although in the scrappiest of scenarios it’s a village of one). And everyone in the village has a complementary role, generally
:

The
product owner
acts as a liaison between internal and external stakeholders. Because this person communicates to both the product team and the customers, they should be knowledgeable about the needs and concerns of both.
The
development team
takes the product from ideation to execution to promotion. They’re the engineers, designers, content creators, data scientists, and marketers who get their hands dirty and ensure customer needs are met along the way. As a cross-functional team, this group of folks should embody the flexibility of the iteration process.
The
stakeholders
could include customers, other teams in the company, board members—anyone with an interest in the project and/or its outcome. And because agile values a constant input of feedback, support from stakeholders should be frequently sought out.
The
agile mentor
, like the stakeholders, isn’t someone who is necessarily directly involved. However, they should be familiar with the agile project management process and readily available to provide guidance to the team.

7 types of agile project management

Several frameworks have been developed under the agile umbrella. And although they possess unique qualities, they all embrace the four agile values mentioned above. Here are seven you should be aware of:

Kanban

is a style that emphasizes transparent and constant communication. The most obvious characteristic of this framework is the use of a kanban board, which generally depicts tasks as cards categorized into three status buckets: pending, in progress, and complete. Because the tasks are updated in real-time, stakeholders have consistent access to the project’s progress.

Scrum

is perhaps the most popular agile framework, but also the most prescriptive as it has its own set of values. Through the lens of courage, focus, commitment, respect, and openness, Scrum leverages the Scrum master, product owner, and developer team to focus on a singular product goal. Scrum is also characterized by close attention to time; everything is time-boxed. The process looks something like this:
The product owner selects a problem from the product backlog.
During sprint planning, the Scrum team turns the work required to solve that problem into increments of a sprint.
Daily Scrums, or stand-up meetings, are held to check in on progress and workflows.
At the end of the sprint, a sprint review is held, followed by a sprint retrospective to reflect on what went right (or didn’t).

Extreme programming

relies on a solid feedback loop through communication and collaboration. The voice of the customer is sought after and integrated throughout the project development. XP is also characterized by short cycles of iteration that encourage productivity and transparency.

Crystal

is a less regimented framework focused on the trust of the agile team’s knowledge of the problem. Crystal is characterized by a near-complete lack of documentation, which allows teams to move very quickly. And while transparency and communication are key, there’s also a risk of scope creep and future misunderstandings.

Dynamic systems development method

(DSDM)
differs from the other frameworks in that is attempts to add back some of the structure agile was created to avoid. Like Scrum, DSDM time-boxes the project development process, but decisions are prioritized using the MoSCoW technique, which stands for must have, should have, could have, won’t have. And because this framework acknowledges the result of flexibility as potential modifications during project development, prototyping, testing, workshopping, and modeling techniques are employed to ensure stakeholders have consistent input during the process and concerns are addressed early.

Feature-driven development

(FDD)
is, as the name implies, focused on the product. But
feature
isn’t always a product feature—it could be an improvement, a metric-mover, or a customer delight. FDD follows a five-step process that looks like this:
Develop an overall model.
Build the features list.
Plan by feature.
Design by feature.
Build by feature.

Because the process is so simple, the team can move quickly. However, the quick project development time also encourages top-down decision making unlike the shared ownership strategy of other agile frameworks.

Lean Software Development Methodology

is determined to eliminate waste. Waste, in this context, is anything that doesn’t add specific value for the customer. And this includes internal inefficiencies, like handing off tasks, documentation not used by the customer, and incomplete code. This framework is characterized by making decisions as late as possible while still developing and delivering as quickly as possible.

Agile project management vs. traditional (waterfall) project management: How to find the right fit?

Traditional project management, or waterfall, is a linear process that values documentation and prioritization. This approach follows a
that includes initiation, planning, execution, monitoring, and closure phases.

What’s the difference between agile and waterfall?

Loading…

Waterfall is in some ways the opposite of agile. While agile tackles tasks in small increments, waterfall
. Where agile embraces adaptation and flexibility, traditional project management emphasizes the need for formal processes and documentation.

Perhaps the most important difference between these project management mindsets is customer involvement. As you know by now, agile values individuals over process and taking a customer-first approach to every phase of a project. Waterfall project management may consider the voice of the customer before and after the project, but rarely during.

Which project management methodology is right for you?

Choosing between traditional and agile project management is dependent on many things, from your team’s skills to the company culture. Although some reports show that agile is up to
, you need to carefully consider your goals and needs.

Here is a table of considerations that might help you decide:
Consideration
Agile
Waterfall
1
Customer involvement
High
Low
2
Development process
Continuous iteration
Linear, life-cycle based
3
Project timeline
Flexible
Fixed
4
Budget
Flexible
Fixed
5
Approvals
At the end of each iteration
Continuous leader-specific approvals
6
Documentation requirements
Low
High
There are no rows in this table

Coda templates for agile project management

Coda is a new doc that brings words, data, and teams together. It starts with a blinking cursor on a blank page and can grow as big as your team's ambition. Coda comes with a set of building blocksーlike pages for infinite depth, tables that talk to each other, and buttons that take action inside or outside your docーso anyone can make a doc as powerful as an app. And that flexibility makes Coda a great tool for agile project management.

Here are a few templates that you can copy for inspiration:

A team hub that combines kanban boards and tracking tables to give every member of your team an idea of what needs to get done.

A simplified doc that guides you through the Scrum process, so that you don’t have to start from scratch for every new project.

Insights on creating agile workstreams to balance focus, autonomy, and creativity.

Kanban in three simple steps.

Agile project management FAQ

How to choose the right project management methodology for my team?

What is the difference between PMP and Agile?

What are the benefits of agile project management?

What are the drawbacks of agile project management?

What's the difference between agile and Scrum?

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.