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”.
Dan Ashby 
“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
LikeLiked by 1 person
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. 😉
LikeLike
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).
LikeLike
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.
LikeLike
In my opinion I think the first point regarding agile manifesto could be changed :
#Individuals and necessary timely interactions over processes and tools
Too much time on interactions is not healthy for the agile team.
Also the interactions needs to be prioritized if you need more of it. So the high prio interactions should happen first so that team can move ahead in working pace.
It is responsibility of each team member to ensure that you are not taking too much time for interactions inhibiting day today work.
Thanks for hearing out the opinion
Feel free to share your thoughts on this.
LikeLiked by 1 person
I couldn’t agree more. Working software needs to be high quality software. I also believe that in order to have working software you need to have some level of documentation. It doesn’t have to be comprehensive, but it also means that there has to be enough so that all team members are on the same page and can have some guidance in terms of what needs to be developed and tested. I have had more disagreements from developers who point to this one item on the manifesto than any of the other ones.
LikeLiked by 1 person
Hi,
Thanks for sharing the nice information.
It’s a pretty nice and valuable piece of writing.
Your information is very helpful thanks those who want to take online it certificate programs
LikeLike