How Process Debt Slows Down a Product?

Imagine taking shortcuts during construction to finish a building faster. While it might be tempting at first, neglecting proper procedures can lead to problems down the line like this:

In the product language, these problems are called Technical Debt. For those who don't know what this is. It's the consequences received when a product team chooses to go over quick and cheap ways rather than robust and effective. It's a "fix it later" situation that developers create for themselves, but that fix never happens and keeps piling up.

There are various kinds of debts in this. A gross debt appears when QA enters into the product - process debt. It doesn't appear because of QA entering, but because it becomes visible then. While technical debt typically affects development time, process debt shows up when product teams work collaboratively with other teams during their development process like working with testers.

Process debt appears when there are inefficient or outdated development processes and methodologies. As weird as it sounds, this includes poor communication practices, a lack of agile methodologies, and insufficient one-to-one collaboration tools.

When working in an organization where products are identifying their positioning, they need to address business stories over - "clean up failed unit tests", "redo documentation", "update dependencies for the application" or "refactor old code". It's fine to let some debt collect at that time, but not for long. After a minor debt is stacked, you'll watch your developers go into a struggle to pay down this debt, pulling in the testers with them. This eats away at a time better spent testing the software, much like technical debt eats away at development time.

Warning Signs of Process Debt

• There is a huge defect/bug backlog to be picked
• It's hard to choose between what to work on - feature or bug fixes
• A significant amount is being spent to manage documents

How do you handle this?

You can't have this debt for long, because this will start to creep up leading to no efficient result.

Stage 1: Call-Out = Realize | Manual

It's when developers and testers work together, a process debt becomes visible easily. Calling it out in standups and meetings is the first step towards improvement. Enacting an improvement rather than asking to do it could work as long as you are prepared for the possible fallout it could have

Stage 2: A Bug Triage = Continued Stability | Manual

Bug Triage is a concept where the tester, developer, and product lead meet once a month or quarter to create a cycle for killing the defects in the product. Bugs reported, pending priorities, and issues in production are discussed and aligned.
Ideal effect period: 2 months

Stage 3: Pipeline = Confident Delivery | Automation

You must have heard of CD/CI pipelines. CI pipelines are used to ensure that end delivery is good for the user. When working on the backlog, the oldies will be the goldies. They have the highest potential to bring damage to the product because they are old enough to not understand the current products.
Ideal effect period: 3-4 months

Stage 4: Create a Policy = Quality Ensured | System

It may sound cliche to have SLAs. But, you pay your bills only when it's the last day, isn't it? It's similar here. If you decide to have No bug policy, it's only then you can expect to receive the least bugs.
Ideal effect period: 1 week

At GreyB, we have various such policies. One of them is, that any bug found during the triage is categorized as Obvious, Workflow, or Edge. If it's obvious, it has to be fixed as appeared. If it's workflow, you have 2-3 days. If it's Edge, you have 1-2 weeks. Once fixed, it is released with an automation check in the pipeline. When it occurs frequently, it becomes the policy.

After a few months, the process debt will start to be fixed. If not, then Demo, demo, demo until someone understands the impact. Because the only way out now is to declare bankruptcy on the debt and start over.

To Wrap Up

• When process debt appears it's important to address them and fix
• Testing and building will not always save you, regression works need to be automated to focus on product
• Speed and Quality will always remain as trade-offs. So, Debt or Fast looking Slow Product - what would you choose?