Introducing Process

what is a good process vs a bad process

Posted by Cads on 17th Feb 2017

There are many more pages and definitions of Process in the software world than I would care to go into. But as an overview there are some things that are not clear to a lot of people. Let's call these "caveats".

  1. Process is not procedure
  2. Process is descriptive not proscriptive
  3. Process is not a dirty word - despite the reaction it garners in general conversations

So, what is process then? How do you define it, and what is a good process vs a bad process?

Let's start with that first question, "what is process?".

According to the Oxford English Dictionary, a Process is:

  1. A series of actions or steps taken in order to achieve a particular end:
    military operations could jeopardize the peace process
  2. A natural series of changes:
    the ageing process
  3. A systematic series of mechanized or chemical operations that are performed in order to produce something:
    the manufacturing process is relatively simple
  4. Computing :: An instance of a program being executed in a multitasking operating system, typically running in an environment that protects it from other processes.

So - that all seems pretty innocuous, right? So why is it so hard to define "Process" in the Software world? Well, it really boils down to the fact that there are a lot of differing methodologies designed to make a given company's process robust. External factors have a lot to play, too - Customers want to know how we guarantee the delivery of our product. This means they want to know what the Process is around getting a feature to market, so that they can better understand timescales etc.

So, moving on to the second question:

"How do you define [your] Process?"

This really hinges on point 2 of the caveats above.

  1. Process is descriptive not proscriptive

This truly means that the best way to define the process that you are using is to describe what actually happens. And by that I do not mean "We use SCRUM." I mean that we have to go back to basics and ask questions:

  1. How do we capture customer requirements? [who, what, when]
  2. How do we prioritize those requirements? [who, what, when]
  3. How do we pass the requirements to engineering? [who, what, when] . . .

Only when you have that description down you have a definition of your process. This is where the fun begins. Taking a leaf out of LEAN Principles "eliminate whenever possible those steps that do not add value". We can start to tweak the process. Now, value is an interesting problem in itself - what has value for an engineer may not have value for the business and vice-versa, and this doesn't include any layers of management, stakeholders, interested parties etc. And we will delve into that elsewhere within this manual.

So - now we have a definition of our process, we know what process is, let's try and move on to the last one

What is a Good vs Bad Process

You aren't going to want to hear this, but there is no such thing as a bad process. There is only a bad process for you (read: your organization etc.). It is manifest that in an age of rapidly changing, continuously delivered products, process methodologies such as PRINCE2 are too heavyweight for most organizations. That doesn't make it a bad process, it just means it is incorrectly applied (and a note here - process is descriptive, not proscriptive, so "applying a process" is often a bad idea in the software world).

Here's what makes a Good process: The process accurately maps how you perform your work (deliver your code to the customer) and is efficient as possible without compromising business requirements. In other words your process correctly "Maps the Value Stream"