Regulate usage to improve performance

The last post suggested that the performance of the delivery organization depends on two factors. The first is its capability and size/capacity. The second is how it is put to use by business leaders who drive its priorities and set its deadlines.

I concede this is not an ideal framing of the relationship between business and technology. Even saying business and technology is not ideal because everyone is part of the business. But that’s how it is in many big companies, even as we begin 2022. The delivery or engineering organization functions in order-taking mode. They are expected to commit to delivery dates with limited understanding of scope. They only have a delivery mandate. The impact of delivery on business outcomes is invisible to them, and often, to the business leaders as well. Nonetheless, there is a big push to improve delivery performance.

Yes, there are also places where the opposite holds true – where the business is at the mercy of the tech organization. This post is not about them. This post is about places where tech must jump whenever the business snaps its fingers.

At these places, there is often no product management organization between business and technology. They might have a demand management function instead or have engineering managers responsible for it. In theory, demand management regulates and schedules demand. In practice, they might not be empowered to regulate. Business leaders might not take “no” or “later” for an answer. They expect the demand managers to schedule all new demand immediately and provide them with an acceptable delivery ETA.

As a result, inexperienced developers get tasked with starting off new work on their own. Their pull request review comments end up requiring more time than the initial effort to address. Or the experienced ones are assigned to multiple streams of work. Too much context-switching leads to loss of focus and therefore, a loss of productivity. With a mounting backlog of committed work, regular weekend work is taken for granted.

Developers come up with their own ways of dealing with the pressure. In one case, we realized that developers were taking advantage of the lack of detail in the spec. Rather than ask for clarifications, they’d interpret it in a way that called for the least effort. It allowed them to call the story as “Dev complete” and push it to QA. Doing so let them buy time to plug holes later when they came back as defects. They knew it led to wasteful rounds of testing, but it was their way of coping with delivery pressure.

Wasteful use of limited testing infrastructure adds to congestion in the value stream. As congestion increases, all work gets delayed. Escalations ensue. VIP lanes get created to make way for the most critical work. Over time, escalating to VIP-status becomes the only way that something can go live. All other work remains stuck in congestion.

Productivity improvements and capacity addition help a little, but they have their limits in the face of unrelenting demand. Productivity improvements through better spec writing, better engineering practices, and greater automation are possible, but they take time. Capacity addition is limited by budget and by the carrying capacity of the underlying codebase. Too many developers working on the same section of the codebase at the same time gives rise to a different set of challenges.

Therefore, demand must be regulated using WIP limits of some kind. That’s one example of improving system performance by regulating system usage. Depending on where the bottleneck is, the tech organization’s update to the business might be, “We’ve started working on it, but it’s held up for a bit to relieve congestion.” Or, “We don’t have capacity to start it until the current congestion clears up a bit.”. Unless business stakeholders are coached to understand and appreciate this language, they won’t buy it. That’s where the driving school of the last post comes in. WIP limiting would be part of its curriculum. A congestion indicator would be a new dial on their dashboard.

But before you get there, you might have to learn when and how to apply WIP limits because it is easier said than done. What’s an objective way of knowing when to apply these limits? The next post in this series will get into this.

There are other important questions. How do we convince business leaders to respect these limits? What if they refuse to be blocked? What if they say that blocking their demands is equivalent to blocking the business? That’s for later.

Until next time, take care and prosper.

Sriram