I recently attended an Agile workshop for new joiners at my company, where as part of the workshop, the agile manifesto and principles were presented.
For those of you that haven’t seen the manifesto in a while, here they are:
The manifesto seems to have stood the test of time. I’ve not seen any edits to the manifesto, although admittedly, I haven’t really looked for posts that have tried to change them. But my point is that the manifesto is still very relevant and promoted today, 18 years on from when they were written.
But, there is one word that is causing a niggle for me.
That word is “Working”.
Right there – the second thing listed as a value: “Working software over comprehensive documentation”.
My problem with this word, is that “working” implies “correctness”.
I’ve heard many people talk about this in the context of the manifesto and they always mean “correctness” – “It’s important that the software works correctly” or “It’s important that the software is correct based on the requirements”.
And many people associate this line in the manifesto as being the one that relates most to “quality” – “Quality is mentioned in the manifesto! Look, it talks about working software!!”
And this idea of “correctness” also trickles through to the agile principles too: Principle #3 is ” Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” (you can see it here: agilemanifesto.org/principles.html)
But here’s the thing, when we think about quality, “correctness” is only a part of it. A bigger part of quality relates more to “goodness”.
Correctness != Goodness
Your software can be completely correct in terms of it aligning with the expectations of how it should work, but could still be horrible to use, meaning it’s not good software. There could be glaring bugs in your software based on unexpected things that are completely missing from the specs, requirements, ACs, etc…
Testing is about uncovering information about both the “correctness” (based on the expectations from the perspective of the specs/requirements) as well as the “goodness” of the software (based on the actuals of the software, from many perspectives – customer, business, teams, stakeholders, etc).
Arguably, “goodness” is a more important measure when thinking about quality. It’s what I’d definitely promote teams look at when it comes to their perceived quality of their software.
So with this in mind, if I could change one thing in the agile manifesto, I’d change the word “Working” to be “Great”:
“Great software over comprehensive documentation”.