Developer velocity is choked on BAU
Velocity is choked by maintenance

Developer velocity is choked on BAU

Software allows us to meet customer and employee needs but like an asset, software needs maintenance. Whether it's something you buy off the shelf (Software as a Service) or build your own, someone still needs to administer it and ensure changes happen properly for users. Especially, when we build our own solutions we face a challenge of balancing new capabilities with maintenance and business as usual (BAU) tasks. The more maintenance needing to be done, the slower your developers can deliver new value leading to a feeling of frustration with how quickly your IT team can respond to new requirements.

In this article, I will explain how maintenance and BAU can reduce the ability of software engineers to deliver more business value over time, and share some tips on how to reduce Business As Usual.

The problem of maintenance and BAU

Maintenance and BAU are the activities that software engineers have to perform to keep the existing features and systems running smoothly and securely. They include tasks such as fixing bugs, updating dependencies, monitoring performance, troubleshooting issues, applying patches, and complying with regulations. While these tasks are necessary and important, they can also consume a significant amount of time and resources that could otherwise be spent on developing new features and improving the user experience.

Contoso - a worked example

To illustrate this problem, let's consider a hypothetical example of an ecommerce retailer called Contoso.

Contoso have recruited two teams to work on features for their new AI interface for their app. As a starting assumption, the teams will run in an agile fashion and they can do 100 story points of effort a week. The product owner has a backlog of features they want to build next and they're, handily, 200 points of effort each.

Please note I've taken gross liberties with agile methodologies to provide illustrative maths.

The 10% BAU team

Let's start with the processes, tools, etc one of the teams uses will need 10% of their time, or 10 points of effort, to go on maintaining each feature once it's live.

They start working on features and they get their first feature out in a sprint or two weeks. (100 points of effort per week available for new features)

They start their second sprint to deliver their second feature but now they didn't finish by the end of their sprint. They had 20 points still to do! (90 points of effort per week available for new features, 10 points of effort used on BAU)

On their third sprint, they finish off their second feature and crack on with their third. By the end of the sprint, they managed only 150 points worth of dev. (80 points of effort per week available for new features, 20 points of effort used on BAU)

Skipping over a few sprints to the eighth, they haven't even finished their sixth feature and this new dev team is deeply unhappy because they're spending half their time doing BAU and they're really late on where they thought they would be. From the business perspective, the team isn't delivering on the big AI launch the CEO wanted.

10% Maintenance perspective - over time the delivery of features. By the end of 8 sprints, 6 features not quite been completed.


The 5% BAU team

Let's now assume the other team's platform and processes are a bit more effective so it'll be 5% of their time, or 5 points of effort, being needed to go on maintaining each feature once it's live.

They start working on features and they get their first feature out in a sprint or two weeks. (100 points of effort per week available for new features)

They start their second sprint to deliver their second feature but now they didn't quite finish by the end of their sprint. They had 10 points still to do, which is 10 points more than the 10% team. (95 points of effort per week available for new features, 5 points of effort used on BAU)

On their third sprint, they finish off their second feature and crack on with their third. By the end of the sprint, they managed 180 points worth of dev, 30 points more than the 10% team. (90 points of effort per week available for new features, 10 points of effort used on BAU)

Skipping over a few sprints to the eighth, they've almost finished their seventh feature and this new dev team is grumpy because they're spending 30% of their time doing BAU and they're bit late on where they thought they would be. From the business perspective, the team is much more capable to deliver on the big AI launch the CEO wanted than the 10% team.

5% Maintenance perspective - over time the delivery of features. By the end of 8 sprints, 7 features not quite been completed.

Contoso lessons learnt

After 8 sprints, there's a clear difference in the teams delivery rates with the 5% team more than a whole feature ahead of the 10% team already. The 5% team spend less time on maintenance, allowing them to deliver more quickly on business goals. The 10% team would need to spend at least a couple of weeks to reduce down their BAU burden, further putting them behind, but giving them more throughput capability going forward.

The benefits of reducing maintenance and BAU

Reducing maintenance and BAU can have a positive impact on the software engineering team's ability to deliver more value over time. By spending less time on maintaining the existing features and systems, the team can allocate more time and resources to developing new features and improving the user experience. This can lead to faster delivery, higher quality, better customer satisfaction, and more competitive advantage.

How to reduce maintenance and BAU

Reducing maintenance and BAU is not an easy task, and it requires a strategic and proactive approach from the whole team and a willingness at the executive level to support proactive investment in the platform and processes associated with it. Here are some recommendations on how to reduce BAU:

  • Reducing administration of platforms to reduce operations time. This can be achieved by using cloud services, managed services, and automation tools that can handle the infrastructure, configuration, deployment, and scaling of the software systems.
  • Ensuring code quality to reduce defects and code amendment time. This can be achieved by following coding standards, best practices, design patterns, and principles that can make the code more readable, maintainable, and testable.
  • Top notch observability to avoid extensive debugging. This can be achieved by using logging, tracing, metrics, and alerts that can provide visibility and insight into the behavior and performance of the software systems.
  • Security and automation at every step to ensure safe and fast deployment. This can be achieved by using security tools, policies, and processes that can protect the software systems from threats and vulnerabilities, and by using automation tools, pipelines, and workflows that can enable continuous integration and delivery.
  • Scalable by design to avoid efforts scaling solutions when volumes vary. This can be achieved by using architectures, frameworks, and technologies that can support the growth and change of the software systems without compromising the quality and performance.

Conclusion

The organisations who have lower BAU burden will move faster than their competitor.

Maintenance and BAU are inevitable and essential aspects of software engineering, but they can also reduce the ability of software engineers to deliver more business value over time. By reducing maintenance and BAU, software engineers can increase their velocity and productivity, and deliver more value to the customers and the business. To reduce the impact maintenance and BAU has on your organisation's developer velocity, you need to adopt a strategic and proactive approach that can optimize the operations, quality, observability, security, and scalability of software systems.

Ironically, most organizations where I have worked try to reduce BAU by just not updating software tools, but the result is that BAU costs escalate because we spend most of our time fighting out of date software tools. I am thinking right now about a network servicer with an out of date OS that now does not work well with other applications. In the past, trying to convert data for use with Excel 95 when the year was 2012.

回复
Stephanie Locke

Technology leader with an AI and entrepreneurship background

7 个月

Dang, somehow missed the comments. Glad you found it useful/informative Steve and Philip!

Mark Richey

Developer for Morgan Sindall Property Services

7 个月

Great visual and post Stephanie Locke!

Ian Alderman

Driving digital transformation with deep expertise in strategy and architecture.

7 个月

Love this Stephanie, such an important aspect that isn't often factored with the obsession around releases. The simple power of naming things usefully and writing clean focused code that can be extended or replaced easily cannot be overstated. Using show and tells for new code, and retrospectives for old can be a great way to surface some of these opportunities and keep pushing the bar up.

Steve Powell

Lead Data Engineer at Uinsure

7 个月

Stealing this. Its so very relevant to an ongoing conversation I’m having

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

Stephanie Locke的更多文章

社区洞察

其他会员也浏览了