Process Patterns: Design Patterns for Process Nerds

Ever hear of ITIL? It’s a great way of looking at an entire IT department. How about SPICE? It’s a way to assess software development practices? CMM? A Maturity model for software development? CMMI? An extension of that model to integrated platforms.

How about PSP? A way to manage your personal work habits to develop software. ADKAR? A way to talk about organizational change. The MAT? A way to measure software process risk. (I invented that one). SIPOC? An older way to describe processes. BPM? A way to visually describe how the business works.

I could go on at length. Once you get through learning a few programming languages, then how systems go together, there’s a whole other world of patterns of how people organize and create value when working on technology projects.

When you start learning Object-Oriented Programming practices, you eventually will hear about Design Patterns. They’re little blocks of reusable solutions to common problems. The idea is that when you come across a common pattern, don’t re-invent the wheel. Instead pull one of these pre-canned ideas from the book and kablam! Presto Chango! You have solved a problem.

What really happens, though, is a little different. Once design patterns are learned, folks start seeing them everywhere. I’ll never forget looking at the data model for a retail store back around 2000. It had over 900 tables in there! Just to sell stuff to people. When I started looking for reasons why, I noticed that the architects had taken every problem they ran into and applied a data modeling design pattern. So there wasn’t a customer. There was a party-person pattern. Everything in the problem domain splayed out into 5 or 6 tables.

Instead of thinking about the problem we’re solving, patterns can encourage us to jump to over-reaching (and many times very constraining) premature solutions.

It’s the same way with process patterns. Process patterns encourage us not to think about the exact situation we have, weighing pros and cons of various options. Instead they promise to provide us with pre-optimized solutions.

Just like design patterns, once you start learning process patterns you have a tendency to shoot yourself in the foot.

How to prevent this? At all times focus on the rate your team is providing value back to the organization. That value can be defined various ways, but it’s critical to identify and track it. Personally I find user stories work the best here.

No matter how you structure your work, if you over-rely on patterns you are setting yourself up for big trouble.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy this password:

* Type or paste password here:

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>