DevOps as an enabler for digital sales

Fast experimentation is a key part of growth hacking and these fast experiments are integral to efficient improvement of digital sales. But what if you are not able to run these experiments efficiently? What if it takes you months to release new features, or new releases seem to be riddled with bugs and instability? How do you reach the status of being able to start running these fast experiments?

One way to approach these challenges is utilising the DevOps practices and ways of working encouraged by the DevOps community. These can be used to lay the groundwork for fast experimentation in digital sales and growth hacking, and we have been using these tools efficiently in our work.

DevOps in a nutshell

DevOps as a term does not really have a single universally accepted definition, but the core idea is sometimes crystallised as a process for improving the speed at which new features are released to customers as code running in production. The concept has been established due to challenges faced in organisations where software developers and IT operation teams have been working in silos without efficient communication between teams, but has since been applied in a much broader way. The practices discussed by DevOps practitioners are closely related to agile practices and lean manufacturing, and draw a lot of inspiration from them.

On a more concrete level, a relatively straightforward view of DevOps can be summarised in three principles, as popularised by Gene Kim in the books The Phoenix Project and The DevOps Handbook. These three principles, also known as the three ways, are the principle of flow, principle of feedback and principle of continual experimentation.

Principle of flow

Principle of flow is built around the idea that software development can be treated as a flow, or a value stream, starting with ideas for new features and ending in code running in production. Furthermore, this flow should be seen as a single system that must be optimised as a whole without focusing too much on smaller parts of the system. Optimising only parts of the process leads easily to suboptimal results when local optimisation leads to global degradation. For example, when different teams are responsible only for their parts of the flow, they tend to naturally focus on making only their own work flow as smooth as possible without thinking enough about how their improvements affect other teams.

One important idea when considering software development as a flow is the theory of constraints, or simply bottlenecks. If you look at building software as a single stream, there would naturally be a single bottleneck in the process that defines the speed of the flow. Optimising the flow should thus primarily focus on identifying the bottleneck, and resolving it as that is where real improvements can be made. Any improvements made outside of the bottleneck do not improve throughput of the development at all as the bottleneck is still constraining the process.

An example of optimising the flow can be seen with continuous integration tooling. It is used to take a part of the flow that is often time consuming and very repetitive, building the code, and automating it. This both makes an often error prone part of the process straightforward, and lets developers focus on feature development, instead of routine tasks.

Principle of feedback

To make sure that improvements made to the process are actually improving flow of the entire system and the services being built, there should be effective feedback loops between different parts of the flow. If we focus purely on improving the speed of flow without feedback, we risk constantly introducing new bugs to the system, building the wrong things very fast and local optimisation. Having these feedback loops allows us to see what corrections need to be made. For example, automated testing provides immediate feedback to developers when potential bugs are introduced by code changes, and user analytics provide insights into how new features are received by users.

Principle of continual learning and experimentation

Similarly as in agile, this principle highlights the importance of continuous improvement and creating a culture where focus is on iteratively improving current processes. Improving the flow of work should be seen as a journey that is expected to include some mishaps and wrong steps. Example practices include having retrospectives, post-mortems on production incidents and reserving time for testing potential improvements.

Together these three principles lay the groundwork for thinking about continuous improvement of the software development workflow. Important to note is that DevOps is not only about technical solutions. The tools provide solutions to many of the issues that arise when applying these principles, but at the core DevOps is focused on improving the flow from ideas to code running production, accessible to customers.

Applying DevOps to growth hacking

If we then apply this line of thinking to improving our growth hacking work, we could phrase the question as “How do we maximise the speed at which we are able to try out new experiments?“ and start looking into how applying the three principles can be used to answer this. We are then able to identify what needs to be done for each new experiment, look at what is currently slowing us doing and start tackling those issues.

As an example, let’s look at potential questions that may arise and could optimised as a part of DevOps work:

• If you want to start a new A/B test, what needs to be done? Can anyone in the team use simple tools to create new tests?
• If your copywriter needs to change the texts on the front page or a shopping cart, are they able to do that themselves, or do they need help from a developer?
• How long does it take on average to release tested code into production? Is it measured in minutes, hours, days or even weeks?
• What happens if there is a large peak in the number of customers visiting your website? Are the services able to scale automatically with increased demand?
• When new servers are needed for a new service, how long does it take for them to be available? Can a development team start them up themselves according to existing guidelines, or do they need to wait for the IT department to have time in their queue to work with them?

Iterating through the growth hacking loop is often limited by technical and process challenges such as those listed above, and tackling them is an effective way to increase the overall velocity of experimentation in digital sales.

So, how to get started?

As usual with software, there isn't really a silver bullet that you can extract from DevOps that would solve everything neatly. While having tooling for e.g. continuous integration and delivery is often necessary, just setting up the newest system doesn't automatically lead to benefits from it. Building this automation takes time and has to be balanced against the benefits you gain in the long term. Given that, spending the time and effort in the short term on improving your flow of work has been shown to often be beneficial in the long run.

Getting started with applying the DevOps principles and gaining benefits from them can be simple. You don’t need to completely change your working practices, or a separate DevOps team, or new systems. Instead, one concrete way of getting familiar with the three principles could be starting to apply the following steps to your current process.

1. Make work visible. Identify all steps that are currently needed to release something new to your customers. This could be a simple list of steps, or maybe a Scrum or Kanban board.
2. Identify the current bottleneck. What is the biggest slowdown in the process currently? Where is the flow of work bunching up?
3. Figure out how that bottleneck can be resolved, and resolve it. This might mean e.g. setting up automation, improving communication between teams or simply getting rid of an unnecessary step.
4. Repeat. See how resolving the current bottleneck affects the flow of work, identify the next bottleneck and resolve that.

This minimal loop gets you started at looking at the flow of work and starting to improve it without the need to implement a huge process around it. While it seems fairly trivial, an iterative process of solving bottlenecks leads to significant improvements over time. Software development is a complex flow of work with good reason, and the simplest way to improve is iteratively, one bite at a time.

For more details, you can take a look at Google’s DevOps guidelines, the two books mentioned earlier, DevOps Handbook, and Phoenix Project, and of course, we are more than happy to have a chat with you about this.

Learn more on growth hacking with our Growth Hacker's Handbook, a guide offering you insight, learnings and tools to tap into your unleashed potential. Implementing growth hacking methods to your work will allow you to create a stronger impact through your work.