BizDevOps: Bridging the Dominant Divide between the Business and IT
Or: Why DevOps Success Needs a Successor
DevOps practices have had a huge positive impact on teamwork. However, the DevOps paradigm mainly focuses on the more technical aspects of delivering value as a team. A question posed after DevOpsDays Amsterdam 2019 illustrates the issue: we’ve come so far, but where is the business? In this article, I will share how we are trying to go beyond the success of DevOps to tackle the divide between agile DevOps teams and the Business. We have found our approach makes it possible to do true agile outsourcing while still avoiding much of the typical friction between business owners and developers, and I hope to inspire you to try our approach to BizDevOps yourself.
All too often, business stakeholders are unexpectedly involved in the development process, and business requirements tend to get lost in translation. This is why the solution provided by the development team often scarcely addresses the needs of the business, and little value is delivered. How can we best bridge that dominant divide between the Business and IT?
Recently I stumbled on this picture. It struck me that, if anything, our spacecraft have become more technically complex over time. Yet, somehow, we have managed to remove this complexity from sight over the years. At least it looks as if everyone could control a (SpaceX) spaceship nowadays.
When technology is hidden, it tends to become accessible for a broader public (this is known as democratization). Where public cloud technology (e.g. AI, ML, Deep Learning, blockchain—feel free to complete your own buzzword bingo card) from Microsoft, Google and Amazon is still targeting professionals, their respective low-code platforms—PowerApps, AppSheet and HoneyCode—are designed for citizen developers: those who ‘create new business applications for consumption by others using […] shared services, fourth-generation language (4GL)-style development platforms and cloud computing services’ (source). The same applies to the low-code platforms from Mendix, Betty Blocks, and others. Moreover, programming tools such as IFTTT, Apple’s Shortcuts, and good old Excel can easily be used by the average consumer.
With all this technology becoming available for a wider public, products and services are increasingly impacted. It’s not only internal or secondary business processes that are impacted: the customer-facing, primary processes of businesses are increasingly changing because of the driving force of technology and innovation. Just look at the premier provider of postal and parcel services in the Netherlands, PostNL, which has developed a digital alternative for postage stamps. Regardless of how this trend will develop precisely — it’s happening. Under these circumstances the business expects more from teams than ‘just’ doing their ‘DevOps trick’: they expect teams to understand that it’s all about creating value. If they don’t do that, the chances are that ‘the business’ will swipe their credit card and starts building themselves. That last point is an important difference compared to the business-IT gap in the 1980s.
Because the thing is, today, IT is mostly still totally separated from the business. It’s separated within organisations (different departments, islands, silos) as well as between organisations (when IT is being outsourced to a third party). Neither side understands the other, yet both expect the other to do more to understand them. There’s a lot of finger pointing and, as a result, real fortresses are built. A corporate immune system is delaying innovation and delays smart people finding an answer to the question how are the company’s products and services going to be impacted/changed/improved by all these new technologies?
The hierarchical structure of many organizations doesn’t help. It creates a comfort zone that discourages transparency and vulnerability. As an attempt at diplomatic cooperation, external consultants, project managers, agile coaches, and/or so-called ‘thought leaders’ are hired to function as translators between the two sides. Clearly this only addresses the effects of the divide, and fails to tackle its cause. Worse: it just introduces more overhead.
So, how do we bridge the gap between those who write code and those who write emails? Maybe I can share a bit about how we work together at Schuberg Philis, and what I’ve learned during my time there.
Imagine the collection of blue dots on the right is a team. Developers, Engineers, and Sales are roles that are typically represented in the dedicated customer teams of Schuberg Philis. When we’re about to embark on a journey with a customer, one of the first things we do is think about the roles we need those in the business to play (the yellow circles). What responsibilities do we expect? And which roles seem to fit those responsibilities? Do these roles generate the required mandate? Who do we need to contact to get this approved and arranged on the customer side?
Once all the roles are allocated, before the start of the project, we go and sit together in a room. We close the door. Call it a cross-functional team, self-steering team, X-team or even co-creation—the name doesn’t really matter. It’s about putting the people with the right knowledge, expertise, vision, and passion together.
We call this “whole system in a room”. In this setting, there’s not much hierarchy. It’s all about getting unnecessary management out of the way and putting experts in the lead.
The idea is to then cross over in each other’s space and commit to mutual bridge-building—to share the responsibility for building a bridge to the other side. Ideally, IT has someone from the business who talks their language, appreciates them, and even can be an advocate for them. The business then takes more ownership of tech decisions and understands better what‘s needed. Since both sides are involved in a single team, there’s no finger pointing.
So the challenge is to find people from IT and the business who can operate in the purple shaded area and won’t meet resistance from the business and IT sides, respectively. This is not a walk in the park. It really is more work and it can be very demanding to go over to ‘the other side’. We see from our colleagues, too, that they find it difficult to cross the space sometimes and show respect to either business or IT people. Each side has its own language and practices. Screaming ‘#noestimates!’ isn’t really helpful if business is trying to cope with milestones, budgets and release deadlines. Yelling ‘#justdoit!’ is just as unconstructive when engineers are trying to understand ‘the why’ before sharing their advice, let alone committing to a deadline. I think that, at the end of the day, bridging the gap boils down to things like vulnerability, honesty and transparency. Getting out of your comfort zone. Genuinely trying to understand the other person. When such an atmosphere is established, there’s no finger pointing—and the other party praises you for the partnership you’ve created together (this then replaces the more usual transactional customer/supplier relationship).
Getting into the same room with the right roles and disciplines can be very valuable for sharing project updates (think of the Sprint Review, for instance). In addition, we’ve found it to be a powerful way to kickstart projects. Getting into the same room from Day One creates an atmosphere of trust and transparency, which helps us realise short time-to-value together. Let me introduce the Proof of Value Pressure Cooker™. This consists of five phases that are typically executed in 1–2 weeks. These phases are detailed below.
1. Prepare
Well begun is half the work. This phase typically starts before the pressure cooker starts and is performed by the more solution- and/or technically oriented team members. It involves getting to the heart of the matter:
- So what is this really about?
- Why (why, why) are we doing this? Are we doing this?
- (How) can we be successful?
Only if all questions have a satisfactory answer, can the team continue to the next phase.
2. Ideate
This phase is where the business takes the stage, and shares their knowledge, experience, frustrations, wishes, ideas. IT is listening, in an emphatic way, trying to ask smart questions. In addition, the technical team members should ask themselves:
- Do we understand?
- What are we missing?
- Shall we start? When do we start?
3. Sketch
After the problem domain has been laid out by the business, it’s time for IT to reflect and share how they understood the explanation made by the business. Visualizing this interpretation helps mutual understanding. Moreover, sketching initial screens helps the team keep the final goal in mind, while answering the following questions:
- Is this what you mean?
- What should be changed?
- Is this going to bring you value? How? Why?
4. Prototype
This is where the magic happens. Based on all the notes, drawings, sketches, and other input from the previous phases, an initial prototype is built. As a prototype makes the results of the pressure-cooker process much more concrete and tangible, it implicitly asks these questions:
- What are the most important requirements?
- Is it clear enough who are our audience and who are the end-users?
- What are we going to deliver? And, equally important, what are we not going to deliver?
5. Decide
After the prototype phase—and lots of coffee—the prototype is presented to the business. It’s essential to ensure that the business understands what’s been demo’d and delivered (as well as the effort that went into it :-)). This phase is about asking and answering these questions:
- To which extent was value delivered?
- If so: what does it mean to go live?
- If not: what needs to be improved?
To be clear: my intention is not so much to introduce a new way to kickstart a new project. There are many more ways to do this. The thing is: if you start a project with The whole system in a room, you get an early notion of what you can expect during the actual project in terms of collaboration, communication, creativity and critical thinking. If it hurts, do it more early, right?
A pressure cooker gives you early insights. Either you know the whole thing is not going to work like this—e.g. the problem was not clearly defined, the business was not sufficiently present, feature creep is already occurring, and descoping is needed, or you have a quick, transparent way to add actual value, which could serve as a kickstart for the way of working during the rest of the project: BizDevOps.
With BizDevOps, it all starts with a business need. Within the team, the business defines that need in the form of requirements, which should be detailed and refined enough for the technical members of the team to plan and build them. After testing (it’s best if this is done by the business, too), release and deployment, monitoring data from both the technical and functional operations create primary input for the team — and the business in particular—to form new functional and non-functional wishes and requirements.
BizDevOps not only means getting together during the start or design of a project: it also means getting together during the run phase. Sit behind the desk of end users. Feel what they are experiencing when they have to wait five seconds during each and every login.
The product owner (or component owner, value stream owner, …) basically forms the glue between the three disciplines depicted above and he/she proves to be quite crucial for the success of this way of working. The product owner is virtually a mini-CEO who should be fully mandated to make decisions on behalf of the business. What’s more, this role should be respected by all other disciplines.
So, to sum up:
DevOps Needs a Sequel ♻️
We need to repeat the DevOps success of bringing Development and Operations together, with the Business. We need to double down on the DevOps approach of bridging gaps, and now work to bridge the gap between the business and IT. Different roles, beings, and struggles are involved. But the struggles are real.
Hierarchy = Comfort 🛋
Rethink your way of working, governance, and reporting. Get in the same room with at least three different roles: tech, business, project management/facilitation/delivery. Don’t even start if these 3–4 roles are not sufficiently established.
Technology is Everyone’s Business 🚀
Doing ‘just the DevOps trick’ alone isn’t going to cut it anymore. Business wants to be involved. BizDevOps is about organizing a short time-to-value, and it actually reduces risk as it allows things to fail early, and to fail fast—together with the business. After all, technology is now everyone’s business.
This story is based on my keynote talk at DevOpsDays Amsterdam 2020. In case you have any questions, remarks or suggestions: please feel free to comment below or drop me a line!
