When Good Workflows Go Bad | Inflectra

When Good Workflows Go Bad

July 17th, 2014 by inflectra

A few months back, I was training a group on test management using SpiraTeam.  All was going well until I mentioned the ability to design a work-flow. Instantly I heard the sighs and groans.  WHY?

Enter The Workflow from Hell

The entire class asked me to hold on for a bit. They left and took a little while. When they returned, they were holding a stack of papers.

What is that? I asked, expecting them to want to take a detour and input a test plan and walk through it again.

This is our JIRA workflow!!!

1-2 inches thick of 8x10 paper, this was their workflow. Good grief.

It was explained to me that an engineer had spend the better part of a year documenting and building the most complex, byzantine, over-engineered workflow anyone had ever seen. There were approximately 80 types, and 500 statuses with multiple transitions between each, plus a lot of boolean logic.

Guess what? The development group and QA use Excel, because no one understands this monstrosity, and defects are getting through. Non-adoption rules the day. Plus the engineer who built it had since left the organization and no one knew how to fix it. This is a perfect example of a person writing themselves a job through complexity.

Workflows Should be Simple

Let me put this simply, you should not be looking to map the entire world with your workflow, you should be attempting to boil it down to a few types, with simple transitions, and well defined statuses that EVERYONE understands.

Is it a defect in the application, training, or documentation? Who has the ball? Is it new? Assigned? being worked? duplicate? non-reproducable? Fixed? or being retested? When we put too much granularity in the workflow we actually create a great deal of additional work for ourselves, and the picture of where we are becomes less visible.

In SpiraTeam we have the ability to assign other values to provide the granularity and reporting to handle special situations. Priority and Severity are two built in examples, or any of a myriad of custom fields that you could create to facilitate filtering. Why make the workflow so convoluted?

An Iterative/Incremental Approach to Workflows

It is my opinion that a workflow should flow out of discovery, to triage, into validation, through fix, and to close within 5 or 6 steps. People can understand 5 or 6 steps, they cannot understand 70. If you are creating a workflow that takes multiple pages to print, you are creating a few things; 1. Confusion for users, 2. Non adoption, 3. Job lock for yourself, and 4. A Mess when you leave.

Stick to the KISS (Keep It Simple Stupid, and rock on) method and you will get more done. All of the Spira tools contain a proven, basic workflow, don’t muck it up with more than is needed.

workflow customization defects