would claim that the software worked fine in testing on
their laptops, so the infrastructure must be broken. The
operations teams would say that the buggy and poorly
written software was stressing their environment and
creating all kinds of extra work. These two groups were
in need of some serious marriage counseling.
Developers and operations teams often have very
different expectations and metrics for success.
Developers care about functional code, APIs, libraries,
services, and Agile sprints. Success to them means
software works on their laptops and in testing, and they
finish their latest sprints in time. Operations, on the
other hand, cares about the environment being stable,
standards, templates, and not getting awakened at 2 a.m.
to go fix a problem. Success to operations means
software and applications are stable, backup and restore
processes work, and all systems are operating within
defined thresholds. Developers are all about creating
new features and capabilities in their software; change is
a constant in their world. Operations folks are looking to
maintain stability in their environment. The two could
not be further apart.
If you take a calendar view of the two organizations, it
becomes very apparent where the challenge is (see Figure
13-14). How can you possibly deploy new features and
capabilities added every 2 weeks as part of an Agile
sprint when your operational maintenance window is
only open every 6 months?