DevOps: Bridging the gap between business and development

Day by day, companies are becoming more reliant on applications to help them remain competitive and break into new markets. In line with this growing dependency comes an equally growing number of trends that influence the way an application is designed. This can be anything from changing business needs to market trends, themes, user stories, and more.  

There are two very clear communities when it comes to app development. Firstly, there are the business stakeholders, who define the product direction from a business perspective. Then there’s the DevOps team in charge of testing, building and delivering the product itself.  Each app development project I have worked on has had these two distinctive constituencies, one focusing on how to surpass customer expectations with competitive differentiators while the other looks at interpreting those definitions and translating them into a real life application.

This all sounds like a reasonably simple process. But, in reality, expectations around what a service or product should look like differs from role to role, and it’s impossible to use one single approach to fulfil everybody’s communication needs.

When communication breaks down, the biggest loser is the customer, who ends up with a poorly designed product or service. So how can companies bridge the communication gap between DevOps and business stakeholders to build the best applications possible for customers?

A spotlight on customer expectations

There is no straightforward explanation as to who defines the direction of a product. Not only does this vary between companies but it also stretches across a variety of roles – from sales reps and product managers to marketing and services delivery teams.

These various stakeholders collect and share information in a range of different ways. However, they all need to work towards the common goal of creating a great customer experience with a product or service that sets them apart from their competitors.

It’s vital that businesses invest time and effort in the initial phases of development, gathering information and planning thoroughly, if they are to develop a truly innovative and useful product. The most common areas to consider when starting this process are customer feedback, market trends, analyst reports and competitive analysis.  

This analysis should represent the views of numerous stakeholders across the company, with as little confusion as possible. It should lead to a positive outcome through effective and focused collaboration between the two constituencies of business stakeholders and DevOps.

Living by the backlog

Those working in agile must focus on helping the development team understand what needs to be delivered. Agile workers create, validate, break down, estimate and rank user stories in the backlog, and they need as much information as possible in a story in order to:

1) Estimate: the story must be clear and consistent for the team to understand it and estimate effectively

2) Deliver in a single iteration: multiple iterations may lead to confusing results, so it’s important that stories are small enough to be delivered in a single iteration

3) Test: clearly outlined acceptance criteria enable the team to decide the best test strategy and create appropriate test cases to verify the delivery of the story within a specific build

As the number of iterations increases, so too does the backlog alter its form and its size. The form can change as stories spread following prioritisation exercises. The size can also change, growing in line with the addition of new user stories which support different trends like defects or development research spikes, or shrinking due to the removal or replacement of stories. 

The evolution of the backlog is key as it reflects the journey towards the final product or service – it is the single source of work that agile teams deliver against. With this in mind, the question arises of how these stories should be written – should they be written to reflect the needs of the business, aligned with the views of the business stakeholders? Or should these stakeholders adapt their practices and communicate their requirements as user stories instead?

Finding a halfway point

Neither the DevOps team nor the business stakeholders should have to alter their processes to deliver applications better and faster. They should be able to express their needs in different manners while still communicating in a way that ensures all parties understand what is being delivered, and how. 

It’s important that the agile development team needs to focus on adding value to the business by delivering functionality through agile principles, tools and processes. It also needs to ensure the stories within the backlog represent the priorities requested by the business stakeholders.

In turn, these stakeholders need to understand how the development team has broken down and prioritised the business needs into stories. They also need to be aware when a priority changes in the backlog and what this means.

Organisations need to bring these principles together and bridge the communication gap between DevOps and business stakeholders. Only then will we see applications being built that give businesses a real competitive advantage and that are truly enjoyed by customers.