If I could change one thing in the Agile Manifesto…

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:

Agile Manifesto, taken from agilemanifesto.org

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”.

5 thoughts on “If I could change one thing in the Agile Manifesto…

  1. “Working” as a word is a logical fallacy.
    Historian’s fallacy:
    the assumption that decision makers of the past viewed events from the same perspective and had the same information as those subsequently analyzing the decision. This fallacy frequently arises when a programmer is working with code

    Like

    1. Thanks! That helps strengthen the point perfectly re why it’s important to update manifestos as such – contexts change, and new perspectives arrive. So refactoring the words helps to remove ambiguity further. 😉

      Like

  2. I cannot agree that the term “working” application should be replaced with something another because for startups mostly the quality of the released product is not important. If developers often fill up the consumers with improvements, then users “eat” them also without any quality.
    Two articles say that the term “correctly” can’t be used in testing: “Uncorrectly correction” (https://tjupka.blogspot.com/2018/09/uncorrectly-correction.html), “Храни меня..” (https://tjupka.blogspot.com/2018/12/blog-post_19.html).

    Like

    1. Really? You don’t think that startups should care about quality??
      I can’t believe that.
      Quality matters. Probably moreso for startups. You need a high quality idea, or your dead in the water. You also need a high quality implementation, otherwise your competitors will defeat you. You also need high quality customer feedback methods and opportunities in your software, and high quality observability within the software, so that you can get the feedback you need to improve your idea and solution.

      Like

Please leave a comment!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s