#3 in our list of the Top Characteristics of an Agile Organization is Quality and Faster.
Ryan and I have been talking about quality and faster as necessary components of an Agile organization for awhile. A non-Agile view of a successful organization would have us believe that pushing more and more features into a release and to the market necessitates a loss, or at least reduction or great variance, in quality. In an Agile organization, the thinking is quite the opposite.
Curiously, when we speak of quality and faster inside Rally or with clients, we talk about each being indispensable to the other.
For a traditional, non-Agile case study, let’s look at the RCA case study Ralph Aguayo brings up in his book “Dr. Deming: The American Who Taught the Japanese About Quality.” At its height, RCA’s business model focused on getting as many televisions into the hands of consumers as possible. (Did your family have an RCA T.V. when you were growing up? Mine did!) Quality was secondary to the savings RCA could make from cheap components and speed of product to market. Cheap and fast meant greater profits. Well, as it turned out, no…

Nipper on RCA's first color tv set - the CT 100
Unfortunately for RCA, their model began to crumble when television sets started being returned due to defects, lots of them all still in the warranty period. The cost of attending to these faulty sets ended up being as much as 25% more than the cost of manufacturing the existing set.
Do you have a similar situation in your software product delivery? Are you trying to get profits by pushing features out with “defective parts” because they are “cheaper”?
And to throw another wrench into the works, are you taking so long to get these feature sets pushed out that you have too much of a delay in your feedback to find either the defects or the value of the features you pushed? In other words, is your emphasis on speed, at the expense of quality, coupled with very large feature-rich releases, exactly the wrong way to create greater value and fewer defects?
In an Agile organization, the entire organization concentrates on value delivery and quick feedback on that value.
That is, “are we delivering the right features to the market?” In turn, a real Agile organization understands, “there ain’t no such thing as a free lunch,” and they do increase throughput without the traditional expense of decreasing quality. Defects held in check through a “stop the line” mentality free-up the organization to always respond to value feedback information faster. Think about RCA. If your scarce resources are tied up in managing defects and “returns,” they can’t be working on new feature sets. Or the feature sets delivered are being pushed on defects not yet resolved.
And so, the notion of “quality and faster” is not so counterintuitive as we may have once thought.
We need faster and faster feedback loops in time-to-market in order to continuously improve our ability to deliver quality (defect-free and valuable) features back to the market. Symmetrically, we need higher and higher quality features that are not defect-ridden or dubious in value in order to respond ever faster and more innovatively to the market.
See our previous coverage of #10 Work/Life Balance, #9 Being a Servant and Leader, #8 Sustainable and Successful, #7 Contributing to the Community and the Company, #6 Collaborative and Smart, #5 Bottom-up and Top-down Decision Making and #4 Flexibility and Rhythm. Stay tuned for #2 “Creating Your Own Reality” and Corporate Vision.

Jean,
I completely agree with your post and am glad to see this kind of thinking increasingly start to penetrate software development discussions (particularly among Agile and/or Lean advocates).
As you imply, the concept of “Quality and Faster” has been well established for decades in manufacturing (though not always widely adopted) thanks to the efforts of Deming and others. My father, William G. Hunter (who incidentally wrote a chapter in Deming’s book “Out of the Crisis”) co-founded the Center for Quality and Productivity Improvement in the mid 1980’s. See http://cqpi.engr.wisc.edu/ The idea of “Quality and Faster” has been fundamental to the Center’s mission since then.
Increasingly, development teams are realizing they can succeed at “Quality and Faster” by adopting efficient and effective tools and methods (including Agile methods and Rally tools). Lesser known is that they can also make their “Quality and Faster” efforts even more successful by intelligently designing experiments (using applied statistics-based principles taught by people like Deming and my dad), seeing what works well, and making data-driven decisions. A great 22 minute presentation on this topic can be found at: http://testingjeff.wordpress.com/2009/06/24/controlled-experiments-to-test-for-bugs-in-our-mental-models/
Lastly,combining both of these points above (e.g., (i) proven tools and methods, and (2) Design of Experiments methods in particular), we can drop the middle word in the phrase for a moment and achieve “Quality Faster.” Through better test case identification in software testing Quality Assurance, test design tools like Hexawise can identify test conditions to be executed in test cases through the use of Design of Experiments methods that have been refined over 30+ years. Doing so, generates a smaller set of tests that will achieve higher coverage (and higher quality/thoroughness) during testing. That’s what the Hexawise test design tool does.
- Justin
Justin,
Thank you for a truly amazing and affirming response. You are right: drop the middle word and you get “Quality Faster”. So interesting how the software world (especially in larger organizations IMHO) continue to cling to the notion that these two words are oxymorons. The work your father did with Deming was brilliant, evidenced by the fact that it still resonates so deeply today. In fact, I think it is having more and more impact. I see this in the software Kanban movement.
Thank you for sharing the links and the guidance. I am so grateful.
Best regards,
Jean
[...] #3 Quality and Faster – Top 10 Characteristics of an Agile Organization | Agile Blog: Scaling … [...]
What an excellent post. It should have been more comprehensive to exclude some general reactions.
While the agile methodologies encourage the team to deliver things fast, the concept of “feedback loops” (at least in my individual experience)by far remains non-agile in the following ways:
1. Means and ways to collect feedback is not strategic
2. Feedback consolidation, often times, is non agile
3. Factoring the essence of feedback is not as fast as a direct change that a business analyst asks for
4. We don’t know if we are responding to the right feedback (a classic example is varied thoughts on usability)
But again, I have faith in the postulate that “design of experiments” will supposedly address a major part of the concerns.
Some marketing intended to hint at my tool – Pairwise Test Case Generator at http://www.TestersDesk.com targets “quality and faster” problem in its own way. It creates a very small number of test cases for software testers, covering all the pairs of values of all the test parameters.
Besides, there are a lot of other tools provided by the free online toolkit at http://www.TestersDesk.com in the areas of Software Test Design and Test Data Generation (which are not yet agile, IMHO).
Thanks,
Ashwin.
———–
Ashwin Palaparthi
Founder
http://www.TestersDesk.com