Discussion: Harnessing the power of DevOps to collaborate with digital sales

Mikko and Rory bridge the gaps when it comes to unifying IT and developers with digital sales and marketing teams.

Here they delve deep into several topics around DevOps — specifically something they call full-cycle DevOps — and share their experiences, thoughts and perspectives about what it means as a way of working in digital sales.

Let’s talk a little bit about DevOps and full-cycle DevOps

Mikko: Real simply, full-cycle DevOps is a set of organisational practices that expands DevOps from being solely for development and operations to spreading the shared ideas throughout an organisation.

Rory: That’s right. DevOps is the combination of development and operations. Basically, this philosophy proposes a series of improvements to ways of working, where the development team and the operations team aren’t in two separate silos. The fundamental idea of DevOps is combining these two teams, with a single philosophy of, “What you build is what you operate, in the long-term”.

Mikko: While the idea behind DevOps is to narrow two teams' processes down to one, full-cycle DevOps does the same, taking into account multiple teams. For example, streamlining the processes of marketing, development, operations, sales and so on all into one.

We broaden this from the ideation of development and operations and think about how we can build new services fast and effectively.

Rory: One idea I like to think of is decreasing the time to value for a software process. So, within the development team, you could decrease the time to production, where you have a change in the code and reduce the time that it takes to reach production. That would be an optimisation within the development team.

But when you look at that on a broader system or operation level, you can decrease the time to value: between the conception of an idea of some change and getting business value as an end result.

By reducing all these bottlenecks and introducing communication channels, the time to value organically decreases. It’s bringing out these optimisation tactics — which are quite common in development processes — and applying them to a broader system level with the business objectives as the main goal. “Time to value” is a nice way to describe it.

What is the rationale behind digital sales, marketing and development working under a single shared philosophy?

Mikko: It allows everyone to look at the entire process of creating value to customers as a single process. You can then optimise the single process as one unit. In other words, there is continuous improvement and assessment of the bottlenecks preventing us from getting things done.

Rory: Bottlenecks are an important idea when talking about improving processes.

Mikko: One example of a bottleneck on the development and operations side is when developers are ready to pass their code over the wall to the operations team. The operations team then needs to figure out how to get the code running in production. That’s a bottleneck. 

Instead, what if the developers handle this themselves? They figure how to get their code running in the production environment and how to automate the process, and skip this handover process altogether.

On the digital sales and marketing side, it could be that they have a very good idea of what they want to build, but they have no communication channel to the development team building it for them. And the bottleneck fix there could be simply creating this communication channel for them.

If you’re not under a common umbrella or unified organisation, people will naturally tend to focus on and improve only their own part, which can make their colleagues’ work more difficult.

Rory: And obviously, team members have different competencies and skills. When there is a shared mission and shared vision, for whatever you’re looking to deliver, then there’s the likelihood of running into scenarios where you’re over optimising a certain box or making changes at the expense of something else.

We should mention the contribution that goes into the general working culture. By having everyone in meetings and involved in some way in a product that’s being delivered, you’re more likely to have a successful delivery of that product or service. 

Everyone that’s been involved has been fully invested and able to share opinions on what she or he felt should be developed there. So, it’s not just about optimising existing processes. It’s also about how to resolve the age-old issues of communication problems within many digital teams.

Mikko: This also enables a much better understanding of what the different teams and areas are working on. So, a developer will see more and get a better understanding of the issues that digital sales and marketing are tackling, instead of just receiving a list of requests. This creates a constant dialogue between the developers and sales and marketing, along with a better understanding as to why the business wants something fixed and the reasoning behind it.

And on the flipside, sales and marketing colleagues gain a better understanding of the system being built. They see what kinds of tasks might be trivial and might take half a year to be completed. This allows them to prioritise by themselves the must-haves.

Let’s talk about what a good set up of full-cycle DevOps should look like in the optimal situation

Rory: As with many problems, this depends on the business case and the intended outcomes for the organisation. The core philosophy of this is that all relevant stakeholders have a shared space and platform to be involved in the entire value stream of a product or service.

The way this takes shape can vary.

“There is no end-goal. There is no perfection. You want to ensure that you have a culture of continuous improvement in place all the time.” — Rory How

It could be as simple as having a weekly meeting together where each of the different teams helps set the development goals for the next weekly period. Very easy and straightforward.

Or you could go further and involve different areas of teams and include them in these feedback processes to see what’s being developed. Ask if the development initiatives meet the goals of the objective. The main idea here is involvement: allow them to communicate and express what they think should be developed and included in the end result. This way they feel they have a stake in it.

Rory: The overarching message here is that there is no end-goal. That’s the truth. There is no perfection. You want to ensure that you have a culture of continuous improvement in place all the time.

That sounds a lot like agile development, which has been all the craze the last 20 years or so. How is this different?

Mikko: That’s a good question. I see agile development and DevOps as complementary methodologies. Some key ideas in agile are focus on customer collaboration, early delivery, flexible planning and adaptive response to change. These key ideas of agile direct the team to focus on building the right thing right now, and not just building what was defined in some requirements document a year ago. DevOps then complements that work. With DevOps the driving idea is optimising the flow of work through the development process. So agile aims to make sure we are doing the right things, and DevOps makes sure we are doing those things as efficiently and reliably as possible.

Rory: And if we compare agile specifically to full-cycle DevOps, we see a similar division. Agile methods help the team to focus on the right things as a team, and full-cycle DevOps practices make sure they are constantly working towards one efficient process from an idea to code running in production.

“If the DevOps mentality already exists in IT, which in most cases it does, then expanding the full-cycle DevOps set up begins with setting up a communication channel where you start to bring the teams together.“ — Mikko Karjalainen

How would someone in IT start to introduce a full-cycle DevOps process as a first step?

Mikko: Fundamentally it is about bringing people together. If the DevOps mentality already exists in IT, which in most cases it does, then expanding the full-cycle DevOps set up begins with setting up a communication channel where you start to bring the teams together.

And you’ll need to tap a “champion” from both sides — someone from IT and then someone from digital sales or marketing. And it’s usually someone who will genuinely want to be this champion.

It’s bringing them together and asking them to look at the problem. It’s usually something common and they start ideating some solutions that both sides will want to see implemented and running in production for the customers. Then they start to identify the goals. In a full-cycle DevOps set up we look beyond connecting two teams, and instead at all relevant teams and stakeholders within a business operation.

Rory: One thing to reinforce here is that a full-cycle DevOps team process doesn’t mean everyone has to be involved. It’s important to know that if you are involved or tap someone to be involved, involvement should only be in the spots that are relevant to your working area.

Deciding who should be involved is something you learn over the course of implementing these types of processes. It’s a common practice to have a kick-off or workshop where many different stakeholders are involved. By having a larger number at these early phases, colleagues can make their own decision as to what’s relevant for their area, where they fit in, where they can have the most impact and so on.

If your teams are working towards shared goals, it should allow people to self-optimise and to naturally pick and choose where they feel they’ll have the most impact.

Mikko: That’s a good point. It also brings up a second important thing for getting started with full-cycle DevOps. The team and the people within need autonomy, to decide without asking for permission from a change management board, for example, for every change they’re making.

Rory: Yes, that would be a bottleneck. Of course, there’s an element of trust that has to be introduced and given to various teams so that they will make decisions with the business objectives in mind.

Having that implicit trust is crucial, otherwise it’s very difficult to let go of something. By giving the trust and autonomy to the team with the expectation that they act in terms of the business objectives under this shared goal, then you can remove these bottlenecks quite easily.

Mikko: The final piece in this puzzle is to ensure a culture of continuous improvement. Start looking for the bottlenecks and solving them one-by-one. It doesn’t need to be more complicated than that. Establishing these three ideas — continuous improvement through identifying bottlenecks, a single full value stream team, and trust and autonomy for the team — is enough to get started.

This blog post is part of The Digital Sales Handbook for leaders in IT. The handbook is a crystallisation of the key themes leaders in IT need to understand in 2021 to push their digital-enabled sales forward. The book includes interviews with industry experts from companies including Stora Enso, SAS, UPM and Tiger of Sweden. Learn how your IT can become an active driver for digital sales!