Bringing development and operations closer together to increase the business’ output – quite a lot of enterprises rely on DevOps to achieve this end. The organizational boundaries between functional silos of the IT are fading.

Now, there are interdisciplinary teams who are pursuing common goals and due to new available technologies, much more appealing service offerings are created. Alongside of Devops, the agile approach and automated processes help to accelerate the delivery of integrated services for innovative business models.

But it’s not a simple matter – quite a lot of changes are required for this process, which is a real test of strength for some IT organizations. Still, it is worth the effort, as the “State of DevOps Report 2017” (by Puppet)[1] shows it. According to the report, the high performers provide new code 46 times more frequently, among the more than 3200 respondents. They can also realize changes 440 times faster, while reducing the average recovery time by a factor of 96 and also reduce the error rate for changes by a factor of 5.

In light of these figures the questions is no longer whether DevOps makes sense, but rather how to implement the concept practically.

DevOps without business does not achieve much

There is a common experience, shared by multiple customer projects: A DevOps approach in IT doesn’t help much if the specialist department rapidly schedules proposals without any involvement of the actual IT department. As a reaction to these actions, IT takes an immediate and reactive stance, which is commonly experienced as a bottleneck situation.

What an enterprise needs instead is a change of attitude and work methods between all of the company’s parts. These changes envelope various business departments, as well as IT development and operations. Hence, we speak of BizDevOps. It is a set of interrelated and cultural changes, which IT and business utilize to drive the digital transformation of the enterprise.

Which difficulties can occur and how to best them can be described by a frequently encountered scenario of the everyday business life: The misconception of IT as a blocker.

Context changes are a costly affair

It is quite common that many business perceive IT-development and -operation teams as a blocker. There is a reason for that: IT is fully occupied with all the ongoing projects and change requests of the business, so that they have to routinely decline new requests. This of course has consequences: Single specialist departments will try to bind and keep the resource IT for as long as possible, so that they can achieve their individual agendas. Now they too are blocking IT. A situations like this quite often develops in such a way that it is not usual for development teams to work simultaneously on multiple projects.

And this constant context change is a very time intensive matter. The rule of thumb for the measurement of time loss through context changes (by Gerald M. Weinberg)[2] is the following: 10% multiplied by the number of all simultaneously ongoing projects. What does this mean? It means that a developer spends 30% of his time ineffectually if he works on three projects at the same time.

A reason for this inefficiency is the point that development teams must prioritize projects and changes (the service operation of already developed applications), without any knowledge about the higher goals or scheduling. There is also Eliyahu Goldratt’s Theory of Constraints[3] to take into account. It states that the waiting time scales exponentially with the percentage utilization of a workstation. This means that if there is an utilization rate of 100%, then the waiting time will be infinite.

In a situation like this, specialist departments are trying to break the blockade of their project by means of escalation. It does not help developer teams with sorting or processing any tasks, but quite often it is the only possibly way to induce development. Though the resulting, additional expanses tied to this process are quite counterproductive.

What developers can do

The blockade scenario is not only uneconomical, but also extremely demotivating for development teams. Enticing them to cooperate in solving the problem is therefore usually easy when they are given the opportunity to make changes. As a first and most important measure, closed feedback cycles with the various stakeholders in the company help to achieve this. Only in the interaction of all participants – in the sense of BizDevOps – the blockade in IT can be resolved permanently.

A variety of different methods and tools are used for the implementation, which can vary depending on the size, industry segment, starting situation and strategy of the company. In general, however, the following four measures can be identified as important steps on the way to an IT with higher added value.

Prioritize in accordance with overall business objectives:

As self-evident as this measure may seem – in many companies the corresponding specifications are grey theory. To change this, the development teams must first bring stakeholders together and raise awareness. Then it goes together to the answering of questions like: What are the main objectives? Which criteria apply for prioritization? How can competing interests be reconciled?

Create and communicate delivery transparency through metrics:

If it is clear to everyone, which services are provided in which period of time, then it will be easier for everyone involved to put together work packages, which then can be processed as planned. This also includes the tracking of the runtime of change requests and measuring the error rate: How many changes actually fail and thus cause rework?

Regular reporting for the team and stakeholders is an important contribution to the functioning of any DevOps organization. In addition, the basic principle applies independently of official communication: everyone should be open with information so that everyone involved can adapt to the current situation. In this way, all parties involved can perceive improvements or actively contribute to the elimination of deficits.

Organize work with Scrum Boards and Kanban Boards:

Methods such as Scrum and Kanban provide valuable tools to keep the focus even in a complex environment. But tools alone are not enough. All members of the team must always consciously focus on the common goals. Just because a task is quick and easy to check off, it does not necessarily contribute to the team’s current goal. Progress must be made together. Establishing small batch sizes, avoiding work in progress and completing tasks is important.

However, it is not always beneficial for the team that someone starts a new task as soon as they have completed one. To achieve a sprint goal, it is often more important to support others in their tasks. In addition, the joint work ensures that the loss of individual team members is better compensated for.

Retrospectives – Looking back to the future

Regular retrospectives with a focus on action items (measures) for continuous improvement show what has worked in the past – and what has not. This is the basis for improvement and for finding an answer to the central question: What can we do to better manage the full pipeline?

However, learning from the mistakes and successes of the past also requires time that has to be planned in advance. Gene Kim, Jez Humble and Patrick Debois recommend in the DevOps Handbook[4] to save twenty percent of the time for such improvements.

The implementation of the measures are the first step in the DevOps transformation, and experience shows: Anyone can set the start impulse – no matter if Biz, Dev or Ops!

Culture eats strategy for breakfast!

Explore the Business & Company Culture Track

Learn more

An example scenario

Here is a typical case of IT blockade: The marketing department of a large mechanical engineering company planned the relaunch of their website for two years. Originally the lead generation was to be boosted via the website. However all the maximum requirements of the business were compiled into a completely new website concept.

The result: The content management system (CMS) was replaced by a product for whose technology the own IT did not have the necessary know-how. Changes could only be implemented externally. It would have been much more effective if marketing and IT in the sense of BizDevOps had first tried out concrete changes in the customer approach together on the basis of the existing solution with A/B-Testing. The principle of “shift left” ensures the correctness of changes and their operability early in the development process. Marketing can contribute to this, by the participants using hypotheses to reduce their requirements to a minimum viable product.

The central question is: What is the minimum product that provides the customer with a benefit? This not only shows whether the required services and features are working. Rather, it becomes clear what benefits they bring. In this way, IT and business can expand the product step by step in close consultation.

This hypothesis-driven approach reduces the waste of resources for non-practical requirements in development. Functions that are of no use to the end user are not extensively revised and tested until they are ready for the market, but are sorted out in the prototype stage. In classical projects, on the other hand, experience has shown that more than half of the effort is often spent on functions that are of no importance to the user.