The Agile Path to Quality
Photo Credit: Skinnyde
I’ve been looking for a paper, article or blog post explaining the Agile approach to quality, but having failed to find something suitable (as yet), I decided to write a post myself. So here it is.
A Licence to Hack?
Over the years, many folks I have talked with regarding Agile software development have expressed concerns that such approaches (XP, Scrum, Kanban, etc.) are, in essence, a license for hacking. In my view, nothing could be further from the truth.
But I will agree that many so-called Agile adoptions, being merely the thinnest of veneers, rather than a change of any substance, can lead to a situation where formal controls, etc. (i.e. the “conventional path to quality”, see below) get abandoned without the adoption of any viable alternative “path to quality”.
Starter For Ten – What is Quality?
To get the ball rolling, it might be helpful to define what we (I) mean by “quality”. Setting aside – but not ignoring – Christopher Alexander’s Quality Without a Name (QWAN), my working definition of quality comes from Jerry Weinberg, (with hat-tips to Marshall Rosenberg and Tom Gilb):
“Quality is meeting the needs of some several collections of people”
See also: Lesson 1 The Definition(s) of Quality
Different Paths to Quality
So what viable alternatives could there possibly be to formal controls, strict governance, imposition of standards, compliance to defined processes, and so on?
Michael Kennedy wrote a great book, “Product Development for the Lean Enterprise“, which explores this question at length, and provides some illuminating answers.
But in case you don’t have time to read it, my take on the “agile quality” question boils down to this:
- Conventional “path to quality” = Extrinsic motivation + process + violence + management
- Agile “path to quality” = Intrinsic motivation (derived from e.g. purpose) + skilled workforce (mastery) + nonviolence + self-organisation (autonomy, in the Dan Pink sense)
Maybe we can begin to appreciate the gulf between these two perspectives? And the impossibility of trying to travel both paths at the same time?
Aside: In Rightshifting terms, we might describe conventional beliefs about quality as congruent with the Analytic mindset, and agile beliefs about quality as congruent with the Synergistic and Chaordic mindsets.
Effectiveness = f(Mindset)
Aside: To understand the Agile quality question, I believe we’re generally much better off reading about quality issues in the context of Lean Product Development (but NOT e.g. Lean manufacturing), rather than say software development or TQM.
Extrinsic motivation includes, on the negative side, things like fear, obligation, guilt and shame, and on the positive – or, rather, less negative – side, rewards, bonuses, payment by results, competition, applause, etc.
Intrinsic motivation describes the motivation found in doing things – such as work – out of interest or the joy derived from the task itself.
To sum up, then. An often-overlooked, and in practice, seldom-realised benefit of Agile software (or product) development is the opportunity for adopting a more effective path to quality. And just as with Agile adoption more generally, being able to reap these benefits involves a seismic shift of assumptions, i.e. from an Analytic view of the world of work, to the Synergistic viewpoint. That’s never going to be quick or easy.
“Two paths diverged in a wood, and I—
I took the one less traveled by,
And that has made all the difference.”
~ Robert Frost (paraphrased)
Toyota Traditions – Web page
Exploring the Link Between Intrinsic Motivation and Quality ~ Captain Steven M Christy
Product Development for the Lean Enterprise ~ Michael Kennedy
Lean Product and Process Development ~ Allen Ward
Zen and The Art of Motorcycle Maintenance ~ Robert Pirsig
The Timeless Way of Building ~ Christopher Alexander