Explore

Ultimate Guide to Agile Project Management [+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.

Agile project management methodology overview

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

Agile Manifesto⁠

—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 project management methodology

Much of the Agile Manifesto details

four key values⁠

and

12 principles⁠

(which I’ll discuss in a bit). The values are simple and were originally written with software development project 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

tables to spreadsheets⁠

: 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 methodology⁠

. 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 agile project management principles

Where values are subjective, principles are objective—they highlight a truth that transcends industry, culture, and preference. And while the

12 agile principles⁠

, as read in the quotes below, certainly reflect their values, they also work to

negotiate the cross-functional collaboration⁠

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

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

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

delivers value to the customers⁠

and also allows the project team members to move on to the next project.

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

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

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

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

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

9. 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).

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

11. 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?

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

Agile project management roles and responsibilities

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

one of these four⁠

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

⁠

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

⁠

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

⁠

Extreme programming (XP)⁠

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

⁠

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

⁠

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

⁠

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

⁠

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. waterfall (traditional) project management: How to find the right fit?

Traditional project management, or waterfall, is a linear process that values documentation and prioritization. This management approach follows a

fixed sequence⁠

that includes initiation, planning, execution, monitoring, and

project closeout⁠

phases.

What’s the difference between agile and waterfall?

⁠

This link can't be embedded.⁠

⁠

image source⁠

⁠

Waterfall is in some ways the opposite of agile. While agile tackles tasks in small increments, waterfall

defines an entire project ahead of time⁠

. 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

1.5x more successful than waterfall⁠

, you need to carefully consider your goals and needs.

Here is a table of considerations that might help you decide:

Consideration

Agile

Waterfall

Customer involvement

High

Low

Development process

Continuous iteration

Linear, life-cycle based

Project timeline

Flexible

Fixed

Budget

Flexible

Fixed

Approvals

At the end of each iteration

Continuous leader-specific approvals

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:

⁠
`The best methods for leading a Scrum sprint planning meeting`⁠
⁠

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.

⁠
`Scrum Project Template`⁠
⁠

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

⁠
`How Chris's team at BCG Digital Ventures scales startups with a Scrum doc`⁠
⁠

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

⁠
`Kanban Board for Projects`⁠
⁠

Kanban in three simple steps.

Agile project management FAQs

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

Choosing the right project management strategy for your team depends on many things. Do you trust your team to make decisions? Is your budget fixed? Do you value hard deadlines? How important is customer input? How you answer these questions will help you decide. Check out the table above for more considerations.

What is the difference between PMP and Agile?

PMP is an acronym for Project Management Professional, and it’s a type of certification offered by the

PMI Institute⁠

. The PMP certificate is based largely on the waterfall approach. However, you can become certified in Scrum, including the Certified ScrumMaster (CSM) by Scrum Alliance, and Professional Scrum Master (PSM) by Scrum.org.

What are the benefits of agile project management?

The most valuable benefit of agile project management is actually for your customers. Consistent monitoring of the voice of the customer often ends in

higher customer satisfaction⁠

. And because agile embodies a flexible process that de-prioritizes documentation and constant approval, projects are completed faster and productivity is maintained—all while having clearer visibility into who is working on what and when.

What are the drawbacks of agile project management?

Too much of anything can have a negative impact, including flexibility. The agile approach runs the risk of scope creep, as

teams become distracted⁠

by the next idea or piece of feedback. Final delivery dates and budget costs are also hard to anticipate when both aren’t fixed at the start of the project. And over-collaboration can result in additional commitments and eventually burnout.

What's the difference between agile and Scrum?

Scrum is a methodology, and agile is a mindset that grounds that methodology. Scrum expands agile’s foundational values and roles into a technique more focused on a singular goal. Scrum is also characterized by a time-boxed process that 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).

⁠

A few of the 25,000+ teams that 🏃‍♀️ on Coda.

⁠

a77eed08d9f915aabec0346b67a40b7ec93457a9864e51bde1e9239fad175c59624ad1bd252ec5041198bc8e9a52ce31b441ab4767fbb714b9172474278d0b29434f118c46abc5c7a7377f4ad1ea733677ca74d97bc8661e4bbfde8d9cdafabc285f5616.jpeg

⁠

Coda is an all-in-one doc for your team’s unique processes — the rituals that help you succeed. Teams that use Coda get rid of hundreds of documents, spreadsheets, and even bespoke apps, to work quickly and clearly in one place. This page is a doc published on Coda.

Find out how to Coda-fy your rituals.

⁠

Connect with a Rituals Architect

⁠