If I could make one change to the Agile Manifesto, it would be this:

Recently, I attended an Agile workshop for new employees at my company. There, the manifesto and principles of agile were shared.

Here’s the manifesto for those who haven’t seen it in a while: Agilemanifesto.org

It seems that the manifesto has stood the test of age. Although I haven’t seen any changes to the manifesto, I admit that I haven’t looked for posts trying to change them. My point is that the manifesto still has relevance and is being promoted 18 years after it was written.

However, one word is bothering me.
This word means “Working”.

There’s the second value, “Working software rather than comprehensive documentation”.

This word has a problem for me because it implies “correctness”
This is something I have heard people say in context of the manifesto. They always refer to “correctness” as “It’s essential that the software works correctly” and “It’s important that it’s correct based upon the requirements.”

Many people think that this line is the most related to quality. The manifesto does not mention “Quality”. It talks about software that works! !”

This idea of “correctness”, also seeps through to agile principles. Principle #3 states that you should deliver working software frequently in a few weeks to a few months with a preference for the shorter timescale.

Here’s the problem: Quality is not all about “correctness”. Quality is more about “goodness”.

Rightness = Goodness

Although your software may be perfectly in line with expectations, it could still be difficult to use. This is a sign that it’s not good software. Your software could have glaring problems due to unexpected items that are not included in the requirements, ACs, or other specifications.

Testing is about finding out information about the “correctness” of software from the perspective of specs/requirements and the “goodness” of software (based upon the actuals of software, from multiple perspectives – customer/business, teams, stakeholders, etc).

When it comes to quality, I think “goodness” is more important than “quality”. This is what I would encourage teams to look at when it concerns their perception of the quality of their software.

With this in mind, if there was one thing I could change in the agile manifesto it would be the word “Working” to “Great”.

“Great software over comprehensive documentation”.