When we hear about Agile development, we think software. But Agile doesn’t have to apply only to software development! The principles of Agile Software Development can be applied to many different projects. Over the next few articles we’ll look at the values and principles of Agile Software Development which can lead to an understanding of how we can apply these values and principles to become more agile in other areas.

At the heart of Agile is being able to respond to change efficiently. I believe when an organization states they want to be more agile, they are looking for ways to do exactly this – respond to change efficiently. As we will see as we explore Agile, becoming more agile via Agile is not about a process, but about a mindset.

Let’s start by looking at the four stated values found in the Agile Manifesto (agilemanifesto.org).

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

agilemanifesto.org

Trusting People

Note that half of the stated values, namely “Individuals and interactions over processes and tools” and “Customer collaboration over contract negotiation,” put people first. While processes and tools are necessary, people doing work and talking to each other is more highly valued. Similarly, developers working with the customer as the project progresses to produce what is needed is considered more valuable than a rigid contract spelling out all the terms and requirements.

With these two Agile values in mind, we already see that trust is a big factor in becoming agile. We need highly defined processes when we don’t trust that people will be able to replicate success otherwise. With Agile, we need to figure out how we can trust team members to be successful when a granular process may not exist. We also need to figure out how our organization and our customer can win if we don’t have every last detail spelled out in a contract.

With Agile we must cultivate trust within our team and with our customer to be able to react to change efficiently.

Producing Results

The value of “Working software over comprehensive documentation” is all about efficiency. While documentation is still important, the result produced is more highly valued. Documentation for documentation’s sake is anti-agile. Every moment the team spends documenting is a moment the team is not producing results. Please note! This does not mean agile teams do not do any documentation! It means there is a balance between producing results and documenting the work. Some types of projects will require more documentation than others. Agile does not prescribe how much documentation is needed, only that a working product is valued more highly than comprehensive documentation.

Being Agile

The fourth stated value is “Responding to change over following a plan.” This value is where a lot of organizations trip. Established companies are used to seeing a full plan, start to finish, for a project. From the plan a projection of cost can be made, and a budget can be established. The plan is tracked via milestones and tasks. Metrics can be calculated indicating how far ahead or behind the project is in schedule and cost.

In Agile, a plan is established, but responding to change is valued more highly than following that plan. Understanding this value is important to understanding Agile. This also makes following Agile difficult because the plan is expected to change. And if the plan is always going to change, how do you budget? How do you know if you should go ahead with a project? Will this project have a positive return on investment? How can you know the answer to that question if the plan will only be the plan until it inevitably changes?

Asking those questions usually ends up in killing an Agile initiative or adding a lot of constraints or checkpoints. I don’t have a definitive answer for how you go about answering those questions, but I have enough experience with traditional project management to know that having a full plan at the start of a project gives a false sense of security. Change will occur whether you have a traditional plan or an Agile plan.

engineer your life

If we were to rewrite the second stated value slightly, where could you personally apply the values of the Agile Manifesto (agilemanifesto.org)? What would need to change for you and your team to adopt these values?

Individuals and interactions over processes and tools
Working product over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan