A simple approach – a huge effect

The market for software solutions is constantly changing. What might be new today could already be outdated the following day. To survive in this market, you need a close, seamless working relationship between development and business units. There are two examples that show how this might work in practice.

Business, development and operations make up the cornerstones of modern product development in IT. BizDevOps, as this approach is called, attempts to bridge the gaps between business and IT.

What’s known as the “DevOps model” became established just over ten years ago. As far as IT was concerned, this bridged a gap that existed between development and operations. The goal was for newly developed software and new features to be released as quickly as possible.

But there was often a catch here. The requirements set out by business units would frequently be drawn up without consulting IT. This meant that the ideas and requirements of specialist units would often not take into account the capacity of IT departments. As a result of this, the speed advantage that should have stemmed from closer working relations between development and operations was ultimately lost again.

To prevent this from happening, the BizDevOps model was established. Business, i.e. the specialist units along with marketing and sales, is working more closely with IT to transform corporate visions into digital solutions. To see how this works in practice, I would like to give two real-life examples.

First an example of what not to do: when I first took on the role of product owner a few years ago, it wasn’t long before the requirements of other product managers started landing on my desk, the idea being they would be implemented in my application. The product managers assured me that these requirements had been worked on and fleshed out over the course of many months, and so there shouldn’t be any issues. So, being inexperienced as I was, I agreed, and incorporated the requirements into our sprint planning phase.

To cut a long story short: the people on the sprint planning team absolutely tore the requirements to shreds. The specifications we were looking at made no sense whatsoever given that the people who submitted them were not familiar with our systems. In the end, we had no choice but to start all over again on the planning phase with the developers so that we could actually come up with something useful.

Now for an example of things going better: I learnt my lessons from my initial experience in this new role. Before taking a requirement to the sprint planning phase, I first go through it with our developers, regardless of what the requirement covers. I also avoid taking highly detailed requirements to these discussions. Instead, what we discuss tends to be a vision of what the requirement should achieve. This saves a lot of time, money and stress. Ideally, these discussions should only take around ten minutes: I briefly outline the requirement and put forward a proposed solution, at which point the developers respond right away and put forward their own ideas on how to reach the goal more efficiently.

BizDevOps to me is an approach/guide that can be applied to various agile models. It doesn’t matter if it’s Lean, SAFe, Scrum or Kanban we’re dealing with. All that matters to me is that everyone involved plays a role in finding solutions.