Continual service improvement (CSI) is one of the most critical practices organizations need to perform to ensure their services meet customer needs. There are two main focuses of CSI: improving business services and improving the practices and processes used to deliver services. True improvement comes from a strategically focused effort, ensuring the incremental improvements being made are aligned with overall organization strategy. An Agile approach can help organizations improve incrementally, while achieving a longer term, strategic transformation.
There’s So Much to Do...
When people think of improvement, they might think they just need to make some small changes. However, for many organizations the level of improvement needed is transformational. They get stopped however, when they realize they don’t have the appetite for the effort of a true transformation. When they perform a gap analysis of where they are versus where they’d like to be, they see the level of effort can take several years or require a high degree of change, and so they make a few changes and stop. There are several reasons this happens:
- Fear of change fatigue: they’re afraid of driving the level of change needed vs. making a commitment to manage change effectively
- Fear they can’t commit the time and effort needed to be successful
- Fear of losing steam and having it be another “flavor of the month” effort that doesn’t really change anything in the longer term.
The seven ITIL® guiding principles provide an opportunity for organizations to change the way they approach improvement programs by maintaining a focus on value and encouraging organizations to work iteratively until they reach their desired operating state. This concept is a core distinction of the Agile methodology, making Agile an extremely useful tool in improvement initiatives.
Agile in a Nutshell
While this will be a bit of an oversimplification of the Agile methodologies, anyone who has engaged in Agile development recognizes several core concepts that can be applied to CSI:
Minimum viable product. The smallest product unit that is able to achieve the desired outcome. For an organizational improvement, this means looking at the end state or strategic result of the improvement program and breaking it down into smaller efforts, each one of which results in an outcome by itself.
As an example, perhaps the overarching initiative is to turn customers into “Raving Fans,” but customer satisfaction surveys indicate they feel it takes too long to reach someone by phone and the support provided is not very good. There are several minimum viable products that can be defined:
- Lower call wait times
- Build a knowledge base that provides consistent experiences by starting with the top 10 issues handled
- Add 10 knowledge articles/week based on remaining high-volume issues
- Provide a self-service website that offers the ability to find quick answers online
Stories and Kanban boards. A user story is a documented description of what a user needs and how the solution will be provided to achieve this. For example, a user story for creating the knowledge base might be:
As a customer service representative, I need a collection of instructions for the most common issues I receive. I’ll know this is done when the knowledge base in my call logging tool is available for use.
A Kanban board is nothing more than a planning board that enables people to work collaboratively when planning a release. (Kanban boards are easy to obtain! There are many free electronic products available and many release management tools use a Kanban approach.). For initial release planning, a typical Kanban board might have columns for the backlog and each of the sprints, like the one shown below.
The team would work together to move each of the stories into a sprint, ensuring that at the end of each sprint a unit of work that stands on its own is completed.
Sprints are then managed in a similar fashion, using a Kanban board that in its simplest form has columns called backlog, doing, done, not doing. Again, the stories are moved from the backlog through the columns until they are either done or identified as not needed (not doing).
At the end of each sprint, a retrospective should be held. The achievements are celebrated, lessons learned documented, and adjustments made to future sprints. By doing this collaboratively and at the end of each sprint, the plan is always being adjusted to meet the organization’s needs and the team members are acknowledged for their contribution to the overall outcome. This is the feedback portion of “progress iteratively, with feedback.”
Moving Forward with Agile
By breaking down significant initiatives into smaller outcomes and then breaking the smaller outcomes into tasks to be accomplished within a time-boxed window, Agile enables an organization to think big and then move forward in small, iterative steps. As long as the sprints are small enough to be accomplished by project participants in their brief duration, on top of the person’s normal day job, change fatigue can be avoided. Working this way means that each task accomplished is seen as part of the whole unit of work. Thus, even each one of ten people did nothing more than write one article, the outcome of building a knowledge base was achieved. Celebrating each person’s contribution at the end of the sprint keeps the momentum going and keeps people engaged.
Change management efforts need to be included. While the key stakeholders are actively working, keeping all of the teams impacted by an effort informed is another key activity. The change management activities should be documented as user stories, and as with the other activities, included in each and every sprint. By using Agile to keep the work from becoming too much for people and including change management activities in the ongoing work, the biggest fears of taking on a large initiative can be successfully addressed.
By making each unit of success something that is easily achieved, organizations can see improvement every step of the way and realize that improvement isn’t that hard. Selling this message and acknowledging people will keep them engaged. Ultimately, service transformation isn’t achieved in the short term, it needs to be embedded in the culture. Once an organization gets started using Agile methodologies, the plan can be changed at any time and additional initiatives can be added to the longer-term strategic plan.
Service transformation isn’t achieved in the short term, it needs to be embedded in the culture.
One of the benefits of this way of working is that each effort is targeted to an eventual outcome, rather than just “improving for improvement’s sake.” If organizational change management is performed well, people can always see each task as a small step to a larger outcome. This helps maintain momentum and keep people fixed on the big picture or “working holistically.”
Phyllis Drucker is an ITIL® certified consultant and information leader at Linium, a Ness Digital Engineering Company. Phyllis has more than 20 years of experience in the disciplines and frameworks of IT service management, as both a practitioner and consultant. She has served HDI since 1997 and itSMF USA since 2004 in a variety of capacities including speaker, writer, local group leader, board member, and operations director. Since 1997, Phyllis has helped to advance the profession of ITSM leaders and practitioners worldwide by providing her experience and insight on a wide variety of ITSM topics through presentations, whitepapers, and articles and now her new book on the service request catalog, Online Service Management: Creating a Successful Service Request Catalogue (International Best Practice). Follow Phyllis on Twitter @msitsm.