Innovation Tools: Pattern Forming

By November 1, 2014 Modelling, Thinking 2 Comments

This is the 7th in a series of posts regarding innovation and mechanisms for achieving it. You can find the previous articles here if you want to catch up.

Following on from my previous article about pattern recognition, the next innovation tool is Pattern Creation, or forming – the combination of elements and operations in such a way that they produce a consistent form or outcome.

What are patterns?

In this kind of a context, the word pattern is often taken to mean a template, blueprint or dare I say best practice. Software developers often apply patterns during the crafting of code for the very reason that they anticipate a consistent outcome. Therefore where a problem has previously been solved by applying a specific architecture or algorithm, that solution can be captured and applied to the same problem in the future, as a design-pattern.

Patterns are applied in other disciplines as well of course. In manufacturing or clothing for example, once a successful design has been identified it is codified into a blueprint, design or template and reproduced. In cookery as well in the form of recipes.

The flip-side of the pattern coin is the anti-pattern, or patterns which have been observed to result in the same undesirable outcome. Anti-patterns tend to be considered from organisational and team perspectives where behaviours deemed to be unhelpful are manifested. The term was originally coined in relation to bad coding practices and later expanded to include organisational and project management anti-patterns. The term can probably be applied to sociological and political problems also.

What I want to think about in this post, is ways in which we might go about forming new patterns, should we want to. In particular I wanted to think about the formation of patterns that might lead to new (i.e. innovative) outcomes.

Deconstructing patterns

As I started thinking about this (from a software testing perspective), I figured a first step might be to take all of the various tasks, activities, people and processes that make up a context, and then try to find ways in which to combine them that might result in a new outcome(s).

As a start, I came up with the following:

elements and processes of a project

elements and operations of a project

I went on to think about what how some of those elements interacted. The following example jumped out at me:

a common reporting situation

a common reporting situation

Which is more clearly represented thusly:

tester reporting pattern

tester reporting pattern

Creating new patterns

It’s pretty easy to think of ways in which this particular pattern might be modified in order to produce a different, possibly better result. We could swap out email and replace it with face-to-face communication, or we could implement some form of low-tech dashboard or information radiator like a Kanban board. We could go a step further and remove the tester and email from the reporting equation completely, and replace them with some other mechanism, like Jira, Quality Centre, or Jenkins that reports testing progress without necessarily requiring the extraction and/or assimilation and interpretation of results and metrics.

The pattern might end up looking like the below:

improved reporting pattern?

improved reporting pattern?

It’s difficult to say whether this qualifies as a success pattern or not. Depending on the testing approach, tool, reporting mechanism, and context – it could easily become an anti-pattern instead. Many agile teams work towards this kind of a pattern with a strong focus on automation and continuous delivery. The big “A” agile philosophy eschews the use of tools or processes in favour of people and communication, which in theory prevents the worst abuses of this kind of an approach. I have reservations, but they’re not the focus of this post.

Looking at my original mind map (with a couple of embellishments by this point) provided another example:

a common requirements capture pattern

a common requirements capture pattern

Is this a success or an anti-pattern? Again, it probably depends on the context within which the pattern is being applied. The question that springs to my mind is whether or not the requirements documentation is useful to the people for whom it is intended. If we assume that it’s not that useful (which is a fair assumption since any requirements document is likely to contain errors, misunderstandings, out-of-date information etc) then again, we can consider creating a new one to try and fix the problem.

improved requirements communication pattern?

improved requirements communication pattern?

The modified pattern relies on [effective] communication between the project team (developers, testers and anyone else who needs to know) in order to produce code that a) works and b) solves whatever problem it is we’re trying to address. Once again, this is more akin to the way in which agile teams normally work, though in my experience there is still often some documentation involved in the form of executable specifications.

Further thoughts

So I’ve identified some ways in which the elements and operations which constitute patterns can be isolated and rearranged to form new ones. The examples that I’ve used have been fairly trivial, and as a result I haven’t identified anything particularly innovative. I’m hopeful though that continuing this line of thought would ultimately result in new approaches and ways of doing things.

The real benefit, certainly to me anyway, of writing this post has been to observe my own thinking about patterns, and also to find some way of documenting and communicating them. The very act of stepping back and attempting to identify the elements and processes of a situation, e.g. a software engineering project, and then going through a process of isolating and rearranging them to form new patterns seems like it could yield real benefits.

It’s certainly a pattern for thinking that I plan on returning to in the future. And of course, thinking about patterns can be extended to all kinds of places – our own behaviours for example. My communication patterns are something I’ve talked about in a previous post. Self-limiting beliefs are another area that might warrant further scrutiny (and that I touch on here).

Do you think about patterns, in your workplace or project? What about in your own behaviours, or those of the people around you? If you do I’d love to hear your thoughts in the comments section below.

- Simon

P.S If you're interested in learning more about performance testing, checkout my Performance Testing 101 course here.


2 Comments

Leave a Reply