We’ve written before about the intersection of business, experience, and technology (BXT) and how it can help businesses to overcome roadblocks to growth and transformation. The following article provides a practical example of how working in agile teams with a BizDevOps mentality utilises the BXT principle for success.
- Traditional development structures and processes are often siloed, costly, slow and miss their market.
- A BizDevOps approach can overcome many of the problems businesses face with product development — though consensus on its definition is mixed.
- The collaborative model embodied by BizDevOps teams will lead to superior products that customers love and the business can get to market within budget.
BizDevOps (Business + Development + Operations) is like blockchain: it’s all the rage in modern business and tech best practice, but not everyone’s on the same page about what it is or how it should be used.
This is a problem because BizDevOps — the practice that brings your tech, operations and business people together to build, run and improve solutions and experiences for your customers — is necessary for organisations to compete in today’s world. Traditional approaches to product or service cycles — usually defined by a ‘plan, build, run’ or waterfall approach — simply aren’t fast enough.
BizDevOps bridges the gap between customer and code by bringing the marketing and product people into the team. It allows for a quicker and more customer-driven go-to-market approach. It’s no longer nice to have, it’s a necessity.
One of the issues with selling businesses on the usefulness of BizDevOps is that there is currently no single definition of what it is.
In a cultural sense, BizDevOps is the shared understanding, responsibility and collaboration between business, software development and technology operations team members. It is their shared values of delivering products and services that meet the needs of the customer.
But this cultural understanding is closely linked to its definition as an operating model. From a structural standpoint, BizDevOps is seen as the redesign of separate product and service teams into a team that is multidisciplinary and autonomous by nature. These teams have end-to-end ownership of the product from inception to execution. Gone are the days of a project team throwing their product over the fence to the operations teams.
And from a technological perspective, it is a combination of elastic, modular and scalable IT services with automated practices and frameworks that can deploy a product to market and be responsive to changes and errors in the most efficient, fast and innovative way possible for the business.
We like to think of BizDevOps as a bit of all three. A collaborative culture which enables a new model of operating (business, operations and technology together) to produce superior products and services through an automated pipeline.
Meet Ravi, Ying,
Barry and Jenny
To help wrap your head around the core concepts that lead to BizDevOps enlightenment, we’ve created some characters to show the importance of this approach in the current market.
Ravi, our marketeer, is the person in the business who understands the customer and shapes products. Barry, our development engineer, technically designs, codes and maintains products, while Jenny, the operations engineer, ensures it is deployed to customers like Ying, and keeps it operating at all times.
Why doesn’t the usual approach work? Let’s have a look at how a typical product gets to market in a traditional organisation.
Chances are you’ve experienced something similar to our intrepid four characters, right? While it’s a caricature of business and IT roles and interactions, the challenges are very real. Let’s look at where things go wrong.
First, there is a reliance on experts and a lack of customer centricity. New products are often created in isolation from the final users, instead sourced from the ideas of a few experts (such as marketeer Ravi), whitepapers and research articles. Even worse, sometimes the fear of falling behind competitors and industry trends motivates the organisation to launch new products or services without thinking them through.
Second, Ravi never talks directly to developer Barry, who essentially works in an IT department kept separate from the business needs. And Barry never talks to ops engineer Jenny, either. This lack of end-to-end ownership creates unnecessary handovers, slows down decision making and time to production. The absence of a shared roadmap and budget hinders the ability to plan, prioritise and innovate and creates the risk of increased overheads, IT costs and duplicate IT functions.
Worse still, slow decommissioning processes create a reliance on legacy technologies that require manual orchestration, by engineers like Barry and Jenny, and thus cause high operating costs. This leads to a disaggregated IT landscape — highly coupled assets, fragmented multiple portfolios, and added complexity when making product or service changes.
As day to day work is disconnected from business objectives, Ravi, Jenny and Barry are disengaged as they have no clear focus on the outputs or delivered end-to-end benefits. Most likely, they are working towards misaligned targets, being rewarded for compliance to siloed processes, which will culturally impede the ability of the organisation to pivot initiatives.
At the end of the day, the customer, Ying, is the one who suffers.
way to work
So how would it go in a BizDevOps workplace? Let’s see:
Using a BizDevOps approach, the team puts humans at the centre of the approach, developing and improving products and services around the customer, such as Ying. This means ensuring her needs, behaviours and attitudes are understood and validated.
Next they work as one team, dissolving the arbitrary lines between internal business and technology departments. Ravi, Jenny and Barry all collaborate, and as a cross-functional team they can focus on the products and services end-to-end. This close feedback loop minimises hand-offs, ambiguity in design and allows decisions to be made faster.
Behind the scenes, the team have modernised by automating processes that don’t need human thinking or creativity. The business has invested in agile processes and modular, scalable and automated technologies. This means Jenny and Barry can work together to continuously — and carefully, with automated testing —deploy updates.
With the business objectives aligned to the team’s everyday work, fewer internal and external metrics are needed to drive action and learning. Customer value becomes the most important measure — for everyone. To drive simplicity, focus and adaptability, teams are also learning to select the set of metrics that matters at each stage of a product/service lifecycle.
BizDevOps is a common-sense approach to the product lifecycle. Its cultural, structural and technological approach (or business, experience and technology in BXT speak) allows for quick releases, pivots, and ultimately, customer happiness. Even if you don’t see customers wandering the halls of your office to collaborate with engineers, the basic concepts can be applied in any organisation working with software. If you recognise any of the issues that Ravi, Barry and Jenny encounter in your own organisation, or worse, you’ve heard feedback similar to Ying’s from your customers, it’s time to think about a BizDevOps implementation.