When Agile Fails, Review the 4 Agile Values

When Agile projects start to fail, it’s easy for people to get lost in the weeds, arguing about what Agile is and isn’t. At times like this, you need to take a step back and look at the big picture. Specifically, it’s valuable to go back to the original sources and remind ourselves of the basics that are the foundation of all Agile approaches.

The 4 Values of the Agile Manifesto

Back in 2001, several leaders in the Agile movement got together at the Snowbird resort in Utah, and came up with a unifying set of core values and foundational principles that are common to all of the flavors of Agile.

They identified 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

The Manifesto for Agile Software Development

To clarify, they said that though they still value the items on the right, they value the items on the left more.

This is an important distinction. They didn’t say that the items on the right were of no value. You still need the items on the right. You just need the items on the left even more. The trick is to maintain the appropriate balance between them in order to avoid Agile failure.

Individuals and Interactions over Processes and Tools

Agile approaches still have plenty of processes. Take Scrum for example, which is the most popular Agile approach. Just look at all these Scrum processes and tools:

  • product backlog
  • user stories
  • sprint planning
  • planning poker
  • sprint backlog
  • sprints
  • Scrum board
  • daily stand-ups
  • burn-down charts
  • sprint reviews
  • sprint retrospectives
  • velocity charts
  • colocation

The key is to remember that the processes and tools are means to an end. Customer satisfaction is the ONLY real measure of project success. These processes and tools can improve your chances of project success, but they don’t guarantee it.

Do you feel that you have enough interaction with your key stakeholders and the project team members? Is you project serving them, or frustrating them? What can you do to improve this?

Working Software over Comprehensive Documentation

For me, the biggest paradigm shift in the Agile movement is admitting that comprehensive documentation isn’t possible. In some industries, you need a lot of documentation. But don’t kid yourself into thinking that it’s complete, and that it won’t need any changes before the project is done.

Unfortunately, too many people, in their frustration with comprehensive documentation, have failed to understand this Agile value, and have completely abandoned documentation. We still need it. We just need to make sure that the documentation we generate is actually worth it.

Do you have the right amount of documentation? Is it in the right format? Are you getting the feedback you need from key stakeholders?

It’s more important to demonstrate real progress. In software development, that means delivering working software with every sprint. Don’t think that’s possible? Take a look at these 12 practical steps.

Have you organized your work in a way that allows you to deliver more value with each sprint? Or have you convinced yourself that it’s just not possible? Are you stuck in a waterfall mindset, thinking that some things are just too big, and that you need multiple sprints to deliver value?

If so, then you need to reconsider the value of getting customer feedback on working software – even if you’re embarrassed by how inadequate it seems to deliver only one sprint’s worth of value.

It’s not easy sometimes to break down large features into small parts that can be delivered in a single sprint, but it’s worth it.

Customer collaboration over contract negotiation

You’ll still need contracts with external suppliers. Between departments of large organizations or government agencies, you’ll still want letters of intent and memoranda of understanding.

One of the important lessons we in the West learned from Japan’s success in manufacturing in the last few decades of the 20th century, is the value of long-term relationships with suppliers. By working to understand each other’s needs, they were able to identify win-win opportunities that increase quality and lowered costs.

How closely do you work with vendors to understand their needs? What opportunities have you identified to increase quality and timeliness?

Responding to Change over Following a Plan

In preparing for battle I have always found that plans are useless, but planning is indispensable.

Dwight D. Eisenhower

Far too many Agile projects fail due to a lack sufficient planning. Yes, you have to embrace change. But you also need a plan.

For starters, you need to have a project charter. It needs to clearly identify the high-level scope of the project. Otherwise, it may become an opportunity for everyone to ask for everything they’ve always wanted. That’s a recipe for a bloated project that spins out of control, quickly consuming the budget and failing to deliver.

Periodically Review the 4 Agile Values

Every so often, to avoid Agile failure, take a look at your project, and ask yourself:

  • Are we valuing individuals and interactions over processes and tools?
  • Do we have quality problems because of a lack of processes and tools?
  • Are we delivering value with every sprint?
  • Do we have enough documentation, or are we losing track of things?
  • How well do we know our suppliers? What win-win opportunities have we identified and maximized?
  • Do we have a plan? Is it helping us keep the project on track, and focused on a single key benefit?
  • Are we working with key stakeholders to identify even better ways to provide this benefit? How many have we found so far?

Continue your Agile education here: What’s Agile? Customer Satisfaction (Principle #1)

Click here to learn about my course, built for IT Professionals.

1 Response

  1. […] To continue reading about Agile go here: When Agile Fails, Review the 4 Agile Values […]