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!
Did you enjoy this article? Help spread the word by sharing:
Engage in the conversation and leave a comment:
About Brian Copeland (19 articles)
With over 25 years of senior level experience in the software development industry specializing in organizational transformation and development, Brian has been instrumental in the testing of critical business systems, from mission critical applications to commercial software. Mr. Copeland’s career has included 10 years as the Test Operations Manager for the Titan II, 34D, IVA, and IVB programs, managing both flight and ground software-testing facilities for Lockheed Martin. Mr. Copeland also served as the Sr. Manager of Quality Assurance for the shared services of Deloitte & Touché, LLP. His diverse experiences range across the aerospace, medical device, title insurance, legal services software, big four accounting firm, and banking industries. Brian led the global testing organization for The Nielsen Company, overseeing the successful transformation of the testing function made up of over 750 testing associates. Mr. Copeland has been a key-note speaker at the International Business Forum, and has been a featured speaker at HP Software Universe. Brian is a past president of the greater Cincinnati International Institute of Business Analysts (IIBA), and holds an ITIL v3.0 Foundations and RCV certifications.