True fact: a lot of people don’t understand the Agile Manifesto, and therefore they don’t understand agile.
It doesn’t help that there’s a huge amount of variance in what people who think they are “agile” are doing. Some think that it’s working in two-week timeboxes, having a daily stand-up, or working off a Trello board. Some don’t care and proudly declare “we’re agile,” no matter how they’re working.
Project managers often talk about agile methodologies, frameworks, and agile practices and their benefits, but purists tend to disdain those who are pursuing a hybrid or blended approach.
While the agile vs. waterfall debate is a classic project management hot topic, I’m not here to argue which is better, or whether you should be using agile over waterfall.
In this article, I’m going to delve into what’s at the heart of agile—the four values laid out in the Agile Manifesto and the 12 principles of agile software that sit beneath them.
You’ll learn how you can adopt an agile mindset and begin applying the principles behind the Agile Manifesto. I'll go beyond terminology to arm you with some tangible actions you can take that will benefit your project team.
I’ll cover:
- What is the Agile Manifesto?
- How to Apply the Agile Values and Principles
- Criticism of the Agile Manifesto
What Is The Agile Manifesto?
In 2001, a group of software developers gathered at the Lodge at Snowbird ski resort in Utah to develop the set of values and principles that comprise the Agile Manifesto. Their stated goal was to “[uncover] better ways of developing software by doing it and helping others do it.”
This so-called “agile alliance” included representatives from various development processes, including extreme programming, Scrum, and crystal.
17 people participated, including Alistair Cockburn, Jim Highsmith, Martin Fowler, Andrew Hunt, Arie van Bennekum, Brian Marick, Dave Thomas, James Grenning, Jeff Sutherland, Jon Kern, Ken Schwaber, Kent Beck, and Mike Beedle.
Group discussions culminated in four values and 12 principles.
The 4 Key Values Of Agile
The graphic below shows the four values that comprise the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
As you can see, the Agile Manifesto is not about following a certain process or using a specific tool.
The creators were also not prescriptive about how you manifested these values. They don’t completely discount the ideas on the bottom. They simply state that they value the items on the top more than the ones on the bottom.
The 12 Agile Principles
In addition to the four values, the Agile Manifesto lists 12 supporting principles that explain how to interpret and apply the values on agile projects.
Why Should I Apply The Agile Values?
The values behind the manifesto for agile software development are intended to produce better software that gets to the customer more quickly and therefore provides value sooner. Who doesn’t love happy customers?
How To Apply The Agile Values And Principles
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 are part of the agile manifesto.
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.
Enable free-flowing team communication
As one of the agile principles states:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
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.
Take five minutes and work out how much of your communication is done via channels like email and how much is face-to-face. If asynchronous communication dramatically outweighs face-to-face, and you feel you’re experiencing communication challenges, consider some of these tactics to help you course correct:
- Colocation: Sit everyone together. This means developers, designers, testers, and you! In a remote environment, this might mean scheduling time for live working sessions.
- Test an email ban: Maybe a little extreme (but I bet I’m not the only one who hates lengthy email threads…), but rule out emails within your team during certain days/times so that people can focus on deep work. Reserve other times for synchronous communication to encourage collaboration.
- Encourage team relationships: I’m not saying to organize an awkward team-building event, but reflect on how you can facilitate situations to build relationships and promote face-to-face conversation. Try a group lunch or a shared knowledge session.
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).
Here’s another principle from the agile manifesto:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
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?
- Remove blockers: Rather than telling the team what to do, listen to their issues, and work to unblock them.
- Allocate a team to a project: It’s much harder to create a good team environment when your team is booked up at odd times during the week to work on various projects. Creating a good agile work environment is always trickier to manage in an agency, but look at your project contract. Could your team work consistently together through the project life cycle? Talk to your internal stakeholders and the client about the benefits of this agile approach.
- Don’t micro-manage: If a task takes longer than expected, don’t constantly harass your team member or complain that it’s “not on time”! There’s a good reason for this. Instead, flag to your client or stakeholder, and work with the team to reprioritize.
Don’t stress about the process or tool
I know, I know—talk of project management tools is ever present in the agile PM world.
But, here’s the deal—your customer doesn’t care about your internal 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 for the duration of a project or for key moments can help. Talk to your company about how to enable this, and suggest a test run to demonstrate the benefits.
- 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!
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.
- 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
Another of the Agile Manifesto’s principles is:
Working software is the primary measure of progress.
This is crucial. 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:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
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 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.
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 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 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.
Consider these ten tips for creating an agile product roadmap. Then, share the product roadmap with stakeholders to promote awareness of how the product is developing.
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 validately.com or 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.
4. Responding to Change Over Following a Plan
As another agile principle states:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
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. 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.)
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 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.
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 retrospectives regularly in whichever process you use—and that you have a mechanism for incorporating your learnings!
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.
Don’t forget to subscribe to The Digital Project Manager newsletter for more on agile and other ways of working.
5 Comments