The Agile Manifesto and How to Really Apply It to Your Projects

Author: Suzanna Haworth

Source: TheDigitalProjectManager

Here’s a fact: a lot of people don’t get the Agile Manifesto, and they don’t get Agile.

There, I said it.

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” whatever way they’re working. And believe me, I’ve worked with a lot of companies who have done this!

In our industry, there’s also a lot of talk about Agile methodologies, frameworks, and agile practices and their benefits. Generally, this comes with some snobbery around those who are looking at more of a hybrid or blended approach.

In this article I’m going to delve into what’s really at the heart of Agile—the four values laid out in the Agile Manifesto, and the 12 principles that sit beneath them.

I’ll help any of you who are working in a more structured, gated or Waterfall way to see how you can start thinking with a more Agile mindset, and start applying the principles behind the Agile manifesto.

Then, going beyond simple Agile terminology, I’ll arm you with some tangible actions to start to be able to apply to your projects, team and organisation immediately.

What Is Agile Project Management?

What is Agile?

Let’s start with a basic Agile definition: The Agile Manifesto is a set of values and principles born out of software development, and the term was coined in 2001.

What is Agile not?

Recommended Related Reading:

• List of The 10 Best Agile Tools For Managing Projects
• 130 Top Project Management Influencers of 2020
• 10 Best Project Management Software of 2020 Expert Review

It’s not a process or project management methodology (although many do refer to it as “agile methodology”).  It’s not Scrum—Scrum follows Agile principles. It’s not Kanban—Kanban applies Agile principles. You get where I’m going with this.

What is Agile Project Management?

This is more of a tricky one. Agile principles are founded on having a self-organising team, therefore the role of the traditional Project Manager becomes more redundant within Agile frameworks. That’s where we’ve tended to adapt or move into other roles if we’re following stricter frameworks, such as ScrumMaster or Delivery Manager. Project Managers still tend to be involved in more hybrid or blended approaches.

Agile vs Waterfall

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. If you’re interested in the Agile values and want to see how they can benefit you, your team and your projects then read on!

Why should I apply the Agile values?

Agile ways of working have been proven to help deliver better, more high quality products to customers, with generally faster delivery. The values behind the Agile Manifesto aren’t necessarily ground-breaking—all are there to promote an agile team working together to produce better software that gets to the customer more quickly, and therefore provides more value sooner. Adopting more of an Agile mindset whichever framework you use can help deliver some of these benefits.

The Agile Manifesto

In 2001, the Agile Manifesto was created. It was a collective effort of a group who got together over a weekend to try and define the values and principles around software development. They stated:

“We are uncovering better ways of developing software by doing it and helping others do it.”

They then stated what they value:

As you can see they don’t say “follow this process” or “use this tool”. In other words, they’re not prescriptive in how you manifest these values. They also don’t completely discount the ideas on the right. They say that they value the items on the left more than the ones on the right.

So let’s go a little deeper into each of these four parts of the Agile Manifesto to take on an Agile mindset in your organisation. Through these four values we’ll also explore the twelve principles that are further defined within the Agile Manifesto.

Here’s a great resource if you’re interested to learn more on the background on the Agile Manifesto, values and principles.

1. Individuals And Interactions Over Processes And Tools

People, people, and oh, did I mention people? This is the centre of Agile. It’s about a team working together, collaborating closely and making decisions between themselves. It’s not a team being told what to do or what to build. Communication needs to be free-flowing and continuous, not defined and scheduled. Working in closed-off silos is not what Agile is about.

How to make it happen in your projects? Read my advice below.

Enable free-flowing team communication.

As one of the principles states: 

Agile Principle: 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 really enable things to happen faster. It encourages trust, openness and relationship-building.

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 the channels largely outweigh the face-to-face, consider some of these tactics:

• Colocation: Sit everyone together. This means developers, designers, testers, and you!
• 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 for a certain period and encourage people to get up and talk to each other.
• Encourage team relationships: I’m not saying “organise an awkward team-building event”, but think about how you can facilitate situations where your team can build relationships and get more used to face-to-face conversation. Try a lunch out, or a shared knowledge session.

Be less of a control freak.

Yes, even I have been guilty of this one on occasion. But trust is integral to Agile. The one thing you can implement straight away: DO NOT MICRO-MANAGE (yes, I meant to shout that).

Here’s another principle from the Agile Manifesto:

Agile Principle: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

It’s all too 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 really empower your team, you need to back off a bit and let them have ownership of their work!

Which leads me on to…

Encourage a more self-organising team.

It’s not about managing—it’s about leading and facilitating. A self-organising team means a team choosing how best to accomplish their work. They will decide how to take the backlog of work and turn this 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.

How do you move away from handing out tasks and determining what people are working on then?

• Help remove blockers: Rather than telling them what to do, find out what the issues are 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 out at odd times during the week to work separate parts of the project. 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? 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”! Generally there’s good reason for this. Instead, flag to your client or stakeholder and team, and work with them to reprioritise.

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.

However, as I said in a talk I gave recently, “Your customer doesn’t give a s*** about your process!” And I stand by that.

It’s about taking a more customer-first approach, and enabling your team to be able to deliver better and more valuable work. I’ll delve more into the customer-first approach a little later.

Move away from silos.

As I said before, silos just don’t help collaboration. This works both in a physical space, but also within your projects. Anybody working in any form of isolation moves away from the Agile values around team collaboration.

So to move away from silos, try out these tips:

• Colocation: 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 organisation but even getting together for the duration of a project 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

In about 2009 (I know, 8 years after the Manifesto!) I wrote a functional specification document that came to 35 pages long. It outlined all the functional behaviour of the site we were building, including wireframes. It took a long time to create. And guess what? Things changed. This functional spec we were working to became more and more out of date. It took time to update, so we ended up ditching it and just working with… the site itself. Crazy, huh? Whilst I’m not saying kill all documentation (and the Manifesto isn’t either, remember it’s valuing the items on the left more than the ones on the right), this value is about getting quickly into something real and tangible.

Documentation still exists. For example in Scrum there are user stories—just enough information for a developer to get going on the build. So what can you do to move away from the heavy, time-wasting documentation?

Streamline the documentation that you use.

Identify any pain points or blockers in your process. Are you too documentation heavy? Do you spend days crafting 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.

It’s all very well writing streams of requirements documentation, mapping out all the needs of the business, client and customer—all great. But ultimately seeing something working, behaving and reacting is much more useful. Consider some of the following ways to push your project forward quickly:

• Time-box upfront discovery or definition into a shorter period. Putting this constraint on how much time you spend defining and working things out means there is a greater push to get to something that the designers and developers can be working on more quickly.
• Hold workshops. Using workshops with the team pulls everyone together and generally helps make decisions faster.
• Change your project plan. Have you staggered definition, then design, then development? Consider pulling the development forward and getting designers and developers working on producing something together, earlier.

Use prototyping methods rather than flat designs.

Another of the Agile Manifesto’s principles is:

Agile Principle: Working software is the primary measure of progress.

This is crucial. Instead of seeing progress as a definition document or a flat design, a tick-box for your client to approve, show them something that is actually going to be part of the finished product. To help move towards this approach, use prototyping to get something working and usable—and importantly able to be tested with customers. This will enable you to have something useful to track progress, rather than relying on something that doesn’t have the benefit of being part of the final product. There are three types of prototypes we’ve classified in organisations I’ve worked with:

• 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 able to be taken forward into releasable code.

High fidelity prototypes are obviously the more “working software” version of the three, but can be more time-intensive. However, using low or medium fidelity prototypes rather than flat designs can ultimately help deliver more quickly by giving good guidance to the developers.

Deliver something to the end user or customer quickly.

This is an important one:

Agile Principle: 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 help achieve more frequent delivery in your organisation?

• Review your project plan or roadmap: Have you planned for all the development to be completed and then launched at the end? Work with your team to break up the work into features or chunks of work that could be released on their own. Even moving to a few smaller releases can have benefits.
• Focus on blockers: A core part of your role is to help unblock the team when issues occur. How can you help them work to deliver more efficiently? Are there ways of working that are slowing down releases? Holding a retrospective with your team can uncover reasons behind this.
• Automate: If your releases are always a big deal in your organisation and a huge amount of effort is put into them, automate processes where possible. This includes tasks like testing and deployment, therefore saving some of the manual labour to in turn reduce the enormity of a release. Speak to your agile development team about what processes they use, and how these can be automated.

3. Customer Collaboration Over Contract Negotiation

Instead of fixing a contract in stone at the beginning of the project (which details deliverables, scope, budget and timelines), try to fix as little as possible. Resolve decisions throughout your project by collaborating closely with your clients and stakeholders.

This is not about lengthy requirements definition up front. This is about getting going on the project and defining as you go based on working software, customer testing and feedback and learning from this.

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 just 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 centre of everything you do.

Put the end customer at the centre of the plan.

Rather than planning around deliverables and estimations, plan around valuable customer outcomes. What do we want them to do, why and how will we measure that this works?

Reframe the conversation to what value have we delivered for the customer rather than how many work items have we delivered.

Get your client closely involved.

Rather than a weekly status call, and then delivering to your client and stakeholders at the end of a certain period, try and get your client or stakeholders closely involved in the project and working with you on a day-to-day basis. If you’re running more of a Scrum process, make the client the Product Owner, leading on bringing the business, technical and customer requirements together. Getting their buy-in and collaboration early on and frequently is critical to avoiding delays, and ultimately getting to a better product or service.

Involve a distant client.

If your client doesn’t have the time or is not very present, make sure that someone represents the client in the team. Ensure there is the necessary consideration of both business and customer needs. Still make sure all decisions are communicated to your client, and try at least to involve them closely in any planning and prioritisation. Show them how it would be much more beneficial for them to be closer to the project.

Implement a product roadmap.

Consider using a product roadmap to map the trajectory of your product. This will communicate the overall product plan, and visualise features planned for delivery. A roadmap isn’t fixed at the beginning of a project, it evolves over time to reflect changes in priority.

Ensure this goes in front of all stakeholders, so they know the focus of what you’re working on and how the product is developing. Have a look at these ten tips for creating an Agile product roadmap.

Make sure you’re talking to your end users or customers.

I cannot stress this enough (and I’ve seen so many clients and organisations leaving this out of projects), you must try and test with end users and customers early and often. There are so many benefits to this:

• You can learn from the testing and feed this back into your design and development process, resulting in a better end product.
• You can ensure that your focus for the project is the right one, and what the customers need i.e. is valuable to the customer and therefore to the business.
• You can gain insights to feed into future work.

The often cited issue with customer testing is budget—it can be very expensive. Here are some ways to test for all varieties of budget:

• Guerrilla testing: I love this one! Cheap and easy, just go to a coffee shop and offer to buy people a coffee if they’d answer some questions on your designs or prototype. Obviously, it’s harder to specify who answers your questions, but some quick feedback can be really helpful when testing look and feel, or simple interactions.
• Surveys: To get more quantitative data from a wider range of people, you can create a survey of questions around a design or to delve deeper into customers’ behaviour.
• Using 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 and 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:

Agile Principle: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Now this is where Agile really starts to push out the more traditional Waterfall methods. With Waterfall methods, the requirements, cost, and timings are all set upfront, whereas Agile allows for and actually 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 once worked on a project with 12 iterations of the project plan).

Plans are a best guess estimate at the time, which you can firm up as you move along—however they tend not 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 as you thought?

Agile ways of working tend to embrace this by a planning as you go approach. For example, Scrum values prescribe that the work is planned Sprint by Sprint, taking items from the backlog and prioritising them before starting the timeboxed period.

Whilst there is often a push to ‘fix’ things like costs, timings and scope at the beginning of a project, moving towards a looser shape and allowing for change can end up with a much better end product—and ultimately this is what you, the clients and the stakeholders should want. Here are some ways to start to allow for change in your projects, and encourage 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 prioritised and estimated user stories in your backlog. Work with the Product Owner to group these into rough releases, and map these to your overall 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, but also this avoids you having to guarantee features. Your team can also feel more of a 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 often destined to fail, or at least be very stressful getting there. This goes back to trust. Enabling this trust between you and your team and your client or stakeholder, that you will deliver, and deliver value to the end customer is really important.

Remember, you’re trying to reduce the need for multiple checkpoints and approvals, therefore implementing deadlines on your project isn’t going to achieve this. 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 really good way to move away from this fixed date approach. Giving stakeholders a sense of what will be released in the near future can help them to trust that there is a plan, and reassure them. This will also enable your team to move away from fixed dates and deadlines determined in an upfront plan.

Use a time and materials based scope.

If you have a fixed price, fixed deliverables scope it’s very 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. However 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. Despite the huge benefit of not deciding exactly what you’re building upfront, this also puts in place a team that is working together to develop the product.

However, external clients can often get nervous when they don’t know what they’re getting. To avoid this, I’ve previously used a backlog approach within the scope where I’ve indicated activities or tasks that we’d be looking at as part of the backlog. It’s then specified that we will replan and prioritise the backlog as we progress, with the client, therefore not all of these items might get addressed.

Continue to track progress.

Tracking and visualising progress doesn’t get thrown out of the window when you don’t have a formal project plan. Keeping progress visible for the team and stakeholders ensures that you don’t lose sight of blockers and bottlenecks, but also that stakeholders can be kept easily in the loop. Employing a Kanban-style WIP board works really well as a tool to adopt when you’re trying to work in a more Agile way.

Once you’ve visualised your process, you can start to map out tasks and activities within this. From here you can start to see bottlenecks or queues, and here’s where you can help to unblock them and therefore ensure things are delivered quicker to customers.

Agility, Not Agile

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 start to behave and strive to work with more agility, then this will start to have great benefits. If you look at developing a more customer-centric approach, help enable team collaboration and try to achieve more frequent delivery—all these things can really help shift you towards more agility, and therefore more Agile (there, I had to say it).

One final thought is: remember the retrospective! As the Manifesto states:

Agile Principle: 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, this is a really effective way of inspecting how you are working, and adapting to find better ways to work. Ensure you include these regularly in whichever process you use!