Archive

Monthly Archives: March 2013

Three Books

March 8, 2013
Agile, Product development, Software development
11 Comments

Three Books

I like books. You may have noticed I read some, and I generally learn much from doing so. Well, actually that’s not really true. I don’t learn much. I fact, I hardly learn anything at all.

Rather, I find many ideas. And more specifically, parts of ideas. Fragments. Snippets. Crumbs. Slivers. My brain then somehow weaves these splinters together into more concrete, joined-up ideas. Things like covalence, emotioneering, FlowChain, Javelin, and so on. The words “synergy” and “synthesis” spring to mind.

Aside: I just wanted to mention that I haven’t bought a dead-tree book for at least two years. And it seems unlikely I ever will again.

That being said, I’m fairly sure that folks can learn things from books, or at least gather some fragments of some ideas which might prove useful. Although I do accept that some folks have a “learning style” at odds with book-learning.

“People who ‘read little’ are ripe for becoming process zealots because they only learn one thing & believe it is everything.”

~ Jim Benson

Many folks have written copious amounts about the pros (and cons) of book-learning as it relates to software people. See, for example,

Tweet by @anthonycgreen:

@flowchainsensei ‘Programmers Don’t Read Books — But You Should’ http://t.co/fRhWBN6XNK – @codinghorror

This post is not so much an addition to the oeuvre, but rather an attempt to recommend just three books – as a starting point for software folks who may not have had the opportunity or motivation to begin their reading on the subject, as yet. This post is also in the way of thanks to all the folks who responded to my recent tweet:

“Which three books would you choose to recommend to software folks who have read very little, yet want to improve?“

My Top Three

Note: My choices here are tempered by the nature of my imagined ‘audience’; not just programmers, coders and testers, but everyone involved in software and product development. I very much agree with the sentiment expressed by Jim Benson:

“If we in software only read books about software, we will build crappy software.”

~ Jim Benson

  • Principles of Software Engineering Management ~ Tom Gilb (Dead tree only)
    A primer for all aspects of software development work, most notably quantification of e.g. stakeholders’ needs (a.k.a. understanding value, requirements).
  • The Goal ~ Eliyahu M Goldratt (Kindle version available from e.g. the USA)
    An accessible and entertaining (?) entry-point into the world of Theory of Constraints and – indirectly – Systems Thinking.
  • Zen and the Art of Motorcycle Maintenance ~ Robert M. Pirsig
    Contextualising the whole Quality thing.

Honourable Mentions

Given that software development and product development – are disciplines largely, if not entirely, about people; people working together, people collaborating, people learning together, etc. – maybe I should also mention some people-related books too.

  • Nonviolent Communication ~ Marshall B. Rosenberg
    My choice for “best book of all time”. At least, given its life-changing influence on me.
  • Drive ~ Dan Pink
    “The surprising truth about what motivates us”. Surprising indeed, for many.
  • The Five Dysfunctions of a Team ~ Patrick Lencioni
    A compelling model for teams and team effectiveness. Also a great entry point into the Lencioni canon.
  • Peopleware ~ Tom DeMarco and Timothy Lister
    The granddaddy of software-oriented people-related books. I regularly find myself incredulous at the number of folks who say they haven’t heard of this one.

Top Three Programmers’ Books

Many of the folks who so kindly responded to my tweeted question seem to have answered in the context of programmers. I’ve consolidated the many recommendations into the following list:

Honorable mentions

Others’ Top Three

Excluding the titles which I have more or less arbitrarily included in the above “programmers’ books” category, here’s a list of the other books folks recommended (no clear Top Three emerged):

Any books you feel we missed out? Please do mention them via the comments.

– Bob

The Agile Path to Quality

March 6, 2013
Agile, Product development, Software development
9 Comments

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