Agile, Mobility, and the App Economy: Driving a New Approach to ITSM

Three related business changes are challenging IT service providers, and should cause us to rethink the way we plan, deploy, and deliver services to customers:

• Mobile work: The transition from stationary to mobile work, which, in turn, is driving the increased adoption and use of mobile platforms (smart phones, tablets, and laptops), in contrast to traditional desktop PCs.
• Apps: This adoption of mobile devices in lieu of desktop PCs is driving the demand for smaller, more frequently updated apps, in contrast to traditional, larger footprint client-server-based applications.
• Agile development: The increasing demand for mobile-based apps is driving the adoption of Agile development methods, to quickly provide smaller and more frequent releases of apps that add incremental functionality, boosting productivity for users and the business.

The transition to mobile platforms started several years ago in earnest and shows no sign of slowing down. According to an IDG Enterprise study, 83 percent of organizations are planning to invest in mobile technology in the next twelve months. Services are being increasingly deployed on a standard set of limited, well defined, and supported platforms. Typically, these include smartphones (Android, iPhones), tablets (iPads, Android), laptops (Mac, Windows), and other mobile devices.

Is ITSM relevant in this new app economy? Absolutely.

The “age of the app” is upon us, and an increasing percentage of workers are using apps to carry out their daily work. Prime examples include Google Apps, Dropbox, Box, Office 365, Skype, Facebook and other collaborative apps, and countless others. The fact that these apps run in a standardized mobile environment of limited platforms—and are smaller in size and more limited in scope—has provided the opportunity for organizations to plan, develop, and deploy more frequent releases of incremental functionality. The popularity of Agile development and deployment methodologies has risen in response to this demand.

Is ITSM relevant in this new app economy? Does it still make sense to follow an ITSM approach? Absolutely. In fact, the principles of ITSM and the application of the ITIL framework in an organization are very compatible with the adoption and use of Agile development methodologies. Furthermore, ITSM and ITIL can and should provide the overall framework within which Agile development can successfully operate, developing and deploying apps that are part of a service fit for purpose and effective use in a mobile environment.

Let’s Agree on Some Basics

First, you must remember that value is comprised of much more than just the functionality of an application (what ITIL calls “utility”). It takes both functionality (what the service does) and performance (how the service performs) to create value for the customer. For example, I may have a fantastic smartphone, with all the cool functionality I could ever want, but if I can’t get a reliable connection, my phone isn’t worth much to me in terms of the value I’m deriving from it. The functionality requirements (utility) of an app must also be extended to include scalability (does the app operate correctly on a smart phone, a tablet, laptop, and desktop?) and compatibility (does it functional well under iOS, Android, Mac OS, or various Windows releases?).

Second, it’s important to understand that what customers and users want is a service that enables a business activity, not just an application. To be sure, the app is a key component of a service, but in order to be of value, the app must not only deliver the functionality the user is looking for, it must perform well relative to expectations. As ITSM and the ITIL framework emphasize, the service must be designed to meet minimum warranty, or fit for use, requirements; that is, it must be available enough, have enough capacity, be continuous enough, and be secure enough. For web apps, this also includes ease of use. Contrast Google’s simple user interface, for example, with other search tools. Simplicity and ease of use are also key considerations for apps.

Third, it’s important to remember that services are composed of two types or levels: customer-facing services and supporting services. Apps operate as part of a customer-facing service, or a service that directly supports a business process. However, without supporting services (e.g., network, storage), customer-facing services aren’t possible. Both levels of service are critical for the end user to derive overall value. This is true no matter what types of platform you are operating on—desktop, laptop, or mobile device (tablet or smartphone). The lesson? When designing, developing, testing, and validating a service, you need to pay attention not only to the app core functionality but also to how it performs in its customer-facing environment. And you need to consider the effectiveness of supporting services and components in assuring value (e.g., the type of platform, the operating system, the network, storage, security).

Fourth, Agile proponents must remember that “stakeholders” include more than just the project sponsor or the customer. Stakeholders, per ITIL, should include all of those impacted by the new or changed service. In addition to the customer or project sponsor, you must consider your users, as they are the ultimate consumers of the service (as well as any apps that are a key part of the service); IT service operations, especially the support center that is providing the people and resources to support the service and app; and suppliers, who may be providing infrastructure support services (e.g., platform services, hosting services).

There are no inherent contradictions between Agile development methods and the ITIL framework.

Finally, it’s important to be clear that there are no inherent contradictions between Agile development methods and the ITIL framework, despite the claims of the Agile Manifesto. To illustrate, allow me to list some of the core principles that are a part of the Agile Manifesto, and explain how ITIL is fully compatible with ITIL principles:

• “Individuals and interactions over processes and tools.” Although ITIL is based on the idea that a service should go through a lifecycle, this doesn’t mean that it fails to consider the importance of people and interactions. In fact, the ITIL business relationship management (BRM) process makes it clear that it’s vital to connect with customers on a regular basis.
• “Working software over comprehensive documentation.” The ITIL framework emphasizes that it’s important to document processes, but nowhere does it emphasize documenting for documentation’s sake. The practice of designing, developing, and deploying frequent, small-size release updates is compatible with the principles of ITIL service design and service transition. And Agile development methodologies emphasize the value of documenting as a continuous process during development.
• “Customer collaboration over contract negotiation.” Like Agile, ITIL is very much about collaboration. By including the BRM process in the latest edition of ITIL, and by underscoring the importance of the BRM role connecting and collaborating with the customer on a regular basis, ITIL fully supports the principle of customer collaboration—that customer satisfaction and the voice of the customer are key to the successful adoption of deployed services.
• “Responding to change over following a plan.” Is ITIL interested only in creating detailed plans, to the detriment of responding to change? Certainly not. There’re several elements with ITIL that play a key role in enabling IT to stay in touch with changing business needs. The BRM process, mentioned above, regularly has its account managers meet with business units to check that services are meeting current needs, as well as to discuss with the customer any changes in the business that might require new or changed services.

Integrating Agile with the ITIL Service Lifecycle

Not only are Agile development and ITIL practices not contradictory, Agile can be integrated with ITIL best practices and the ITIL service lifecycle successfully. They aren’t mutually exclusive practices! Why? They have different but very complementary aims:

• Agile provides a software development framework that enables a development team to carry out fast, effective delivery of software that provides value, in a constantly changing environment. ITIL is also focused on how best to provide services that deliver value, as well as staying aligned with changing business and customer needs. Both practices stress the importance of defining, developing, and delivering value to customers: Agile from the perspective of software that delivers value, and ITIL from the perspective of services that deliver value by enabling business processes, customers, and users.
• ITIL provides a service management framework that focuses on enabling an IT organization to manage a portfolio of value-added services that enable the business and customers to perform at a high level. ITIL acknowledges that well-designed and well-developed software applications are a key component of the value delivered by a service, but it also stresses that a service is much more than just an app. Thus, ITIL can and should serve as the overall ITSM framework that ensures the design, transition, and delivery of valuable services to the business, while Agile can operate within this overall framework to optimize the development, testing, and deployment of applications that are a fundamental component of services.

The key integration points between Agile and ITIL include integration between two key functions: the Agile application development team and the ITIL application management team. Application development and application management aren’t the same activities. Development teams are typically very utility-focused, placing heavy emphasis on developing chunks of software code that meet certain functionality requirements, without much attention to how the app will perform when in live operation (its warranty) or how it’ll be supported. The application management team is both utility- and warranty- focused, concerned with functionality, of course, but also with the performance of the application as a part of the service running in live operation. Application management is also responsible for the ongoing lifecycle management of all applications, not just those that are developed in-house, but also all third-party applications.

For these reasons, the in-house application development team and the application management team shouldn’t be the same team, but should instead be two teams that work very closely together—through the service design and development stage, as well as during transition into the live environment. The roles and responsibilities of both teams need to be clearly defined and documented, the way they interface with respect to process execution needs to be clearly mapped out, and teamwork needs to be encouraged and supported by management, ensuring that the two functions can work effectively together through all stages of the service lifecycle.

Service Design: Where Agile and Support for Mobile Engage

In addition to the integration of the application development and application management teams, both Agile and mobile development can be nicely integrated within the ITIL service lifecycle, particularly in the service design and service transition stages.

In the service design stage, the design coordinator role leads the service design team, which works with the Agile development team to gather the requirements for the new/changed service (and its apps). The application manager assigned to the application area works with the service/product owner, the development team, the business relationship manager, and the customer to gather and document the full set of requirements—the functional requirements (utility) to be provided by the service, and the performance (warranty) requirements—including desired levels of availability, capacity, continuity, security, user friendliness, etc.

Agile user stories and story points can help document the functional requirements during service design. These can then be prioritized by the service design team, which should include development, application management, and other stakeholders. The result is the prioritized product backlog for the development team. ITIL emphasizes “designing the architecture” as one of the five aspects of service design. Thus, the Agile development team can work with the service design team to arrive at the best architectural approaches for the service.

Agile supports the practice of capturing all requirements in a single source—and that concept maps right into the ITIL concept of the SDP.

Agile encourages documenting continuously through development, and service design documentation is critical at this stage. During service design, development documentation can be mapped into the service design package (SDP), which captures the complete set of design documentation for the new/changed service. The service model (how the service operates) is a key component of good service design, and it’s here that Agile modeling can be used by a development team to include stakeholders in the modeling process and help define the service model that goes into the SDP. Finally, Agile supports the practice of capturing all requirements in a single source—and that concept maps right into the ITIL concept of the SDP.

Agile test planning and development can also be integrated into service design. Agile encourages the development team to create quick unit test plans as code is being developed. As part of service design, the Agile development team can specify input to the testing strategy—as well as component and integration test plans—that become part of the SDP.

Service Transition: Integrating Agile and Supportability into ITIL

Service transition is the stage that is responsible for transitioning a new/changed service into the live environment. This includes not only building and deploying the app but also building, testing, and deploying all aspects of the service: the supporting services, the user training, the monitoring systems, and last but not least, the preparation of service desk support capabilities.

Change management is critical at this stage, as it functions as the control process within the ITIL framework, controlling all changes, especially those that are about to go live. Change management is often perceived by development as a barrier to the rapid and frequent deployment of value-added functionality. Can change management work with an Agile approach? Yes! By integrating Agile and ITIL role assignments, Agile roles and responsibilities can be shared by those carrying out vital ITIL roles and responsibilities, thus facilitating collaboration between Agile and ITIL processes, especially around change management.

Agile roles include the product owner (the voice of the customer), the scrum master (the facilitator), and the scrum team (the developers). The ITIL roles relevant to new/changed services include the service owner (responsible for the quality of the service), the change manager (responsible for managing, approving or rejecting changes), the change advisory board (responsible for reporting to the change manager), and the CSI manager (responsible for managing continual improvement).

Integrate Agile and ITIL roles where it makes sense. For example, make the ITIL service owner and the scrum product owner the same person. This makes perfect sense, since both roles should be listening to the “voice of the customer” and should be keenly focused on requirements (the overall service requirements and the application requirements as a subset of that). Integrate the scrum master and the service/product owner into the change advisory board (CAB) that advises the change manager on whether to approve the service update that may result from the release of an Agile development sprint. Finally, integrate the scrum master role with that of the CSI manager, as both roles need to make decisions about the fitness and supportability of the service and the app. The ability to continuously learn and improve the development process is a core Agile value and part of the scrum master’s responsibility. Since continual improvement throughout the lifecycle—all stages, processes, services, and supporting technologies—is the business of the CSI manager, it makes sense to combine these two roles.

Optimized support for mobile platforms, the adoption of Agile development methods, and effective use of ITSM and the ITIL framework can all coexist.

To support frequent releases more effectively, drive authority and responsibility for review, approval, and implementation downward through an increased level of standard changes (preapproved, low-risk, repetitive changes in release content). The high-level strategy should be to migrate to more standard changes (that require only operational level approval), and fewer normal changes (that require CAB approval). The Agile approach focuses on developing, testing, and release of small chunks of releases, presumably with limited risk, testing, and validation requirements. In the cases where an Agile release meets standard change criteria, employ the use of change models to make these sorts of releases routine, standard changes. Next, as much as possible, employ automated functionality testing, performance testing, and regression testing, to validate the new/changes service functionality. The service transition test team can employ the application development test cases devised during service design as an input to an automated testing process carried out during service transition.

An Integrated Approach Is the Key

Optimized support for mobile platforms, the adoption of Agile development methods, and effective use of ITSM and the ITIL framework can all coexist. In fact, there’s no good reason why we shouldn’t integrate the design for mobile support, Agile, and ITIL.

• ITIL should serve as the overall service management framework within which we operate.
• Agile development methodology can and should be well integrated into ITIL, and specifically into the service design and service transition stages of ITIL.
• Support for frequent app updates, and mobile platforms, should be well integrated into our service lifecycle approach.

The first step is to adopt and implement ITIL as fundamental guidance for IT best practices. There’s no question that apps are here to stay. And it’s clear that we must design, deliver, and support solutions for the mobile business environment. But that doesn’t mean we take short cuts: we must consider the needs of all stakeholders; we must realize that value is a product of both functionality (utility), and performance (warranty levels); and we must acknowledge that what customers want is a service that enables their business and daily work.

Second, apply a revised and integrated approach to service design, service transition, and service operation. Service design teams should work closely with development teams to leverage and integrate Agile methods and teams into the service design stage. Optimize service transition to handle planning and transitioning smaller, more frequent releases; leverage Agile methods and automated testing to validate functionality and performance; empower change management to perform its controlling function, protecting the live environment while allowing for more frequent changes; and integrate service operation teams more fully integrated into both service design and service transition activities, allowing them to provide critical input on how to best support mobile devices in the new app economy.

With ITIL as the overall service management framework, Agile for rapid development and deployment, and the integration of support teams early in the service lifecycle, IT service providers can position themselves to successfully plan, transition, and deliver more frequent service updates into the live environment, as well as ensure quality and value is delivered in this new mobile and rapidly changing economy.

Paul Dooley is the principal consultant for Optimal Connections, LLC, as well as an ITIL Service Manager, ITIL Expert, HDI Faculty member, and HDI Certified Auditor. Follow him on Twitter and connect with him on LinkedIn .

Reviewer and contributor Shafique Hassan is a cloud architect at VMware. His specialties include IaaS, cloud infrastructure design and administration, application virtualization, workload/data center consolidation, ITIL, service and service catalog design. He is also a Certified Scrum Product Owner and Certified Scrum Master.