Resourcing BAU & Strategic Product Development

Posted: Aug 22, 2018 in Business, Product Development
Tags: , , , , , ,

Ops

All products will have an element of BAU (business as usual) and strategic work, where both are equally important to get after if the product is to remain competitive now and in years to come.

BAU work can also be referred to as ops (operational) work and I’ve always preferred the word ‘Ops’ over ‘BAU’ because no problem to solve should be looked at as solving it in the usual way which BAU can often be treated like. Also there’s often a stigma attached to BAU irrelevant of the business value it drives which is bonkers, so let’s look at the definitions of both:

  • BAU – work which doesn’t involve significant architecture redesign or thought, but BAU work is typically the blood line of the business
  • Strategic – work which involves a significant amount of up front technical design and often uses the latest / next generation technology. Strategic work often comes into play if there’s an architectural org restructure, the existing technical platform is no longer fit for purpose or it’s a new product

When it comes to delivering either BAU or Strategic work, there’s a couple of ways:

  1. Simply follow the same agile process which any other problem does, which includes adding a high level PBI (Product Backlog Item) detailing the problem to solve with value and then the Scrum Master / Team Lead looks well ahead in the product backlog to start contemplating approaching the ‘how’ with very close collaboration with the Technical Architect (TA) with the aim to get the item in a ‘Ready‘ state for development. This would in turn lead to the development teams planning in Technical Support backlog items to help the TA with technical designs, spikes or investigations well in advance of the problem appearing towards the top of the backlog which applies to both Scrum and Kanban.
  2. Split development resource into BAU only and Strategic only

The risk with No 1 is that the Scrum Master doesn’t collaborate with the Technical Architect soon enough resulting in the PBI hitting the top of the backlog before technical designs have started, causing significant delays to getting after the strategic work.

But there’s a much bigger risk to No 2 where there would naturally be a big reluctance for a team to work purely on BAU and therefore miss out on any green field project and there’s risk of breaking the ‘One Team’ mentality across the product development teams working on the whole product together and in turn impacting team morale.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s