The devops handbook how to Create World-Class Agility, Reliability, & Security in Technology Organizations By Gene Kim, Jez Humble, Patrick Debois, and John Willis

Café 
Bistro
restaurants. Unlike the mobile app value stream where the business 
need was to reduce time to market and increase feature throughput, the 
business need here was to decrease cost and increase quality. In 2013, Nord-
strom had completed eleven “restaurant re-concepts” which required changes 
to the in-store applications, causing a number of customer-impacting incidents. 
Disturbingly, they had planned forty-four more of these re-concepts for 
2014—four times as many as in the previous year. 
As Kissler stated, “One of our business leaders suggested that we triple our 
team size to handle these new demands, but I proposed that we had to stop 
throwing more bodies at the problem and instead improve the way we worked.”
They were able to identify problematic areas, such as in their work intake and 
deployment processes, which is where they focused their improvement efforts. 
They were able to reduce code deployment lead times by 60% and reduce the 
number of production incidents 60% to 90%.
These successes gave the teams confidence that DevOps principles and practices 
were applicable to a wide variety of value streams. Kissler was promoted to 
VP of E-Commerce and Store Technologies in 2014.
In 2015, Kissler said that in order for the selling or customer-facing technology 
organization to enable the business to meet their goals, “…we needed to in-
crease productivity in all our technology value streams, not just in a few. At 
the management level, we created an across-the-board mandate to reduce 
cycle times by 20% for all customer-facing services.”
She continued, “This is an audacious challenge. We have many problems in 
our current state—process and cycle times are not consistently measured 
across teams, nor are they visible. Our first target condition requires us to 
help all our teams measure, make it visible, and perform experiments to start 
reducing their process times, iteration by iteration.”
† 
The practice of relying on a stabilization phase or hardening phase at the end of a project often 
has very poor outcomes, because it means problems are not being found and fixed as part of 
daily work and are left unaddressed, potentially snowballing into larger issues.
Promo 
- Not 
for 
distribution 
or 
sale

---

54 • Part II
Kissler concluded, “From a high level perspective, we believe that techniques 
such as value stream mapping, reducing our batch sizes toward single-piece 
flow, as well as using continuous delivery and microservices will get us to our 
desired state. However, while we are still learning, we are confident that we 
are heading in the right direction, and everyone knows that this effort has 
support from the highest levels of management.” 
In this chapter, various models are presented that will enable us to replicate 
the thought processes that the Nordstrom team used to decide which value 
streams to start with. We will evaluate our candidate value streams in many 
ways, including whether they are a 
greenfield
or 
brownfield
service, a 
system of 
engagement
or a 
system of record
. We will also estimate the risk/reward balance 
of transforming and assess the likely level of resistance we may get from the 
teams we would work with.
GREENFIELD VS. BROWNFIELD SERVICES
We often categorize our software services or products as either greenfield or 
brownfield. These terms were originally used for urban planning and building 
projects. Greenfield development is when we build on undeveloped land. 
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, where we build our appli-
cations 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. Furthermore, 
because we are starting from scratch, we can worry less about existing code 
bases, processes, and teams.
Greenfield DevOps projects are often pilots to demonstrate feasibility of public 
or private clouds, piloting deployment automation, and similar tools. An 
example of a greenfield DevOps project is the Hosted LabVIEW product in 
2009 at National Instruments, a thirty-year-old organization with five thousand 
employees and $1 billion in annual revenue. To bring this product to market 
quickly, a new team was created and allowed to operate outside of the existing 
IT processes and explore the use of public clouds. The initial team included 
Promo 
- Not 
for 
distribution 
or 
sale

---

Chapter 5 • 55
an applications architect, a systems architect, two developers, a system auto-
mation developer, an operations lead, and two offshore operations staff. By 
using DevOps practices, they were able to deliver Hosted LabVIEW to market 
in half the time of their normal product introductions.
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. In the Nordstrom example 
presented earlier in this chapter, both the in-store restaurant systems and 
e-commerce systems were brownfield projects.
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. In these cases, there 
was a large performance gap between what the customer needed and what 
the organization was currently delivering, and the DevOps transformations 
created tremendous business benefit.
Indeed, one of the findings in the 
2015 State of DevOps Report
validated that 
the age of the application was not a significant predictor of performance; 
instead, what predicted performance was whether the application was archi-
tected (or could be re-architected) for testability and deployability. 
Teams supporting brownfield projects may be very receptive to experimenting 
with DevOps, particularly when there is a widespread belief that traditional 
methods are insufficient to achieve their goals—and especially if there is a 
strong sense of urgency around the need for improvement.
†
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. How we overcome these issues 
are discussed throughout this book.
Examples of successful brownfield transformations include:
† 
That the services that have the largest potential business benefit are brownfield systems 
shouldn’t be surprising. After all, these are the systems that are most relied upon and have the 
largest number of existing customers or highest amount of revenue depending upon them.
Promo 
- Not 
for 
distribution 
or 
sale

---

56 • Part II