Tom
back to blog...
values and the agile manifesto ⬇️
I'd like to say what I value, but the agile manifesto does such a good job of it, so I will just describe what it means to me and add a few things.
values ⬇️
Values should prioritise one thing over another, which is how the agile manifesto is written.
It seems the vast majority of people working in Tech nowadays don't know that capital "A" Agile is not the same as "agile" ie. to actually work in an "agile" way. Agile has become a way for people to sell consulting to companies wanting to evolve their ways of working. But Agile™ is rarely agile as it is described in the manifesto above back in 2001. It has become a buzzword.
And broadly speaking, people have taken it to mean "don't think too much about stuff, just do things and then reflect on them". Or maybe it's more process oriented and is something like "follow the 'rules' of <insert Agile methodology> and your software will be great and business prosper".
agile manifesto ⬇️
But I keep coming back to it and resonating with it even more. There is so much knowledge distilled into it. But it is also nuanced and can seem anodyne to someone who doesn't know much about Tech. "Of course I value Individuals and interactions!" I hear you say.
So I will describe what it means to me and what I value. Let's take a look at the manifesto's main statement in full:
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.
Before looking at the four values, the two contextualising comments at the start and end already tell us a lot.
contextual comments ⬇️
The opening contextual comment says that better ways of developing software are being uncovered through "doing it" and "helping others to do it", it is not through naval-gazing or armchair-architecting or managing teams but through actually developing software. That is to say that while there is value in a lot of the "overhead" roles, if we want to uncover better ways of developing software there is more value in "doing it".
The closing contextual comment for me summarises why this stuff is so hard to get right and what the vast majority of people misunderstand about agile and systems thinking. For me, it is the biggest epiphany I had in systems thinking: every system has trade-offs and bottlenecks, it's about choosing which ones you want in order to optimise for certain outcomes; therefore nothing comes for free in your system - every process you have is another process you do not have, every way of working is some other way of working you're not following, the culture* you have is some other culture you do not have...etc. *In fact, culture is something best stated as what it is over what it is not!
So what does the closing comment say? It acknowledges there is value in the items on the right: processes and tools have value, documentation has value etc. But it is doing what any good definition of a value does: values one thing over another. And this is where the misunderstanding arises - these things are in tension! You can do a bit of both, sure, but you cannot do both of these things to the max.
If you value Individuals and interactions over processes and tools that means you would take a quick conversation over asking someone to fill in a spreadsheet, it means that the last conversation you had about a thing is the truth over what it says in some issue tracker, it means that you would go and speak to another person in another team about a thing over setting up a meeting with all possibly relevant people or perhaps raising a ticket in a week-long queue to some "team" in a basement (or even just across the room!).
So what do most people get wrong? Yes, there is value in the things on the right. Writing docs will feel useful because there is some value in it. Having a plan is often useful if not only to force us to think. Etc. But there is more value in the things on the left, and they are at odds with each other. So yes, we can plan things but in light of new information there is more value in "responding to change" over "following our plan". Yes, we can have some docs but we cannot expect them to be the source of truth or imply that our software does what the docs say, because they can only ever be secondary to the code itself. So there is more value in spending time writing good software over writing good docs that explain what the software should do. Etc.
individuals and interactions ⬇️
...over processes and tools. The first value is my favourite. Work is so much more fun when we work as a team with a high amount of trust because ultimately everything comes down to trust.