In the IT universe, we have continuous integration, continuous testing, continuous delivery, continuous deployment, and continuous service improvement, just to name a few. The overall intent is to automate as much as possible to reduce risk and, yes, bring continuous business value.
If you follow DevOps, you probably have a good grasp of the meaning and significance of most of these terms. However, you may not know as much about continuous service improvement (CSI), since it’s not typically mentioned in the same breath with the others. In official ITIL books, CSI is described as a key phase and good practice in implementing IT service management. In this post, I’ll provide a definitive description and talk about how CSI should be used in conjunction with the other “continuous” buzz phrases mentioned above. For dessert, I’ll throw in some thoughts on how CSI fits into the scrum framework.
CSI is a phase that a service goes through in the IT service management lifecycle. (Other ITIL phases, which are out of scope for this post, include service strategy, service design, service transition and service operations.) The goal of CSI is to ensure that a service will continue to align to an organization’s business needs, even as those needs change. CSI uses knowledge management good practices that transform data into information then into knowledge and finally into wisdom, which is used for implementing the correct improvements. Using metrics to identify and implement improvements to IT services that support business processes, CSI is also a great way to determine an IT service provider’s performance by quantifying the provider’s value.
Ready, Set, Go
Step 1 of the seven-step CSI process is identifying the strategy for improving the service. Identifying the strategy requires us to understand and define the organization’s goals and vision for the improvement and how the improvement would impact business needs.
Step 2 is the very important step of defining what should be measured, a step that will drive the metrics on which we build reports. For reports to be truly useful, we need to define—up front—the services we should measure, why we should measure them, their key performance indicators, and how a successful service would perform.
Step 3 is creating a metrics baseline. To do that, we need to determine who uses the services and when and how they are used.
Step 4 moves us from raw data to information by processing the service’s data from, say, a gap analysis. In step 5, we analyze the data and compare it against goals we defined in step 1. We use the quantifiable knowledge to determine if we were successful in making an improvement.
In step 6, the results are presented to stakeholders. We determine action plans, road maps, etc.
In step 7, the improvements are implemented.
At that point, the process begins again, focusing on improvements to new or existing services.
CSI and the Scrum Framework
As a CA Services architect who designs and implements our solutions, I appreciate using an industry good practice such as CSI to quantify ROI and/or a service improvement and demonstrate an implementation’s success.
However, can CSI, an IT operations process, be integrated into a scrum framework or DevOps process? To answer this, let me walk you through a typical scrum process:
- To get the ball rolling, a product owner, who represents the end user, has a product improvement idea and convinces stakeholders to fund the improvement: CSI step 1 helps here.
At that point, a scrum master is engaged to facilitate the sprint that will deliver the product improvement. A delivery team (engineers, architects, etc.) decides how to do the work. The product owner, scrum master, and delivery team make up the scrum team. The scrum team has roughly 30 days (a sprint) to deliver the product improvement. To get there, they take these steps:
- The product owner creates a product backlog of requirements or user stories: this is a good place to apply CSI step 2.
- The rest of the scrum team refines, updates and prioritizes the user stories. The delivery team develops a release plan that maps user stories to sprints and develops the code, architecture, and infrastructure. The team identifies tasks, discusses issues, makes cost and timeframe estimates and implements continuous integrations and continuous delivery processes. The team also defines what “done” is: CSI steps 3 and 4 help with these processes.
- Once the tasks are complete, stakeholders are invited to a sprint review, which typically includes a product demo and a walk-through of user stories: This aligns well with CSI steps 5, 6 and 7.
The last phase of the scrum framework is the sprint retrospective, in which the scrum team reflects on recent improvements, identifies how it can become more efficient and makes adjustments for the next cycle.
CSI is not only a useful tool in and of itself; it also can help us facilitate and manage the scrum framework. To continue this conversation, please visit me at CA World 2017, where I will present a session on leveraging ITIL to quantify business value (session AMT32T) or connect with me on Twitter @DarrenArcangel or LinkedIn.