Demings 14 Points and Agile Development

Source: Deming, W. Edwards. Out of the Crisis, The MIT Press, 1982.




If you keep your ears open in any agile discussion, you can hear the echoes of W. Edwards Deming in the various practices that comprise agile development. W. Edwards Deming was a visionary man whose practical reformed wartime America and post-war Japan.

The agile values (to soon be re-presented here) include driving out fear, removing barriers to pride of workmanship, continuation of eduction, sharing knowledge as on-the-job training, and retrospectives to improve constantly and forever. You will also hear the echoes of "institute leadership", "adopt the new philosophy", etc.

When I revisited these values, I was surprised to find "cease dependence on inspection." I suppose fifteen years ago when I read up on Deming originally I must have seen and read that admonition, but I must have blocked it out. Maybe it was because I tended to read it from the point of view of QA professionals who were more comfortable with the other principles.

It is a simple admonition, but not one that is easy to follow. It is certainly easy to simply stop inspecting/testing/reviewing. But that's not quite what it says. It says to eliminate our reliance on inspection by building quality into our products throughout the process. Deming did not recommend piling scrap on crap, but recommended instead that every station in a process would measure and evaluate its input and its products. This is where the idea of stopping the line came from. If we receive only input of the highest quality, produce results only of the highest quality using the simplest process of the highest quality, then post-production inspection becomes useless.

Let's say that again. If we honestly can assess that we are building things well by checking them early and often, then tail-end QA becomes unimportant. If it becomes unimportant, then we can stop doing it. That is an exciting proposition, even if it does require us to take on different procedures than we would normally follow.

While the Agile methods are not typically considered to be a school of Deming's Total Quality Management, it does acknowledge that speed is primarily caused by quality. In this sense, quality is not something you trade off for speed, but something you increase to get speed.

Oblique Strategies

Thanks Tim for reminding me of the Oblique Strategies card decks. I am tempted to try to pick up a set--they are wonderful collections--but it'd probably be a lot easier to simply create my own from the text listings on the site.

Eno and Schmidt used the Oblique Strategy cards in collaborating on Eno's classic 1977 album Before and After Science. (Before and After Science is one of four stupendous albums that Eno made in a row before abandoning--for a while--vocal "pop" music in favor of soundscapes. Before and After Science is my second favorite, behind Taking Tiger Mountain By Strategy).

Some of the cards are strictly constrained to recording an album ("feedback recordings into an acoustic situation") but others are applicable to any circumstance: "Emphasize differences," "emphasize repetitions," and "emphasize the flaws." Or, "listen to the quiet voice."

I can imagine randomly pulling an Oblique Strategies card to help us look at things in a different way on an agile project. They could act as effective tools for keeping retrospectives (and perhaps other events) lively. Some of the cards are quite interesting when you think about both their musical application and adaption in a software development process: "Look closely at the most embarrassing details and amplify them." In a fashion, that is what the lean concept of "stop the line" is about.

What might you do with "Take away the elements in order of apparent non-importance?"

The Magic of Cards

I was exposed to the XP idea of using index cards as a preferred tool back in 1999. For a while, I still preferred whiteboard work to cards, just for the large visibility. But I quickly came to recognize the simple power of things like deletion-by-ripping, rapid ordering, arbitrary grouping, simplicity of shared communication and agreement, and also the power of mobility--they go everywhere, even through an airport metal detector. (Water, often found in washing machines, is a bit of a problem.)

Once a week or so, I run through the dozen or so cards tucked in my jeans or shirt pocket. I scratch out useless or already ingrained information, consolidate the really useful information, and delete the completely used or otherwise useless cards. So much quicker than a BlackBerry!

I keep a small number of reference cards handy; one is a vi card. Despite what you might think, the vi card changes frequently. I'm often seeking better ways to do things, and of course note those on my vi card. But once I do something often enough and thus ingrain it (I now know to rotate my split screens with ctrl-w-r), it doesn't really need to appear on the card. I scratch it off, and after enough scratchings or when there's no room left, I rebuild the card.

Apropos of little: Despite our best attempts otherwise, many of us end up being just like our parents. A few years ago, and by then well addicted to the cards, I caught myself in the mirror. I realized that I was like my father in many ways: political philosophy, appearance, and demeanor. I had to laugh when I noted what made the transformation seem complete: scribbled notes on a stack of index cards stuffed into my shirt pocket, sitting alongside a couple pens. I am my father.

Agile Manifesto

Source: http://agilemanifesto.org

This is where it all started, on February 11-13, 2001, at the lodge at Snowbird ski resort in the Wasatch mountains of Utah. The original signers met to talk, ski, relax, and try to find common ground. These are the original seventeen:

• Kent Beck
• Mike Beedle
• Arie van Bennekum
• Alistair Cockburn
• Ward Cunningham
• Martin Fowler
• James Grenning
• Jim Highsmith
• Andrew Hunt
• Ron Jeffries
• Jon Kern
• Brian Marick
• Robert C. Martin
• Steve Mellor
• Ken Schwaber
• Jeff Sutherland
• Dave Thomas

The result wasn't a scathing attack on business-as-usual, nor a rubber-stamp for the eXtreme Programming or Scrum. It was a simple statement of values. The statement of values is important because the practices without the values are empty.

These values are pragmatic and practical, arising from many combined decades of actual software practice. The preamble (not quoted on the card) says:

We are uncovering better ways of developing software by doing it and helping others do it.

If a company is devoted to following a plan, fighting changes to scope or priority, purchasing expensive and opinionated tools, following a rigid process, and producing copious documentation then that company certainly may continue to do so. It may even be successful. But it will not be agile. In fact, such a company should not waste time and money attempting to adopt an agile process. Agile is for companies devoted to simplicity, iterative development, time-to-market, and quality.

Failing to adopt the values is the first and greatest failure mode.

Intro

Working at Object Mentor (where I'm a double-alumnus) I learned the value of brevity and the patience to seek teaching opportunities. I realized that I need to have information not only in my head, but in a form that I can hand out to my clients.

As an Agile coach, I tend to have a lot of index cards handy. I glommed onto a habit of teaching by having a student (or class full of them) bring three index cards and a marker to a session. I would explain enough information to fill three index cards, and the meeting was over. They left with a good reminder of the information I had explained.

I blogged about my TDD reference cards at Object Mentor's blog and a little while later found that a reader produced the same blog, but with pictures. I found his because it got a great reddit score, much better than the reddit score on my own original article. The pictures matter (though it may also be that Brian Di Croce is a more entertaining writer).

Another ingredient came when my friend Glen introduced me to Brian Eno's concept of Oblique Strategies. These are little cards that provide some advice out of context. Eno and Peter Schmidt

... tended to keep a set of basic working principles which guided them through the kinds of moments of pressure - either working through a heavy painting session or watching the clock tick while you're running up a big buck studio bill. Both Schmidt and Eno realized that the pressures of time tended to steer them away from the ways of thinking they found most productive when the pressure was off. The Strategies were, then, a way to remind themselves of those habits of thinking - to jog the mind.

I found that when I was facing difficult times or pressures or sleeplessness, I could pull out a card that explained the canonical way to do something. The brief explanation would anchor my thinking and remind me of the essential simplicity I need to approach difficult tasks. This is because it is as General Carl Von Clausewitz said of war:

"In war everything is simple, but it's the simple things that are difficult."

The final ingredient for the index card mania is that I picked up a gig working with Jeff Langr, the author of Agile Java. I immediately enjoyed the way we argue, discuss, work, and learn together. I decided to pair up with someone who has been through book publishing (more than just my chapter of Clean Code) before and Jeff was my first choice of collaborator.

After working under the radar for a while, we decided to open up and start getting content in front of developers. Here you will see the results of our efforts, and be able to contribute via comments and tasty arguments.

I hope you'll join us.

Agile In a Flash

The notion of the magical number of 7 (plus or minus 2) was devised by George Miller in 1956. (No, not that Mad-Max movie-producing-George Miller.) The Wikipedia page illuminates that the "7+/-2" concept is simply a hypothesis--not something for which you can find extensive scientific research.

That's ok--you won't find extensive scientific research for agile either, or for that matter, much of anything to do with software process. But we have stories! We have anecdotes! We have seen agile work, and we've also seen it fail. We've also noted that it doesn't "work" overnight: The whole point of agile is that you start somewhere, bite off a small chunk of work, and then continually reflect and adapt.

There are lots of elements in agile to learn and remember. Uncle Bob defines three laws for TDD. Kent Beck devised the four rules of simple design. The agile manifesto defines four values. And so on. We found at least a full deck's worth of such lists, and have started capturing and using these lists to prod ourselves when our memories fail. The goal of our "Agile In a Flash" project is to produce a web resource, a book, and a replenishable index card deck, all to use as tools in your day-to-day application of agile.

And we will go George Miller two better! Most of the lists fall into the "5 plus or minus two" category.

So who are we? My name is Jeff Langr; you can find more about me here. I've known Tim Ottinger for only a little over a year, so I'll let him speak for himself in his own blog entry. Tim and I are both Object Mentor alumni (and both of us contributed to Uncle Bob's Clean Code). Tim and I also don't see eye to eye on everything and we're both pretty picky, which is what I think will help make the Agile In a Flash cards the best possible set. Stay tuned.