Start small, think big, move fast,” was the collective mantra of 25 IT leaders at a recent meeting in San Francisco to exchange ideas on how to start and how to scale-up a DevOps approach to getting their work done. They had interesting responses to six thorny questions.
1. “What is DevOps?”: Attempts to find the perfect definition for DevOps – essentially a more collaborative way to develop software – may create more problems than they solve. Discussion at the meeting showed that most attempts to define lead people back to how-to words like “process,” and underemphasize outcome-type words, like “fast.”
The point is that DevOps initiatives are fundamentally about reorganizing resources around a clear product or service outcome for IT’s customers (their colleagues all over the rest of the firm). As one IT infrastructure manager put it, “DevOps is fundamentally about (a) building the right product, (b) building the right product right, and (c) running the right product right.” In fact several IT teams are deliberately avoiding the term DevOps, and instead use more outcome-oriented terms, like “solutions engineering.”
2. “What does this mean for the development of IT applications? What does this mean for the IT infrastructure function?”: Fundamentally, implementing DevOps requires a change in how people think about the ownership of their work. Development teams must share ownership for supporting those using an application to ensure a lifetime warranty on the health and maintenance of applications. As one manager explained, “Development teams need to be taking those 3 a.m. phone calls…if you had a hand in building it, you need to involved in fixing it.”
Infrastructure teams should build the platform and suite of tools that allow development teams to take shared ownership of the release-to-production cycle and support. The platform built by infrastructure teams can be thought of as self-service resources for testing and provisioning with repeatable/re-usable components. The tools suite can be thought of as a group of tools that can be integrated, and which accurately measure how useful the application is to its primary customers.
3. “How and where do we start?”: In the words of one leader, “don’t bring a waterfall mindset to a way of working that, by its nature, must be iterative and fast.” The term DevOps can make many staff wary of big and worrying organizational changes that put jobs at risk, and an overly structured or process-driven approach to DevOps may introduce more inefficiencies and unintended consequences than solutions.
Rather, leading IT functions “start small” by identifying and supporting DevOps-like engineering teams and approaches already present in the organization, “think big” by sharing and exporting these practices across teams, and “move fast” by using the right measurements to invest in what works and stop doing what doesn’t.
4. “How do we measure success?”: There was near universal consensus at the meeting that the need to take on a team mindset is the chief barrier to implementing a DevOps approach properly, and that using the right metrics are the best way to change this mindset. The right metrics gauge success by two factors:
First, they measure the end-to-end quality of the release, product, and service, rather than “siloed” metrics will do more than, say, examine whether the coding team achieved zero defects, or whether operations teams are maintaining the availability of a piece of software. While these are important, they’re not important unless seen in the context of the customer outcome: whether an important transaction could be completed, or a business result achieved.
Second, they explicitly account for the role that everyone — development, engineering, and operations teams — have in driving or influencing a product outcome. The basic message this conveys is that any success is not defined as a success for the infrastructure team or the applications team, but as a successful (and measurable) business outcome.
5. “I’ve heard DevOps improves speed and quality. Does it reduce cost?”: In the long term, cost savings are the natural consequence of improved quality and speed. IT teams that choose to outsource new roles or implement a broad set of new tools upfront may incur greater initial costs than others, but this is often unnecessary.
Leading IT functions keep their automation strategies simple — for example, by having teams generate a “top 10” list of automation opportunities every month, and assigning a team to work through those opportunities. Nor does a DevOps initiative imply a need to hire new staff — many teams have reallocated resources while delivering more frequent releases to the rest of the firm.
