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.

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.

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.