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 should prioritise one thing over another, which is how the agile manifesto
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
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
- 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
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
through actually developing software. That is to say that while there is value in a lot of the "overhead"
if we want to uncover better ways of developing software there is more value in
The closing contextual comment for me summarises why this stuff is so hard to get right and what the vast
of people misunderstand about agile and systems thinking. For me, it is the biggest epiphany I had in
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
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
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.