DevOps Blog

Get the RSS Feed

Selecting Which Value Stream to Start With

where to start with devops #1

Part 1 of 4: Where to Start with DevOps Series

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.

  • Andreas

    Thanks for this – interesting to read and good hints

  • Robert Falkowitz

    While the points made have their place, there seems to be a non-agile assumption about getting the value right, rather than incrementally adjusting the value stream in a pragmatic, low risk way (even though a phased, rather than a big-bang approach is recommended). An alternate approach responsibilizes the various teams and encourages them to optimize their value streams in function of their specific service goals and constraints, and in function of their continual improvement levels of maturity. This approach avoids creating a bottleneck at the level of the “leader” of change and avoids issues where “best practices” for one team might turn out to be very bad practices for another one.

  • http://www.ranger4.com Helen Beal

    I love what Scott has to say about bi-modal – thanks for sharing that!

  • Randy Tangco

    I have spoken to quite a few IT leaders and managers. The common theme I read from those conversation is the fear of the unknown. I have heard this many times “We are not google” or “We are not facebook”. “We are a business (whatever that is) and not a software company.” BTW, I hear these from execs who read the “Project Phoenix” book. There is a gap between the idea of innovation and keeping the lights on. I believe that to truly be successful, the exec has to take a leap of faith and make something good just like what Ron van Kemenade, CIO of ING, did.

  • Daniel Breston

    VSM is a way of getting people to collaborate and see what is really happening that do not necessarily take the time to strategically ensure that past intent matches future need. VSM exercises are amazing AHA workshops that make the 3 Ways (flow, feedback and continuous experimentation and learning) turn into a sustainable engine of improvement.

Sign up for the IT Revolution Newsletter and get our whitepaper,
The Top 11 Things You Need To Know About DevOps.

We won’t share, sell or spam you. –Gene Kim