Here is a video interview I gave summarizing some of the main themes and discussions which came out of the DevOps Summit on May 23rd in London: a shared goal for development and operations; anti-fragility as a way for DevOps and ITIL to complement each other; surface the quality of the software for all to see; tools can produce a step change in behavior for the better; and use the theory of constraints to focus improvements.
Matthew Skelton (SoftwareOperability.com):
[0:06] Here are some of the themes that came out of today’s DevOps Summit around Enabling DevOps.
[0:13] It’s really crucial to have a shared goal for development and operations. That shared goal is something around delivering business value, but delivering business value regularly, rapidly, but also reliably as well. If you have a shared goal like that, you should expect to have shared pain between development and operations so that they both feel the pain of a botched deployment or of downtime. They also share in the rewards as well, the success of the products and the customer satisfaction.
[0:44] We heard a lot about understanding where your problems, constraints, and assets lie. Understand where your strengths and weaknesses are before you go and try and tackle something. Realize that DevOps is not just about development and operations but actually really should include the business as well. It’s an organizational challenge, not a technical challenge.
[1:04] We had several recommendations for books. “The Goal,” which was written in the 1960s by Eli Goldratt; “The Phoenix Project,” by Gene Kim, which is an updated version of “The Goal” but for a DevOps focus, for technologists today. “Release It!” by Michael Nygard and “Continuous Delivery” by Jez Humble and David Farley.
[1:33] There was a strand of conversation or debate today around the relationship between DevOps and ITIL. A useful word to Google search is anti‑fragility. There’s been some interesting stuff that Jez Humble and other people have done around the way in which DevOps and ITIL can and should work together.
[1:59] Two final things. One was that it’s very, very important to understand what motivates different people in different teams and to use language which is appropriate and understood by them, rather than using language which may be internal to your team, and also to make the quality of the software very apparent and very clear.
[2:19] Traditionally, the operations team probably mistrusts the development teams because the software perhaps is buggy or flaky or didn’t work in production. Development teams have a responsibility to surface the quality of the software they’re producing to give operations the confidence that it is possible to deploy this stuff on a more regular basis in production and see that value coming out much more quickly for the customer and the business.
[2:50] At DevOps Summit today, we were looking at Enabling DevOps. We had an interesting panel discussion*. We kicked off with a question, “Which comes first, DevOps or tools?” which is obviously a bit of a contentious question. We put that in there deliberately, and that generated some interesting questions.
[3:16] We had a few different opinions. The tool starts building the culture. In situations where, perhaps, technologists, developers, or operations guys haven’t had experience to a particular way of working that a tool brings in, introducing a tool can actually make a step change in behavior and can open people’s eyes to new ways of working. But it does take a long time for that to take effect within a large organization.
[3:49] Dan North had an interesting phrase, which was that tools enable commoditized learning, and that, in his opinion, tools should accrete opinion but not features. They should be very focused on one particular thing. There’s Subversion as a good example of that. James Betteley pointed out that, of course, what comes first is a problem that you’re trying to solve, not DevOps and the tools. Those are part of the solution.
[4:24] We had another question about best practices within DevOps. Now, at the moment, there isn’t, and there probably shouldn’t ever be a book which says, “This is how to do DevOps.” There are several different takes on it. There are some very useful books. “Continuous Delivery” by Jez Humble and David Farley is a key book to read. “The Phoenix Project” by Gene Kim and other authors is also very valuable for the insights it gives.
[5:02] “Release It!” by Michael Nygard is a really crucial book for understanding the kinds of problems that happen in production. It’s written from a developer’s point of view, but it highlights the operational issues that do happen in production. It’s extremely valuable.
[5:21] Again, we heard that it’s important to understand exactly where your constraints and problems lie before you go off and use tooling or try and introduce a particular change. Use the theory of constraints to help you focus your efforts around improving your organization.
* On the panel were: James Betteley (DevOpsNet), Sylvain Cailliau (Serena), Peter Eeles (IBM), Kiffin Gish (SDU Information Systems), Rainer Heinold (Collabnet), Dan North (Dan North & Associates Ltd), Alex Papadimoulis (Inedo), Wesley Pullen (UC4), Gary Voller (HP). Thanks to all the participants and the audience for taking part.
Transcription by CastingWords
Matthew Skelton 