Selecting Which Value Stream to Start With

Choosing the best value stream for your DevOps transformation deserves careful consideration. Not only does the value stream you choose dictate the difficulty of your transformation, but it also dictates who will be involved in the transformation, how you organize teams, and how you can best enable those teams and the individuals within them.

In the first part of our Where to Start with DevOps series, adapted from the fully updated and expanded second edition of The DevOps Handbook, we’ll look at three key components for selecting the best value stream to start your DevOps transformation with:

1. Greenfield or brownfield service
2. Systems of engagement or systems of record
3. Expanding DevOps across your organization

Determining Whether to Start with a Greenfield or Brownfield Project

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 and there are no toxic materials that need to be removed.

Greenfield Projects

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.

Brownfield Projects

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.

Which is better—Greenfield or Brownfield?

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

Systems of Record vs. Systems of Engagement

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

They 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

They 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 the 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.

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

Where to Start with DevOps Series

1. Selecting Which Value Stream to Start With
2. Understand the Work in Our Value Stream and Improving Flow
3. How to Design with Conway’s Law in Mind
4. How to Integrate Operations Into the Daily Work of Development

- About The Authors

Gene Kim

Gene Kim has been studying high-performing technology organizations since 1999. He was the founder and CTO of Tripwire, Inc., an enterprise security software company, where he served for 13 years. His books have sold over 1 million copies—he is the WSJ bestselling author of Wiring the Winning Organization, The Unicorn Project, and co-author of The Phoenix Project, The DevOps Handbook, and the Shingo Publication Award-winning Accelerate. Since 2014, he has been the organizer of DevOps Enterprise Summit (now Enterprise Technology Leadership Summit), studying the technology transformations of large, complex organizations.

Follow Gene on Social Media

• 
• 

Jez Humble

Jez Humble is the coauthor of Accelerate and The DevOps Handbook

Follow Jez on Social Media

• 
• 

John Willis

John Willis has worked in the IT management industry for more than 35 years and is a prolific author, including "Deming's Journey to Profound Knowledge" and "The DevOps Handbook." He is researching DevOps, DevSecOps, IT risk, modern governance, and audit compliance. Previously he was an Evangelist at Docker Inc., VP of Solutions for Socketplane (sold to Docker) and Enstratius (sold to Dell), and VP of Training & Services at Opscode where he formalized the training, evangelism, and professional services functions at the firm. Willis also founded Gulf Breeze Software, an award winning IBM business partner, which specializes in deploying Tivoli technology for the enterprise. Willis has authored six IBM Redbooks for IBM on enterprise systems management and was the founder and chief architect at Chain Bridge Systems.

Follow John on Social Media

• 
• 

Patrick Debois

In 2009 he coined the word devops by organizing the first devopsdays event. He organized conferences all over the world to collect and spread new ideas. As a pioneer he is always on the look out for new ideas to implement and explore. Currently in the media sector where he is guiding broadcasters with the transition to enter into a dialogue with it's audience as a closed feedback loop.

Follow Patrick on Social Media

• 
•