The Four Values of Agile
Traditionally, managing projects generally meant we had to completely understand what we were doing up-front at the start, do it, and finish it.
This article is part of a series. Go to the Contents page.
We would plan out a project, and follow it. Change from the plan was considered a risk, and something to be avoided. Why did we get it wrong at the start? Why didn’t we know? We should have planned more! How can we avoid it happening again? And so on.
We produce Gantt charts. We create detailed documentation. We spend a considerable amount of time producing them, discussing them, changing them. Meetings are held to make sure we are on track, following the plan. We create baselines, and inquisitions are held when delivery is not adhering to the plan.
We become a slave to the plan.
We maintain projects logs, and spend time reviewing them. They get longer, not shorter. At the end of the project, we discuss why the plan was wrong, and how could we have planned better.
With the introduction of more complex and uncertain projects in an age of IT and Information, Agile has brought a different way. When requirements are more uncertain and less defined, when projects are more complex, when change is frequent and welcomed. This is where Agile has proven it’s worth.
This is a significant shift. So, what does it mean to “Be Agile”?
The Agile Manifesto
The history of how a meeting in February 2001 came about is interesting, along with key Agile activities, but we will fast-forward to this meeting which was held by 17 industry leaders. They produced a simple manifesto that feeds in to all things Agile. In fact, so short, we can place it here.
Whilst simple and short, understanding the ideas is important as they are the foundation from which all else is influenced.
An important point, which is always raised, is that “it says software”. It does. But this represented the focus of the meeting in 2001. Please understand that Agile is now used in everything from building a bridge to producing company strategies.
When you see “software”, think “solution”.
The Agile Manifesto is as follows:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
* 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.
And that’s it! There are also 12 principles, equally concise, but we will park them for now until the next article whilst we consider why we value the left side of the following, over the right side of the following.
Myths of Agile
There are many myths around Agile. We’ve already addressed “it’s only for software”. So let’s address four more, and will cover a full set up 12 in a future article.
- “You do everything how you want”
- “You don’t do documentation”
- “You do what you want”
- “You don’t plan”
We’ll answer them by looking at the four values in a little more detail. And this is where it’s very important to stress the word “over” in the four values.
Individuals and interactions over processes and tools
Processes and tools are important, and I’ve never known a project without them. But they are not as important as the individuals on a project, and the interactions between them.
Microsoft Excel does not write a spreadsheet. A person uses a tool called Microsoft Excel to produce the spreadsheet. They could also use other tools. But it’s the person, that is creating the spreadsheet.
Agile sets the focus to be on the individuals of a team, and how they interact. Ultimately, projects are about people.
Processes and tools, therefore, are selected to support the people and their interactions.
Working software over comprehensive documentation
Documentation is important. But suitable and relevant documentation can be produced when it is required, allowing the working software (solution) to be the focus. Documentation has no value in itself. Working solutions do. Working solutions with sufficient documentation is the goal.
Spending months on a Project Brief, a High Level Design, a Low Level Design (and so on) can traditionally take months, and the customer charged, and yet nothing of actual working value has been produced. Instead, we produce documentation that is needed, as needed, to be able to start producing working software quicker.
Customer collaboration over contract negotiation
Contracts are obviously important. Whether commercial or not, a contract is almost certain to exist. But, traditionally it would focus on the scope of the project. What is in scope. What is out of scope. The scope becomes fixed. The effort can be Time and Materials, or Fixed Price with contingency. A change request process is agreed to handle variances in effort and resources, and time. The contract is typically written to protect both parties from a change in effort and time.
Agile flips this, and this will be covered in more detail in a later article where we consider how we can “sell” Agile.
We are looking for a collaborative contract. One where we can gather enough information to be able to estimate effort and cost, with the freedom to adapt as more information is uncovered during the project. Effort and time becomes fixed, with scope being flexible.
It literally flips the traditional contract on it’s head. This does not mean we will not know when we are finished, or that we are likely to not get everything done. When we do our initial planning, we will work with the customer to understand how we can deliver things that we must deliver, and the things that we should deliver.
Responding to change over following a plan
Not following a plan is a common myth. In fact, the opposite is true.
We plan before starting. We understand the vision. We produce roadmaps. We identify as much as we can to estimate effort and time from which we can then plan the project duration and the team required (to deliver the must-have’s and should-have’s). We engage with the customer frequently. We are always considering how we will deliver what is of most value to the customer, by reviewing priorities. We meet daily as a team to review the work to see how we can achieve our targets.
In short, we plan all the time.
Summing Up
The Agile Manifesto is not a set of rules to which to adhere. It is actually more powerful that that, in that it guides us to take into account the values when doing anything.
In short, we focus on the people, the product, co-operating and remaining flexible.
We focus our efforts on the left side of each of the four values.
However, and this is key, using Agile terms and holding Agile ceremonies (meetings) might be “Doing Agile”, but it is not “Being Agile”. This will not produce the benefits of having the Agile mindset, which is ultimately what it means to “Be Agile”.
This is where it is useful to be aware of the 12 principles of Agile, which is the topic of the next article.
