Rob England

Today's presentation is about crossing the streams, which is that analogy from those of you who are old enough to remember Ghostbusters: "Be careful, don't cross the streams." Powerful forces, and when they come together, the power of the synergy of those things.

It's our observation that this year seems to be the year where the streams of DevOps thinking and conventional, if you like, ITSM thinking seem to be crossing over at last, and that's what we want to talk to you about today.

We are Teal Unicorn. That's a brand that we use for consulting. Teal, because that's the aspirational high culture of the Laloux model, for those of you who know that, and teal has sort of entered the lexicon as an aspiration for high culture. And unicorn, of course, because that's the aspiration for new ways of working, and the new way of working because it is.

We're well aware that this is a fad brand. It's one of those trendy brands. But we're big fans of fads. We think that anything that has that energy in the industry is something that you should harness to help you power your transformational change, and not something you should resist. So we're quite happy to surf that wave, if you like, in helping us to be agents of change.

We're based in Wellington, New Zealand. Four hundred thousand people in Wellington, but it's the capital, so there's lots of government work, and the majority of our work is government work. That's where we live.

We do consulting by the hour rather than weekly or monthly or yearly work, so we're doing true consulting around strategy and driving the ideas of DevOps in organizations. And our work is 100% DevOps. That's all we do, and have done for several years now.

Our clients are pretty small by the standards of Europe and the USA. One of our clients is New Zealand's biggest government department. They've got about 500 IT people. The taxman is another one of our clients. They've got about 400-and-something IT people. So that's big by New Zealand standards, which is pretty small by global standards, but it's still big enough to be interesting. And then we range down to even smaller organizations.

So we is Dr. Cherry Vu, who has a background in leadership and public policy and ethics and organizational change. And lately she's been immersing in all this stuff around IT culture and transformation of culture and Lean thinking and DevOps and ITSM, and all these ideas that we all love and know. But she knows nothing about IT and has been on a, I think, terrifying journey over the last year or so immersing in that space.

And I'm Rob England. My background is IT strategy and governance and management. And in the last few years, I've been learning, absorbing all these ideas of Agile and of culture change, and of leadership.

I used to know all of the tech once. I know none of it now. So I'm not on Slack. I can't get that damn thing to work. I honor those of you who can figure it out. And so you can see where you can find us on Twitter.

We're partners in life and work, so we're one of those--

Cherry Vu

As well.

Rob England

Yeah. Cherry is the CEO of the organization. So we make that brave decision to work together, which some of you know can be quite terrifying, but so far it's been delightful. So that's who we are.

We want to talk today about how you've got these bodies of knowledge that all sit behind DevOps, and it's grown out of maybe three primary bodies of knowledge: Agile, Lean, and ITSM. But somewhere along the way, we went all tribal, and I was a contributor to this in the early days. I have a blog that one or two of you in the room statistically will know about. And I was one of those people throwing rocks early on, before I sort of had a road-to-Damascus conversion.

So we went all tribal, and there's been these wars of attitude and stereotype between the groups, with the, "Ding-dong, the wicked ITIL is dead," coming from one side, and the, "Who are these free-range cowboys?" coming from the other side. Right?

And it's a real shame, because when we do that, we lose a lot by breaking our community and rupturing it in that way. It would be so much better if we can work together and bring those bodies of knowledge together.

Back in 2014, when I finally understood what the hell this stuff was about and that it really was important, I started this community called Kaimu, which is a Maori word for being together and working together, to try and capture the crossover, the intersection between the two, and it was a roaring failure. It got no attention at all, really.

But there is a group on Google Plus. Don't laugh. Google Plus was a good idea at the time. And we contribute, and "we" is mostly me so far. We'll talk about that more at the end. But just to say, this is a good fight that particularly I've been fighting for a number of years now, and Cherry has now joined me in the battle.

But it was interesting that this year, we're really starting to see this crossover. We're really starting to see these communities share ideas and connect in ways that I don't think we've done so much up until now.

So we're going to talk today about what we're seeing about the crossover, both from the side of the DevOps world coming up with ideas that are quite impactful on the service management thinking, and also from the other side, with somebody just learning and immersing into the ITSM area and seeing how it's transforming itself and what the ideas are that come out from that side, and seeing how the two are coming together. That's the message of today's presentation.

So if you look from the cool kids' side initially, then there's a number of things going on which are really starting to move into that. I did a blog post years ago about DevOps Run, that the world of DevOps isn't quite as complete as it thinks it is, which Cherry's going to talk to you more about. And now we're seeing a greater spread into those areas that have been more traditional, conventional service management spaces.

One of those is SRE, so the book from Google, which has now become a groovy, trendy job title. It's not really a book, it's a collection of essays, those of you who've read it will know. And fascinating about how a unicorn, how Google functions, and some of the ideas that they've developed and how we can learn from those.

Some of those are amazing ideas which are really going to have a big impact on the service management world. The ideas of different attitudes to risk. This word toil, I love this word toil. We're going to use that a lot. And the error budget is another one which just does the heads of service management people in. When you can run at eight-nines capability, why don't you dial it back to five nines so you give your people a bit of room to innovate? That's just a complete mind mess for service management people.

But at the same time also, there's a few things in there which are almost naive. So they talk about all the research they did to understand the best metric for the reliability of their systems, and after a whole lot of thinking, they came up with unplanned downtime. And the service management people are all kind of like, "You think?"

So it's a really interesting combination of naivety and unbelievably powerful ideas.

And then, the STELLA Report was the one that really kicked my thinking off, to go, "Oh my God, we're coming together." Has anyone read the STELLA Report? Or who's heard John Allspaw talk about it?

Go and hear John talk about this stuff if you're in any way interested in this space, or look on YouTube, because he's on there. And read the STELLA Report from the SNAFUcatchers. What a great name for a group.

The concepts in that document are a complete rethink of incident management and problem management through a fresh lens. It's like, again, almost naive. It's people approaching this space with no prior art almost, and rethinking it from the ground up. And as a result, coming out with concepts that are just whole new concepts in what was a very old and stale space, and really reinvigorating the incident management and problem management space with amazing new ideas in that area. So that was what really kicked me off, was hearing John and reading that.

And then there's other stuff that the DevOps community have been surfacing over a longer period of time. But when I read Richard Cook's paper on how complex systems fail a couple of years ago, three years ago, it completely changed how I thought about support and incident, and this whole concept that complex systems are always broken, and we should be designing and acting on the assumption they're always broken and let go of this fallacy of perfect systems, and so on. So that's an extraordinary paper which is having an impact in the service management world.

And likewise, the work by Sidney Dekker, who did the Field Guide to Human Error Investigations, which was redone as the one you're probably more familiar with, The Field Guide to Understanding Human Error, as a transformational book, which says if we don't design on the assumption that people are going to screw up, then it's our fault for our poor designs, not the fault of the people who make the mistakes.

And then Safety Differently. If you haven't watched Safety Differently on YouTube, watch it. It's about occupational safety and health, but again, it completely revamps our thinking about risk and what we think of as safe systems. Also more recently, he's come out with Just Culture, which is equally powerful, a video and set of ideas.

So Cook and Dekker have become heroes of the DevOps community, right? Who's heard them at a conference? Anyone? Well, you'll get the opportunity in the DevOps world, right? And in other worlds, because they speak a lot and they're really transforming the way we think about complex systems and designing and interacting with complex systems.

Oh, and finally, resilience engineering. So I like to say that the fad of DevOps has its own sub-fads every year, right? We had Docker, Docker, Docker, and then we had ChatOps, and then we had DevSecOps, and then we had transformational leadership. Now we've got resilience engineering. This year it's all about resilience engineering, and there's a whole conference around that with REdeploy in a few weeks' time that we'll be going to. And there's the rugged software, the work that Josh Corman has been doing for a number of years and working quite closely with Gene, and has presented at this conference as well.

So those are powerful bodies of knowledge that are coming out of this community, if you like, that are very impactful on the service management, the traditional or conventional service management world. And I encourage you to get your head around all of these things because they're changing the whole landscape of how we think about DevOps Run, about the bigger picture.

But it's not just that this community is moving more into that conventional world. It's also equally that that conventional world is coming to absorb some of these ideas. And so as part of her learning experience, Cherry's been on that journey, and she's going to tell you about that.

Cherry Vu

It's scary. Someone just asked me how can I have the courage when I present with Rob. I'm praying. I'm scared, mate.

So one of the main ideas that I've learned from ITIL is that the holistic picture that it provides is all about the whole value stream that IT delivers to the whole organization. It's just not the middle bit that DevOps tend to live on mostly.

So this IT4IT model is another body of knowledge that we like. We like this model because it's much simpler than ITIL. Have you ever seen ITIL's picture so far? It's extremely complex, and we love this picture because it explains there are only four mainstreams of IT.

So ITIL certainly focuses on all these parts of the stream: from the original needs to request, to fulfill, to detect, to correct. So this is a clear picture of how ITIL and DevOps cross the stream.

As we can see here in the picture, ITIL actually has the bigger picture in time because it covers all the IT lifecycle, and it's taking care of the software long after it's built.

ITIL also has a bigger picture in space. When DevOps tend to focus mostly from require to deploy, ITIL cares a great deal, almost equally, about all others.

Rob claims that ITIL pays less attention in design and build, but after the software is built, ITIL pays a great, great care about how to deploy it into production and maintain it long afterward.

In principle, Agile would say, we need a standing team forever. However, after some time, the business loses its interest. Then there's not much change in the software itself, but it's still in the core system, and people still use it. New people come in to access it, and sometimes it breaks down, and someone has to be there to fix it.

So what ITIL focuses on is what ITIL actually calls the service. They care about all this stream, including the last mile to the user, to make sure that people get what they want.

So it's obvious that ITIL has a bigger picture in time and in space than DevOps. Again, it's not that DevOps doesn't care at all about these activities, but ITIL seems to care more equally, and DevOps focuses mostly from the require to deploy rather than other activities.

Have you ever come across ITIL Practitioner? No? Yes? Okay. So this book, Rob calls it ITIL 3.5 because it comes just after ITIL 3, and the new additions make ITIL much more agile. And as you can see here, there are nine principles of ITIL. It's just so familiar to Agile, right?

So what I find very interesting is how ITIL people are transforming themselves into the whole new ideas.

You may have also come across this book, VeriSM. It's a new framework for digital services, and I'm so proud that Rob is one of the lead authors of this book. And to me, these guys seem to be very impatient to ITIL because they come up with a whole new idea that the ITIL people, you better hurry up. And please check it out if you are interested in.

Another idea that I feel is very interesting that I learned from the service management people start using Agile's idea to improve their work, including change management, incident management, and also all of these ITIL processes.

If you want to see a very interesting example of this, please go to YouTube and watch this guy, Eduardo. I always have problem to pronounce this guy's name.

Rob England

Eduardo Novaes Fuentes.

Cherry Vu

Yes.

In the presentation, this guy is talking about how he uses Agile ideas into his service desk in a call center. It's very interesting.

And another plug-in for Rob: he wrote a book that's called Standard+Case. It is about how service management people coming to understand the complex system that I believe that DevOps taught them.

Rob has taken the idea of the complex system from Cynefin, and this is how he pictures the world: the combining between standard worlds and the complex, the whole personal cases that we have to deal with in our real world.

Cynefin suggests that there are five different situations that we find ourselves in, and in the service management world, people tend to standardize everything. They presume that the world is just simple, so we just need to standardize it. But in fact, it's not.

So Rob's idea is that we should divide the world into two situations only: the standard and case. Some of our activity will be standard, where it's known, familiar, and defined, and the rest is the case, where it's unknown, it's unfamiliar, and undefined.

So Rob suggests that we should treat the unstandard case as normal using a body of knowledge called case management. By combining the two approaches, we can come up with a whole complete model to deal with whatever situation we face, whether it's familiar or unfamiliar, using Standard+Case.

So to me, it's all about how we look at the world from where we see the world, rather than just like us. I don't know how people look at us, but to us, we are a perfect match. What do you think?

Rob England

In our complementary views of the world. Yeah.

It's quite interesting when you look at the world in different lenses. So for example, we're Kiwis. Not both of us born there, obviously, but there's this tool, thetruesize.com, where you can overlay any country over any other country and get rid of the Mercator projection distortions.

I was fascinated to realize just how big New Zealand is. I never realized that when I overlaid it over Europe, I was like, "Wow," all the way from Scandinavia to the South of France. Or perhaps more appropriately for Teal Unicorn, that Vietnam and New Zealand are pretty much a perfect match for each other. See?

So one last thought for you is, how do you get the service management people on this journey? A mechanism that I like to use is crazy goals. I set crazy goals. No, I don't set crazy goals. I get someone of influence within the organization to set crazy goals, a manager to say, "Hey, what would happen if we killed this cat?"

And then there's a formula that I learned, two really powerful words. People go, "Ah, it's impossible." You go, "Okay. Impossible unless..." Are we still ticking? Yeah. "Impossible unless," and then just leave it hanging.

And people go, "Well, it's impossible to kill the cat unless blah, blah, blah." And you go, "Oh, what about them?" "No, they're impossible." "Oh, all right. Impossible unless..." "Oh, well, we could..."

And so you get them to unpack stuff and work their way back up the sort of causal chain until they say something. You go, "Well, we could do that, couldn't we?" "Yeah, we could do that." "Oh, well, let's start with that then."

And so by setting some sort of crazy goal, you work it back until you get some sort of implication that's actually achievable, and you get people started on the journey. So that's an interesting way to get people to start thinking about, maybe this is possible after all.

Cherry Vu

Mm.

Rob England

So Gene likes us to finish with what do we need?

I'd love to breathe some life into Kaimu and get some more stories in there from people about how DevOps has informed ITSM or how ITSM has informed DevOps, and what are some of the learnings and what's some of the power when the streams cross. What do you get when the two come together? And I'd love to build that body.

And then there's a more general thing that we constantly ask in any presentation: what are the engines for transformation, like crazy goals? What are some of the actual functional teams you set up? What are some of the mechanisms and models you use to drive transformation in the organization to power it along? What's the engines? What's the power? Because that's our business, and so we'd love to have some more ideas in that space.

And finally, of course, we'd challenge you to see the world with new perspectives, to pick up some of these new lenses. If you're from the service management world, pick up the STELLA Report, pick up SRE. If you're from the DevOps world, then pick up ITIL Practitioner, pick up Standard+Case. That would be nice. Pick up some of these new ways of looking at your universe.

Thanks very much.

Cherry Vu

Thank you.