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:
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.
Posit Fan
4 个月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.
Technology leader with an AI and entrepreneurship background
7 个月Dang, somehow missed the comments. Glad you found it useful/informative Steve and Philip!
Developer for Morgan Sindall Property Services
7 个月Great visual and post Stephanie Locke!
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.
Lead Data Engineer at Uinsure
7 个月Stealing this. Its so very relevant to an ongoing conversation I’m having