Over a series of five articles, I will look at the Agile Values as described in the Agile Manifesto and why they are worth thinking about. Before diving into each value on its own, this first article is about why values are useful at all. The question about which foundation you build your product (or project, team, company!) on has a big influence on every aspect of your result. It is worthwhile to take the time to re-think decisions made and setups chosen.
Importance of Values
The “definition of value” has two aspects which is important in Software development: A monetary aspect (“the value of this object is $10,000”) as well as importance (“I value your input”). Perception of value is a huge part in motivation. It also is a critical part in communication – if two people have different value-sets it can be difficult for them to agree on an action as their desired outcome differs. Situations like these are obvious when there is a marketing manager talking to a developer. They become more complicated when it is two peers talking about a topic. Examples:
- Two developers talking about testing depth (“I value automated quality assurance and long-term support” vs “I value fast, short-term output”).
- Two analysts giving feedback on a campaign (“Terrible. The invest will not show any return this quarter” vs “Excellent. The campaign managed to attract slow converting, long-term users and will increase our revenue per year beginning in six months already”).
- Two Product Managers argue about a feature (“This is terrible! It only aims at our churning users and ignores our most loyal customers!” vs “This is awesome! It will help us grow our userbasis by preventing churn!”)
All examples above are from situations, where the values are based on individual judgment. The same situations can occur between teams and management though. This is where development values come into play. They help to align multiple individuals behind a common goal and they give focus on what is important.
Just like the two meanings of value, the reason you should think about the values you set up and communicate is twofold as well: Transparency and reflexion. With transparent values, you allow all participants to work together on the same goal and to point out parts of the workflow which are against your values.
Note that this statement is true independent of the inherent usefulness of value. If one of the values established is “everything we do we do to milk our user as fast as possible” then all three examples would look completely different – and the two colleagues would be able to work together.
The Agile Values
The values wich will be discussed in the next articles focus on how to build software. They were first phrased in 2001 and even now they still hold true. This is because they focus purely on an abstract but clear prioritization. If the question is “should we do A or B” they give a good orientation and can help to (re-)focus on the goals and what is important to create software. The Agile Manifesto in its full form is simple and to the point. It gives a lot of freedom to its readers and demands a lot of interpretation. This is also the reason it is still as important today as it was nearly two decades ago.
Within the Agile Manifesto, there are four values formulated which form the foundation for this series:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
In addition to those values it says: ” That is, while there is value in the items on
the right, we value the items on the left more.”
That’s it. In those four incomplete sentences is everything that is needed to create good software – even today. What to take away from them and how you can improve your product through them is up to you though. I hope that in the next few articles we can find some ideas on where to start.