of patterns and frameworks

Image for post
Image for post
ripples on Auckland harbour— photo Chris Lennon

Like many of you reading this, I walk to work every workday. My walk, from the bus station to the Fraedom office in downtown Auckland, New Zealand is on the edge of the harbour. Auckland — nicknamed “the city of sails” has a beautiful waterfront, but I’ve taken this route so many times I generally don’t take much notice of my surroundings. Again, you may relate to this!

Since becoming aware of patterns I’ve started noticing the patterns I pass each day. Just in this short ten-minute walk there are hundreds of patterns to be seen, and likely thousands more I’m not seeing. A boat pulls out of the dock, leaving swirling patterns in the water behind. Man-made patterns are there as you would expect in the inner city. Cranes hang over high-rises under construction and form triangles. Faded red railings on the fence separating the street from the port form a regular series of oblong shapes.

Image for post
Image for post
Fence railing at Auckland harbour — photo Chris Lennon

This post describes how patterns apply to the jobs we do in software, and how being aware of these patterns can help our teams and our companies.

what is a pattern?

“A pattern is a regularity in the world, in human-made design, or in abstract ideas” — Wikipedia

Take a look at this photo:

Image for post
Image for post
Photo by Casey Horner on Unsplash

How would you describe this pattern? When I look my eye is drawn to the middle of the photo, an oval shape of blue where the tree tops converge. At the very outside of the photo is another circle, formed by the base of the tree trunks, a trick of perspective.

Here is a key point about patterns. They do not announce themselves, rather they are there to be observed. There is also an element of subjectivity; you may see a pattern that I don’t. We are looking at the same thing, but noticing different things. So it is in the Volatile Uncertain Complex and Ambiguous (VUCA) world of software development. The patterns are there for the observing. Why do some teams thrive and others struggle? Why do some software projects succeed but others fail? The causes are many and complex — if you look closely you will see patterns there, patterns of success, patterns of failure.


Lets take a closer look at the photo above — outside of the top core circle I notice that the branches of the trees themselves form circles, some are irregular, but their circular outline is evident.

“Visual patterns in nature are often chaotic, never exactly repeating, and often involve fractals.” — Wikipedia

A fractal, referred to in the Wikipedia quote above is a pattern that contains similar patterns, which themselves may contain similar patterns, and so on.

Image for post
Image for post
photo — wikimedia

The Sierpinski triangle above is a classic fractal pattern, a single triangle decomposes into smaller identical triangles, and so on.

So it is with patterns in software development. A large pattern is a collection of sub-patterns, these patterns can be broken into smaller patterns and so on. Consider the concept of splitting work into manageable chunks: a large project can be split into a number of releases or phases, which can be split into stories.

some patterns I’ve noticed

Having worked in software for a long (long!) time, here are some patterns I’ve noticed:

  • A motivated, empowered and autonomous team with a clear and consistent vision, more than tools or processes, is how meaningful work gets done.
  • When starting a project, product or feature often the best way to start (your first “story” if that is your language) is (in the language of improvement kata) to grasp the current condition.
  • A team with clear leadership when it comes to product, process and technical domains has a better chance of success than a team where these roles are absent or unclear
  • Discovery > Design > Execution > Operation

There are of course many, many more. Patterns I’m aware of and patterns I’ve yet to observe. Patterns and patterns of patterns.

patterns vs frameworks

A framework defines boundaries and processes. A framework is something you work within. A pattern is something you work with.

To make use of a pattern is to begin to create order out of dis-order. There are no prescribed ‘rules’ as to how this order is created.

Although framework authors may not agree, my perspective is that a framework is best seen as an example of a pattern. The Framework author or authors have, through research and experience, drawn out patterns for success, and (to varying degrees) codified these patterns into a written framework. See Mike Burrow’s post on this.

open your eyes

The challenge I will leave you with is simple. Open your eyes and start observing patterns where you work. What team roles work and what team roles don’t? Are there particular processes or ways of working that work better than others? When a project succeeds or a milestone is reached, what were the ingredients?

The patterns are out there.

Agile coach. Ways of Working researcher. I live in beautiful New Zealand and work for Fraedom — part of Visa. I am also the founder of a start up — voyzu.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store