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

• 
Overly tight architecture: We cannot achieve deployments on 
demand if overly tight architecture means that every time we 
want to make a code change we have to send our engineers to 
scores of committee meetings in order to get permission to make 
our changes. Our countermeasure is to create more loosely coupled 
architecture so that changes can be made safely and with more 
autonomy, increasing developer productivity. 
After all these constraints have been broken, our constraint will likely be 
Development or the product owners. Because our goal is to enable small teams 
of developers to independently develop, test, and deploy value to customers 
quickly and reliably, this is where we want our constraint to be. High perform-
ers, regardless of whether an engineer is in Development, QA, Ops, or Infosec, 
state that their goal is to help maximize developer productivity. 
When the constraint is here, we are limited only by the number of good business 
hypotheses we create and our ability to develop the code necessary to test 
these hypotheses with real customers. 
The progression of constraints listed above are generalizations of typical 
transformations—techniques to identify the constraint in actual value streams, 
such as through value stream mapping and measurements, are described 
later in this book.
ELIMINATE HARDSHIPS AND WASTE IN THE 
VALUE STREAM
Shigeo Shingo, one of the pioneers of the Toyota Production System, believed 
that waste constituted the largest threat to business viability—the commonly 
used definition in Lean is “the use of any material or resource beyond what 
the customer requires and is willing to pay for.” He defined seven major types 
of manufacturing waste: inventory, overproduction, extra processing, trans-
portation, waiting, motion, and defects.
More modern interpretations of Lean have noted that “eliminating waste” can 
have a demeaning and dehumanizing context; instead, the goal is reframed 
Promo 
- Not 
for 
distribution 
or 
sale

---

24 • Part I
to reduce hardship and drudgery in our daily work through continual learning 
in order to achieve the organization’s goals. For the remainder of this book, 
the term 
waste
will imply this more modern definition, as it more closely 
matches the DevOps ideals and desired outcomes.
In the book 
Implementing Lean Software Development: From Concept to Cash
, 
Mary and Tom Poppendieck describe waste and hardship in the software 
development stream as anything that causes delay for the customer, such as 
activities that can be bypassed without affecting the result. 
The following categories of waste and hardship come from 
Implementing Lean 
Software Development
unless otherwise noted: