Agile vs Fragile: Quality Matters

Part 8 in a series of 17. To start at the beginning, first read Agile vs Fragile: A Disciplined Approach or an Excuse for Chaos.

The seventh Agile principle is all about quality.  It says that WORKING software is the primary measure of progress.  I spoke with a noted Agile coach and keynote speaker at a conference recently.  We were having a discussion about the fact that the words quality and testing don’t show up anywhere in the agile manifesto or in the 12 principles.  The point of his argument on why it wasn’t there is that the manifesto wholly implies this in the phrase “working software”.  While I completely agree with his premise, the perfectionist in me wants there to be a much more explicit reference to testing and quality.  I agree that in order to verify that you have working software, you must have adequately tested to verify that it was, in fact, working.  I also agree that the word “working” means fully functioning and quality.  The problem I have is that it is far too easy for Fragile teams to declare that whatever they produce is working as defined by them. It is also easy for Fragile teams to eliminate testing to meet timelines as it is not a pronounced part of the manifesto or in the 12 principles.One of the key differences between an Agile team and a Fragile team is the definition of what “done-done” is.  In a true agile team, the definition is well understood in the form of completed stories and expected level of quality.  In a Fragile team done is whatever the team, or worse, leadership decides.  When the clock expires, the code goes out.  One of the major misunderstandings about Agile is the concept of a sprint.  In Agile, the sprint is a way to compartmentalize a body of work (one or more user stories) that will be delivered as value to a customer.  One of the key parts of this principle for Agile is that if the user story is not ready, it doesn’t go out.  The sprint boundary is not seen as an absolute boundary, but a target.  In a Fragile project, the end of the sprint is absolute.  Code ships no matter what.

In the next installment of the blog we will talk about the 8th Agile principle. In the meantime…Keep on testing!