Embark on an enlightening journey with Peter Madison and David Sharrock as they tackle the ever-evolving world of service delivery. From the bustling crossroads of Agile, DevOps, and ITSM, they dissect the common confusions that arise from industry jargon, ensuring that when they speak of 'service', everyone is nodding in agreement. Promises of clarity in this tangled web of terminologies are fulfilled as they lay bare the distinctions between product and service delivery – a must-hear for those navigating the intricate paths of modern organizational structures.
As the episode unfolds, Peter and Dave navigate the critical processes of incident response, problem management, and change management. They consider how these elements, integral to the IT service framework, come into play with Agile and DevOps methodologies. The dialogue weaves through the importance of maintaining system stability while managing risk, and the role of context in understanding the various perspectives and terminologies that often lead to confusion.
This week's takeaways:
We love to hear feedback! If you have questions, would like to propose a topic, or even join us for a conversation, contact us here: feedback@definitelymaybeagile.com
Embark on an enlightening journey with Peter Madison and David Sharrock as they tackle the ever-evolving world of service delivery. From the bustling crossroads of Agile, DevOps, and ITSM, they dissect the common confusions that arise from industry jargon, ensuring that when they speak of 'service', everyone is nodding in agreement. Promises of clarity in this tangled web of terminologies are fulfilled as they lay bare the distinctions between product and service delivery – a must-hear for those navigating the intricate paths of modern organizational structures.
As the episode unfolds, Peter and Dave navigate the critical processes of incident response, problem management, and change management. They consider how these elements, integral to the IT service framework, come into play with Agile and DevOps methodologies. The dialogue weaves through the importance of maintaining system stability while managing risk, and the role of context in understanding the various perspectives and terminologies that often lead to confusion.
This week's takeaways:
We love to hear feedback! If you have questions, would like to propose a topic, or even join us for a conversation, contact us here: feedback@definitelymaybeagile.com
Welcome to Definitely Maybe Agile the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello Dave, how are you today?
Dave:Excellent, Peter. Great as always to catch up and have a conversation.
Peter:It is, it is. We're in the same city as well, which is lovely for a change too.
Dave:But not, of course, in the same building or the same room. That would be far too easy.
Peter:Wouldn't it, jess? Yes, so what are we talking about today? I?
Dave:think there's an observation. So we've been kind of trying to think about what this might be about.
Dave:But there's an observation that you know life is getting more complicated right, the services that you and I offer, which used to be really well categorized, agile or DevOps, transformational services whatever it is, are now impinging on many other well understood forms of, quite frankly, frameworks, continuous improvement frameworks, whatever they may be, and we really bumped into that whole idea of service and what it means when you're coming at it from a DevOps mindset versus an agile or product delivery mindset.
Peter:Yeah, and this concept of service, and really what we're talking about is and I think the term used earlier was a terminology soup, but it's this place where we somebody's got a hammer and they're using it to hit the nail. They know how to do things in one particular way with one particular model and they say, well, it sort of fits, so let's do it that way, and it's like well, probably not actually what person needed. It may be too much, maybe too little in some cases, I guess, but there's this piece where, when we look at this, it's just not quite the right fit.
Dave:Well, and I think, to start with touching on that, that sort of terminology soup piece is, if we just use the word service, service means different things in different places in your organization with a different perspective, and so, whether or not it's, I don't know, if it's necessarily lazy in terms of I hear you say service and I immediately think this, or whether it's a natural bias. I mean, we're listening, we're hearing it and we interpret that word in a way that is contextually significant for our experience but may not be the same sort of context that is, it is being used in. So where is the curiosity? We need to explore a little bit to understand. If you say agile service, whatever the word is, how do we know that we're both talking about the same thing?
Peter:Yeah, and I think there's a piece where it comes from different parts of the organization, like your parts of the organization, that the customer facing and interacting with the customers will have a different definition of service than your technology teams that are delivering the technologies that they provide for you to run those services. They're, fundamentally, the concepts are very, very similar and but they're just implemented to a greater or lesser degree and there may be different elements that need to be brought to bear on the particular problem that's being solved, and I've seen organizations hangle themselves in all sorts of knots and trying to and I was just going to add in call centers and customer service and all of those things start changing it, changing our understanding.
Dave:But what's interesting here, and what we're really trying to drill into, is the difference between, say, product and service delivery, where the service that is being delivered maybe is part of the product we offer, maybe it's an insurance product or an experience in terms of trying to get some financial product, some of the other products that we can get as a service pipeline versus, let's say, it, service management, itsm, and what service delivery looks like in that space, which is very much more, I would say, well defined and articulated.
Peter:Yeah, and that there's a couple of differences in the way that these environments work. When you call into a call center, there's typically there will be something that directs you to the right queue in the right place, and so then you're now waiting in that queue to be the next one, and it's often a first in, first out. There doesn't tend to be a triaging mechanism unless there's one that's been implemented within the call center for a particular reason, like you're calling a particular hotline or a company knows they have a problem with their products, so they set a particular queue within the call center to direct people who say, press one if you have a problem with your printer and it's like, and then direct you into that feels a lot like some sort of triage system.
Dave:It's just not an intelligent system necessarily.
Peter:It's a different. It's a little different from, but similar to the it. With us within it SM you would have service levels and a structure within the service levels that would. That is a tree, I said, but it's kind of built into the service management system. It's like it's all predefined ahead of time, whereas I think in the call center perhaps it's set up as needed and there where, if you, they want to direct things in a particular way and they're looking at the overall flow and governance, governance through the that Whereas the, the ITSM, is just a particular example of that very structured version with service levels and feeds into problem and change.
Dave:So so I know you spend a lot of time working in this space, so talk a little bit about that incident problem, problem change model, if you like that. What? What is the assumptions or the, the specializations, that particular context you're looking at, where an incident problem changes the right sort of framework or model to think of, or the structure, whereas there are lots of spaces where it would probably be overkill. I guess.
Peter:So the, so the incident problem change IPC is to call it and often defined or taken the definitions are from sort of itil as a model, the information technology infrastructure library, which was a UK government initiative from many decades ago and has been since adopted as kind of the way to do ITSM Though it isn't the only framework, but it is kind of the one that's probably best known and the, so the very, very sort of basic level incident. The purpose of incident response is how do I get the service back online as quickly as possible? My job here is to to band aid, triage, put, put some kind of solution and get the system up and running again. Now, if I have lots of incident calls coming in or there's an underlying, or we identify some sort of underlying problem that we've just basically bandated over to get the system back online, it will feed into problem. Now, problems will either be things that are impacting a large number of users or are ones which are, which are on, where we've got something that we need to dig into deeper.
Peter:So it's going to take a little bit longer than the incident response time frames and for so problem management then takes over where we start to, where we'll assign a team potentially to look into and dig into, like what was it that was causing the, the underlying incident, or selection of incidents, or whatever. The underlying problem might be problem and then, in turn, problems may generate changes to the system. So and change management provides a mechanism whereby we can ensure that those changes are implemented in a safe manner within the target systems. Often and this is the interesting part, and it'll be a bit of a digression to talk about how this intersects with something like DevOps, where we're doing this more continual basis, but but the same principles, regardless of the speed at which you are doing it. To play, it's a good model for thinking about what does it take for me to keep my services up and maintain them in good health? So that's, that's the way to think of that service management piece, regardless of what the sort of delivery mechanism that you're using is.
Dave:Well, and what I find sort of the reason that I thought this conversation was an interesting one is my experience from an agile context is agile. It doesn't happen in a vacuum, of course, and is often very focused on a much looser definition of service if you're looking at product or service delivery. But, just as an example, when I my very first agile transformation that I was ever involved in was a combined agile and itil transformation, agile and itil are super aligned and work very, very well with one other and, in fact, if you kind of layer in.
Dave:DevOps to speed up elements of that. It becomes a very natural pairing. So a lot of what we're talking about comes into that view of if I come from that agile context, my understanding of service is often different to if I come at it from an itil operations DevOps mindset. And a lot of it has to do with that the the tighter or the more defined structure is a lot to do with the context in which things that go wrong are a higher risk or higher cost when they go.
Peter:Yeah, and so this is where you run into often, where those types of initiatives sort of run into friction with the service space comes both in request management, where the team is trying to deliver a slowdown by having to put a ticket and ticket disappears into black hole and you never hear back for a variety of different reasons as a whole bunch of things around that side of it, and the other one is on the like cab, as a governance mechanism for change, which is also something that isn't that.
Peter:Once you have a sufficient understanding of risk, you then the then it doesn't necessarily need to go through cab unless there is the purposeful need to look at something that is going to be massively disruptive to your systems, like there's some things require you to have a sufficient management of the change and understanding of it. But and so typically what I've seen over time is that if, if cab doesn't dissolve entirely because you're in a largely cloud based scenario cab is largely reserved for management of infrastructure size changes where there's a need to get the people together and you're impacting potentially a lot of people at once, the risk is very, very high of having something quite disruptive as a consequence of the change you're making.
Dave:Even as you're describing this, peter. This exactly draws out because when I'm listening to you start talking about change, I'm coming at it from the scope creep type of mindset, which is totally different to the way you're coming at it. So, as I'm thinking, I'm having to be curious and listen and understand that actually my immediate change means x is completely different to what you're describing as change in this part of the conversation.
Peter:Yeah, it's interesting, right, because and again this ties back to originally terminology soup. Right, it's a different meanings for words.
Dave:Well, and I think I mean it really helps us draw out the fact that, well, how there are lots of frameworks out there and we're bumping into various ones and sometimes we get into that view of my framework is better than your framework, or what you need is this, and what you need is x or y or whatever it is, and I certainly I know we've talked about this before we need to be a lot more curious to understand the context and the scenarios and when to use which ones. And I think that brings us into some interesting conversations, and I know in the last six months or 12 months, I've personally had a lot more conversations where I'm starting to talk about ITSM and realizing that the change, the conversation or transformation that is being asked for is not an agile transformation but is around an ITSM type of transformation, and recognizing that is a different thing.
Peter:Yeah, and that ITSM space very often ties into the DevOps space as well, of course, because that's when we there's a very close line between to your point I mean there are. There is a very limited number of scenarios where I actually recommend implementing a CAD if you don't have one very, very limited, but typically it's when the house is burning down and your systems are not stable at all and you need to somehow get control of it. Then one of the first like implementing CAD is stop change.
Dave:Stop changing systems, but that's it's putting a constraint on the change. So it's a way of getting control in any sort of complex environment, is you start with the right constraints.
Peter:Yes, exactly, exactly, and but you, you always want to be aiming to how do I get that out of here as quickly as possible again? So, because it's not. It's a constraint that can severely limit your ability to deliver once you have your systems under control.
Dave:Now I have a sneaky suspicion. We're wandering and we're beginning to tap on doors that maybe we don't have time to open into and dial into. How do you bring us home, how do you bring this conversation around to a couple of key points to take a take on?
Peter:Well, I think a couple of really key ones is understanding how much of the frame we need. Are you applying it right to this space that you're in? Is it applicable to what the customer needs, or is it a case of like going in and blindly applying a full incident response system for like, triaging emergencies, when basically what they need is the ability to have a queue of tickets they can work their way through? These are different scales of problems and by applying a full blown service management framework is just going to be too much for them to manage and it's it isn't addressing the right problem. So that's definitely a key one. Another which I think we touched on several times in this conversation is the overlap between all of these different areas, the intersections between them, and add something we've talked about in the last few podcasts around how, the change into thinking about what are the underlying things that we need to see happen in order to help the overall system improve, versus focusing on the particular framework or buzzword or way of doing things. What did?
Dave:you add. I just, I just want to add that that sort of overlap that you described, I feel, is is what's so rewarding about the work that we're doing and the opportunities, its problems, the challenges that we face when we're working with different sort of organizations and where they're at, and I'm.
Dave:I actually think it's it's long overdue that people start recognizing that the topics that we've talked about whether it's digital transformation or agile or devox change, organizational change aren't single things that need to be pursued, but it's a it's a part of a much broader understanding of that landscape. And I think the more curious we are, the more we recognize that one framework doesn't cut it, that you need a lot of different approaches and then an understanding of the situational context. I think the more interesting the work is than better solutions that we reach.
Peter:Yeah, holistic thinking there we go. Yeah, awesome. Well, thank you very much. As always, dave, always enjoy these conversations and look forward to next time.
Dave:Yeah, it's a blast. Until next time. Thanks Peter.
Peter:You've been listening to, definitely maybe agile, the podcast where your hosts, peter Maddison and David Sharrock, focus on the art and science of digital agile and devox at scale.