Agile Service Management


by Jayne Groll


Lately, there’ve been a lot of calls for IT to become more “agile.” This trend is showing up in webcasts, conference presentations, blogs, discussions, and white papers, and the term itself has become part of our IT vocabulary. However, while “agile” is freely used, there’s not a clear definition of what “being agile” actually means, particularly in the context of technical support and service management.

In this article, I will provide a high-level overview of Agile concepts, its origins, its primary frameworks, and its value. More specifically, I’ll explain how Agile service management can help organizations meet the rapidly changing requirements of their businesses and customers.

The Origins of the Agile Manifesto

First things first: What is Agile? Agile is a set of guiding values and principles that was originally crafted by and for software developers. By itself, Agile is more perceptive than prescriptive; it’s not a framework, standard, or method of working. Instead, Agile values are embedded in and underpin other frameworks, such as Scrum, Kanban, and Xtreme Programming, and it’s a critical success factor (CSF) for organizations trying to instill a DevOps culture, since the core concepts equally apply to IT development and operations.

In 2001, a group of frustrated software developers got together to discuss and identify alternatives to the heavyweight, documentation-driven, bureaucratic development processes prevalent in that industry at the time. Despite coming from different approaches and disciplines, the group was able to define and agree on a set of core values that were intended to refocus developers to what really mattered.

The Agile Manifesto

While we value the items on the right, we value the items on the left more.

Individuals and interactions  

Processes and tools  

Working software   Comprehensive documentation 
Customer collaboration   Contract negotiation  
Responding to change   Following a plan  

At first glance, you may think that the values of the Agile Manifesto are contrary to everything we hold dear in technical support and service management. Doesn’t it seem to diminish the importance of the effective and efficient processes, good tools, useful documentation, and practical SLAs/OLAs that guide us every day? Not at all.

The group that drafted the Agile Manifesto very clearly stated that while they valued the items on the right, what really counted were the items on the left. They elaborated by adding twelve guiding principles:

  • Our highest priority is to satisfy the customer.
  • We welcome changes, even late in development.
  • Deliver working software, frequently.
  • The business and IT must work together daily.
  • Projects should be built around motivated individuals.
  • The most effective and efficient method of communication is face-to-face communication.
  • Working software is the primary measure of progress.
  • Agile processes promote indefinitely sustainable activities and a consistent pace.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity—the art of maximizing the amount of work not done—is essential.
  • The best services emerge from self-organizing teams.
  • At regular intervals, the team should reflect on how it can become more effective, and then tune and adjust its behavior accordingly.

I’ve truncated the principles slightly, but I don’t think anyone can dispute the relevance and significance of what was captured in the Agile Manifesto. It reminds us why we do what we do and what we’re trying to achieve. Not surprisingly, most of these values are very similar to the accepted objectives of service management and support:

  • Align with the business.
  • Ensure ongoing customer value.
  • Understand and enable business processes.
  • Deliver quality IT services.
  • When incidents occur, restore service as quickly as possible.
  • Adapt to changing requirements.
  • Minimize risks.
  • Be effective and efficient.
  • Make processes sustainable and repeatable.
  • Fulfill IT governance requirements.

Making Service Management More Agile

The Agile Manifesto emphasizes the core values that all IT service providers should embrace and instill in their cultures. It doesn’t suggest that we should discard all of the efforts and investments already made in service management; rather, it validates what we’ve already accomplished and encourages us to lighten the load by simplifying and expediting processes and related assets. In short, Agile recommends that we do just enough of the items on right to make the items on the left amazing!

Becoming Agile is a great opportunity to step back and assess where your organization is today, where you’re going, and how you’re focused. Is your organization delivering value to customers through its services? How do you know? Are changes happening more quickly and successfully? Is service being restored faster? Are you achieving the service levels captured in your SLAs/OLAs? Are you really aligned with the needs of your customers? More importantly, are you focusing on business outcomes, or are you too entrenched in tools, flowcharts, documentation, and reports?

Service management initiatives should use Agile as a soft benchmark against which they can determine whether their programs are rewarding the right behaviors, initiatives, and achievements. It’s not a matter of semantics; it’s a matter of where your value proposition lies. And it should unequivocally lie with the ability to enable your customers’ success quickly, responsively, and innovatively. Here are some additional questions to consider:

  • Do you understand your customers’ definition of “value”?
  • Does the result of each process emphasize the business outcome or a resolved incident, change, problem, or request?
  • Do you value signed SLAs or understood service level requirements?
  • How often do you meet with customers to review their requirements?
  • Are tools driving your processes or are customer requirements driving your tools?
  • Are business representatives on your change advisory board (CAB)?
  • Are changes—big and small—being deployed on time and on cost?
  • Do customers and IT staff regularly try to circumvent your processes?
  • Is customer satisfaction increasing, flat, or decreasing?

The answers to these questions will help you identify the areas of your service management program that need to be reshaped, refocused, or streamlined in order to become more Agile.

If I were to propose an Agile Service Management Manifesto, here’s what my vision of the core values would look like:

The Agile Service Management Manifesto

While we value the items on the right, we value the items on the left more.

Business value

Processes and tools

Quality services Managing configuration items
Customer collaboration Executed SLAs
Embracing change Protecting stability

I’m not suggesting you lose control of changes, stop performing risk assessments, forget about your SLAs/OLAs, or abandon your process improvement efforts. Like the original authors, I’m encouraging you to do just enough of the items on the right to create extraordinary customer value through the items on the left.

This is just a suggested starting point. Let’s do what the developers did: work together to agree on a collective set of core values and principles that keep us focused on what really matters.

Agile Frameworks

As I mentioned before, Agile isn’t an actual framework, standard, methodology, or technique. Instead, frameworks like Scrum, Kanban, and Xtreme Programming structure and establish a body of knowledge around Agile principles and give organizations something to “do.” Each framework, method, standard, or technique helps to move the organization forward and contributes to the creation of an Agile culture.

Scrum is often perceived to be synonymous with Agile—but it’s not. What it is is the most globally recognized and implemented Agile framework. Scrum is rapidly replacing the traditional waterfall approach as the preferred software development lifecycle approach, and successful Scrum adoption is often considered to be critical to achieving continuous delivery and a DevOps culture.

Scrum concepts are based on small teams and small releases. The teams are self-organizing and the goal is to release frequently (if not continuously). A defined backlog of tasks is parsed into planned and incremental “sprints” that guide the teams’ work. Each iteration moves the project forward because each sprint produces some aspect that is “done” (however you define that word).

Scrum is deceptively simple, yet it’s difficult to master. Scrum discourages and reduces “work in progress” as teams learn to understand and improve their velocity (i.e., the ability to absorb work). The team also relies on frequent communication and the removal of impediments to clear the path to completion. As a result, Scrum helps organizations move faster, with greater customer engagement and better resource management and communication.

While Scrum was originally intended for software development projects, it’s now widely recognized as a useful approach to any complex project, such as a service management program. The road map usually associated with service management adoption can and should be broken down into meaningful, related increments. Since sprints generally span about two to four weeks, an increment shouldn’t be an entire process, but should instead be broken down into smaller bites. As each sprint is completed, the project or program will gradually move forward.

Over time, Scrum could help service management organizations become Agile service management organizations with:

  • Trained ScrumMasters
  • Small self-organizing teams with increased responsiveness
  • Better workflows and improved communication
  • Less work in progress
  • Measurable accomplishments
  • Shorter feedback loops
  • Less bureaucracy
  • The ability to go much faster without sacrificing quality

Leveraging Scrum in support of Agile service management will also expand the IT vocabulary by introducing terminology from multiple disciplines, frameworks, and methods.

As operational teams become more Agile, the gap between Agile development and Agile service management will shrink. Operational and support staff will be invited to join development scrum teams (and vice versa) and contribute to prioritizing and fulfilling the backlog of tasks for new or updated software. Silos will gradually break down and there will be fewer bottlenecks. A DevOps culture will start to emerge, and IT will be able to deliver quality services faster and meet the changing needs of its customers.

An Agile Future

It’s important to recognize that Agile service management is first and foremost a state of mind that marries Agile values with service management objectives. It reminds us of what really matters and enables us to meet our customers’ rapidly changing requirements. Once we institutionalize Agile values, we can then realize the benefits of being Agile by looking at ways to integrate Agile and service management practices through approaches like Scrum, ITIL, KCS, and DevOps, enabling us to break down silos, cross-pollinate knowledge, and make complex projects deliver value much, much faster.

This is the future—and the future is now.

 

Jayne Groll is the cofounder and president of ITSM Academy. She holds many ITSM credentials, including ITIL Expert, Certified ScrumMaster, Certified Process Design Engineer, and ISO/IEC 20000 Manager Consultant. She was also one of the first to be certified as an HDI Help Desk Manager. Prior to founding ITSM Academy, she held several senior IT management positions across multiple industries, focusing primarily on operations and service support. Jayne is a frequent conference and webcast presenter, and she’s authored multiple white papers and blogs. Follow her on Twitter @ITSM_Jayne, or email her at JGroll@ITSMAcademy.com .

Jayne will be presenting sessions on practical problem management and DevOps at FUSION 14 (sessions #606 and #704). Add them to your schedule today!

Tag(s): ITSM, service management, process

Related:

More from Jayne Groll :

    No articles were found.

Comments: