all right okay so let's get rolling so we're going to talk today about the agile process owner and I love this quote we live in a moment of history where change is so speeded up that we begin to see the present only when it is already disappearing I don't know about you all but I'm not sure how we got to November I just you know so just in life things are moving quickly these days when you think about the IT industry and with dramatic changes have occurred as a result of you know the Internet cloud based computing mobile community competing dramatically things change all the time it's kind of no wonder we all on any given day I'm quite sure you know what's going on around us here's one of the things that's really fascinating about this particular quote rdy who was a psychiatrist actually died 25 years ago so if we think we're feeling overwhelmed with pace of change today or I guess I'd rather i should say if he felt overwhelmed with the pace of change in his day and age think how we feel today so when we talk about this notion of agility and I'm going to first talk about the notion of an agile enterprise every enterprise today whether you're in the in the private sector whether you're in the public sector and striving to achieve the the mission of your agency we all have to be we all have to move faster today we have to be flexible we have to be willing and and ready and able to respond when priorities change when we face challenges and that requires good policies and good processes you know if you look at organizations that are reaping the benefits of practices like DevOps practices and agile software development practices those organizations aren't getting there because they are throwing out all of their processes and and there's sometimes that misperception that you know if we want to move quickly we can't have processes that's not the case having said that we can't move quickly if we have over really rigorous processes if we have processes that are bloated that our bureaucratic we've got to make sure that our processes are designed to provide just enough control in order to support the aims of your organization and to enable you to move as quickly as as as the business requirements demand now all of us are involved in processes in some way shape or form many of you are involved in multiple processes over the course of your day you change hats constantly you may be working on incidents one minute handling changes another minute deming actually said if you can't describe what you're doing this process you don't know what you're doing you're just kind of floundering around so why are why is the notion of process is so particularly challenged challenging for IT organizations we all understand I think that concept of agility and that need to focus on speed and change but when it comes to IT who cares if you're moving quickly if you're you know Rican chaos in the production environment every time you make changes with IT organizations we also have to focus on stability you know the upside of an IT organization is held accountable for the availability for the security for the capacity for the continuity of the production environment so achieving that balance and and and also achieving good quality services services that are truly a value to the business is really challenging but at the end of the day that's what the business once they want all of the above they want speed they want stability and they want quality so agile thinking and agile practices are really helping us to get there we're seeing phenomenal improvements in IT organizations especially those that are adopting for example DevOps practices so who is responsible or who is accountable for ensuring that these processes work effectively well Denny actually said hold everybody accountable that's ridiculous and and sometimes we actually say things like when everybody is in charge nobody is in charge right at the end of the day it is a process owner that is accountable for the performance of a process and for making sure that process delivers value now anybody who's been involved in creating racing matrixes which map roles and responsibilities to process activities that a stands for accountable so a racing matrix is responsible accountable consulted and informed who plays what role within a process those of you familiar with racing matrices know there's only ever one accountable so the process owner when it comes to process performance is where the buck stops so to speak the process owner has a lot of responsibilities and one of the things that's really important to understand is that those responsibilities may change over time you may find that initially the process owner is very very hands-on in all of these different areas but as the process matures as we maybe have a process manager who's really capable of taking over the day-to-day responsibilities in terms of the process the process owner may move to more to process sponsorship process sponsorship is really about setting the policies setting the scope of the process what falls within the boundaries of that process and really most importantly making sure that the strategies associated with that process are in line with the overall strategies of the organization and here's where we have to think about things like the risk profile of the organization perhaps the industry that the organization is in and how what the organization has to be doing in order to compete in that industry to are we in a position where we really gotta speed up dramatically time to market for example has become a significant focus in order for the organization to be competitive so you know all of those factors like you know risk and cost and quality all contribute to the strategy that we put forth for our process and how we want that process to perform part gives process sponsorship is also just representing the needs of all of the process stakeholders and and really no matter where they are in the organization and increasingly today even if they are outside of our organization moving many processes today in the in the in the world of cloud computing span over into other organizations process resourcing involves of course making sure that we have all of those stakeholder groups represented but a lot of what a process owner does is get out there and work with line managers to make sure that the line managers are that have their teams represented when we're undertaking process design and improvement initiatives that process managers or line managers are allocating significant resources to execute the process itself and also a process owner works with the line managers to make sure their people get the training that they need not only in terms of the process itself but any technologies that may be associated with that particular process process design and improvement is really overseeing the initial design of the process and making sure that again all stakeholders are represented in those design activities and then on for the for the long run making sure that needed improvements are being made process management is really about setting objectives setting performance measures overseeing those performance measures here's where a process manager is really important a process manager is typically overseeing the day-to-day activities so process you know owner isn't necessarily running reports and analyzing those reports rather he or she is looking at and kind of analyzing a dashboard or higher level sets of day that enable them to understand how the process is performing and then certainly awareness in terms of communicating how the process is in performing and also serving as a single point of contact relative to that process so process owner has a very very wide range of responsibilities again initially a process owner needs to be very very hands-on and interacting with the process improvement teams in order to make sure that all of these activities are occurring in time here she may delegate some of these activities to a process manager and and really focus on that process sponsorship that higher-level role of making sure that the process is staying aligned with organizational strategies one of the things that is important when we talk about processes is really understanding and ensuring that that the process is is a working seamlessly end-to-end across functional areas I think that's one of the things that really distinguishes a process is that it may span many many different functional areas within an organization and we want to make sure that those processes aren't a burden to those different different functional areas and that the process is executing very very seamlessly across those those departments so a process owner really has to have a really broad understanding of what's going on in the organization not only and it's very common for a process owner to be a manager or director in a particular department or division within the organization but really to be effective he or she has to understand the higher level organizational strategies and goals so whether it relates to you know that process owners division or department they still have to understand because they have to interact with other managers they have to interact with other directors and not be making process related decisions that are going to be potentially detrimental to other people within the organization they have to understand the process itself and really be a subject matter expert in that particular process was very exciting to me that a lot of you said that your process owners are certified in their particular process they really should be they should be very much aware of best practices tools of other practices like agile and lean practices that that they can use they have to have this really big robust tool kit that they can use in order to ensure the process is efficient as effective as possible I think a really important Olympus test for a process owner is also how well they understand related and interfacing processes a process will never be as effective as it possibly can or as mature as it possibly can and until it's interfacing effectively with other processes so a good process owner has good relationships with other process owners and works together with other process owners to make sure that all of the processes are performing as well as they can be and really understanding that sometimes when it comes to process improvement it may not even be about you know the process owners process itself it may be about how that process interfaces with some other process whether in terms of how it takes input from another process or how it provides output or information to another process so again big broad range of knowledge and and there also has to be a level of authority for a process owner to be affected up to be effective they've got to have the authority to get out and enlist resources and to actually take action in order to make improvements and enable the process to work as effectively as it possibly can and and this has to be an ongoing process this is not in any way shape or form and I think this is where a lot of times we make mistakes with processes we implement and I'm using little air grooves here we implement a process and then we think that process is done well hopefully DevOps has taught everybody that technological changes can occur and new practices can emerge that really require us to completely rethink and perhaps re-engineer our processes so that they're not serving as a bottleneck or constraint within the IT value stream and if you look at the skills and attributes their process owner needs to have I almost kind of wanted to add to the slide like able to leap tall buildings right because you know there's a lot of first of all soft skills that are needed in order to be an effective process owner there's a lot of communication collaboration type activities that a process owner needs to undertake but they also really do need to be very process and outcome oriented sometimes you would think they need to be a little bit left brain they need to be a little bit of a logical thinker but really it's quite the opposite that notion of being logical is important but today process owners have to be very creative they have to constantly be thinking out of the box so to speak in terms of how we can in fact meet the needs of our organization you know you may have regulatory controls you have to comply with you have higher level organizational policies you have to comply with so process owner has to really have you know the ability to kind of think creatively in order to understand how best to stay within you know that governance structure to operate within that governance structure but also have a free-flowing and an efficient process and some of that also may just involve getting out there and negotiating changes to some of those higher-level policies they have to be really passionate they have to be really excited about how we can improve this process and how we can make sure that that process is delivering value so really how do processes deliver value well first of all they deliver value by enabling the organization to work together seamlessly from end to end so here's where the notion of a office working across functional areas within the organization an able different areas within the organization to work together is is really invaluable if you look at the agile manifesto it says we value processes and tools / we value people in interaction excuse me it were processes and tools and that doesn't mean the processes and tools aren't important what it means is that enabling people to collaborate is what's really important enabling people to work effectively together so a good process enables that from nth and across the entire value stream a good process focuses on outcomes as opposed to outputs I did a presentation recently and I ask the audience what an outcome of the incident management process was and everybody kind of very quickly said restore service as quickly as possible and one of the things I said to them is well let's go beyond that let's go beyond just restoring service and talk about what that really provides in terms of a business benefit so an outcome for example of the incident management process is to give productivity back to the business to enable people to get back to their jobs and do what they need to be doing in the context of of their part of the business so process owner has to think beyond right and really understand the end result that's really desired and and how that result benefits the business effective integration with other processes I've talked about that before adapting to feedback and changing needs if you've ever been in a situation where you've complained to a company about their process perhaps you had difficulty getting ahold of them or you you know you found that their policies were really difficult to understand or weren't really satisfying your needs you know you either got a sense that they cared about your feedback and thank you for that feedback and and we're willing to make changes based on that feedback or and I actually heard this from a service provider once the person told me that I was like the 20th person that had complained about that day it was kind of like get in line with everybody else so in this day age we have to listen to our customers and really let's all understand that our customers can be out there talking on twitter right and and kind of telling the world about how we're doing so we have to get very very good a processor has to be very good at listening to what customers are saying and then also making sure that we're doing things in a way that's meaningful to our customers you know when we think about it in the context of processes today people want processes that are pretty lightweight people want to be able to have processes that are technology enabled kind of the good old days of a big standard operating procedures manual is is fairly obsolete we want to hop onto our mobile phone we want to be able to click a couple of buttons and we want to be able to you know trigger a process or get information about a process so we really do have to understand right what's really important to our customers in order to ensure that our processes are delivering value now when we talk about a process owner I want to spend a minute and talk about the fact that there are other related roles certainly I've talked about the process manager a little bit within your organization's you may have in place value stream owners and typically a value stream spans over multiple processes there are process architects and process design engineers so there are a lot of different roles associated with process design and improvement but specific to the role of a process owner very often we see this notion of a service management office and the idea of a service management office in the context of Isis or service management is that we're coordinating all of the processes and all of the functions throughout their lifecycle so typically process owners report and very often it's a dotted line report into a service management office and that service management office works together to ensure that all of the processes are aligned with the organization strategies and goals one of the things I've introduced before and many other presentations I'm sure you can find presentations out there is the idea of doing a prioritization matrix to really look at what are the challenges that we're facing what are the perhaps pain points that our customers are experiencing and then let's wait what processes would enable us to respond to that challenge or alleviate that pain point for our customers that implies all of the process owners working together and thinking about the greater good in terms of the overall enterprise and in terms of their customers and not just kind of putting their blinders on at any given day and thinking about only their particular process you know you know it's really important to understand that process owners on any given day can make a change that could negatively affect other processes because we're no longer producing the information we need to or we're not producing it in the time frame week we need to so there has to be strong collaboration and cooperation between all of the process owners within an organization and typically that happens within a service management office now I'm not suggesting that you have to stand up a separate Department and all the process owners report into that service management office it doesn't have to be that formal it actually can simply be a community of practice it can be a working group within your organization whatever you call right that activity that enables the teaming of people in order to ensure that whatever they're doing supports the organization's need so please don't turn the service management office into a them versus us type of situation where the service management office kind of sits up on high and dictates down to everybody else would they they need to be doing really an effective process earner very much has the finger on the pulse of what's going on in the organization and and and it is again communicating and collaborating on an ongoing basis with other process owners so that everybody's thinking about you know how can we do the right thing how can we make it easy for people to follow these processes now when we think about agile planning very off and we have this kind of higher level vision for where we want to go in IT service management we talk about the overall IT service management strategy and a lot of times that comes with a roadmap and perhaps a series of changes in the form of releases that we want to undertake in order to move forward on that road map and that's really we're this service management officer this working group of people can come into play to set that higher-level vision and then provide that insight to process improvement teams who are actually then working on individual processes on a day-to-day basis to you know either design those processes or improve those processes as needed and notice that our process owners are involved in all of those activities so very very important ongoing engagement now in the context of agile the process owner plays a very very important role you know a lot of you mentioned that you are using agile processes agile practices in the context of design and improvement seven percent of you said majority of your projects you're using agile design improvement practices 15% of you said that some of your projects and forty-one percent of you said you're just getting started using agile but agile lends itself to any type of project and it lends itself in particular to a process design and improvement project now I'm not going to do you know a scrum 101 session here there's plenty of sessions available that talk to you about scrum but I do want to talk about scrum in the context of an agile process owner in scrum there are three primary roles a product owner a scrum master and the team itself in the context of software development it would be the software development team in the context of agile service management and agile service management's really about adapting scrum practices to process design and improvement projects we have similar roles we have the operational equivalent to a scrum product owner and that is our agile process owner there is a role called the agile service manager who's the operational equivalent of a scrum master and then we have a team as well and that team in this case is a process improvement team the team of stakeholders from across all the different functional areas in the business who are engaged in designing and improving that process in scrum the product owner and I'm going to from this point for we refer to the algebra center is responsible for maintaining and managing the requirements of the process and and maintaining those in something called a process backlog if we were talking about software development we would talk about a product backlog so our process backlog has our requirements for all of our stakeholders and the iterative approach we use to design and improve your process says let's understand what's most important in terms of requirements let's pull out those highest level items those most important items first work on those typically within a time boxed period referred to as a sprint sprint sir typically two to four weeks and produce as a result of that sprint what's called a potentially releasable process increment now notice the word potentially there we may not release this process increment but if it makes sense for example maybe if we just need to make a small change to a process in order to improve its performance we may go ahead and release that process increment what agile service management does and what using a methodology like scrum does in the context of process designer improvement is enable you to chunk up your process so rather than doing what we have Oracle II do with processes which is we go through this long exercise to make sure we understand everybody's requirements then we make sure that we design the end-to-end process in such a way that it's going to satisfy everybody's requirements and then we put out typically a massive process definition document and get everybody's approval on that document and then we try to implement that whole entire process in all its you know glory all at one time can be really overwhelming for organizations this is where organizations really start to feel a little bit of change fatigue because especially if we've gotten multiple process initiatives going on at the same time so agile service management says let's chop that up let's let's start looking at that adopting the notion in in software development there's this notion of Minimum Viable Product what's the most pared down version of a product that we can produce let's think about that same concept in the in the context of process design improvement let's look at what are the minimum critical activities that I need to have in place and then over time expand upon that process so let me give you a very simple example of how that might work you may say okay let's first of all look at a very basic change management process let's look at standard changes these are pretty low risk changes perhaps they can be pre-approved we have some pretty minimum requirements associated with them let's make sure we can answer questions like you know what changed who made the change when did it get change right let's have a really simple record of the fact that that something has changed most folks can kind of understand those minimum critical activities and see the value in those activities the next iteration of the change may start to look at okay what if we have a more complex change what if we have a change that's going to affect more stakeholders what if we have a change the tire risk here's where we may start talking about for example engaging getting line manager approval or perhaps even having a change advisory board that needs to approve that change but rather than having a process that has to Rock 70 and dot every I right out of the gate let's think about this notion of minimum critical activities and then grow the process over time we almost never back up right we implement maybe these bloated processes or overly bureaucratic processes and we might almost never take away we almost never thin the process down it's just kind of the nature of the way we operate in IT organizations so let's not start there right let's start with those minimum critical activities so the process owner the agile process owner is responsible for the process backlog and ensuring that process backlog is visible and it's available to people and that it's it's being used continuously to capture the requirement and to order or prioritize the requirements associated with a particular process now some of you may actually have something called the CSI register and if you do that's okay you have the same concept and and actually a process backlog may actually be a subset of your CSI register typically CSI registers in the i tol context have all of the changes associated with all of your processes and all of your IT service management tools so this we're talking here about a subset in the context of a particular process the aim of a process backlog is really not to try to define all of the requirements in great detail upfront same as same concept does with agile software development in agile software development they don't write these very comprehensive requirements definition documents they might capture very very broad requirements which are often referred to as epic like to some big broad topic area they may use and we can use and processes on an improvement as well user stories user stories say as a I want so that i can write so it has kind of a who what why concept in terms of collecting those vironment and Athene simply put a collection of user stories so this these same practices that are very often being used by agile software development teams in order to capture requirements for a product can be used to capture requirements for a process and then to also you know provide an order or a priority in terms of how this requires need to be satisfied so remember those minimum critical activities those those highest priority activities are what you're going to be working on in your current sprint or perhaps your next couple of Sprint's then you may have other requirements that you're going to address as part of your current release and remember we talked about the notion of agile planning in terms of having that roadmap and within that roadmap defining what those releases are and then we may have some things that are on the list but they're just big items that we know about and we don't want to get them we don't want them to be forgotten about but they're low priority so we really don't have to spend any time and effort right now really defining in detail what these big items are all about let's just put them on the list even if only in the simple user story forum as a i want to so that I right it can be on a post-it note let's capture that simple requirements who it doesn't get lost or forgotten but let's not spend any more time on it until we get to the point where we're starting to think about pulling that requirement into a current sprint and then we're going to start having adding greater detail having those conversations to make sure the requirement is understood and really figuring out how we're going to actually satisfy that particular requirement now for a lot of you you may actually have multiple backlogs that you're dealing with so there might be a backlog for your IT service management program overall this may be a product of your service management office in terms of setting right that high level roadmap and that high-level strategy for your processes I talked about your process backlog and then you may also have a product backlog for whatever the product is that you're using in order to support your processes so those of you they're using you know service now or you know service center all of the different IT service management products that are available today that underpin your processes it's very likely that you have a product backlog and even if you don't call it that somewhere along the line you've got a list of stuff people want to have done right a list of changes that people want done relative to that product so give some thought to how you can bring these concepts together so that again our process owners are always kind of collaborating and working together and thinking about the greater good in terms of how we're ordering our requirements and satisfying those requirements and this is difficult sometimes you know every process owner once their process to be the center of attention and to be the process that gets focused on first but remember every process has a relationship with every other process so there may be changes that need to be made to some interfacing process that will really benefit you a lot and it may be to your advantage as a process owner to let those changes we made let those changes go to the front of the list so you can then reap the benefits of those changes somewhere down the street downstream so we want to make sure that we're taking an iterative approach and and that's what what's prints are really all about Sprint's really say let's chunk up my process design activities and and you know more and more I'm hearing organization say our leadership really wants us to show progress they don't want us to go away for six months and then come up come out with this what we think is perfect process implement that perfect process and then start you know in all honesty hearing everybody complain about it they want to see progress so it really is to everyone advantage in this day and age to figure out ways to chunk up their work and it really makes sense in the context of process design and improvement because it enables us to have a little bit of a cadence to have a little bit of a rhythm in terms of how we undertake those activities we can also really just be very open and honest about what we're doing we can demonstrate to the stakeholders of our process to the leadership within our organization what we've been doing we can solicit feedback on a product process increment instead of again waiting until we have that big comprehensive document that sometimes hard for people to wade through and here's the really good news we can very very quickly adapt based on that feedback so so rather than waiting to have the process actually in execution to get that feedback we can get that feedback based on a demonstration may be in the form of a process flow or may be in the form of perhaps if our process is tool enable the demonstration of the tool that supports that that process get that feedback and then adapt before you actually start to try to shift the culture and change the behaviors of everybody who is a stakeholder in that particular process you also by chunking up your process design activities provide just enough detail to start to trigger development activities you know I talked about the notion of you know service center or service now whatever is the product you're using a lot of times the folks were involved in in configuring those tools and hopefully you're not customizing those tools anymore but if you are customizing those tools a lot of times they kind of have to wait while all the process design work is done and then they can start doing the work on the tool and that's not changing you know we still have the no rules before the tools philosophy of life when it comes to IT service management I always say if you're doing things wrong and you automate them you'll do them on faster that ocean hasn't changed at all but we do have the ability with Sprint's to take this very iterative approach so we may for example look at n activity within a process we can use our user stories to represent the requirements of all of the people who are stakeholder in that particular activity we can work through those user stories make sure that we design that activity and and and the procedures associated with that activity on paper that's the process part right we can then trigger that tool related configurations that support that particular part of the process so now if so I need to see that rhythm now we're starting to get that momentum that enables us to take this very iterative and incremental approach to designing and improving the progress process we're showing progress all along the way we're enabling collaboration between the people who are the process stakeholders and the people who are the technology stakeholders in that particular process and again we're able to show progress much much more quickly we're able to reap the benefits of agile development methodologies so Deming said the aim of leadership should be to improve the performance of man and machine I'm going to cut him a break since he was born in the 1900s I actually adapted his his quote to say we want to improve the performance of women and machine but this notion of having technology enabled processes has existed for a long time and so we really do have to make sure that we have that integration between process and tool one of the other mistakes we make sometimes with process design and improvement is we we create this great process on paper and then and then we never quit getting around to configuring or making sure that the tool does fully support the process itself I find sometimes where knology actually gets in the way of the process performing as smoothly as it needs to be now a lot of that's changed because today many of the tools were actually designed to work with frameworks like the IT infrastructure library many of the tools are configured configurable so the days of having to customize and kind of develop or program tools has really gone out of fashion you know it's much much easier to make simple configuration changes and and and rule changes that enable your tool to support the process and that's really at the end what we want to do like Deming said we really want to enable people to be proud of the work they do to work as efficiently as they possibly can to you know increase their output and not get in the way of them doing good work so the process increment is really the outcome of that sprint and we want to think about again that word potentially releasable process increment you have to give some thought to is this increment in a usable condition can it it is is it something that we could execute as a standalone item remember that we may release a process increment but we may not there's lots of things that we have to consider but one of the things that you can be looking at is the relationship between not only the improvement activities that are occurring within a process but we can also think about interfacing processes as well so we have this opportunity to kind of very incremental e look at improving our process getting feedback on how that process is performing before we move on to make the next round of team in just this is plan do check act in its absolute purest form is it not if you think about from it from the standpoint of the Deming cycle so let's undertake the the next increment of provement you know get that feedback as well and you also have the ability to again look at interfacing processes and make sure and start to kind of build the relationship to see all right if if we could have a better problem management process by better integrating it with our incident management process right can we in fact do that right are there changes that we need to make to incident management as an example that would enable problem management to move lon to the next level of maturity perhaps we have a good you some particular activity within problem management up until now because we're not getting the data that we need from incident management as an example so you really again we can start have this bigger picture perspective and understanding of how changes to one process integrate with and potentially affect other processes so what are some of the things we need to think about in terms of whether or not we would release a process increment well of course always is your organization really ready and receptive to this particular change a lot of times we see where there's something else going on in the business perhaps you know it's a particular time of year or there are some other big initiatives going on and everybody's you know absorbed everybody is consumed by some other higher priority projects and that's never a good time to introduce process related changes could we potentially confuse process practitioners because maybe this increment can stand alone maybe we have to make sure that we have multiple increments before the changes will really start to make sense to the practitioners associated with that process or people will start to think we'll hold on you know I understand that this is going to get us there but when are we going to get there right a lot of times people want to want to know that the thing that's really causing them pain is in fact being addressed and sometimes making incremental changes just makes it feel like we're not listening and hearing what they are saying is really the pain point making sure our dependencies are done you know perhaps changes that need to be made to interfacing processes could we cause change fatigue change fatigue is kind of that like collective sigh that people feel when we make changes its like the rolling of the eyes like oh gosh here we go again sometimes organizations call it framework fatigue we're trying to make so many changes that people have lost sight of why we're doing this and and people will start to say things like wait hold on you know why why are we doing this does that mean what we've done up until now is it hasn't been worthwhile if you look at the IT organizations that are successful today they're leveraging agile practices and leading practices and IT service management practices and DevOps practices so everything that you've done up until now has enabled you have one step after another on your continuous improvement journey but you haven't messaged all of those changes properly otherwise people will start to feel that that change fatigue and it's a kind of big bottom line the increment has to really deliver value Deming says we always have to focus on the why we let's never forget about what our overall organizational strategies are with the overall goals of the organization what's happening in our industry what we need to be doing to be competitive how we can better support the mission of our agency let's not forget why we're doing all this stuff here's where we always want to make sure there's process owners that we're focusing on the outcomes of our particular process so realizing the value of prompts of a process really requires a couple of things making sure the process is aligned with business needs and in this day and age every process out there needs to be looked at to see how it can be made leaner how we can eliminate waste how we can eliminate wait time how we can eliminate unnecessary approvals that we may have in in our process how can we make sure that we have just enough control in place within our process to really support and meet the needs of our business we also have to make sure that the process is sustainable so we can't have a process that is so bloated and so bureaucratic that it's getting in the way of people doing their real jobs we want to make sure that processes make it really really easy for people to do the right thing to do whatever it is that that process aims to do and selecting the right process owners with the right level of authority and influence is really critical to making sure if that value is fully realize the processor in a role is an invaluable role especially in this day and age where every organization is is being challenged to look at each and every process within their organization and figure out ways to improve the value that's being delivered so Deming once said experience by itself teaches nothing and I love this quote in you know he goes on to say you know experience doesn't give you any context it doesn't help you do any you know ask questions or make comparisons how how are we performing for example relative to best practices so we've into all of our lives must come a little theory and without that theory there is no learning so in that spirit let's talk a little bit about the types of educational opportunities that we have available and then we're going to get to what I always consider the most fun part of making a presentation and that is answering your questions so Eric are you out there and Eric you've got yourself muted hahaha I just unmuted yourself I they Donna good how are you oh I'm fantastic thanks so much for doing this webinar here with us today um thank you I was really it was really a fantastic webinar and uh I'd like to say what kind of hit the nail on the head for me were the real world considerations to release a process increment I think so many times we lose sight of how in our pursuit of why let's change this because it's gonna give us a boost in speed mobile control etc but wait now our protecting press sorry practitioners have no clue what's going on ultimately that's going to slow us down I just absolutely love how you like um and so I've been really excited for this webinar because it's it's kind of the banner for our new class certified agile process owner we kind of did a test class a little while ago and people were raving about it saying that they needed their whole team's to be certified in it and I I wanted I've been waiting for this webinar to kind of push it out to the masses and say that we've gotten a class coming up on January nineteenth um it's it's it's going to be huge it's already filling up and I wanted to give you guys an opportunity to join us and just because of how awesome Donna is it's inspired me to give everybody on this webinar a twenty percent off coupon for capo so what you're going to do is um there's going to be a link you can go on to itsm academy com and you go into the search and you're going to search for capo and go ahead and just pick the date there on January nineteenth I know who you are so if you register I'll be sure to get you that twenty percent off coupon and we'll have a code emailed out to as well as just kind of a reminder um and Donna again I can't thank you enough for joining us today and giving us this knowledge and um just just making the world a better place with it I'm happy to do that so who's who's been collecting questions we have questions thank you Eric I'm no problem actually I have the one of the questions here Karen I didn't know if you wanted to say the questions but I'll I got one here from Greg arnholt and it says can you equate the scrum master and the product owner and the team to the process owner the sm 0 and the team how does that map well I wouldn't yes I would equate the product owner and the process owner so we view the agile process owner as the operational equivalent to the product dinner when you when you talk about pure scrum they you know they manage the requirements they in the process back or the product backlog right all of the same kind of conceptually they have the relationship with the customers conceptually the same types of activities between the process and the product dinner um the and let me use I'm just going to use this slide just because it's kind of here in handy the we relate the lips wait hold on um we relate the scrum master role sorry come on play nice with me here we go there we go we relate the scrum master role to this certified agile service manager rule whenever organ is our one of our other offerings is called chasm certified agile service manager so that looks at and adapts the scrum master role too agile service management and part of what a scrum master does for anybody who's not familiar with the role they really make sure everyone understands the scrum methodology that the team understands how to work in terms of working within Sprint's how to do things like sprint planning how to decide you know and establish your definition of done for an increment the sm 0 in the context of i would say pure scrum doesn't really have a role that the concept of an sm 0 is really an IT service management concept but i have to say and scrum you do something here sometimes use the term scrum of scrums and that's where kind of scrum masters tend to come together and kind of work together if we've got multiple Sprint's going on that have multiple scrum masters associated with them so that so conceptually the idea there in scrum but the sm 0 is is really something that that's more in the context of IT Service Management and process design an improvement in particular and then both have the concept of teams right so both have three roles the third role being the team in a scrum true pure scrum environment it would be a software development team and in the context of an agile service management it would be a process improvement team so hopefully that that makes sense yeah Thank You Donna that was a that was a very large question and thank you Greg for putting that in I don't have any other questions at the moment but I do have several more announcements for you and so while I'm doing that if you would chat in any other questions that you have for Donna because she is so knowledgeable about this this topic and very passionate about it so she's ready for you but those of you that do need to drop off I just like to remind you that due to the holidays they will not be a December webinar we at itm academy would like to wish you all of the very happiest of holidays and we'll see you in January and look forward to having you join us then and we'll continue to bring you practitioner presentations discussing agile and IT service management implementation experiences and challenges people want to hear and learn from the practitioner experiences if you would like to share your implementation experience or your implementation challenges with us and with our audience please let us know we'd be happy to work with you and make that happen for you at one of our monthly replications and I don't have any other questions at this time Donna I do that that weight and I I do they just came in come here is a question how many times do you see that how many times did died so I have to I have to like just clue everybody in I did a presentation recently and a couple of my co-workers teased me that they were going to make a drinking game out of how many times I said deming in the course of the presentation so I actually decided with this presentation to have a little fun with them in that respect Soho my coworkers are still standing out there but I you're just just trying house I do love damning and I do i do quote Deming in every presentation but just wanted to have a little fun with this one that's funny and they're great Lisa um I have a question from Marie and she's saying in the agile service management slide what does the 24 hours represent so in in pure scrum and um if you if you're kind of not familiar with scrum I have to tell you just like Google's like scrum in you know in 10 minutes or something there are a lot of good presentations out there that kind of very quickly give you a review of scrum but typically with scrum there is you know one of the kind of premises of agile development is time boxing things so we hear this notion of a sprint and Sprint's are typically time boxed 2224 week increments um it will in a lot and in a lot of organizations you know two-week increments work really really well think about it in for four weeks in a month it that's that's kind of a long time to potentially be going in the wrong direction so but that that's a conversation for another day but this notion of 24 hours in scrum there is this concept of the daily stand-up and in the daily stand-up the team comes together very quickly no more than 15 minutes and said and answers three questions what did i do yesterday what am I going to do today and are there any impediments on my way it's it's a fundamental part of the transparency that it that that enables organizations to move quickly making sure and I'm sure some of you have been in projects where you know somebody's been struggling but they haven't told anybody about it until it was too late so we really want to make sure that through those daily stand-ups everyone is working on whatever they're supposed to be working on as a member of your process improvement team so that's that's where the 24 hours comes into play that every 24 hours you do is stand up and you account for what progress you're making in the context of the sprint and all of the process improvement team members participate in that daily standup great Thank You Donna um she also had to have the question so I just wanted to kind of say it up to the tippy group just in case anybody missed it at the beginning yes you will you all do have a copy of this presentation available to you it's available to you either in the chat there's a link in there for it or you can go directly to our website at WWE is m academy com forward slash webinar hyphen archives and you can download it there