DevOps is a movement for developers and operations professionals that encourages more collaboration and release automation. Why? To keep up with the faster application delivery pace of Agile. In fact, with Agile, as development teams deliver faster and in shorter cycles, IT operations finds itself unprepared to keep up with the new pace. For operations teams, managing a continuous stream of software delivery with traditional manual-based processes is Mission Impossible. Vendors have responded to DevOps requirements with more automation in their release management, delivery, and deployment tools. However, there is a key process that sits between development and operations that seems to have been given little attention: testing.
In fact, some key testing activities, like integration testing and end-to-end performance testing, are caught right in the middle of the handover process between development and operations. In the Agile and Lean playbook, I’ve dedicated my latest research precisely to Agile testing, because I’ve seen testing as the black beast in many transformations to Agile because it was initially ignored.
The data shows that 70% of corporate change efforts either totally fail, have lukewarm results, or the change never becomes an integral part of the company culture. As I talk to clients about their change efforts, what’s worked and what hasn’t, some clear patterns emerge.
Change is not an event — it’s a process. You make plans for the executive to announce the change to employees. The executive talks about why it’s important for the company to make the change, what the change will look like, and the assistance the company will provide employees during this transformation process. The executive responds to employee questions and recommends that employees discuss any additional questions with their managers. A thoughtful speech, well delivered with empathy around challenges of change . . . it’s good, but it’s not enough. The executives have been thinking about and planning this transformation for weeks or months and know it well. The employees are hearing about the change for the first time, in this hour-long, all-hands company presentation. Anxiety, shock, and fear are typical reactions. Rather than this one-time announcement, make sure executives explain that today’s meeting is the first of many that will be held periodically using different media (web, in-person, email, social network, etc.) to provide updates and answer questions. Remember, half the audience may have heard nothing beyond the statement that major change is going to happen. Fear set in and they began to think about how this change will affect them.
The most notable news to come out of the VMworld conference last week was the coronation of Pat Gelsinger as the new CEO of VMware. His tenure officially started over the weekend, on September 1, to be exact.
For those who don’t know Pat’s career, he gained fame at Intel as the personification of the x86 processor family. It’s unfair to pick a single person as the father of the modern x86 architecture, but if you had to pick just one person, it’s probably Pat. He then grew to become CTO, and eventually ran the Digital Enterprise Group. This group accounted for 55% of Intel’s US$37.586B in revenue according to its 2008 annual report, the last full year of Pat’s tenure. EMC poached him from Intel in 2009, naming him president of the Information Infrastructure Products group. EMC’s performance since then has been very strong, with a 17.5% YoY revenue increase in its latest annual report. Pat’s group contributed 53.7% of that revenue. While he’s a geek at heart (his early work), he proved without a doubt that he also has the business execution chops (his later work). Both will serve him well at VMware, especially the latter.
With the updated version of ITIL imminent (the 29 July 2011), I participated in a BrightTalk webinar on “what next for ITIL.”
My views on this are very clear, that we need to “look back before we look forward.” I touched on some of this in a previous blog, 2011: An ITIL Versioning Odyssey, but think it worthwhile to continue to articulate my views in this area.
Let's start with what I consider to be the biggest issue: the gulf between theory and practice with ITIL.
There is no doubt that ITIL can benefit I&O organizations. There are certainly many I&O organizations encouraging, or even forcing, their people to take ITIL training and qualifications: There are at least 1.5 million people with the certification and there is no sign of this slowing down. Not only are trainers busy, so are ITSM consultants and, of course, industry analysts. But, from an industry analyst perspective, there is a lot wrong with ITIL. This is not just how it ballooned in size from ITIL v2 to ITIL v3, but also how it is adopted in the real world.
So what's going wrong?
If you look at existing ITIL v2 adoption, there is a focus on the reactive elements such as incident management, problem management, change management, and maybe even configuration management and service-level management. How many organizations have moved on to the more proactive elements such as availability management, capacity management, IT financial management, and continual service improvement?
My colleague, Glenn O’Donnell, and I (do I sound like the Queen?) have delivered a Forrester report called “Improving The Ops In DevOps” inspired by the long-bemoaned tension between “change-the-business” (dev) and “run-the-business” (ops) IT teams and their activities, and the need for change.
This tension inflicts a detrimental impact on the business. In fact, most organizations suffer this curse, and stereotypes that reflect this animosity abound. Does this sound familiar? Ops people see dev people as sitting in their ivory towers cranking out code all day and wanting to release applications oblivious to real-world constraints; dev sees ops as cog-turners ensuring that the IT infrastructure doesn’t break under the strain of poorly written code. Chances are that your organization is not this bad. But this exaggeration is indicative of the tension between these two IT “tribes” and their opinions of each other. These stereotypes exist because organizational behaviors do exaggerate genuine conflicts, and both parties must act quickly to change.
Getting DevOps right will address many of the issues enterprises consistently have with IT, such as applications failing to meet both functional and nonfunctional requirements, delivery delays, increased costs, and an inflexibility to change. But is DevOps enough to save I&O from extinction?
Like many movements before it, IT is rapidly evolving to an industrial model. A process or profession becomes industrialized when it matures from an art form to a widespread, repeatable function with predictable result and accelerated by technology to achieve far higher levels of productivity. Results must be deterministic (trustworthy) and execution must be fast and nimble, two related but different qualities. Customer satisfaction need not be addressed directly because reliability and speed result in lower costs and higher satisfaction.
IT should learn from agriculture and manufacturing, which have perfected industrialization. In agriculture, productivity is orders of magnitude better. Genetic engineering made crops resistant to pests and environmental extremes such as droughts while simultaneously improving consistency. The industrialized evolution of farming means we can feed an expanding population with fewer farmers. It has benefits in nearly every facet of agricultural production.
Manufacturing process improvements like the assembly line and just-in-time manufacturing combined with automation and statistical quality control to ensure that we can make products faster and more consistently, at a lower cost. Most of the products we use could not exist without an industrialized model.