Guy's Blog Blog from Sep 26, 2009

As our company has grown we've had to start mapping out all sorts of internal procedures and decided we needed a nicer way to do process diagrams...

Ad-hoc and Agile don't mix

Most people confuse ad-hoc for agile. The two are polar opposites IMHO.

In the early days of a start-up company, ad-hoc reigns supreme. It's the only way to get stuff done fast enough and any form of formal procedure is shunned.

As a company grows, teams and projects get bigger and the ad-hoc approach starts to break down. Every task, no matter how simple, starts to take inordinate amounts of time and generally ends up suffering 'design by committee'.

You can't improve a process that's ad-hoc - because something that's ad-hoc isn't a process. It's this fundamental trait of being ad-hoc that prevents you from applying an agile approach to improve the process.

In order to be agile, you first need to formalise how things are done. For many people, this is totally counter-intuitive.

Map the processes

The first step to being more agile is to identify the processes that matter most. For example, how do you handle sales enquiries, how does the billing team process a purchase order, etc?

When you've identified key processes you can start to work out what actually happens in them - from start to finish what steps are taken and what decisions are made? Once you know what happens in a process, you can iteratively improve it because you understand how the process works. You've got to base improvements on fact, not guesswork and intuition.

After you've mapped a few dozen processes, you'll start to see how they interact with each other. Often you'll find that a sub-process is what's causing all the problems. And, usually, sub-processes are used by several critical larger processes. You'll often find that there are issues caused when processes cross departmental boundaries and these can cause utter chaos.

Once you've done all that you can start to apply the 'theory of constraints' (google it) and a plethora of agile techniques to every part of your business. You'll get a sense of a large pile of confusing jigsaw pieces suddenly starting to fit together perfectly as problem after problem succumbs to your will.

Might as well make the mapping look nice!

So, this was the original intention of my blog post before I started rambling on what got me here in the first place. We've been mapping our internal processes like crazy recently, but before doing so obviously googled for ideas on best practice. We didn't like what we found.

The traditional approaches to doing process diagrams seem to be designed in such a way as to ensure that as few people as possible can understand them. Duh! They also contribute to process documentation being amongst the most tedious things you'll ever experience.

So, we thought Bollocks to that! and decided to come up with our own way of mapping processes - and we've come up with this:

It's an OmniGraffle stencil that doubles up as a template for a 'guide to flowchart symbols'. OmniGraffle has this awesome feature of being able to use a flowchart as a stencil and then switch between flowchart and stencil shapes views. In flowchart view you see the diagram above, in stencil view you see each individual shape separated out in to a grid. In both views you can just drag and drop stuff on to your workspace and start editing it.

Being the sharing bunch that we are, we've open sourced it and made it freely available on the intertubes via the Graffletopia website: click here to get it!

Here's an example of a process map in our Sales department for handling forms that customers ask us to fill in:

We've mapped about 80 processes so far and it's worked like a charm. Being non-techie it's easy to work with and understand.