A Simple Cycle
Bycycle by Akdesain
Since learning of the Deming/Shewhart Plan-Do-Check-Act cycle (PDCA) I've rather struggled to embrace it as being especially suited to software development. It was designed for an engineering/manufacturing paradigm, and still has that air about it—very formal, and phase-like. Sure, a framework like scrum, when implemented, has a planning phase, a doing phase and a checking phase, although it is much more than checking of course, as it involves acceptance, feedback, the generation of new ideas, and sometimes a reset of goals. It's the "act" part of PDCA I've never liked. It's all action, isn't it? And the action that follows the review/retrospective (checking) in scrum feeds directly into the next iteration—the whole PDC part. It isn't a separate thing.
I used to teach the scrum process as being Plan-Execute-Reflect, which for me is closer to what actually happens in scrum. Roughly, we meet with customers to talk about what we're going to do, we go away and do it, and then we reflect (with customers) on what we've done. But this is also an inadequate description. Planning isn't all done at the start, but is often ongoing. Both the PDCA cycle, and my own simplified cycle infer that all planning is upfront. It isn't.
Reading Mike Cohn's review of Just Start, a new book by Schlesinger, Kiefer and Brown, I learned about a new cycle for creative work: Act-Learn-Build. Sounds cool. Get into action immediately, learn from what we've done, build on what we've learned, and do it all again. I haven't read the book, only this review, but it seems as if something is awry. What action, and who selects it? There is surely some dialog before we go into action. I think the point the authors make is to keep the upfront dialog real short (good!) and focus on the doing and learning. This cycle seems an improvement on PDCA and on my scrum plan-execute-reflect cycle, but it still isn't intuitive to me. Dialog isn't apparent. It may be implied, but it isn't called out. The ALB cycle seems to imply a closed system. It may be good for a researcher or scientist, spending months alone, learning as she goes. I'm not those things though. I seek team work, and I seek customer interaction. So what else is out there?
My colleague Bob Marshall introduced me to LAMDA—Look-Ask-Model-Decide-Act, which is essentially a breakdown of the two parts of the Deming Cycle, i.e. 1. Plan-Do and 2. Check-Act, it's inventor claiming the two parts each have these five components. Maybe so. It's interesting, but more of a How to Deming's What. It still doesn't capture the essence of what we do in agile development.
The terms divergence and convergence are sometimes used to describe the agile process. Teams build software, possibly diverging from the plan due to, e.g. better ideas, or unforeseen circumstances, then they meet with customers to converge and reach agreement for the next iteration. I like these terms, but they describe directions rather than human interaction and activity. I prefer to focus on the human element.
I also prefer to avoid the terms "do" and "act" as both are overly general. When are we not doing, not acting? Possibly when we are alseep, but otherwise practically never. Instead I use the term "Make" to describe what we do as creators. Make (inspired by Lee Devin and Rob Austin's book, Artful Making) indicates some kind of hands-on approach, the building or forming of something, or practical experimentation for the purpose of furthering knowledge. It is (somewhat) separate from the conversations that precede and follow such activity. It's all action, yes, and some of the action alters the physical world.
What we do in software development is actually identical to what any artisan or craftsperson does when they are making new/bespoke products for customers. It comes down to just two things. Here's the pseudocode:
- Makers talk with customers.
- Makers go off and make stuff.
- Goto 1.
This can be captured in a two word cycle: [Align-Make]*. Does this mean that all dialog is contained in the first phase, and all action in the second? No—and here's the cool thing. This is a fractal model. At any time we can interrupt our making, have a short dialog, and act on that dialog, which will change the bigger Make we are engaged in. Likewise, at any time during an alignment we can try stuff—model, prototype, test, etc. and those actions will inform the dialog, and generate a realignment based on the new knowledge/data. So breaking that down we might express this as:
[Align[make, align]*, Make[align, make]*]* with each word "make" and each word "align" having the same pattern ad infinitum (or at least to a sensible level of granularity). It can scale upwards in the same way, each [align, make] being contained in a larger Make and each [make, align] being contained in a larger Align.
This cycle describes the What of the creative process. Anything else we do is really concerned with the How.
You may be wondering what the purpose of this model is. I actually don't know—but while I don't know its purpose for you I do know that for me the experience in making it was an exercise in abstraction. I have found that whittling good practices down to their core often reveals inherent but hitherto hidden patterns—patterns that can begin to inform us of new contexts that the original practices were not designed for. My earlier work on abstracting scrum from process and practice to values and principles offered me the opportunity to teach it in a meaningful way, far outside its original domain of software development. Perhaps this representation of the creative cycle for business will help others do the same, i.e. foster a creative mindset in areas of business traditionally considered to be formulaic or repetitive. Working creatively is always a more engaging form of work, than following process and procedure.
—
Coda: In the year or two following this post I developed the model into these two simple pictures, which I still use today when teaching scrum.
The pattern applies to any kind of creative, emergent work or activity, essentially anything we do where the outcome cannot be known exactly, and we have to improvise. Try it for yourself.
Palo Alto, 16/01/2013 comment