The Agile Path to Quality
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”
~ FlowchainSensei
cf Covalence
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
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
Intrinsic motivation describes the motivation found in doing things – such as work – out of interest or the joy derived from the task itself.
In Summary
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)
– Bob
Further Reading
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
Think Different
I’m with you on most of this, except for the bit you skipped over: Process.
Process is just another way of saying: standardisation. At the risk of egg-sucking instruction, the best process is derived from existing practise, synthesising what the most skilled team-members do anyway and ensuring that everyone works that way. It’s another way of saying: Current Best Way/Hypothesis.
And of course, updating it as experience/experiment demonstrates better ways.
When you have new situations, sure, use the skills & experience of the intrinsically motivated team to *find* a new way, but there’s an awful lot of “ah, one of *these*” in between the “hmm that’s new” moments.
Oh, also Management. Done right (yes, I know, rare, and for “Mgt as usually practised” I’m agreeing with you entirely), Management’s *main job* is to set up a runtime environment enabling this kind of standardisation and learning to happen hand in hand.
So while clearly your Agile Way to Quality is superior and disposes of the destructive extrinsic motivation and violence, there’s a risk of baby being thrown out with the bathwater.
Thanks for starting the conversation. I’ll update this first version on the points you mention. Hopefully it will become clearer.
– Bob
Having thought about the question (of process, a.k.a. standardisation) further, I’m finding myself at odds with your position. One key reason I coined the term “rightshifting” in the first place was so that I – and others – could get away from the word – and concept of – “process”.
I don’t actually believe that process (in the sense of standardisation) contributes much, if anything, to quality. Let me qualify that by stating the context for my remark: software development, product development and other forms of knowledge work – where variation is often both economically and psychologically desirable – unlike, say, in manufacturing.
I also worry about the violence (coercion) implicit in the idea of standardisation, as you appear to conceive it: “ensuring that everyone works that [the same] way”.
The one aspect of “process” in which I *can* find some utility is the opportunity it affords for thinking about the way the work works, i.e. as a separation of concerns from the work itself.
Your view?
– Bob
Bob,
Although I agree with your main point about two paths for quality, I believe there is a third way shown by the Toyota Production System. What about aiming for quality and worker freedom by respectful management from the top?
The advances of TPS in their history demanded intelligent leadership, and worker empowerment. Both led to their success. I believe the approach you mention, and also TPS / Lean approach are valid to achieve quality.
Cheers,
Joseph Hurtado
Founder Agile Lion Institute
Web: http://www.AgileLion.com
Twitter: @AgileLionInst, @JosephHurtado
Thanks. I concur in general, although am very wary of extrapolating from Manufacturing (TPS) to the IMO very different context of software and product development (TPDS, etc).
– Bob
Pingback: Five Blogs – 7 March 2013 | 5blogs
Pingback: Jennifer Sertl – Lean Impact | changearc
I just love this piece Bob! Thank you
Pingback: Nine Aspects Of Top Developers | HiveMindNetwork.com