Over a million developers have joined DZone.

Selecting Which Value Stream to Start With

The value stream we choose dictates the difficulty of transformation, who will be involved, how we organize the teams, and how we can best enable those teams.

· DevOps Zone

Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure, brought to you in partnership with Sauce Labs

Choosing the best value stream for your DevOps transformation deserves careful consideration.

Not only does the value stream we choose dictate the difficulty of your transformation, but it also dictates who will be involved in the transformation, how we organize the teams, and how we can best enable those teams and the individuals in them.

We will select the best value stream for beginning your DevOps transformation by looking at three key components:

  •  Whether they are a greenfield or brownfield service.

  • Considering systems of engagement or a systems of record.

  •  Best practices for expanding DevOps across your organization.

Let us begin by determining whether the project at hand will be a greenfield or brownfield service.

Originally used for urban planning and building projects, greenfield development is when we build on undeveloped land; while brownfield development is when we build on land that was previously used for industrial purposes, potentially contaminated with hazardous waste or pollution.

In urban development, many factors can make greenfield projects simpler than brownfield projects—there are no existing structures that need to be demolished nor are there toxic materials that need to be removed.

In technology, a greenfield project is a new software project or initiative.

Likely in the early stages of planning or implementation, greenfield projects are where we build our applications and infrastructure anew, with few constraints.

Starting with a greenfield software project can be easier, especially if the project is already funded and a team is either being created or is already in place.

On the other end of the spectrum are brownfield DevOps projects– these are existing products or services that are already serving customers and have potentially been in operation for years or even decades.

Brownfield projects often come with significant amounts of technical debt, such as having no test automation or running on unsupported platforms.

When transforming brownfield projects, we may face significant impediments and problems, especially when no automated testing exists or when there is a tightly-coupled architecture that prevents small teams from developing, testing, and deploying code independently.

Although many believe that DevOps is primarily for greenfield projects, DevOps has been used to successfully transform brownfield projects of all sorts.

In fact, over 60% of the transformation stories shared at the DevOps Enterprise Summit in 2014 were for brownfield projects.

One of the most popular examples of a brownfield project is Etsy (see the Etsy case study here).


Feature Download: Get access to the entire “Where to Start with DevOps” series in one PDF, along with powerful case studies from well known companies. Download The DevOps Handbook excerpt.


Next, let us consider systems of record and systems of engagement within our organization.

The Gartner research firm has recently popularized the notion of bimodal IT, referring to the wide spectrum of services that typical enterprises support.

Within bimodal IT there are systems of record, as well as systems of engagement.

Systems of record typically have a slower pace of change and often have regulatory and compliance requirements (e.g., SOX). Gartner calls these types of systems “Type 1,” where the organization focuses on “doing it right.”

Example: Think ERP-like systems that run our business (e.g., MRP, HR, financial reporting systems), where the correctness of the transactions and data are paramount.

Systems of engagement typically have a much higher pace of change to support rapid feedback loops that enable them to conduct experimentation to discover how to best meet customer needs. Gartner calls these types of systems “Type 2,” where the organization focuses on “doing it fast.”

Example: Think customer-facing or employee-facing systems, such as e-commerce systems and productivity applications.

While it may be convenient to divide up our systems into these categories; we know that the core, chronic conflict between “doing it right” and “doing it fast” can be broken with DevOps.

The data from Puppet Labs’ State of DevOps Reports—following the lessons of Lean manufacturing—shows that high performing organizations are able to simultaneously deliver higher levels of throughput and reliability.

Furthermore, because of how interdependent our systems are, our ability to make changes to any of these systems is limited by the system that is most difficult to safely change, which is almost always a system of record.

Scott Prugh, VP of Product Development at CSG, observed, “We’ve adopted a philosophy that rejects bi-modal IT, because every one of our customers deserve speed and quality. This means that we need technical excellence, whether the team is supporting a 30 year old mainframe application, a Java application, or a mobile application.”

Consequently, when we improve brownfield systems, we should not only strive to reduce their complexity and improve their reliability and stability, we should also make them faster, safer, and easier to change.

Even when new functionality is added just to greenfield systems of engagement, they often cause reliability problems in the brownfield systems of record they rely on.

By making these downstream systems safer to change, we help the entire organization more quickly and safely achieve its goals.


Feature Download: Get access to the entire “Where to Start with DevOps” series in one PDF, along with powerful case studies from well known companies. Download The DevOps Handbook excerpt.


With these pieces in place, we will walk through the steps of expanding DevOps across our organization.

Within every organization, there will be teams and individuals with a wide range of attitudes toward the adoption of new ideas, while others with more conservative attitudes resist them (the early adopters vs. the late majority, and laggards).

Our goal is to find those teams that already believe in the need for DevOps principles and practices, and who possess a desire and demonstrated ability to innovate and improve their own processes.

Ideally, these groups will be enthusiastic supporters of the DevOps journey.

Especially in the early stages, we will not spend much time trying to convert the more conservative groups. Instead, we will focus our energy on creating successes with less risk-averse groups and build out our base from there.

Even if we have the highest levels of executive sponsorship, we will avoid the big bang approach (i.e., starting everywhere all at once), choosing instead to focus our efforts in a few areas of the organization, ensuring that those initiatives are successful, and expanding from there.

We also want to follow a safe sequence that methodically grows our levels of credibility, influence, and support.

The following list, adapted from a course taught by Dr. Roberto Fernandez, a William F. Pounds Professor in Management at MIT, describes the ideal phases used by change agents to build and expand their coalition and base of support:

1. Find Innovators and Early Adopters: In the beginning, we focus our efforts on teams who actually want to help—these are our kindred spirits and fellow travelers who are the first to volunteer to start the DevOps journey. In the ideal, these are also people who are respected and have a high degree of influence over the rest of the organization, giving our initiative more credibility.

Especially in the early stages, we will not spend much time trying to convert the more conservative groups. Instead, we will focus our energy on creating successes with less risk-averse groups and build out our base from there.

2. Build Critical Mass and Silent Majority: In the next phase, we seek to expand DevOps practices to more teams and value streams with the goal of creating a stable base of support. By working with teams who are receptive to our ideas, even if they are not the most visible or influential groups, we expand our coalition who are generating more successes, creating a “bandwagon effect” that further increases our influence. We specifically bypass dangerous political battles that could jeopardize our initiative.

We must demonstrate early wins and broadcast our successes. We do this by breaking up our larger improvement goals into small, incremental steps. This not only creates our improvements faster, it also enables us to discover when we have made the wrong choice of value stream—by detecting our errors early, we can quickly back up and try again, making different decisions armed with our new learnings.

3. Identify the Holdouts: The “holdouts” are the high profile, influential detractors who are most likely to resist (and maybe even sabotage) our efforts. In general, we tackle this group only after we have achieved a silent majority, when we have established enough successes to successfully protect our initiative.

Ultimately, expanding DevOps across an organization is no small task. It can create risk to individuals, departments, and the organization as a whole.

But as Ron van Kemenade, CIO of ING, who helped transform the organization into one of the most admired technology organizations said:

By choosing carefully where and how to start, we are able to experiment and learn in areas of our organization that create value without jeopardizing the rest of the organization. By doing this, we build our base of support, earn the right to expand the use of DevOps in our organization, and gain the recognition and gratitude of an ever-larger constituency.


Feature Download: Get access to the entire “Where to Start with DevOps” series in one PDF, along with powerful case studies from well known companies. Download The DevOps Handbook excerpt.


Download “The DevOps Journey - From Waterfall to Continuous Delivery” to learn learn about the importance of integrating automated testing into the DevOps workflow, brought to you in partnership with Sauce Labs.

Topics:
devops ,value stream ,devops transformation

Published at DZone with permission of Gene Kim, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}