Who Owns the Process (A.K.A. Please Just Let Me Do My Job)

I’ve worked at several places and each had a different process– each one usually very different from the others.  I’ve worked under CMMI level 5 waterfall processes as well as scrum agile processes.  Here is what I’ve learned from my experience: “Nothing can destroy a good product faster than a bad process.”

Now, let me guess.  You’re assuming I’m going to rant about CMMI level 5 waterfall’s rigidity and extol the flexibility of Agile.  You’re right.  On the other hand, if you think I’m going to rail on Agile’s tendency to lead to Cowboy Coding and praise the emphasis placed on thoughtful design by waterfall–you’re also right!  This is because:

The process is not important.

Whoa!  He didn’t just say that, did he?  I should clarify–it’s not that the process doesn’t have any impact on the product.  The right process reduces impediments, manages risk, helps maintain appropriate quality and productivity goals and fosters appropriate collaboration.  The wrong process can literally destroy high-performing teams and obliterate good software.

But, fixating on the process is like hiring a librarian to perform open heart surgery and worrying about the color of thread she’ll use to stitch you up when she’s done.

Here is my rationale:

  1. Every process is defined, modified and enforced by people
  2. Every step in the process is implemented by people
  3. Evaluation of the process and its appropriateness is performed by people
  4. Project and product goals are defined by people
  5. Evaluation of the product and its success is performed by people

Notice a pattern?  At this point it’s tempting to say: “It’s all about the people.  Hire the best people.”  This is true, but it’s a red herring–everyone knows this and it’s not especially helpful.  What I’ve learned is this:

“You must have the right people empowered to change the process as they see fit.”

The right people

This one isn’t as easy as it seems.  It really consists of two things: you need to have people representing the right concerns and you need to have people with the right personality characteristics (a topic for another blog post).  At a minimum your process team should include the following stakeholders:

  1. Representatives from the technical team
  2. Representatives from the customer perspective
  3. Representatives from the business / management perspective

The common exclusion of 1 and 2 led to the creation of agile.  The exclusion of 3 leads teams to return to waterfall.  All three must be represented and empowered for a software development team to be efficient and successful.


There are a large number of aspects that affect how a team should tailor its process.  This includes things like: requirements volatility, developer proficiency and risk tolerance.  The following chart illustrates how various project factors impact the choice of a process:


If you’re writing code that controls nuclear missile launches with a team of ninth grade gym class students — waterfall is the clear winner.  In the real world no canned process will be a perfect fit.  You will need a customized process that includes some elements taken from various processes.  And this leads us back to our thesis:  The appropriate people (technical, customer and management) must be involved and empowered to change the process as they see fit.

conclusion (TL;DR)

No process is perfect and yours is no exception.  Get the right people involved in the process and give them free reign to change it as needed.


One Comment

Leave a Reply

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