BAU is Dead: Rethinking Software Maintenance | Patient Zero

As software development gradually shifts from a project centric to product centric approach, it raises questions around the concept of BAU (Business as Usual) and whether or not that has relevance in a productised world.

In a traditional project approach, once the business has jumped through the all the hoops to get approval, funding and resources, a development team is assembled. Typically it uses a combination of internal and external resources, builds something, and then hands it over to BAU – at which point development slows or stops and the clock starts ticking to the “rebuild”.

In a more product centric approach, there is an acknowledgement that much of the real business value is delivered post MVP (so at the end of the typical “project” stage), and there is an expectation that the product will continue to evolve rapidly, post MVP to achieve and maintain a good market fit.

This tends to clash with typical enterprise procurement and capex / opex cycles, and the result is often an A team MVP and B Team BAU arrangement . The big consultancies have been doing this A team B team switch for decades; put the guns in to build it, then put the B team in for maintenance.

The problem is that product evolution either stops or slows significantly at the handover to BAU, and never recovers. In an Agile world, where the initial build is an MVP, this is a disaster because the A team is disbanding at precisely the time when they are of most value – at the point where you start to get clear, actionable customer feedback.

Handovers don’t really work, because what you are really losing is the business and technical domain knowledge that is now embedded in the “team” that built the MVP. Understanding that the most valuable output of an MVP is not the software, but the domain knowledge acquired by the team that built it.

What’s the solution? I’m not really sure to be honest. I think benefits of building and releasing an MVP is a key Agile insight, and a useful foil to the A Team B Team dance of the larger consultancies. But we need an engagement model with a much longer tail, around 1-2 years. Team members may (and should) come and go during that period, but it’s a managed process that ensures that the team’s collective domain knowledge is maintained. The MVP team becomes the BAU team, because software no longer has the luxury of “Business as Usual”.