why the best software design and development process is all in your head

I promise I’ll tie this back in, but for now keep the image of a metal spoon bending and swaying like a blade of grass.

A while back now at UI11 I watched the beautiful and intelligent Christine Perfetti draw a picture sort of like this:

She actually started by telling a story. She, Jared, Josh, and the other fine folks at UIE had been working with a large number of high performing design teams for a number of years. Their goal was to identify what were best design processes, with the expectation that the best performing design teams would logically have the best design processes. But, what they found was surprising.

She first defined process as the series of steps we follow to effectively design our software. If we write down that series of steps, and add further process steps to confirm that we consistently follow our process, then we’ve got a methodology on our hands.

Here she added the technique dot to this simple continuum. She gave examples of techniques like paper prototyping and usability testing. But the idea was that a technique was a routinely repeated “method of accomplishing a desired aim.” We all use lots of techniques in support of whatever process we follow. Then she added the trick dot. My definition of a trick is sort of an improvised technique – by that I mean using an existing technique or tool to accomplish something different than it was originally intended. The first person who grabbed a stack of index cards and started sliding them around the table to produce a card model was improvising. However, routine improvisations have a way of eventually morphing into techniques. Much of the card modeling we do in Agile software development is a combination ad hoc tricks, and specific techniques such as CRC cards.

So here’s where the surprises that Christine related come in. The UIE folks expected to find that the highest performing design teams had the best processes – but in fact they found that high performing design teams might not follow a consistent process at all. What they did have was a big toolbox full of techniques and tricks, and a history of adaptation and improvisation. She went on to say that in organizations that had a documented methodology, they could almost predict poor performance.

While likely counterintuitive to some, this revelation resonated with my suspicions.

I work as a consultant. This means that I often answer direct questions about process with the phrase “it depends.” Which it usually does. I’ve come up with interesting variations of that common phrase. When asked “what makes a good persona?” I answer with the almost useless word “relevance.”

But what I think is really happening here is that when you start taking techniques, sequencing them in time, and attaching a few deliverables to them to construct a process, what you’re dragging in is lots of context. Context about the team using the process, their skills, the software they’re designing and developing, and loads of other stuff that make that combination of techniques… relevant.

 

I, and many others in the Agile world, often reference Shu Ha_Ri, the three levels of learning Alistair Cockburn described in Agile Software Development. Our Shu brains want a process to follow… but our Ri and Ha brains know that this is unlikely or impossible. As Alistair is quick to point out “one Shu doesn’t fit all.”

When I think to the times I’ve worked with a team to most effectively deliver software the process wasn’t our concern. We moved fast, improvised often, and focused on our customers. We knew we’d delivered successfully not when the “EAR file as uploaded to the server,” but when we saw end users successfully working with the software on a daily basis.

If I think back, I can say what we did on those successful projects. I might even be tempted to describe it as a process. If I wrote it down and coerced others to follow it, I might even promote it to methodology. But I couldn’t sleep and night. Because I know that put in the same situation today, I might likely improvise – use new techniques and approaches I know now that I didn’t know then. I might try completely different approaches, because there’s always more than one right way.

Deep down in my heart, I know that there’s really no process. That I’ll really have control over my process when I let it bend and sway like a blade of grass. When I focus on the objectives of my software – try to transcend the process.

But, that may not work for everyone. I guess it depends.