Revision vs Innovation: how Ops Run It denies you huge value (part 5)

Do you find your teams are continually reworking features? If you’re stuck in an endless cycle of rebuilding and re-releasing features, it’s difficult to deliver valuable new innovations for your customers.

In a recent study conducted by Forrester, an organisation was able to reduce their cost-to-deliver by saving over 3,000 hours of engineering time.

If you’ve read the other articles in this series, you’ll note this is in addition to the $41 million worth of net-present value the organisation was able to realise by improving time-to-market and reducing their ‘concept to cash’ timeline.

How did the organisation realise these incredible results?

By moving to the You Build It You Run It operating model and implementing paved roads.

If you currently support digital services in the traditional Ops Run It model—where teams are segmented by responsibility into ‘Delivery’ and ‘Operations’—you could be denying yourself huge value by engaging in unnecessary rework.

Throughout this article series, I’ve looked at how and why this could be the case:

• Part 1: Ops Run It prioritises stability in a way that fundamentally stops you from delivering at speed (which you can read here).
• Part 2: Ops Run It involves an unnecessarily laborious and manually intensive deployment pipeline (which you can read here).
• Part 3: Ops Run It limits the agility of the development team, making it harder to respond to rapid changes in market conditions or evolving customer needs (which you can read here).
• Part 4: Ops Run It involves an overly strict change management process (which you can read here).
• Part 5: Ops Run It involves a higher rate of rework, which can compromise new feature development (this article).

Ops Run It involves a higher rate of rework, which can compromise new feature development.

Let’s go straight to the data on this one. The following graph is taken from a client I helped to adopt the You Build It You Run It operating model.

The yellow bars in this graphic represent the rate of rework completed by a product team working in the Ops Run It model over a two-year period.

The blue bars represent the rate of rework completed by the same team while working in the You Build It You Run It operating model.

The difference is significant. And the implication is damning: if your development teams are spending time reworking features, they’re not able to deliver valuable differentiators for your customers.

What are the reasons for this higher rate of rework?

In my experience, there are two main reasons.

1. Ops Run It enforces a distance between the Delivery team and your end customers.

In the Ops Run It model, the Delivery team (the developers who actually build new features) hand off everything they build to an Operations team. As a result, they have no visibility of how the features they build are used by customers.

They also have very limited insight into the general behaviours or needs of their customers in the first place.

When you don’t know your customers, it’s hard to know what they need. And that’s when rebuilding and wasted resource is likely to occur.

With limited visibility of the customer, there’s a higher likelihood that the Delivery team will build features that do not align with the actual needs of customers.

These features won’t be used by customers, creating a scenario where the team needs to rebuild things in a way that aligns with what customers actually want.

2. When Delivery teams are solely responsible for deployment throughput—and not availability—they are more inclined to permit technical debt in what they ship.

Nothing against Delivery teams here. In my experience, this is just human nature.

In Ops Run It, Delivery teams aren’t called out at 3am to rectify any incident in production. This is because incidents that interrupt service availability fall within the remit of the Operations team.

The Delivery team is judged on their ability to hit delivery milestones. Not availability milestones.

So, they are sometimes perversely incentivised to cut corners in order to hit those milestones. Sometimes, to the detriment of the availability of what they’re building.

This technical debt needs to be repaid if there are issues in production. And the payback of technical debt becomes an interruption to BAU development. This is because these issues need to be fixed as they present, rather than through proactive planning or work sequencing.

With these constant interruptions to BAU feature development—and the rework associated with fixing technical debt—it can be difficult to dedicate time to delivering new, innovative features for your customers.

You Build It You Run It puts teams closer to their customers. And eliminates the lure of technical debt.

In You Build It You Run It, teams are much closer to their customers.

They have clear and constant visibility of how customers use what they build, because the team who builds the software then runs the software in production. This means they have a far better understanding of what to build to align with customer needs.

Additionally, because the one team owns every aspect of the development lifecycle, they can react quickly to customer needs. They’re also better placed to react quickly to evolving customer needs and prioritise delivery of the feature that unlocks the most value in any given moment.

Teams in You Build It You Run It are also much less inclined to leave technical debt in the software they build.

This is because they themselves are required to implement any fixes in the event of a failure in production. This includes out of hours support.

As a result, these teams are actively incentivised to build proactive contingencies into their software that safeguard service availability.

This includes measures like graceful degradation, where services cascade on failure to prioritise mission-critical functionality in the event of an issue.

When teams are less distracted or preoccupied with reworking problematic existing features, they’re able to deliver new and exciting features for customers. This consistent innovation at pace—and scale—is proven to be key in

• delivering significant return on investment
• differentiating your service offering from your competitors
• unlocking the substantial value that may be dormant in your teams.

When that value could add up to the tune of USD$41,000,000, it’s worth investigating every avenue to unlock the potential in your business.

If you’re stuck in a perpetual cycle of rework and constantly struggling to deliver anything new—despite your Delivery teams being tied up—You Build It You Run It could be the answer.

That completes my five-part series on Ops Run It and the impact it can have on your time-to-market.

To recap and close things off, let’s run through the five ways Ops Run It can impede your ability to deliver new features for customers, both rapidly and consistently.

1. Ops Run It prioritises stability in a way that fundamentally stops you from delivering at speed.
2. Ops Run It often involves an unnecessarily laborious and manually intensive deployment pipeline.
3. Ops Run It limits the agility of the development team, making it harder to respond to changes in market conditions or evolving customer needs.
4. Ops Run It involves an overly strict change management process, which causes delays for releases and costs you in unrealised value.
5. Ops Run It involves a higher rate of rework, which can compromise new feature development (this piece).

If you feel like you’re struggling with any—or all—of these issues, I’d love to help you pinpoint the problem and get more value out of your team.

Get in touch today and start capitalising on untapped potential in your business.