An Introduction To Patterns

I have mentioned patterns several times already, so before we go any further, I should make clear exactly what I mean by a pattern.

Back a few years, when things were still made by hand, a craftsman who wanted to make a set of things that were the same each time would make one reference piece, measured and constructed very accurately, and use it to create more pieces that looked the same. That reference piece would be carefully labelled with instructions on which way to align wood grains (or fabric weave, or whatever was appropriate) and which techniques to use to construct it. This reference piece was called a pattern. There was even a specialised skill within workshops called “patternmaker”, with its own set of specialised (and very accurate) tools. So a pattern is a template or a guide to doing something.

We still use patterns today. When I’m in my workshop I’ll make patterns when I need to make identical table legs. When my wife sews, the first thing she does is make a pattern so that both pants legs or both shirt sleeves will come out the same. It also allows her to make multiple copies of a garment without having to design from scratch each time.

Making a pattern takes time so you would only invest the time and effort to make a pattern for something if it was going to be used often. So it’s a way to make copies of things you make all the time. For something that’s a one off (or a two or three off), it’s not worth the effort in creating a detailed pattern, so a quick sketch or something will do.

Patterns can also save time. Creating a pattern takes a long time but once it’s there, you can make copies quickly and accurately. Once my wife has a good shirt, or pants pattern, she can turn out copies easily and quickly. You can also buy patterns off the shelf. My wife buys sewing patterns all the time. I’m currently making a bed based on a woodworking pattern that I purchased. You can take advantage of someone else’s experience. They have already solved the problem you are trying to solve, so you can apply their learning by applying their pattern.

One thing I hear about patterns (particularly in the woodworking community) is that they limit creativity. Do they really? I don’t think so. For a start, selecting the right pattern is a skill in itself. Patterns can also be tweaked to customise them and I can always select timbers or finishes or decorative details to make each copy look different. My wife can select fabrics and other things to make each garment she makes into an individual piece. Patterns give you a framework that you can work within to build something. You know that if you stay within the framework, whatever you are building will come out fine because the pattern you are using has been tested many times.

So how does this apply to Enterprise Agility? Another way to look at patterns is as a recipe for solving common problems. The design patterns movement within software development uses patterns this way. Each of the design patterns is a standard, proven way to solve common design problems within software projects.

There are a number of problems that software projects encounter all the time and a series of design patterns have been developed to address them - MVC, Factory, Inversion… and so on. That’s not to say that software development is now just a matter of following the patterns. Patterns help with the bits that are common across many implementations. The bits that are specific to the problem that you are solving… those you still need to work out for yourself.

It’s the same with Enterprise Agility. When we start applying agile into a larger organisation, we hit a number of common problems. At the moment though, we are all trying to solve these problems ourselves. Each of us who is involved in enterprise agility is spending a lot of time and effort solving problems that others have already solved. What we need to do is learn from the design patterns folks, and come up with a set of agile patterns that serve the same purpose.

We need some common patterns that we know will solve (with some customisation) the common set of problems that we are facing. That way we don’t need to spend time and effort solving the same problems again, but can concentrate on solving those problems that are unique to the individual organisation.

There has been some work done in this area already but many of the patterns out there, things like Less or SAFe or XScale, focus on what I refer to as the execution of agile - how to apply an agile methodology and apply it to delivering stuff at the enterprise scale. They cover the mechanics of Agility. This is great, but there are a lot of problems with agile adoption that have nothing to do with execution.

I see three distinct levels of pattern. At the top there are organisational alignment patterns - ways to get the various layers of an organisation aligned around an agile adoption. These patterns enable (or disable) adoption patterns - ways to roll out agile capability within the organisation.

In turn those adoption patterns enable various execution patterns (like SAFe and Less and XScale) that deal with the mechanics of the agile process.

If you can pick which alignment pattern you are dealing with, that gives you some insight into the sorts of issues you will experience when managing an agile transition. Knowing your alignment pattern lets you pick the right adoption pattern to get the best success. Essentially, different alignment patterns work well with certain adoption patterns while blocking others. Pick the adoption pattern that matches your alignment pattern and things will go smoother than picking one that is incompatible.

The idea behind this book is to set out a strategy for Enterprise Agility through patterns. By starting at the top with an Alignment pattern, this will guide (or dictate) the choice of Adoption patterns which will in turn influence which of the Execution patterns will be successful.