Get the Business on Your Side

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.?

No alt text provided for this image

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.

No alt text provided for this image

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

How would you define a "technology organization"? Or, more importantly, how would you distinguish between an organization that develops a technology (specifically IT) product vis-a-vis an organization that leverages technology as a force multiplier? And would the "gap" be just as relevant in both cases? For the same reasons?

要查看或添加评论,请登录

Sriram Narayan的更多文章

  • Focus on what: Process or Outcome?

    Focus on what: Process or Outcome?

    It is a question of means and ends. Should you focus on the process (means) or the outcome (ends)? Or both? Corporate…

    2 条评论
  • The Fog of Impact

    The Fog of Impact

    Imagine a multiplayer video game in which players compete to shoot goblins that appear in a foggy landscape. Some…

    2 条评论
  • Has Agile Killed the Business Case?

    Has Agile Killed the Business Case?

    If you are a single-product startup, you probably don’t need to write a business case for every new feature or…

    6 条评论
  • Don’t grow into Product and Engineering

    Don’t grow into Product and Engineering

    A startup usually begins life as a single-digit strong team with no boundaries. As they grow, they might soon find…

    9 条评论
  • Jugaad Product Development

    Jugaad Product Development

    Any business leader will tell you that regular product development takes too long. Setting hard deadlines rarely works.

    5 条评论
  • Guns and Deadlines

    Guns and Deadlines

    Does the practice of setting hard deadlines improve the predictability of software delivery? It depends on the team…

    4 条评论
  • How to transform the agile CoE

    How to transform the agile CoE

    Agility in innovation is a great marker of business agility. Innovation lead time for digital capabilities is the time…

    1 条评论
  • The agile CoE is about to die

    The agile CoE is about to die

    Update March 2023: Also see a follow-up post to this one here, titled "How to transform the agile CoE" Capital One, a…

    25 条评论
  • The flywheel and the slywheel

    The flywheel and the slywheel

    A flywheel multiplies value, a "slywheel" obfuscates it. If you can’t get a flywheel effect going within your…

    2 条评论
  • Visualizing Paths to Value

    Visualizing Paths to Value

    Customer obsession doesn’t always contribute to commercial success–the previous post made this point. Which means it…

    2 条评论

社区洞察

其他会员也浏览了