Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
In this DevOps Chat, Mark Smalley of Smalley.IT, and Lead Editor with AXELOS of the ITIL 4 High Velocity IT joins ASG CEO Mitch Ashley to discuss his work creating this new contribution to ITIL 4. Mark shares the 5 value investments important for organizations seeking to operate at high velocity and some of the insights gained from himself and others covered in this ITIL 4 module.
As usual, the streaming audio is immediately below, followed by the transcript of our conversation.
Transcript
Mitch Ashley: Well, I have the pleasure today of being joined by Mark Smalley. Mark is Lead Editor of High Velocity IT, part of the ITIL 4 initiative. Mark, welcome. He’s also with Smalley.IT, I believe a one-person firm. Welcome, Mark. Would you please introduce yourself, tell us a little bit about you and the kinda work that you do?
Mark Smalley: Sure, Mitch—thank you, thank you. Yeah, Smalley.IT, I’ve been on my own for about eight years now; previously, around 30 years at Capgemini and other managed application service providers. So, very much on the application side, very much on the service provision side. That’s really my background. The personal background—born in London, but have lived in the Netherlands, just outside Amsterdam, for about 45 years now, which is not a bad place to be.
Ashley: No, not bad at all.
Smalley: One of the recent—yeah, one of the recent initiatives I was involved with was the AXELOS ITIL 4 update, responsible for the emergence, I say deliberately the emergence of the high velocity IT module, because it was quite an interesting process, pulling in knowledge from various areas in IT service management, but also agile DevOps and out of the IT space completely. For instance, some people may have come across The Toyota Way, the management book about the Toyota manufacturing process. Professor Jeff Liker at Michigan University, he kindly contributed a bit to the book about the Toyota Kata, which is about an improvement method based on scientific thinking. So, drew in people from various fields to try and get this thing off the ground.
Ashley: That’s gotta make it really fun and engaging, too. Why don’t we start out with what do we mean by it? What’s a good definition of high velocity IT? How would you give kind of a working definition of that?
Smalley: I’d first qualify it by saying it’s not actually high velocity IT, but it’s more about higher velocity IT, because high would imply that there’s low and you say, you know, “High is good, low is bad”—well, that’s not the case. We’re on a gradient, on a spectrum from lower to higher velocity. We’re looking at the kind of organizations that you’d say would be more digitally enabled than most.
So, the kind of organizations that use technology to do things significantly differently or even do significantly different things because technology enables them to do that. And that requires a different way of thinking, a different way of working than many people are used to. So, the book’s about different ways of thinking, different ways of working, and primarily the people in the IT service management space who are now confronted with this digital stuff and how do we deal with that? And trying to get them—it’s sort of a guided tour through the kind of things that you come across in these more highly digitally enabled organizations to encourage them to unlearn the old ways of working that aren’t effective any more and integrate new ways of working, new approaches in how they do stuff.
Ashley: I think one of the really important and kind of fascinating parts of your work on this, Mark, is it’s not just about the bubble of IT or the bubble of my part of, my role in IT, it’s that high velocity for the whole organization and how you all work together. And I know it really—there are many places to start, but clearly, product management, there’s some outcome that we’re doing all of this work for, some product or service or offering that we have, and that’s a great place to really engage in kind of a systems thinking about this.
Smalley: Yeah, very much so. It’s taking the end to end perspective. We’ve defined five objectives to give us a bit of guidance in this space, talking firstly about valuable investments—are you doing the right thing in the first place? Are you automating the right kind of business processes? Are you building digital products and services that are appealing to the marketplace? Are you doing the right thing? Fast development—are you doing it quickly? Resilient operations—once it’s up and running, is it resilient? And deliberately using the word resilient rather than reliable, because the kind of systems we’re dealing with are often complex and therefore unpredictable in their nature. They will fail.
Ashley: Mm-hmm.
Smalley: You know, these are fail-safe systems, these are systems that should be safe to fail, so it’s about the resilience—how quickly can you get the systems back up and running? Then the fourth objective is co-created value. Then again, you have that broader chain; that’s when IT starts engaging again, with the user community, in that intricate and even intimate dance that they do together that’s, you know, to help the users derive value from the investment. And finally, the fifth overarching or underlying objective is all of the above—assured conformance, it should be able to assure conformance to governance risk and compliance requirements, whatever they are in your kind of organization.
So, it certainly is, what you said, the big picture, end to end.
Ashley: Mm-hmm, very much makes sense. You know, it’s interesting—tell me if this jives with what you’ve experienced. Highly reliability, the best way to do it is don’t change anything, right? Make it very stable. But we live in a world where business needs to execute quickly, but also dynamically to react to changing market conditions—you know, pandemic being a great example of that.
Smalley: Yeah, yeah, yeah.
Ashley: A tragic one, but very much one that’s outside of our control—but also, you know, offensive strategies to go after markets and that, and the degree that the whole chain, the whole kind of supply chain of the organization working together can effectively do that quickly and reliably, but also resiliently, because you want to be able to experiment and try things. And maybe you need to fail to find the right answer for product mix or whatever.
So, I’m sorry, I don’t wanna go on too long, but it seems like that’s an underlying driver behind all of why you took this approach, at least in part.
Smalley: Yeah. Well, certainly, if you look at the dominant thinking behind most of the guidance there’s something behind it. There’s that concept of co-creation, realizing that you don’t do stuff and chuck it over the wall, you have to engage with other stakeholders—one of the things.
The other main thing is dealing with, working in complex environments. Again, using that word complexity in the sense of complex adaptive systems, organizational systems where you simply can’t predict what’s gonna happen and where you, because of the volatility, the unpredictability of stuff, you can say that’s bad but from a research and development perspective, you want to be able to, you know, 10 initiatives will fail, but it’s that 10th one that’s gonna make you millions. You’re gonna benefit from that unpredictability.
So, it’s really, it’s from the start, through the whole life cycle that you’re dealing with the—with the unpredictability which, for many people in IT service management, is a bit disconcerting, because if you go back—go way back, and you look at where people came from, IT service management people were very much concerned with the stability of systems and putting a wall around them with the best of intentions, with the belief system safe is good, whereas the developers had a different perspective—fast is good. So, you’ve got this fast versus safe. And seemingly, irresolvable, that conflict.
But if you look at it creatively—and this is something that we’ve got a lot to credit the DevOps community for, and we reference extensively stuff that’s gone on in the DevOps world in the High Velocity IT book. The idea that if you—and it goes back to lean as well, lean in particular, agile a little bit—working with small batches of work, if you do work in small batches and more frequently, then you reduce the risk, ________ smaller changes and less risk in bigger changes. And the interesting thing comes along now—if you do changes more frequently, instead of saving them up for each, you know, masses of changes each quarter, no, do them every day, then you develop your capability to change effectively.
So, paradoxically, you’ve turned it around completely. The more often you change—small changes—the better your change capability and therefore the more confident you can be that the changes will go through pretty safely.
Ashley: Mm-hmm.
Smalley: And it’s interesting, the groups that have to interact together, like, if you’ve got a DevOps group or a classic IT service management group, they identify with their own belief system, and often, the belief system is, you know, safe is fast—sorry, safe is good as opposed to fast is good. And how do you—you know, you’ve got to get these people together and talk about this stuff to resolve the apparent conflict. But it’s great stuff trying to build bridges between these communities.
Ashley: Yeah, I’m totally with you and thinking of the sort of lean mindset and agile and iterative, which is very much where software product and organizations have moved to or are moving there. What are the—how do you deal with some of the legacy silos and sort of that self-protection of don’t change things or don’t, you know, let’s focus on keeping things stable or whatever the mantra of those individual groups are? How can this book, for example, this module help people start to expand their thinking around those issues?
Smalley: Well, firstly, if you look at organizations, they will vary in velocity across the various divisions and departments. So, firstly, you’ve got to take a look at which part of the organization are we looking at? What is the appropriate velocity in the business there? What kind of cadence applies to their work? Interesting looking at the pharma industry that’s traditionally been highly regulated with very long periods in which they work. There’s no point speeding things up if you have to wait years before you move to the next stage. It’s like doing the Olympic games—you don’t want the stadium there earlier; there’s no point. So, it’s got to be very much aligned with the business velocity.
So, look at the specific parts of the business and, depending on the kind of speed—and possibly, you’re dealing with legacy systems that don’t need to go that much quicker. And the advice we like to give in the guidance is, the first couple of statements, the guidance is not complete, and the guidance is not intended to be prescriptive. We don’t pretend to be able to dictate, proscribe how people should act. Rather, we’re trying to encourage them to take a look at the 9 concepts and models that we’ve adopted, the 25 techniques to see which techniques do you think would apply to you. So, be selective, pick and mix, take a few things out, experiment with them, see if it works in your environment.
Because this is going back to lean, you mentioned lean, going back to the lean movement, you’ll probably know many of our listeners, audience will know that the Toyota production system was the precursor to the lean movement. And one of the grand figures in the TPS Toyota Production System, was Taiichi Ohno, who came up with some wonderful sayings, one of which is, “You should think for yourself and face your own difficulties. Don’t try to borrow wisdom.” So, in other words, how another organization has done something, that’s not gonna work for you. You have a different kind of organization, so you really do have to dig deep and look at the specifics of your situation and pick the various parts that you think apply to you and just experiment and see whether they work. So, it’s—
Ashley: Really more of an adaptive approach versus prescriptive, right? It has to be done a certain way because one organization succeeded at it that way.
Smalley: Yeah, no, and of course, it’s very tempting, but people are looking for the quick fix. There’s a fabulous cartoon, if anybody wants to look up a great cartoon, if you look up “Simple but Wrong, Complex but Right” it comes up with a great cartoon and you see people following—there’s a sign pointing in two directions of people, the masses are following the sign “simple but wrong,” because they’re looking for a quick fix.
Ashley: Mm-hmm.
Smalley: And what better than looking at how another organization’s done stuff and say, “You know, let’s do that.” It’s not a good idea, usually. [Laughter] So, you do have to be very, very critical, very selective.
Ashley: Well, these are systemic changes, they’re not quick fixes or just change this one thing of how you’re working and suddenly you’ll get different results. And one of those is, we think about specialties or specialization of what we do, but we’re also now thinking, it’s specialty roles, but it’s also how those things work across the life cycle development operations, product teams. So, individuals and teams’ abilities to work cross functionally is a much higher order skill than maybe we valued in the past.
Smalley: Yeah, look at the—I think we can kind of credit the DevOps community for something, but look at the agile community, how the concept of multi-functional, cross-functional product teams have emerged where you’ve got business analyst disciplines, development disciplines, testing disciplines all working together.
It’s interesting to think about the definition of done that they often apply as a concept that you’ll come across in agile and scrum, you know, “When are we done?” It often, in the scrum world, it ends with a potentially deployable increment of software, potentially deployable. The key word is potentially—it hasn’t been deployed yet. So, it’s just asking for an extension of that domain of the team to not stop when it’s deployable but actually deploy it, so start involving the DevOps kind of competencies as well. Then you could extend it further to the service area, because product owners should be aware that the kind of product that they’re building, that needs to be accessed by people, and service is the vehicle that gives users access to your product. You built a great software product, but it’s only through the vehicle of service that people get to it.
And is the product owner, is the product team looking as much at service as they should be? And I think that’s often not the case, and I’d certainly like to, in the role of bridge builder, like to encourage product teams to take a closer look at service and think about the kind of characteristics the service experience as well that they expect their users to have. So, you can see a service substrate going through all of the life cycle, really, alongside the software and infrastructure artifact.
Ashley: I’m curious, you mentioned design earlier and maybe this is what you’re referring to. I’m curious if design thinking or the design approach is something that also influenced your work on this module, the idea that you’re really, the outcome isn’t the car, the outcome is the experience that the customer, the user of that vehicle has and expects, you know, from whatever the product is that you’re creating. Did that influence this work, too?
Smalley: Yeah, two things, there—design thinking, we’ve referenced more at the start of the process, thinking about the kind of specifications requirements that people have. But towards the end, thinking about the service experience, and you’ll be familiar with the concept of service level agreements, which are often unfortunately formulated. We talk in terms of availability and performance and security and stuff like that—all very technical.
But how do the users feel about this? We’re slowly extending that domain service level agreement to include experience level agreements, looking at outcome and how people feel about their engagement with either their technology or the people behind the technology. So, again, that’s that human co-creational dimension that you see in high velocity IT, alongside the technology.
Ashley: Mm-hmm. Yeah, the SRE world, I don’t know if we’ve talked about that, but it has this idea of service level objectives, which is a little less formal and restrictive as what we think of contractual SLAs of, each team really, you know, defining what they’re trying to strive for, for the service that they’re trying to deliver and the experience that people have. So another area, SRE, is a great one.
Smalley: Yeah, no, that’s in there as well. SRE is certainly something that significantly contributes to more resilient operations, just like chaos engineering, another of the techniques that we reference. But speaking about agreements, certainly, you should measure stuff. Whether you—you know, the trouble is, once you put something into an agreement between two parties, people start to game the system. Things—I think it’s Hawthorn’s Law. It’s like as soon as you make something explicit, intrinsic motivation evaporates.
Ashley: Mm-hmm.
Smalley: Yet you do have to agree something with other parties. So, it’s really, it’s a delicate balance, you know, what’s gonna work in this situation. Also looking at the relationship that you have with your customers and other stakeholders—so, assessing what kind of relationship, what kind of agreements and measurements are appropriate for each particular situation.
Ashley: I was thinking about, too, when you mentioned resiliency, and previously, you were talking about sort of the iterative nature, doing work in much smaller increments—that also gives more flexibility for change. So that, you may have a feature turned into a story that might be delivered over multiple iterations in an agile process, and somewhere in that process, you may have part of it released, but you may move on to other things or shift what you’re actually doing. So, it’s a way of dealing with some of the dynamic, changing needs of the business.
Smalley: Yeah, it’s—we reference four characteristics of the approaches that you’ll find in these kind of organizations. We reference lean, agile, resilient, but also continuous, and I think that fits into this category.
You know, things are changing all the time, so it’s interesting when you’ve got these traditional discussions between business people and IT people. You’ve got IT people almost blaming business people for the fact that the world has changed, who it’s the kind of the core values that you have, the belief system you have, if you have the belief system that things are changing all the time and that’s just part of life, that’s a given, then you don’t resist as much. We certainly try to encourage people to embrace and enable change as well. We used to talk about change—management change control, which seems to be a bit defensive. When now, it’s just language, but even then, we like to talk about change enablement—how can you get changes done as quickly and safely as possible?
Ashley: Very interesting. Yeah, words do matter. What’s the state of the community, the ITIL community in the adoption of some of the principles around lean and agile and DevOps and SRE. Are most folks starting to become aware of or are they educating, are they practicing? Where would you say we are in this journey?
Smalley: Yeah, well, I forget who said it. Somebody said, “The future’s already here, it’s not just evenly distributed.”
Ashley: [Laughter] Yeah, that was Stephen Hawking or someone.
Smalley: Yeah, that’s right, yeah. You know, some people are doing it. I’m very pleased to see on LinkedIn or Twitter a response from an organization in the U.K. that says, “This high velocity IT stuff, this reflects the things that we are doing.” This is a guy on the joint DevOps and IT service management come together. I mean, that’s his area of work.
Ashley: Mm-hmm.
Smalley: It’ll depend on the kind of products and services that people, organizations provide are the digitally enabled? How digitally enabled are they? So, it is very diverse. Lots of people for whom this is all pretty new, one of the things we, one of the objectives we have for the book is to familiarize people who know the old way of working, you know, working in silos, that kind of stuff, and get them used to—make them more confident, confident to engage in discussions with their DevOps, with their SRE colleagues about digital to get the conversation going.
Ashley: It seems like that’s very important because, as things evolve, new things come into the picture—DevOps, et cetera, SRE. It’s really easy to be sort of overwhelmed of, “Now, what’s that, and how is that different and why should I care, or does it apply to me?” So, it seems that maybe taking that approach in this module of trying to bring that together from an ITIL perspective, from an operational perspective makes, maybe, those topics a little more approachable, a little easier to consume and understand?
Smalley: Yeah, and one of the things we advise people is to look at the five objectives that I mentioned, from valuable investments to a short conformance, and discover, identify where the weakest link is in the organization or in that part of the organization. Because if you look at the theory of constraints, another body of knowledge that we reference, you should always be working on the weakest link.
So, that helps you to focus on a particular part—don’t be overwhelmed. You can’t do all of this. You wouldn’t want to do all of this at once. Pick your weakest link, pick something that seems feasible that you can think, “Yeah, I can make an improvement, there,” and very much in the sentiment of continual improvement. Of course, one of the DevOps tenets, the third way of DevOps is continuous improvement—learning and improving all the time.
Little steps. I think that’s the way we’d like to encourage people to go—just take it step by step. Because after each step, you refer to the systemic nature of this kind of stuff. After each step, you’ve changed the system, so you’ve got to look around and see what’s changed and then plan the next step. So, moving from what I call confirmatory ways of working in the high velocity IT books, you know, when you’ve got pre-determined plans and deadlines and milestones, because you can more or less predict what’s going to happen, you confirm that—during execution, you confirm that what you predicted in the plan happened.
So, move—and we’re used to that in IT service management, predetermined process. So, moving from confirmatory ways of working to more exploratory ways of working, where you take things step by step—so, evolutionary. As Dave Snowden, who some people will know from the Cynefin framework, says—Dave authored a great piece about ethics for the book, by the way, but his core area is, he’s known from his complexity work—he says, “You’ve got to move to the adjacent possible in an organization.” So, sort of feel where the disposition of the organization is, in which direction are they moving naturally, and try and give them a nudge in that direction, zig-zagging towards, you know, whatever you want to achieve. That more—again, that’s that working in complex environments, reflecting the and respecting the unpredictable nature of the world we work in.
Ashley: You know, we’re kind of borrowing from a lot of disciplines talking about this and one that comes to mind, I believe, it’s quantum mechanics that just observing something changes.
Smalley: That’s it, yeah, the Heisenberg principle.
Ashley: The Heisenberg principle, thank you.
Smalley: Yeah, shine a light on it and it’s moved. You can either detect the velocity or the position, but not both at the same time.
Ashley: Mm-hmm. Very good. Well, this has been really fascinating—yeah, go ahead.
Smalley: I think Schrödinger’s cat came into it as well, didn’t he?
Ashley: [Laughter] Very good. Well, you know, I think what’s fascinating about your work and the contributor’s work on this is, I venture to guess there wasn’t a lot of discussion about tools and technologies, because you’re really thinking about the how of how we do work, how we work together, how this leads to the creation of software toward some co-created outcome.
Smalley: It’s very much the people dimension as well. You see that just talking—I mentioned ethics, for instance. Ethics—people want to do the right thing. That’s an aspiration that people have. They want to trust and be trusted in the workplace—psychological safety. I’m delighted that our industry is talking about this kind of stuff more often. Talking about things like—I remember at a conference, you know, the good old days when we actually went to conferences, a conference in, I think it was New Zealand, in Wellington, where somebody was talking about social anxiety as a rather introvert engineer.
Ashley: Mm-hmm.
Smalley: And it’s great, because you know, people empathize with that, and it’s great to trust and be trusted, fostering an environment where people can feel free to express themselves without fear for their position or reputation. If you build that kind of a foundation in your organization—you know, all the tools fit into place.
By giving people the confidence to—and the privilege, possibly a final thought, people just don’t work in IT. Some people say it, but you know, I’m sure some people don’t just work in IT, they have the privilege of contributing to the well-being and prosperity of digital service consumers, right down at the end of the chain. And I find that inspirational, thinking, you know, not just what happens in my silo, but at the end of the chain, you’re helping change somebody’s world. And that’s the kind of, that’s what I like to say about this book—it’s guidance that matters for people like us, who care.
Ashley: Mm-hmm. It’s definitely inspiring to know that you’re helping people, right, in the work that they do.
So, Mark Smalley, it’s been fascinating talking with you. I applaud you on the approach you took on this, a lot of great concepts that you’ve incorporated in the high velocity IT module, and I hope folks will check it out, because I think there’s some super valuable things. Again, changing the system is just by first observing it and I think just reading the module, checking out parts of it would be a step in that direction. So, appreciate your contribution, and it’s been great talking with you today.
Smalley: My pleasure, Mitch. Thank you very much, indeed.
Ashley: You bet.
