Rob England

So we are Teal Unicorn.

Well, I'll get to that. It's a really good buzzword-oriented logo, but we like that. So, teal because high culture. For those of you who've read Reinventing Organizations, Laloux's book about the different color-coding of culture, teal is the aspirational highest level of culture that we aspire to. Unicorn, you all know that one. It's the aspirational model for how we work and the new way of working, because it is.

So we know it's brand for a fad. We know it uses these fad words, but we actually like fads. We think they're engines of change. We think that by anchoring yourself to some of these buzzwords, it helps drive things. So anyway, I hope so, because that's our brand as a team.

We're based in Wellington. So for those of you, you can probably guess already, well, you can guess that Cherry's not a New Zealander. We'll get to that in just a moment, but that we're from New Zealand.

So Wellington is 400,000 people. It's not a big city, but it's government. So most of our work is government, and most of our work is consulting by the hour with large clients around strategy and evangelizing some of these ideas, and coaching and training.

And it's interesting that I worked in the service management world for many years, so I come from the dark side, and did a lot of consulting in that space. And no one really wanted to talk about DevOps until three years ago, and suddenly our whole world is DevOps, and all my work for the last few years has been DevOps.

But now we're starting to pick up some work working in agile enterprise in Vietnam, and helping transform large organizations in Vietnam at the enterprise level to new ways of working, which is pretty exciting.

So I am Rob England, and a few of you will know me from my blogging and The IT Skeptic, and I have a bit of an online presence in this world. And with me is Dr. Cherry Vu, who has no IT background whatsoever. So it's highly amusing, especially in the exhibit hall, walking around with Cherry, listening to the vendors trying to explain technology. It's terrific.

Cherry Vu

I often say that you guys have three minutes to talk about whatever you are doing. If you're able to get me to understand, then you can make everyone understand. You can sell to everyone, right?

Rob England

Yeah. And it's been really interesting even to coach a few of them in that language. So that's exciting.

I missed one slide, sorry. Our clients are pretty small by your standards, but now that Cherry has introduced us into Vietnam and her contacts there, we're working with organizations that are 10,000, 15,000 people, and we're working at the enterprise level, not the IT level, which is fascinating.

So I guess the last thing to say is that we are partners in life and work, which is fantastic.

How horrible it would be.

It seems to work so far, so fingers crossed on that one.

Cherry Vu

By the way, I'm his boss.

Rob England

Yeah.

Cherry Vu

Just to make sure.

Rob England

I always omit to mention that, but if we had time, I would tell you about what it does to Vietnamese culture when Cherry gets up and does all the talking and I literally carry her handbag. It's fascinating.

But anyway, come and hear in a bar about that story, because it's fascinating, taking feminism to Vietnam.

But let's get on with the show. So DevOps has three practices parents, right? It stands on the shoulders of ideas from Agile, Lean, and service management. And Gene Kim's been really passionate about saying, "Don't throw the baby out with the bathwater. ITSM has value. It's part of what we do. It is part of our body of knowledge."

But somewhere along the way, we went tribal, right? And I was part of that in the early days. The IT Skeptic was chucking rocks at these crazy Agile people and this crazy DevOps stuff. And it was people like John Willis and Gene who wore me down and convinced me. And eventually, it was a blog post by Jez Humble which was the breaking point where I saw the light, brothers and sisters, and came on board.

But I was part of that sort of factionalism, where you've got you guys saying, "Ding dong, ITIL is dead. Yay, we never have to do ITSM again." And you've got the ITSM people saying, "These free-range cowboys are dangerous people." And those stereotypes have created this fracture in the body of knowledge, which is a bit unfortunate.

And there were really good reasons for it, right? So ITIL had baggage. And I worked for years as a consultant doing ITSM transformations and introducing ITIL and ITSM ways of working, and with mixed success. There's a lot of stick and not a lot of carrot.

And ITIL has these inherent fundamental problems in it around the fact that it's siloed into processes. So I should say, by the way, that the ITIL Illuminati, the ITIL philosophers, would foam at the mouth at some of the things I'm going to say, because in theory, in the books, it doesn't necessarily say this. But there's a difference between what the ITIL dictionary says and ITIL as it is spoken in the streets, right? And so I'm talking about how ITIL ends up being implemented, not necessarily what the theory says.

But the books are still structured. They drive us into thinking about processes. Go and improve change management. Go and improve incident management. We're going to have an ITIL project, and we'll spend the first two months on incident and the next two months on problem, and that'll fix it.

So the thinking drives into processes, and many of you should know that that creates local optima, not systems optima, and that's a real problem.

So ITIL is not inherently bureaucratic, believe it or not, but boy, does it empower bureaucrats, right? They love it. They suck it up. And so it empowers the bureaucracy within our organizations.

And I've always thought with the ITIL books that they feel like one of those hospitals that's been built, and they haven't yet opened it, or they don't have enough money to open it. And there's just these empty corridors. There's all this equipment and these beds and everything, but there's nobody there. And the books feel very sterile, very empty of people. So I've always felt that way.

And then I used to say that ITIL should have color-coded pages, right? There should be the green pages and the blue pages in the ITIL books, because sometimes it's talking about orthodoxy. It's talking about generally accepted practice that's well established, and this is how it's done. And then sometimes it's trying to create thought leadership and establish new ideas, and it doesn't tell you when it's doing one or the other, which is very dangerous.

To be fair, the thinking from ITIL originates in the '70s and '80s and was codified in the '90s. So a lot of these ideas predate a lot of the bodies of knowledge, or some of the bodies of knowledge that we stand on.

Complex systems theory and the work of Cook and Dekker and all of these things predate ITIL. So they're not completely off the hook. Deming doesn't predate ITIL, and so there are no excuses for the stuff that's not in ITIL, but there are some things that just weren't around.

But at its heart, the inherent problem with ITIL is the myth of the simple system, the myth of the define perfectly, execute perfectly, define once, execute once, the waterfall myth, and that's baked into the books. I don't care what the philosophers say.

So there was this baggage. There were these issues, these historic issues.

Then you've got the whole project management thing. So this is the topic of a talk that I gave at New Zealand's largest computering conference, and I had a few people come up and talk to me afterwards.

Cherry Vu

And also, he got a lot of people who get angry.

Rob England

Yeah, they were talking.

Cherry Vu

They want to kill you.

Rob England

Yeah. But I will argue this one in a pub for hours, right? And I've written a lot about this on the blog, and so you can go to itskeptic.org/pm, and there's a number of... I'm not going to go into this, but it's dysfunctional.

Project management was introduced to try and get some control over those people down on the third floor, and it's just been massively damaging to IT. So my thoughts are written somewhere else, but this is just a quick summation of the dysfunctions that it drives and the ways that we work.

So you've got ITIL, you've got project management, PRINCE2 and all those sort of things, and PMI in this country, which is a little looser. But there's this baggage.

So there's good reasons why that tribalism happened, but it would be so much better together. And so I've tried for years to try and find common ground and bring the communities together with no success whatsoever. But happily, we're seeing in the last year or so that this is starting to happen.

And so Cherry's come and joined me just in the last couple of years and comes from a totally non-IT world and has been learning about some things like agile thinking, which seem perfectly natural and common sense. And she's like, "Well, duh, why doesn't everybody do this?" And that feels really natural.

But then also starting to learn about the service management world. And I'm kind of coming in the opposite direction with all this service management IT background and starting to learn more and more about business and strategy and culture and transformation, and moving into the agile world.

So we've kind of had the same coming together, and so it's really fascinating that we have this personal perspective on what is also something we're seeing in the industry. So we want to very quickly talk about the crossover that we're starting to see, and at last, and it's wonderful.

So from one side, you've got things like SRE coming out from Google. You're seeing the DevOps community understand that what you originally meant by ops is not what service management people mean by ops, right?

There's DevOps ops or DevOps run. There's all that stuff after it goes live, which in the early days of DevOps did not get a lot of attention. It's like, well, if it breaks, call me. And now we are really seeing, aren't we, much more focus on operations and on what happens once this thing's in production, and how do we keep this going.

So support's being deconstructed. It's being rethought in some really fascinating ways. And we're getting all the insights into human error from Dekker, and so we'll talk about those.

But all the bodies of knowledge that DevOps people are really good at reaching out and drawing in, Cynefin, and bringing in people like Snowden and Cook and Dekker and now Maslach, people who are completely outside the IT community and drawing that knowledge in, are really good at that. Whereas traditionally, IT's been like, "Oh, no thanks, we'll invent it," and has ignored even Lean, which is just extraordinary.

So we see this stuff coming from this community, and now the big thinking around resilience. That's great.

And then from the other side, from the traditional service management side, we see the service management world embracing Agile IT, believe it or not. I'll talk about that. No, Cherry will talk about that. And ideas of swarming, and seeing the service management community start to suck up some of these ideas and evolve in its own way, and understand things like complex systems.

So we're seeing the crossover at last. We're seeing the cross-pollination, the ideas flowing back and forward between the two communities.

So from the new ways of working side, there was the SRE. I don't know how many people-- Who's actually read the book?

A few people. Quite a lot, yeah. It's a big book and it's really a collection of essays, but it's fascinating to see how the unicorns work, and there are ideas from that that are escaping out of the unicorn world into the horse world. I'm an anti-crypto-equinologist, which means I don't care about unicorns. We work with horses.

So these ideas are flowing down into the horses, and that's fabulous.

But at the same time, one of the essays in that book talks about how they did all this research at Google to try and establish what was the best possible metric to measure the quality of their systems. And eventually they came up with unplanned downtime.

And the service management world was like, "You think?"

So some of the naivety of it is as fascinating as some of the brilliance of it. But anyway, so you've got SRE.

Now, the STELLA report. You should all have read the STELLA report. It's an amazing insight, and many of you will have been privileged to see this material presented by John Allspaw or Richard Cook at some of these conferences. So these are, again, amazing ideas about incident management and problem management, which the service management world just never saw coming. It's like complete first-principles rethink of service management, and it's just amazing.

Then the ideas of Richard Cook have been around longer. I read "How Complex Systems Fail" a number of years ago, I think even before I'd drunk the DevOps Kool-Aid, and it just transformed my thinking about how support works and the reliability of systems and so on. And so that was an extraordinary seminal paper way back that just changed the world, rocked the world.

And then there's the Sidney Dekker stuff. It's having a big impact on service management thinking with the understanding that if you're not designing your systems on the assumption of human error, then you're not designing resilient systems.

So there was The Field Guide to Human Error Investigations, and then the better-known Field Guide to Understanding Human Error, and then Safety Differently, which is an extraordinary video to watch on YouTube if you just want a first introduction to Dekker. And now he's put out Just Culture as well.

So these are people from completely outside IT who are bringing these ideas of complex systems in.

And then I always talk about how DevOps has its own fads. And so one of the latest fads in DevOps is resilience. So Rugged Software's been around for a long time, and some of you will have seen Josh Corman present and seen the stuff on that, around the integrity of systems.

And then more recently, we had the privilege of going to the--

Cherry Vu

Redeploy.

Rob England

Yeah, the Redeploy, the first-ever Redeploy conference in San Francisco that Paul Reed put together. You here, Paul?

Probably not. He's heard all this.

But that was a really extraordinary conference about resilience. And the big thing I took away from that was that half the presentations were about psychology and humanistic things. And half the presentations were about AWS and cloud and stuff that neither of us understood a word of.

But it was this interesting mix of super-geek tech and deep psychological thinking. It was a fascinating conference.

So you've got all this stuff going on from the cool kids, from the new ways of working, that is profoundly starting to influence the service management world. And then at the same time, you've got the service management world, which is going through its own transformation with the ideas leaking across from our community.

So Cherry, who went on this journey of exploring all this stuff herself, is going to talk about some of the key insights she saw in that journey.

Cherry Vu

Thank you, Rob.

Do you believe that he's the best assistant ever? I have to say.

So in IT service management, we have a huge picture in this. Organization has its own value streams, and IT contributes a lot of value streams into the organization.

So this single value stream from require to deploy, that DevOps tend to focus mostly. Do you realize that? Once the software is put into the system, then DevOps tends to care less when it's already run.

On the other hand, IT service management, it focuses on the longer picture, longer time, from before the software is built, from the strategy portfolio programs level. So they could decide what software is to be built.

And then not only that, when the software is built and it's running in the system, it looks after the software until it's retired. So it's running, supporting, and eventually the IT service management decides to retire it.

I don't know what happened with my-- Maybe I'm too tall. Sorry.

Rob England

Yeah, you're too tall for the mic.

Cherry Vu

I'm just too tall for this.

Rob England

No, is that-- Yeah, a little bit further away from your mouth.

Cherry Vu

Okay.

Rob England

How's that?

Cherry Vu

That's good.

So not only that, in space, ITSM also takes a bigger space in terms of, it goes from the strategy portfolio to the detect to correct. So it's a whole thing that IT, which is called IT service, ITIL makes sure that the customer, the end user, get what they want, and it looks after the whole lifecycle of the software, whereas DevOps tends to focus mostly here.

So can you see that, how different it is between the old world and the new world? The new world tends to make the baby faster, but they don't care much about how to look after the baby, taking care of the baby.

Rob England

As it grows up.

Cherry Vu

As how it grow up. So they don't really care about it. I don't know whether, because I have no IT background, but that's what I see, how the worlds function, the IT worlds function.

So the point here is that Rob is an expert, ITIL expert. Is it?

Rob England

Oh, yeah.

Cherry Vu

Yeah.

But what I learned from ITIL practitioners, which Rob jokingly calls ITIL 3.5, because it came after ITIL 3, and the new editions make ITIL much more agile. Can you see how similar these nine principles to Agile and DevOps?

So it's really interesting for me to discover the ITIL transforming itself with the new ideas.

So it's another book that's called VeriSM, and I think that I--

Rob England

Oh, no. ITIL 4.

Cherry Vu

Oh, sorry.

Rob England

One more slide.

Cherry Vu

Yeah, I'm sorry.

So we are looking forward to see the new ITIL book. It's called ITIL 4. It's coming next year, and it also says the same thing. I'm not quite sure how they're going to implement it, but it's just the same thing. End-to-end lifecycle and focus on holistic views, not only the single procedures. Also, they are talking about flexible value flows and continual improvement, just not releasing big bangs or huge chunks of software at the same time or at once.

Rob England

I have to say, though, sorry, just the red arrow. Pop back if we can.

They promised those first two or three in ITIL 3. Really, the only new promise is the moving to more granular continual improvement as an emphasis over major releases. So we'll see how they deliver, but it didn't really deliver in ITIL 3, and so it'll be interesting in ITIL 4. Sorry.

Cherry Vu

So sometimes it's so different between the book and the reality.

So there's a new book. Have you ever read this one, VeriSM?

Rob England

Has anyone heard of it?

Cherry Vu

Anyone heard of it? Oh, yes.

All right. So I'm so pleased that I know someone who's one of the lead authors of the VeriSM. And he's tried hard to explain how it worked to me, but I never get it. So I'm sorry. I never get it. I never get how the VeriSM approach actually works. I need to understand. I actually need to spend some more time to study on it.

So another interesting thing that I see, that how ITIL evolving in the new way of working, it's called Agile service management. So there's a guy who come from South Africa, is it?

Rob England

Mm-hmm.

Cherry Vu

He's talking about how to apply Agile in the call service center, and it's really interesting to see. If you guys have time, please go have a look on YouTube.

Another new idea, and I think that in the old world, the working is based on escalation-based processing. So once something's happened that the first level can't deal with it, they put it in the second level and third level. So multiple layers make the work go very slow.

The new idea, the new world, whenever the problem occurs, we find the right people all together, swarm together, and get things done. So that's how the world goes faster.

So if you guys are interested in these new models, please go to John Hall. He's going to talk about it tomorrow, right?

So now get over to Rob. Thank you.

Rob England

Thank you. Yeah, thanks.

So it's been fascinating to watch how the two worlds are coming together, the two worlds are crossing ideas across, and some of this stuff seems really obvious to Cherry, but it's not necessarily obvious to the service management world. And watching those ideas emerge, I think has been interesting.

So we're seeing them come back together. We're seeing the crossing over, the synergy, and at long last. It's long overdue. We've been going, what, with 18 years of Agile and 10 years of DevOps, it's high time that we explored more of the synergies between the two groups, and that's come out in the presentations at this conference. Damon's last one before, and in a whole bunch of presentations, are talking about how these two communities are meeting together more and more.

So someone asked me about how do you get these frameworks, where are the boundaries, and how do you fit them together like jigsaw pieces? And I don't think that's how you should think about it. I think they're movements. They're different lenses on the same reality. They're different ways of looking at the same reality, and so they have their own distortions. DevOps has its own distortions just as much as ITIL has its own distortions.

And so it's interesting to see the world in new ways, right? It's really interesting if you're an ITSM person to see the world through the eyes of the SNAFUcatchers and the STELLA report. It's just mind-blowing. If you're a traditional ops person, to read the SRE book is mind-blowing. But it's equally as mind-blowing for some people to come from a world which is obsessed on deploy, and to actually have to start digging deeper into the run world and understand more about run and resilience.

And so this is an interesting example of that. There's this thing called True Size, where you can grab countries and move them around the planet and get rid of the Mercator map projection distortions and see what size countries really are. And suddenly you see the world through different eyes and different lenses.

So this is Vietnam, Thailand, and New Zealand. So I never realized that Vietnam is pretty much the same size as New Zealand, and Cherry never realized that New Zealand's pretty much the same size as Vietnam. And I bet none of you realized that they're that big compared to the good old US of A. Right?

So it's fascinating to just have these opportunities to step outside your normal world and see things through different lenses, and I think that's what we want to encourage you to do, whichever side of that fracture you live on.

So what do we need from you? I've got this thing called Kamu, which is the label I use for trying to find that commonality and the crossover and the shared thing. So any stories, reach out and we can talk about that.

Something that we're always fascinated about is what's the engine for the transformation? What is it that drives transformation, that turns the handle, cranks the handle, keeps the energy going? And so we'd love to have some conversations with people about that stuff.

And the other thing we need from you, as I said, is try and see the world through different eyes. There is all this powerful body of knowledge over there in the service management world. Or if you are coming from the conventional world, then there's this powerful new reinvention of those ideas happening within DevOps.

Thanks very much.