Re-evaluating processes and workflows in software development

• By dfactory
• August 21, 2018

[av_one_full first min_height=” vertical_alignment=” space=” custom_margin=” margin=’0px’ link=” linktarget=” link_hover=” padding=’0px’ border=” border_color=” radius=’0px’ background=’bg_color’ background_color=” background_gradient_color1=” background_gradient_color2=” background_gradient_direction=’vertical’ src=” background_position=’top left’ background_repeat=’no-repeat’ animation=” mobile_breaking=” mobile_display=” av_uid=”]

[av_textblock size=” font_color=” color=” av-medium-font-size=” av-small-font-size=” av-mini-font-size=” av_uid=’av-jl3xiu7a’ admin_preview_bg=”]

You work really hard at releasing a product and spend months executing a well thought out plan. As deployment progresses, a number of critical bugs start to emerge. The customer is screaming at you because some of the use cases seem completely different from his/her expectations. It is an all hands on deck situation.

Once the dust settles, you call for a post-mortem. All the issues trace back to either a lack of process (in requirements gathering, scoping, development and quality control) or non-adherence to the process if one did exist. A blame game ensues on why no process was followed. You eventually decide to double down on filling process gaps and enforcing adherence to it.
Does this sound familiar? Have you ever felt like no matter how much enforcement you attempt, you never get the compliance or outcomes you expect?

Maybe it’s time to acknowledge that the root of the issue lies elsewhere and not in the process

The genesis of processes and workflows

The industrial revolution and assembly lines brought structure to manufacturing. The desire to constantly improve both the quantity and quality of the end product gave rise to the study and implementation of processes and workflows. Standardisation and repeatability of tasks became the foundation of manufacturing processes. As large volumes started flowing through these workflows, line managers were now, for the first time, able to look at inventory and throughput at each station to assess bottlenecks in the manufacturing process. Standardisation of tasks also allowed for the setup of quality control stations all along the assembly line. If the end product didn’t turn out as expected, it was easy to go through the workflow and attribute the defect to a specific process and station. The process and/or workflow would get tweaked to eliminate the defect or inefficiency.

Process in software development

As the demand for software started growing exponentially, developers started borrowing tools and techniques from the manufacturing industry in the hope that it would bring discipline and predictability to software development. At first glance, the issue seems to be that of indisciplined developers — they never seem to follow any process. The real problem, unfortunately, is not with the process, but the foundations on which we developed them

Processes and workflows rely on the following to be true:

• Standardisation of tasks — the end product is the output of a sequence of standardized and well-defined tasks.
• The specialization of tasks — Each person performs only one kind of standardized task
• The output of each standardized task is the same
• Volume — Workflows need large volumes to flow through it to be effective and efficient.
• Workflows move in a single direction.

Unfortunately, in software development, none of these are true.

Most software teams vary between 5 and 15 developers and their growth beyond that number is constrained by communication and management overheads. Each developer performs a variety of different tasks in a given day. These vary from design to bug fixing to feature development and even testing. There is absolutely no standardization of tasks and therefore no specialization. Each feature or bug fix is treated uniquely because no two bugs of features are the same and therefore neither are the steps involved in reproducing, fixing or testing them.

For small teams, there really isn’t any real volume to identify and evolve common patterns that could be used to establish a true industrial process.

The implication of having small teams is that you have limited resources. These teams are therefore more focused on solving problems as they come along. Processes and workflows are shackles that are counterproductive and inhibit this kind of creative problem-solving process.

The overheads of process

Let’s imagine that you were a developer on a small team of 5 that has adopted the Scrum methodology for a new software development project. Jira seems like a good choice to make for process and workflow management. The most basic workflow available in the Atlassian marketplace for bug fixes looks like this:

[/av_textblock]

[/av_one_full]