Get the Business on Your Side

A technology organization is a socio-technical system. If you want to improve the performance of a socio-technical system, you must focus on at least two aspects – its capability and its usage. Capability improvements are essential, but they are not as effective without improvements in usage. Besides, it takes longer to improve capability and you might obtain quick wins by improving usage.

One way of improving usage is to stop overloading the system. WIP limits help achieve this. The last few posts dived deep into this topic.

But how do we take this knowledge to the business? Why would they care?

Show Velocity alongside Intake Velocity

To get the business folks on your side, don’t begin the conversation with system usage or WIP limits. You’ll have to show them the problem in a way they can understand. At one of my clients, we are doing this by visualizing the rate of work intake versus the rate of work completion. The latter is the same as velocity where the definition of done is go-live. Think of the former as intake velocity.

It might take a bit of historical data gathering, but it doesn’t have to be too detailed because the unit of work that matters to the business is usually a feature or an epic. Construct a table like this and calculate aggregate intake and completion numbers.?

Explain it in non-technical terms

Plot the aggregate numbers in the form of a cumulative flow diagram but don’t use that term with the business. The growing gap makes it clear that they continue to take on more work than they can complete.

The unfinished work is stuck or progressing very slowly somewhere in the middle of the delivery value stream. That’s a sign of congestion, and as anyone who has experienced traffic congestion knows, it doesn’t matter what the cause of the congestion is, it usually slows down all traffic on that stretch of road. See if this helps sway the business to accept cross-portfolio WIP limits.

Business stakeholders might still hesitate. In my experience, it’s usually down to two things.

Can you show the benefit?

One, they aren’t sure of the upside. Does the use of these limits really help improve speed to market? How much? To verify this effect in your situation, you’ll need data on delivery lead times (time from the start of software delivery to go live) for the above period. Does the metric improve as you take measures to relieve congestion?

Can you help them limit demand without spoiling their plans?

Two, they aren’t sure how to limit their demand. They’ve always been looking to get more done from delivery. Even without limits, cross-portfolio prioritization might have been a challenge. Any talk of applying limits might be seen as a step backward because their features might have to wait longer to even get started.

This is an opportunity to sell them feature slicing. Slices move faster through the delivery value stream than whole features. That means the slices in wait can get started sooner.

Granted, slicing is not always acceptable to the business, so perhaps you could agree on where it might be. It might also call for more technical prowess from your team to test and deploy slices independently and switch them on or off as needed. Nonetheless, that’s what it might take to deal with reckless drivers – those who can’t help overloading your delivery organization – to return to the metaphor I used in the beginning of this series.

Full Circle

Back then, I asked:

"How can we help them drive better? What dials do technology leaders need to surface on the dashboards of business leaders? What sort of driving school should technology leaders set up to help business leaders understand these dials and regulate their driving?"

I hope this series on “regulating system usage to improve performance” has provided you with some answers to the above or has at least equipped you with tools to come up with your own answers.

The Elephant in the Room

There is one approach I left out because it is considered to be beyond the pay grade of delivery leaders and technology leaders in the classic enterprise. It’s that of actively challenging the demand (constructively) and asking for evidence of business benefits from previously fulfilled demand. A CFO or COO might be better placed to do this than a CTO or CDO. I’ve shared an outline of this approach here.

Until next time, take care and prosper.

Sriram