Demystifying Agile, SCRUM , and IT Service Management , Tesinas de Gestión de Tecnología de la Información

¡Descarga Demystifying Agile, SCRUM , and IT Service Management y más Tesinas en PDF de Gestión de Tecnología de la Información solo en Docsity! \\ Dieta seins Agile, Scrum, and IT Service Management m& Erika Flora CSM, CSPO, PMP, nn oleae Demystifying Agile, Scrum, and IT Service Management Erika Flora, CSM, CSPO, PMP, ITIL Expert Table of Contents Introduction.............. 00sec cece eee ee ee eee Changing How Work is Done . The Agile Framework...... The ITSM Framework . Agile and Scrum........... Products versus Services .. Scrum asa Part of ITSM... ITIL and ITSM............- The Importance of CSI..... Scrum and Process Improvement Scrum and the Service Lifecycle. ITSM and Scrum Component: | 0) . BRM, SLM, and Product Owner Roles . 29 Service Desk, Service Owner, and Product Owner Roles .. Misconceptions. .............5+ Definition of Done ............ Agile and Ongoing Operations Enterprise Agile and ITSM .... ITSM and Scrum at BEYOND20 Simple but Not Easy........... About the Author ..............:.ece eee ee ee 51 About BEYOND20..... Training .......... Assessments....... Implementation .... Vehicles / General Information........ . 55 in which they can’t keep up - perpetually delivering products that customers no longer want. From a customer perspective, Agile helps avoid situations in which requirements are gathered by a Business Analyst who then disappears for months, finally delivering a product or service that fails to meet functional needs and often exceeds projected costs. Demystifying Agile, Scrum, and IT Service Management 3 (qq) uous Poloug Aojdaq 3s ping usiseq uid azApuy RHO Changing How Work is Done ] Design Build Deploy Test IL Analyze Plan Design Build Deploy Agile [ Analyze Plan Demystifying Agile, Scrum, and IT Service Management Agile and Scrum So, what is Agile, Scrum, and how does it all fit into this concept of IT Service Management? Let's first talk about the difference between the terms “Agile” and “Scrum”. Many people use these terms interchangeably, but they are different. Agile is a simple framework originally designed to deliver high-quality software products. It was developed in the mid 1990s with the development of the Agile Manifesto (see www.agilemanifesto.com) and is a tool for delivering projects and products. Scrum is the most common method of the Agile framework, accounting for about 55% of Agile projects - where a team delivers small increments of a product and elicits regular feedback from customers. The Scrum Alliance is the largest of the professional organizations under the umbrella of Agile (www.scrumaliance.org). 8 Agile and Scrum The Scrum method allows teams to rapidly adjust, deliver items in small cycles, and ultimately produce a higher-quality product than they would using traditional development techniques like “waterfall”. IT Service Management Project and Product Delivery Agile Practicing scrum means that you organize, prioritize, and manage your ever- growing, ever-changing product “wish list” in something called a Product Backlog. The project team takes a manageable chunk of that Demystifying Agile, Scrum, and IT Service Management 9 work that can be completed within a short amount of time (called a Sprint). The team then figures out how to best complete the work, so that a “potentially shippable” product is delivered with each sprint. At the end of each sprint, the team performs a sprint review, a retrospective (essentially “lessons learned”), and begins planning the next chunk of work. See the diagram on the following page for an overview of atypical Sprint. 10 Agile and Scrum the scrum process and makes sure everyone is successfully moving forward, and finally the Scrum Team that performs the work. Similarly, the ITIL books define key roles in Service Owners that are accountable for delivering and maintaining an IT service and Process Owners accountable for each ITIL process. Demystifying Agile, Scrum, and IT Service Management 13, Scrum as a Part of ITSM Both Scrum and ITSM focus on delivering value to the business, and both place a heavy emphasis on the customer. How each delivers value, however, differs. As stated previously, the Scrum framework focuses on creating a high-quality product, whereas ITSM focuses on delivering value through services. This difference may seem insignificant, but it is not. A product is something tangible - the result of a project with a defined start and end. Scrum uses the concept of a time boxed “sprint” to ensure delivery of high-quality and valuable products to customers early and often. A service is something that is produced as it is consumed and often intangible. Service delivery requires a full lifecycle approach, and a tight coupling between capacity and demand. End-to-end service delivery can be challenging to measure and report against. ITIL defines a service as “A means delivering value to customers by facilitating 4 Scrum as a Part of ITSM outcomes customers want to achieve without the ownership of specific costs and risks.” A service facilitates a result that a customer wants. For example, email is a service, but what a customer really wants and needs is cheap, fast, written communication (more on this later). Customers do not want to have to own the infrastructure costs or associated risks needed to provide or manage email themselves, but they are typically willing to pay for outcomes. As a result, customers go to a service provider (internal or external) with capabilities to support these outcomes. If you think about the analogy of a restaurant, the reason why we as customers go to restaurants is because we want a meal, but we don't want to have to buy any ingredients, cook the food, clean up after ourselves, or do any dishes! Instead, we go to a restaurant as a service provider that takes care of all of that for us. Demystifying Agile, Scrum, and IT Service Management 15 ITIL and ITSM ITIL is a set of books describing good practice in IT Service Management. Like Agile and Scrum, many people use the acronyms ITSM and ITIL interchangeably. However, ITIL are the “books”, and ITSM is the “subject” of the books. IT organizations practice IT Service Management by genuinely listening to customer needs and delivering consistent, reliable IT services and solid, repeatable processes. In doing so, practicing Service Management helps IT organizations change the conversation with customers - from one of being thought of as a necessary evil and provider of technologies to that of a consultative partner and provider of services that add value and move the organization forward. In order to develop great processes and to continue to deliver amazing IT services, IT needs Scrum. 18 ITIL and ITSM. The Importance of CSI One of the key lynchpins between ITSM and Scrum is that of Continual Service Improvement. CSI is one of the five phases of the ITIL Service Lifecycle, and an entire book devoted to improving how IT Service Management is performed. CSI as part of IT Service Management takes many of the concepts from Lean, Six Sigma, CMMI, and other improvement frameworks and methods and applies them toIT services. CSI helps organizations take the basic processes defined in the ITIL books and turns them into processes that are evolutionary, adaptive, self-correcting, and ultimately “agile” - in response to customer needs. In fact, the role of the CSI Manager as defined in the ITIL books has a lot of similarities to that of a Scrum Master in that both are focused on improving how teams work and serve as an “improvement coach” Demystifying Agile, Scrum, and IT Service Management 19. toa single team or multiple teams within the organization. Both of these roles require strong soft skills and a solid understanding of their respective areas. The sections below discuss how Scrum concepts can be applied specifically to improving ITSM processes and services. 20 The Importance of CSI At BEYOND20, we regularly use Scrum concepts to break ITIL process improvement projects into two-week sprints. This format allows us to rapidly show value in the work that we are doing for customers. Further, it helps ensure sustained stakeholder excitement. This format a is key success factor, particularly with potentially high-risk projects that last many months. Stakeholder enthusiasm can be difficult to maintain over an extended period of time, and support for organizational change can wane after a few months. By regularly delivering continuous, small deliverables at short intervals and measuring incremental improvements, team members get a chance to see the positive changes and effects of ITSM efforts, helping stakeholders remain excited throughout the life of the project. It also gets teams members used to the rhythm of delivering documentation or other deliverables every two weeks, and these projects are often completed faster than expected. Demystifying Agile, Scrum, and IT Service Management 23 The figure on the following page shows how we use scrum concepts with the CSI 6-step model. 24 Scrum and Process Improvement Pee Em eriy Boppeg wads Boppeg 32pod 25 Buwwe ads poy onnadso.nay © Crown copyright 2011, Reproduced under license from AXELOS Limited. Demystifying Agile, Scrum, and IT Service Management ITSM and Scrum Components Both IT Service Management and Scrum have their own “language”, complete with specific and defined roles, artifacts or documents, events or meetings, etc. The following sections define some of these key components that overlap and compliment one another in Scrum and ITSM. It is also helpful for Scrum Product Owners and ScrumMasters to be aware of ITSM roles and interactions that serve as key stakeholders to Scrum projects. 28 ITSM and Scrum Components Roles BRM, SLM, and Product Owner Roles The latest update of the ITIL books (2011 edition) defines the role of the Business Relationship Manager (BRM). The Business Relationship Manager's role is somewhat similar to that of a Product Owner in that they serve as the strategic voice or advocate for the customer. The BRM is also focused on customer satisfaction and building a strong, trusting relationship with customers over the long-term. The BRM may oversee one or many end- to-end services, whereas a Product Owner (PO) may only manage the Product Backlog for a single product or project. Asa result, a BRM could potentially oversee multiple Product Owners. In addition, once a particular service is being designed a Service Level Manager will get involved and begin drafting a Service Level Agreement (SLA) for a service, which includes Demystifying Agile, Scrum, and IT Service Management 29 items like how quickly IT will respond when a service issue or request is logged by a customer, how quickly or often changes and releases will take place, how much capacity or security will be provided, etc. The Service Level Manager will have lots of interaction with the Product Owner (input to the product backlog, etc.). One key meeting that a Service Level Manager facilitates is that of a Service Review Meeting. This is a face-to-face meeting with customers to discuss the service provider's performance against SLAs. Ideas (or requirements) for service improvement may result from these meetings, which can be excellent candidates for the Product Backlog. If these roles exist within your organization, it is important to define the responsibilities of each role as well as how they will interface. 30 Roles Misconceptions When you talk to Scrum teams or IT Operations teams, you hear misconceptions from each side. Scrum teams do not understand why they can’t just deliver products quickly into production. They see the ITIL framework as out-of-date, too focused on documented processes, and too restrictive. In some cases, this can be true. Organizations can sometimes introduce “process for process sake”. However, SOME process is needed to ensure that organizations can consistently deliver high quality products and services. If we stick with the restaurant analogy, think about what would happen if there was no menu or recipes, and any customer could walk in and order anything. It would be chaos to say the least, customers might get strange and inconsistent results (depending on who was in the kitchen and what ingredients were Demystifying Agile, Scrum, and IT Service Management 33 available), and the restaurant would likely not be around for very long. The development of processes needs to be a balance, and processes should change over time. This is the part that organizations sometimes overlook (more on CSI later). The ITIL books focus a lot on processes, but the takeaway message is that processes need to make sense within each organization. That’s why the ITIL books serve as a framework. ITIL defines all the tools that an organization can use, but it’s up to each organization to select the right tools for the job. From the alternate perspective, IT operations teams sometimes see Agile / Scrum teams as fly-by-the-seat-of-your-pants elitists that never want to document anything, and they are often frustrated by, as one customer put it, the “flaming bag of poo that gets thrown over the wall that we are then forced to support”. 34 Misconceptions The Agile manifesto clearly states that the focus should be on “Working software over comprehensive documentation”. What the Agile Manifesto does not say, however, is that you should only care about working software. In fact, the Agile Manifesto states that there is value in having comprehensive documentation, but that there should be more of a focus on working software. IT still needs requirements, but these can take the shape of user stories rather than volumes of detailed technical specifications (see the next section on Definition of Done). Operations should provide the necessary requirements for producing what they need, but development should have the freedom to pick best method to deliver that information. There should be a balance, and good communication is key. Those inside and outside of Scrum teams cannot develop an “as versus them” mentality and expect the organization to be successful. When this Demystifying Agile, Scrum, and IT Service Management 35 stories to the Product Backlog that spell out documentation requirements like the Service Design Package (SDP). A typical user story takes the format of, “As a <role>, | want <goal/desire> so that <benefit>”. The IT operations team could draft something like, “As part of <IT operations>, I want <to know how this application is architected, what key interfaces or dependencies this system has, who the key customers are, what key requirements were met, current known errors and existing workarounds, and/or how this application or service underpins a business process> so that <the team can quickly address customer questions and issues, fully understand the impact of changes, and better support this application over the long term>.” A statement like this would help the development team better grasp the long-term impact of their work. Further, this gives IT operations an opportunity to define the minimum pieces of information required 38 Definition of Done within an SDP template before accepting an application into production and considering it to be “done”. Alternatively, sprint teams should consider adding tasks or an additional sprint entirely for documentation as part of the definition of “done”. IT operations can also improve the integration between development and operations team by speaking the language of the development team, for example, by translating feedback from service review meetings with customers into user story format. IT operations should also insist on inclusion to some level within the confines of the Scrum team to ensure both teams understand and address the needs of the other. Demystifying Agile, Scrum, and IT Service Management 39 Agile and Ongoing Operations Scrum concepts play a critical role when it comes to delivering IT services on a day- to-day basis. There is often a list of things customers want to change or implement, both new services as well as to improve existing services. All of these items need to be addressed, in addition to the day-to-day support of ongoing IT operations. So, how do you make it all work? In order to get out of “fire fighting” mode and handle customer requests, it is necessary to carve out time for enhancements, mini- projects, and even full blown projects. This is another place where agile can help! At Beyond20 we separate out people's time, removing the percentage of time we know is going to be devoted to operational activities (for the service desk, this may be 90% of their time, whereas this may be 50% for a Network Engineer). 40 Agile and Ongoing Operations In the Agile community, one of the recent methods gaining traction is that of SAFe, the Scaled Agile Framework (http:// scaledagileframework.com), for the enterprise. In methods like Scrum, the focus tends to be on a single team, with a single Scrum Master, and Product Owner. Whereas, the SAFe framework defines for organizations how they should structure people, processes, information, etc. so they have visibility at not only the project level, but also at the program and portfolio level. Demystifying Agile, Scrum, and IT Service Management 43. ITSM and Scrum at BEYOND20 Here at BEYOND20 (www.beyond20. com), concepts from the ITSM/ITIL and Agile/Scrum community have not only helped us make positive, tangible, and sustained improvements for our customers, they have also helped us improve how we run our business. Prior to implementing Agile and Scrum concepts at BEYOND20 we were really cranking out work, but as one of the Principals of the company, I did not really have good visibility into what was being worked on at any moment in time and when the next deliverables would be completed. I knew work was getting done and our customers were generally very happy, but I lacked a lot of the in-depth knowledge needed to do strategic planning and make data-driven decisions. As aresult, we not only teach ITIL and Scrum, we embrace it and live it everyday as well. At our core we are a service provider; 44 ITSM and Scrum at BEYOND20 and many of the concepts within the ITIL books apply to us. We have used ITIL concepts to create our own Service Catalog and service packages, manage internal changes, etc. On the Scrum side, we break our projects and ongoing operational work into sprints, conduct daily scrum meetings to manage the work of our virtual teams, and deliver “shippable product” - process documentation, software, reporting, training curriculum, etc. - depending on the type of project. We hold one another accountable, and above all else, we get consistently work done — on time and within budget. We constantly talk with one another and our customers about our work and ways we can get better. We regularly inspect, change, adapt, experiment, and improve ~ and it’s a pretty great place to work. One of my favorite books on team collaboration and creativity is called “Gamestorming” (www.gamestorming.com), Demystifying Agile, Scrum, and IT Service Management 45 56¢ FD 2120: wo Buuren aua}oyynsu EE onc es 162 I 22 210) 02 wea > sausugnun x: EE <0 4 EEE rere on <0) IIIS 21.014 svonesnmusuo> 0 euoneznedio s9pe0.9 y cot (III ::2204¢ epson euonpen mojo) 0 aunssoad eusnaxg 1) REI 202 959 2901080 9 9 et (EIS 40 012 2202 an 9902 axa hydooye dn +51 I 01 2008 266m 205 syeloug aIIs\y poyie4 Jo sasne> sulpec7 ©2014, VersionOne, Inc. All Rights Reserved, VersionOne is a registered trademark and State of Agile is a trademark of VersionOne, Inc, Simple but Not Easy 48 Think of it this way. Running is simple. There are a few fundamental concepts, but really anyone can do it. It’s just a matter of putting one foot in front of the other. However, very few of us have enough discipline to keep at it to complete a marathon, much less win a race! The same holds true for Scrum and IT Service Management. At countless organizations, I have seen teams “try” to do a little bit of one or the other and then decide it cannot be done. Unfortunately, the benefits only come after time, and many quit long before they ever see them. In fact, the rule of thumb with many Scrum practitioners is that sprints are generally bumpy and painful for 3-5 sprints, which often takes commitment for many months! The same is true with any new habit. It can be difficult at first, and organizations find that improvement can often times be unpleasant, time consuming, and expensive. Demystifying Agile, Scrum, and IT Service Management 49. Still, the result is worth the effort. It is often said that ITIL is not a destination, but rather a journey. This concept is also true with Scrum. Organizations that think about the problem(s) they are trying to solve first, and then use the appropriate Scrum and/or ITSM. concepts to address them are the ones that find the most success. These are the organizations that will continue to provide the very best products and services for their customers over the long run. I hope this information has been helpful to you, and I encourage you to take any and all ITSM and Scrum tools mentioned here and elsewhere to help your teams experiment, change, improve, and have a great time delivering great products and services too! 50 Simple but Not Easy About BEYOND20 At BEYOND20, we help organizations transform themselves into powerful, business aligned IT Service Providers. No single solution is right for everyone, so we work with clients to provide a custom blend of solutions including: Training ITIL® Certification Project Management Training, including PMP® Prep and Project+ CobiT and ISO/IEC 20000 Certification Agile / Scrum Training / Certified Scrum Master (CSM), Product Owner (CSPO), and Developer Certification Culture Change Workshops, including PoleStar IT Service Management (ITSM) and Project Management (PMO) Simulations Demystifying Agile, Scrum, and IT Service Management 53 Assessments ITIL / ITSM process assessment Project / Program Manager skills assessments Portfolio Management assessments Training Effectiveness assessments Consulting ITSM Strategy and Governance ITIL Process Assessment and Design Staff augmentation Service Desk transformation ISO/IEC 20000 and CobiT Assessments and Consulting Program, Project, and Portfolio Management Process Design Implementation 54 Cherwell® ITSM Software Partner Bomgar® Gold Partner Integrated ITSM Platforms Enterprise Project Management (EPM) systems, including Microsoft Project, Project Server, and SharePoint Custom Dashboards and Metrics About BEYOND20 Vehicles / General Information + GSA 70 Schedule: GS-35F-137AA + NAICS CODES: 541511, 541512, 541519, 541611, 541614, 611420, 611430 + DBE certified Woman Owned, Minority Owned Small Business + PMI® Global Registered Education Provider + APMG and CSME Accredited Training Organization (ATO) http://www.beyond20.com Micresoft GOLD CERTIFIED [eEy;3 Contract Holder Partner QITIL Y 1 Project TRAINING ORGANIZATION = Management ACCREDITED BY (HE, a Institute _C— CHERWELL PREFERRED PARTNER" BOMGAR | cea Pertna Demystifying Agile, Scrum, and IT Service Management 55. Notes This handy guide will walk you through key concepts on: > Agile and Scrum > Delivering Great Products and Services > ITIL and IT Service Management > Scrum as a Part of ITSM Want to do more with Agile, Scrum and IT Service Management? We can help! Contact us at 866-856-3117 or info@beyond20.com ERIKA FLORA PMP CSPITIL Expert, is a Principal Consultant at BEYOND20, an IT consulting and training firm built on expertise in IT Service Management, Cloud Services, and Project Management. Technology/Computers & Internet ‘www.beyond20.com 235 188 9861 i i So9s> °