Agile Patterns
Last post I briefly mentioned a patterns based approach to agile adoption within enterprises. I should probably spend a little time explaining what I mean by that. The first question, of course, is what do 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 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. It's a way to reliably and consistently make copies of 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. You can also make a pattern if it was really important that it was done correctly.
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 its self. 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 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 an agile adoption? 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 Agile adoption into a large organisation. When we start applying agile into a larger organisation, we hit a number of common problems. Organisational inertia, frozen middle management, command and control thinking, non-agile org structures and so on. At the moment though, we are all trying to solve these problems ourselves. Each of us who is involved in enterprise agile are 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 adoption patterns that serve the same purpose.
We need some common patterns that we can apply. 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, focus on what I refer to as the implementation of agile. There are a lot of problems with agile adoption that have nothing to do with implementation. 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 implementation patterns (like SAFe and Less) that deal with the mechanics of the agile process.
Next time, I'll start at the top and start looking at the organisational alignment patterns. As a starting point, I am proposing a set of 6 in the hopes that others will come along and add new ones, or challenge and refine mine. Stay tuned...