days
0
-7
hours
-1
-9
minutes
-2
-8
seconds
0
-1
search
Biz + Devs + Ops = Success!

DevOps becomes BizDevOps: 4 steps to add more value to your work

Sebastian Schulze and Jacob Tiedemann
devops
©Shutterstock.com / Farizun Amrod Saad

DevOps’ full potential can only be achieved if development and operations work together with the specialist departments and management on a value adding product. Instead of DevOps, it should be called BizDevOps. Sebastian Schulze and Jacob Tiedemann explain how the integration of business and DevOps changes the cooperation, organization, and processes of companies.

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 are creating more appealing service offerings thanks to new available technologies. 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 shown by the “State of DevOps Report 2017” [1]. According to the report, high performers provide new code 46 times more frequently, among the more than 3,200 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 that 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.

SEE ALSO: “We conflate productivity with value too often”: Finding the right metrics for DevOps

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 [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.

SEE ALSO: DevOps-driven development and delivery

What can developers 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.

1. 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?

2. 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.

SEE ALSO: Breaking down silo walls: “DevOps is not an engineering discipline”

3. 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.

4. 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!

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. On the other hand, experience in previous projects has shown that more than half of the effort is often spent on functions that are of no importance to the user.

SEE ALSO: Top 4 challenges to adopting DevOps and the best ways to resolve them

Links & Literature

[1] Forsgren, N., et al.: “State of DevOps report. Puppet Labs and IT Revolution”, 2017
[2] Weinberg, Gerald M.: “Quality Software Management, Volume 1, Systems Thinking”
[3] Goldratt, Eliyahu M.; Cox, Jeff: “Das Ziel. Ein Roman über Prozessoptimierung”, Campus Verlag, 2013
[4] Kim, Gene; Willis, John; Debois, Patrick; Humble, Jez (2016): “The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations”, IT Revolution, 2016

Author

Sebastian Schulze and Jacob Tiedemann

Combined, Sebastian Schulze and Jacob Tiedemann have 20 years of experience in developing Java web applications. As member and leader of the consulting and implementation unit “Digital Growth” of the direkt gruppe GmbH they consult organisations as DevOps evangelists and agile coaches. Their work is dominated by the “Lean Startup” principles and the idea of Corporate Entrepreneurship.


Leave a Reply

1 Comment on "DevOps becomes BizDevOps: 4 steps to add more value to your work"

avatar
400
  Subscribe  
Notify of
Kovair Software
Guest

Establishing the point from DevOps to BizDevOps is very commendable. Very well explained and all 4 points are equally valid and important. Would like to share more details on these topics, please visit – https://www.kovair.com/tag/devops/