Printing, Personal Computing and Mobile BoardsHave Been Migrated to HP Support Forums

Open Menu

Printing, Personal Computing and Mobile BoardsHave Been Migrated to HP Support ForumsOpen Menu

We have completed the migration of all boards within the Printing and Digital Imaging, Desktops and Workstations, and Mobile categories to the HP Support Forums. Please see this post for full details on the migration, and how to get to your content.

Welcome to the Discover Performance blog, a resource for enterprise IT leaders who share a passion for performing better. Here you’ll find strategic insights and best practices from your peers as well as from HP’s own practitioners who help others define, measure and achieve better IT performances.

Miron Mizrahi has had a career spanning more than 20 years in the software industry. In recent years he served as the WW Solution Lead for Business Service Management (BSM) as well as Converged Infrastructure for HP Software Professional Services, where he is now a Portfolio Strategy Lead.

Herman Willemen is a veteran in the Information Technology industry with a career across hardware, software and services. In his current tenure with HP Software Professional Services, he serves as the Business Development Lead for Application Lifecycle Management across EMEA. As a Six Sigma black belt, he frequently contributes to process improvements in the services arena.

Do you know an IT organization where everyone’s showing “green” yet the results tell a different story? When an individual team within a company focuses only on optimizing its own area, team members are often oblivious to what’s needed for the company as a whole to be successful. Each team member doing a terrific job in his or her own cubicle doesn’t cut it when that work has to be handled - or mishandled - by someone else before it moves on to its ultimate use.

Consider this not-so-hypothetical example: A developer proclaims his work is done when his code is checked into the source control system. The day before release, our developer (who has already begun work on another project) looks up to find the project manager, plus one or two others, gathered around his desk. “The build isn’t working in staging and the error log indicates a missing file,” they say. To which our developer replies, “It worked when I tested it. Doesn’t staging have the latest version of …?”

So now changes must be made to allow for backward compatibility so another build can be deployed to staging. QA and Ops will have to work late (again) to test the new build and stage it for production before the release tomorrow. In the long run, this kind of waste is not only demoralizing, it also affects your organization’s ability to compete.

The DevOps approach

Now imagine a company where the heads of Application Development and IT Operations agree to try a different approach, pursuing incremental evolutionary change (driven by customer demand) across their departments.

A collaborative thinking approach between Dev and Ops will show that problems are typically inherent in the system and the processes, not the people. As both development and Ops teams organizationally focus on common goals, the DevOps principle of “optimize the whole” spreads through the organization, making continuous improvement possible. Here are three steps to achieving this.

Step 1. Analyze demand across team boundaries

Dev and Ops need to step back and objectively look at their productivity, asking these questions:

Where does our work originate?

What types of work come in?

What is the rate at which work comes in?

What are the expectations from upstream and downstream customers?

As a result of this process, Dev and Ops will now see problems that are hurting the business, but which have previously been ignored. For example, if customers have been complaining that sustainment changes aren’t being delivered, a demand analysis would make visible that sustainment work is not getting done and that there is no adequate “service delivery” capability for sustainment work. Perhaps it’s due to a perceived higher value on new work from another business unit – or perhaps there is no real bandwidth for sustainment work, other than employees burning the midnight oil.

Step 2. Take a service-delivery approach

Once you understand what work is coming in and what blockages are preventing work from getting done, Dev and Ops can take a service-delivery approach to resolving these problems.

For example, considering demand might reveal variability that randomizes the process and prevents work from being executed consistently and delivered on time. Perhaps the codebase branching strategy being used has crippled the ability to merge certain changes until other changes are also ready for delivery. Using a collaborative thinking approach that is focused on service delivery it becomes acceptable to experiment with new branching strategies.

Or you might discover that Ops are being supplied with confusing and inadequate information that makes it hard to do their job. And you may find that adopting explicit policies that define sufficient handoff information between teams solves that problem.

Step 3. Base decisions on and drive behavior with metrics

To truly gain efficiencies from a DevOps approach, you need to gather data that enables you to make well-informed, high-quality decisions. If you are using a tool like HP Application Lifecycle Management, you are already collecting data you can use for objective, data-driven management. This data exposes risk, bottlenecks and economic overheads.

Maybe the rate at which developers are fixing bugs is trending faster than the rate that Ops can deliver the fixes to production. It may at first appear that Ops is the bottleneck, when in reality the problem may lie with a tightly coupled, complex system architecture that requires nothing less than a miracle to modify. Moreover, if you reward developers for making as many changes in as little time as possible and at the same time you reward Ops for allowing as few changes as they can get away with, is it any wonder the two are in constant state of conflict? Using collaborative thinking you can devise a set of KPIs that reflect the objectives of the whole organization, rather than those of specific teams. This will ensure everyone is marching to the same tune.

Leadership, the essential ingredient

Last but not least, the paradigm shift in DevOps needs more than just good intentions and some tools. True participative leadership is a mandatory ingredient. Moving to a collaborative thinking approach requires management to adopt a consistent evolution in thought leadership. This evolution must be based on:

Acknowledging that this is “our” problem, not “the other team’s”

An emphasis on quality, which encourages craftsmanship and pride of workmanship, rather than process

Establishing avenues to enable collaborative working

A properly designed framework, which enables people to work effectively without becoming overloaded

A sentiment among staff that their actions are directly connected to business success

Management that addresses systemic problems by changing processes and policies rather than waiting for “the other team” to take action

These are leadership imperatives that are essential to making the shift to DevOps work.