The poisoning hidden delay

Delay is a typical situation in the IT world. It can be handled several ways. The main point is whether things are better (including the engineer’s mood) or not.

This article is a part of my Scrum series, see with free links (including to this article):
I like Scrum. The good Scrum.

Image from https://www.gqindia.com/content/heres-how-much-you-can-get-compensated-if-your-flight-is-delayed-or-cancelled

When a delay happens, the managers try to keep the delivery on time. If possible, the scope can be cut. Or more resources can be allocated for the problematic domain (Tiger team). Or the management asks the engineers to make the Story or Epic quick and dirty, and deliver it. But after the delivery, refactoring the nasty code is no longer important to managers, so it will remain as is. If it happens regularly, the code base will be getting more wrong and implies more delays in the future.

I call it “hidden delay”, because the delay is already coded into the source code, but will be visible at the next development on that code. If the company culture does not enable to highlight and solve these hidden delays, it will make the trustfulness wronger between engineers and management, which poisons relationships.

The story

I worked in a unit, where the developers were under pressure to deliver as much as possible. Sometimes the estimated cost was considered too high, in order to goad the…