The Agile Manifesto Explained And How to Apply It
The Agile Manifesto is a document that spells out ways of working that promote adaptability, responsiveness, and flexibility in software development.
At least, that's what its original intent was. Today, agile ways of working have spread far beyond the tech world and are used across countless other industries.
But ... what the heck does it mean? And how does a manifesto translate to the work you do every day? Let's dig in.
What Is The Agile Manifesto?
The Agile Manifesto is a written proclamation that includes four values and 12 principles that are intended to improve ways of working within software development.
More philosophical than prescriptive, the Manifesto was intended to be adaptable to a variety of team sizes, goals, and conditions.
The Agile Manifesto's 4 Values
The official Agile Manifesto consists of these 4 values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
It's interesting to note that the authors followed the values with this clarifying statement: "That is, while there is value in the items on the right, we value the items on the left more."
This underscores the idea that the Agile Manifesto is not about following a certain process or using a specific agile tool. It's about adopting a specific mindset.
The 12 Agile Manifesto Principles
In addition to the four values, the Agile Mtranifesto lists 12 supporting principles that explain how to interpret and apply the values on agile projects.
1. Put the customer first
The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome change
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver frequently
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Collaborate across teams
Business people and developers must work together daily throughout the project.
5. Cultivate talent
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. Talk
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Measure what matters
Working software is the primary measure of progress.
8. Pace work to avoid burnout
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Focus on quality and work will move faster
Continuous attention to technical excellence and good design enhances agility.
10. Embrace simplicity
Simplicity–the art of maximizing the amount of work not done–is essential.
11. Don't micromanage
The best architectures, requirements, and designs emerge from self-organizing teams.
12. Reflect and adjust
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
History, Authors, and Origin Story of The Agile Manifesto
Within the tech world, the Agile Manifesto is discussed with the same reverence and irreverence as any sacred text that has been passed down over time.
In February 2001, 17 software professionals who dubbed themselves “The Agile Alliance” came together in the U.S. state of Utah to develop what they called a “Manifesto for Agile Software Development.” The document, which emphasizes four values and 12 principles, is now known as the Agile Manifesto.
The authors of the Agile Manifesto are often referred to as the Agile Alliance, and included representatives from various development processes, including extreme programming, Scrum, and Crystal.
A quick peek at the official website for the manifesto depicts the authors in a setting that might call to mind a secret society or founding-fathers meetup. It was clear that their intent was to create something that would leave a lasting impact on the industry. It certainly has.
While the individuals who met in Utah were not the pioneers of agile principles in general, they did solidify the values that had been brewing for some time in the background in the software development world.
Today, the agile methodology has permeated almost every industry.
The authors included:
- Kent Beck
- Mike Beedle
- Arie van Bennekum
- Alistair Cockburn
- Ward Cunningham
- Martin Fowler
- James Grenning
- Jim Highsmith
- Andrew Hunt
- Ron Jeffries
- Jon Kern
- Brian Marick
- Robert C. Martin
- Steve Mellor
- Ken Schwaber
- Jeff Sutherland
- Dave Thomas
Why the Agile Manifesto Is (Still) Important
The Agile Manifesto is still relevant because of its focus on human-centric ways of working and its allowance for flexibility.
With rapid technological changes often come shifting project requirements. The Agile Manifesto enables project managers to prioritize adaptability and collaboration by creating a responsive and resilient project environment that can simultaneously deliver work, innovate, and pivot when needed.
It also promotes a customer-centric mindset by valuing working solutions over comprehensive documentation. This allows project managers to gather feedback early and continuously refine their work, ensuring that the project aligns closely with user needs. This iterative and customer-driven approach increases project success rates and satisfaction.
How To Apply The Agile Manifesto
Let’s delve a little deeper into each of the four values of the agile manifesto. By reviewing the core values, we’ll also explore the 12 principles that level-up to each.
Value #1: Individuals and Interactions over Processes and Tools
The core of agile is about people. Agile emphasizes that a team works together, collaborates closely, and makes decisions independently. Agile is not about telling a team what to do or what to build.
On agile projects, communication must be free-flowing and continuous, not defined and scheduled. Working in closed-off silos is not what agile is about.
Evaluate team communication
Ask yourself, are you and your team having face-to-face conversations? Or are you relying on emails, documents, and certain much-loved messaging tools (naming no names here)?
Even if you’re working remotely, having a face-to-face conversation can enable things to happen faster. Especially when a team is newly forming, synchronous communication encourages trust and openness and helps build relationships.
Be less of a control freak
We’ve all been guilty of this one on occasion. But, trust is integral to agile. Looking for something you can implement right away? DO NOT MICRO-MANAGE (yes, I meant to shout that).
It’s tempting to get granular on the tasks, hand these out to the team, and then track them until they meet the imposed deadline (or don’t), so that you have control over everything. But, to truly empower your team, you need to back off a bit and let them have ownership of their work!
Encourage a self-organizing team
It’s not about managing—it’s about leading and facilitating. A self-organizing team means a team choosing how best to accomplish their work. They should decide how to transform the backlog of work into releasable code. But don’t take it to the opposite extreme and provide no help or guidance—the team still needs a vision, motivation, and help to resolve blockers.
In that case, how do you get away from handing out tasks and instead determine how you can facilitate the work?
Don’t stress about the process or tool
I know, I know—talk of project management tools and agile project management software is ever present in the agile PM world.
But, here’s the deal: Your customer doesn’t care about your internal agile workflow process. Nor should they.
Agile is about taking a customer-first approach and enabling your team to deliver better and more valuable work. More on the customer-first approach later!
Remove silos
Silos hinder collaboration and therefore detract from agile values.
To move away from silos, consider these tips:
- Colocate the team: Yes, this one again. It’s great if your designers can sit near each other and chat about design stuff, but isn’t it better if they’re chatting to the developers about building this great product? I know this can be difficult to implement in a larger organization or in remote environments, but even getting together in a shared Slack channel or having scheduled coworking sessions where people can do deep work simultaneously and remotely can keep your team more connected.
- Discourage hand-offs between departments: The more gated waterfall-like approach of having each department work in stages (UX, then design, then development, then QA) can often cause communication breakdowns and increase waste on a project. Consider getting your team to work together on features rather than handing off down a chain. Even if you work in sprints but with an upfront design sprint, get your developers involved in the design sprint—they’re going to be building this after all!
Value #2: Working Software over Comprehensive Documentation
Remember that the manifesto isn’t saying to kill documentation—it’s simply valuing the items on the left more than the ones on the right. That means documentation still exists. For example, Scrum has user stories to inform a developer how to get going on the build.
But, what can you do to move away from the heavy, time-wasting documentation and quickly get into something tangible?
Streamline the documentation that you use
Identify any pain points or blockers in your process. Are you too documentation heavy? Do you take forever to craft the perfect requirements document, spend ages on a functional scope, and then run out of time to build the product? Reduce unnecessary documentation by:
- Focusing on design and development tasks that will feed into the product itself, rather than a written document that ultimately won’t be used
- Hold workshops upfront to define requirements and next steps rather than writing up lengthy documents. Document and share outcomes with photos and brief notes.
Get into build quickly
Writing reams of requirements documentation is one way to map out the needs of the business, client, and customer. But, ultimately, seeing something working, behaving, and reacting is much more useful.
Consider some of the following ways to push your project forward quickly:
- Compress upfront discovery or definition into a shorter timescale: Constraining how much time you spend defining and working things out means you can get to something that the designers and developers can tackle more quickly. You can speed up the process using these discovery session questions.
- Hold workshops: Conducting team workshops brings stakeholders together to make decisions faster.
- Change your project plan: Have you staggered definition, then design, then development? Consider pulling development forward and getting designers and developers to produce something together, earlier.
Use prototyping methods rather than flat designs
Instead of seeing progress as a definition document or a flat design that is a checkbox for your client to approve, show them something that becomes part of the finished product.
Use prototyping to get something working and usable—and, more importantly, something that you can test with customers. Collecting feedback on a prototype becomes a useful way to track progress, rather than relying on a deliverable that doesn’t have the benefit of being part of the final product.
You can create prototypes to different levels of fidelity:
- Low fidelity: Clickable designs. This is when you need to get something quickly mocked up to test with customers, more a test of look and feel and simple interactions.
- Medium fidelity: Using some motion or animation.
- High fidelity: Working HTML. Used for complex interactions, but you can carry it forward into releasable code.
High-fidelity prototypes are closer to “working software” than the other types but can be more time-intensive to produce. Low or medium-fidelity prototypes offer better guidance to developers than flat designs.
Deliver something to the end-user or customer quickly
This is an important one.
With frequent releases of working software, the customer can be engaging with any new features that have been released. Rather than waiting until the end of the project for a big-bang launch, delivering value to your customer sooner is critical to getting a better product.
How can you achieve more frequent delivery in your organization?
- Review your project plan or roadmap: Have you planned to complete development and then launch at the end of your project? Instead, work with your team to break up the work into features or chunks of work that could be released independently along the way.
- Focus on blockers: A core part of your role is to help unblock the team when issues occur. How can you help them deliver more efficiently? Are there ways of working that are slowing down releases? Holding a sprint retrospective with your team can uncover opportunities for process improvement.
- Automate: If your organization puts a ton of effort into releases, automate processes where possible. For example, automated testing and deployment can save manual labor and reduce the level of effort required for a release. Speak to your agile development team about the processes they use and opportunities for automation.
Value #3: Customer Collaboration over Contract Negotiation
Instead of crafting a super-specific contract at the beginning of a project that details precise deliverables, scope, budget, and timelines, keep your agile contract as high-level as possible. Resolve decisions throughout your project by collaborating closely with your clients and stakeholders.
Agile is not about spending a ton of time defining requirements upfront. It’s about getting started on a project and learning as you go based on customer testing and feedback gleaned from working software.
Employ a customer-first approach
I love this quote from an article by Neil Killick:
“An agile thinker continually asks, ‘What’s the simplest/quickest way to get value to the customer?’ Are you asking that question on a daily basis? If not, there’s your first step.”
It’s not only designers and developers who should be thinking this—project managers should too. We’re also responsible for getting the best possible product or service to a customer. Your customer, the user of your product or service, should be at the center of everything you do.
Put the end customer at the center of the plan
Rather than planning around deliverables and estimations, plan around valuable customer outcomes. What do we want the customer to do, and why? How will we measure that this works?
Reframe the conversation to focus on what value we have delivered for the customer rather than how many work items we have delivered.
Get your client closely involved
Rather than running a weekly status meeting and then delivering to your client and stakeholders at the end of a certain period, work to involve your client in the project on a daily basis.
If you’re running more of a Scrum process, make the client the product owner. The product owner is responsible for bringing together the business, technical, and customer requirements. Getting client buy-in and collaboration early on and frequently is critical to avoid delays. It ultimately generates a better product or service for the end customer.
Involve a distant client
If your client doesn’t have the time to contribute to the project or is otherwise not engaged, make sure that someone on the team represents the client. It is critical that someone considers customer and business needs.
Even if the client is not engaged day-to-day, make sure that you communicate with them regularly and, at a minimum, involve them in any agile planning and prioritization discussions. Work with them to demonstrate the benefits of their involvement.
Implement a product roadmap
Consider using a product roadmap to map the trajectory of your product. A product roadmap communicates the plan for the product and visualizes features planned for delivery. A roadmap isn’t fixed at the beginning of a project; rather, it evolves over time to reflect changes in priority.
Make sure you’re talking to your end users or customers
I cannot stress this enough—you must try to test your product with end users and customers early and often.
Testing yields so many benefits:
- You can ensure that your product meets customer needs, i.e., is the product valuable to the customer and therefore to the business? This helps you assess product-market fit.
- You can incorporate customer feedback into your design and development process, resulting in a better end product.
- You can gain insights to feed future work.
- The often-cited issue with customer testing is budget—it can be expensive. Here are some ways to test no matter your project budget:
Guerrilla testing: I love this one because it’s cheap and easy. Offer to buy people a real (or virtual) coffee if they’d answer some questions on your designs or prototype. It’s harder to specify who answers your questions, but some quick feedback can be helpful when testing look and feel or simple interactions.
Surveys: To collect quantitative data from a wider range of people, you can create a survey to evaluate design or delve deeper into customer behavior.
Sites like usertesting.com: You can upload your designs onto one of these sites and recruit people through them (using criteria if necessary). They will then click through your designs, record thoughts, and answer questions.
Face-to-face testing: Yes, this can be a more expensive option, as you’ll likely need to recruit people and pay incentives; however, this can be invaluable if you’re testing complex interactions or high-risk features.
Value #4: Responding to Change over Following a Plan
Agile and waterfall projects could not be more different in this regard. On traditional software development projects, you set the requirements, cost, and timings upfront, whereas agile allows for and embraces change.
Change is good! It’s not evil! How many project plans have worked out for you exactly as you created them at the beginning? Not many, I’d guess (I’ve worked on projects with dozens of iterations of the project plan.)
Plans are a best guess at a point in time, which you can firm up as you move along—however, they don’t tend to allow for change. What happens if the customer needs change? The business changes course? Your client changes priorities? The feature specified isn’t as simple to build as you thought.
Agile ways of working embrace uncertainty by embracing an adaptive planning approach (such as planning poker). For example, Scrum values prescribe that the team plans work sprint by sprint. Before starting a time-boxed period of work, agile teams take items from the backlog and prioritize them for development.
While there is often a push to pin down costs, timeline, and scope at the beginning of a project, being more realistic about the uncertainties you face often yields a much better end product. Ultimately, this is what you, the client, and your stakeholders should want.
Here are some ways to begin allowing for change in your projects and encouraging more flexibility:
Create a “light” plan to satisfy stakeholders
“But we need a plan!”, shout your stakeholders. Instead of freaking them out by saying, “Surprise, there is no plan!”, create a light release plan to give them confidence in the slightly less formal approach.
If you’re doing agile project management with Scrum processes, you’ll have a list of prioritized and estimated user stories in your backlog. Work with the product owner to group these into rough releases, and map these to your product roadmap.
Try not to plan everything, thus defeating the benefits of using the Scrum methodology. Show what you’re planning in the first two or three releases to your stakeholders, and then talk them through how replanning is core to an agile way of working, and you’ll communicate updates and further releases as you go. Hopefully, this will give them the confidence they need!
Ease the team into a sprint-based approach
Mike Cohn, in his article “Introducing an agile process to an organization,” suggests helping teams ease into scrum by defining a set of sprint types, for example:
- Prototyping
- Requirements capture
- Analysis and design
- Implementation
- Stabilization
Here he describes how this can help:
“We then work with the teams to define the artifacts that will result from each sprint type. Using sprint types introduces just enough formality that the teams can more clearly see their way through the project. As the teams become more adept with the informality of the agile process, they gradually drop the sprint types concept.”
This is another way to shape your release plan. If you allocate a “type” to each sprint, your stakeholders can see how the plan takes shape, while precluding you from having to guarantee features. Your team also gets a better sense of what they are going to be working on.
Move away from fixed deadlines
Giving your team a deadline or communicating a fixed date to your client are both strategies that are either destined to fail or at least incur stress along the way. Fostering trust between you and your team and your client or stakeholder is essential to prove that you will deliver, and deliver value, to the end customer.
Remember, you’re trying to reduce the need for multiple checkpoints and approvals. Implementing deadlines on your project aren’t going to help you achieve this goal. It also isn’t good to be breathing down your team’s necks, chasing them for the work they “promised” to deliver.
As I mentioned above, roadmaps and release plans can be a good mechanism to shift away from a fixed-date approach. Giving stakeholders a sense of what will be released in the near future can reassure them that there is a plan.
Use a time and materials-based scope
If you have a fixed price, fixed deliverables scope, it’s hard to deliver in a more agile way. You can definitely employ some of the techniques I’ve discussed already, such as enabling a more collaborative team. But, you’ll be limited in how much you can respond and adapt to change, let the team determine what they’re working on, or use a more customer-centric approach.
Work with your internal team and the client to put in place a time and materials-based scope—i.e., the client pays for a team, rather than fixed deliverables. At first, clients may get nervous if they don’t know exactly what they’re getting.
To mitigate this concern, you could include as part of the scope a backlog of activities or tasks that could be considered for launch. Specify in the contract that the team will replan and prioritize the backlog with client input as the project progresses (although you may not address every item.)
To help manage shifting priorities and deliverables, teams can rely on agile management software to continuously reprioritize their backlog and coordinate cross-functional collaboration.
This way, you’re not committing to a fixed scope, but the client has fewer concerns about what the end product looks like.
Continue to track progress
Tracking and visualizing progress doesn’t get thrown out the window in the absence of a formal project plan. Keeping progress visible for the team and stakeholders not only ensures that you don’t lose sight of potential blockers and bottlenecks but also keeps stakeholders in the loop.
Employing a Kanban-style WIP board or agile dashboards works well for agile projects. Once you’ve visualized your process, you can start to map out supporting tasks and activities. This helps you spot bottlenecks that you can unblock to facilitate quicker customer delivery.
Criticism Of The Agile Manifesto
Like any other project management methodology, agile isn’t perfect. Critics point out that the authors of the Agile Manifesto were a homogenous group that may have failed to consider alternative approaches to work, like the benefits of working remotely or how to apply agile outside of the software development space.
Taken too far, agile might mean decision by committee, slowing down the pace of work. Lack of documentation could end up hurting project delivery, especially in a remote environment where asynchronous communication is critical.
If you decide to use agile on your projects, be sure to consult the agile values and principles. They are a useful guide for keeping the worst tendencies of agile in check.
Read more about the debate over whether agile is a methodology or a mindset here.
Agility, Not Agile
One final thought is: remember the retrospective! As the Manifesto states:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Whatever type of process you’re running, the retrospective is an effective way of inspecting how you are working and optimizing for success. Ensure you include project retrospectives regularly in whichever process you use—and that you have a mechanism for incorporating your learnings! PS: It's important to get your quiet team members talking in retros too—here's how.
If there’s one thing I want you to take away from this article, it’s that you don’t have to go “full-on agile” (whatever that is.) If you look at developing a more customer-centric approach, help enable team collaboration, and try to achieve more frequent delivery, then you’ll derive great benefits.
Learn more about agile and key agile concepts by taking one of these agile certifications.
What's next?
To learn more about how to implement agile ways of working and learn from the best project managers in the business, check out our DPM membership options. These agile project management courses can also help equip you with the tools to succeed.
