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.



