devopsy.kinsta.cloud

Tag: ITSM

  • Enterprise Service Management with Jira Service Desk and Confluence

    Enterprise Service Management with Jira Service Desk and Confluence

    Companies are looking to reduce cost, create efficiency and improve productivity of all internal and external customer services. In many organizations, different departments are using individual tools to provide their customers with the services they need. They can work in silos, can provide inadequate quality of service and not to mention that the portfolio of different tools can be quite costly.

    Enterprise Services Management (ESM) is a popular approach to implementing services within the organization. Departments such as human resources (HR), operations and marketing are seeing the value of Information Technology Service Management (ITSM) processes, and companies are looking to repeat that same value across the business. ESM allows all departments in the organization the opportunity to standardize tools and processes across all of their services departments. This standardization of tools and processes can create transparency, can improve the customer experience and in the end can reduce overall cost.

    There are quite few tools that can be used to support the implementation of ESM. Two components of an effective ESM implementation include a shared service desk and a knowledge base. 

    The shared service desk encourages the standardization of tools, and even paves the way for the alignment of processes. Departments should find tools that can be scaled up from just ITSM to support requirements across different service departments. There are quite a few applications available to companies for a shared service desk.

    In order to promote adoption, organizations must consider the ease of usability for both customers and customer service providers. Atlassian has two applications, Jira Service Desk (JSD) and Confluence, that together provide companies their shared service desk and knowledge base components of their ESM solution.

    JSD can be used as the foundation of an organization’s ESM implementation. Having JSD as the standardized service desk provides customers with a single customizable portal for all requests across the business. Unlike Jira Software and Jira Core, JSD licensed users are called agents. Companies only pay for agent licenses and do not pay for their customers.

    Below are just some of the features that are available with JSD:

    • A portal that can organize request types for customers. This provides them one place to submit all of their requests across the business.
    • Customizable workflows that include features such as custom statuses, conditions and post-functions.
    • Queues that provide the ability for agents to monitor and manage requests.
    • Service Level Agreements (SLAs) that help set time frames for agents to complete a certain step such as responding to the customer and even resolving the request.
    • The ability to automate certain workflow steps.
    • A plethora of built-in reports, to include one that shows overall customer feedback satisfaction.

    The next component is a knowledge-base. Why is a knowledge base valuable to both customers and agents? Confluence is a wiki that helps teams organize and share information. A well configured knowledge base can empower the customer to answer the questions they have without submitting a request. This can reduce the time agents spend on common requests. 

    Confluence has the ability to create a knowledge base, and seamlessly integrate it with JSD. Confluence is organized by pages, which are structured in a series of parent-child relationships—in the end form it’s called a page tree. To add/edit articles in the knowledge base, the person will require a Confluence user license. However, any customer can read the articles in a knowledge base without a license.

    Below are just a few of the available features with a Confluence knowledge base:

    • Built-in templates for how-to and troubleshooting articles.
    • Page labels that help serve as keywords for customers and service desk agents when searching for knowledge base articles.

    Below is a process flow for customers submitting a request in a typical ESM implementation using JSD and Confluence:

    1. User launches portal in web browser.
    2. In the portal, if a knowledge base is configured, the user can start typing keywords to search for articles that answer their question.
    3. If the user does not find the answer to their question in the knowledge base, they can navigate within the portal to the request type they wish to submit. The request types can be grouped by department.
    4. User completes the request form. Fields can be custom or out of the box. They can also be required or optional.
    5. Form is submitted and it creates an issue in JSD. 
    6. The issue is added to one or more agent queues. Agents can also receive notifications in email, and third party applications such as Slack, Opsgenie or PagerDuty.
    7. Agent communicates with the customer via comments in the Jira issue, and the customer communicates with agents via the customer request interface.
    8. Agent works on request in until its resolution.

    In summary, ESM is continuing to improve value in organizations for many reasons. One part of a successful implementation of ESM is which tools are selected for customers and customer service providers.

    — Evan Golden

  • SRE Is the Most Innovative Approach to ITSM Since ITIL

    SRE Is the Most Innovative Approach to ITSM Since ITIL

    For over a decade, ITIL has been the leading ITSM framework adopted by enterprises across the globe. So, what is driving a rapidly increasing interest in Site Reliability Engineering (SRE) as a service management alternative?

    In its own words, Google refers to SRE as its approach to service management: “The SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response and capacity planning.”

    In traditional ITSM terms, the role of the SRE is responsible for service level, change, availability, event, incident, problem, capacity, performance, infrastructure and platform management. While the operational practice areas may be similar, there are significant differences in how the practices are approached.

    ITIL4 Framework Compared to SRE

    Released in 2019, the newest update to ITIL4 remains a complex governance model with four dimensions, seven guiding principles, a Service Value System and 34 processes (now renamed as practices). While ITIL4 pays homage to Agile and DevOps, there is little depth in the publications released to date—to be fair, several other publications in the series are in queue  for gradual release. The framework spans just about every aspect of software delivery and operations and seemingly is trying to be the single source of truth in both principle and practice for IT management.

    SRE Is More Closely Aligned to Agile and DevOps

    By comparison, SRE focuses specifically on the reliability and resilience of complex production system operations. As an engineering discipline, SRE more closely aligns with the Agile and DevOps patterns that are being adopted by product development teams including continuous integration, testing, delivery and deployment. SREs bring the wisdom of production into the teams thereby breaking down many of the silo walls that have impeded IT for so long.

    As a service management alternative, SRE also updates traditional ITSM activities with innovative and self-organizing concepts such as management to service level objectives, error budgets, toil reduction, release engineering, monitoring/observability and embracing risk as neutral approaches to service management. The core SRE book provides practical and actionable guidance for Site Reliability Engineers on managing incidents, learning from failure, testing for reliability, load balancing, handling different types of emergencies, software engineering and capacity planning. Related publications such as the Site Reliability Engineering Workbook and Seeking SRE provide additional insight.

    Most importantly, a Site Reliability Engineer is an actual hireable job with a defined role, set of responsibilities and skills. SREs and SRE teams are encouraged to be creative, accountable and must spend 50% of their time reducing toil by engineering automation in order to make tomorrow better than today. Like Agile and DevOps, SRE supports self-regulation with policies and consequences. In fact, some consider SRE to be the third piece of the Develop (Agile), Deploy (DevOps), Operate (SRE) feedback loop.

    What This Means for the “Humans of DevOps” in Operations and ITSM

    SRE is breathing new life and opening new career paths for operations and ITSM professionals who a few years ago were battling against the mantra of “NoOps.” According to Linkedin’s 2020 Emerging Jobs Report, SRE is the fifth fastest-growing job role with 34% growth.

    Services will always need to be managed. However, competing in a digital age requires new ways of working and thinking with speed and quality as key metrics. Agility must be instilled across the value stream spectrum in order to increase flow and deliver an exemplary customer experience. Your organization may not be as complex as Google’s, but the principles and practices of SRE are applicable to all environments.

    You can read the Site Reliability Engineering and Site Reliability Engineering Workbook publications for free from Google. For those wanting to learn more about the practices and patterns associated with SRE, DevOps Institute recently released its Site Reliability Foundation certification with accredited training being offered globally by its Global Registered Education Partner network. Either way, if you are an operations or ITSM professional, I would highly recommend learning more about SRE. It is the future of ITSM as we cross the digital divide.

    — Jayne Groll

  • DevOps Versus ITIL: How to Win the Battle Over Change Management

    DevOps Versus ITIL: How to Win the Battle Over Change Management

    Ever since DevOps came on the scene a decade ago, ITIL has been under siege.

    ITIL lays out a number of IT service management (ITSM) best practices, including release management, change management, incident management, problem management and many other aspects of running an IT shop so that its priorities align with the business’s. For many enterprises, ITIL is essential for governance and regulatory compliance–especially in heavily regulated industries.

    The basic idea of DevOps is that by leveraging better automation technology across the software lifecycle, it’s possible to rework the culture and organization of all the teams involved in software production and deployment. By breaking down the numerous silos and fostering greater collaboration, it should be possible to dramatically accelerate the ability to deploy quality software at scale.

    From the DevOps perspective, ITIL is nothing but a set of speed bumps and roadblocks, getting in the way of its continuous integration/continuous delivery (CI/CD) priorities.

    DevOps wants to speed up software release cycles, while change management often slows them down. Does this dichotomy mean that enterprises have to choose one or the other? Or perhaps we have to water down one of these approaches sufficiently so it’s marginally compatible with the other one?

    Is ITIL Part of the Problem?

    ITIL skeptics abound. “Frameworks like ITIL create the illusion of control that results in [the] organizational delusion that IT is efficient and manageable,” said Greg Ferro, long-time consultant and co-founder at Packet Pushers Interactive. “The single biggest problem in ITIL [is that] the creation of silos creates ‘not my problem’ attitudes.”

    One such silo is the change advisory board (CAB), a team that has the responsibility for making thumbs-up or thumbs-down decisions on numerous different activities across the IT organization. “Having the CAB review every single change request isn’t efficient,” said Kaimar Karu, head of ITSM at AXELOS, “and it’s definitely not common sense, especially when their costs can run to tens of thousands of deployments per hour in some organizations.”

    One organization that has struggled to transform their ITIL process as it moved to a DevOps model is financial services firm ING. In fact, its CABs were a point of contention for it. “We were just like an insurance company, always rejecting your first claim,” said Mark Heistek, IT specialist at ING. “And then come back if you have good arguments.”

    ING found it was able to modify ITIL to work within its new DevOps approach. “Don’t do everything the ITIL book says,” advised Jan-Joost Bouwman, ITSM process owner at ING. And yet, following ITIL for practices such as incident management are “still the best way to do it, because everybody knows what to do and you don’t get confused about the rules.”

    Or Is ITIL Part of the Solution?

    In spite of the skepticism, there are plenty of proponents of using ITIL with DevOps. “The DevOps Movement fits perfectly with ITSM,” according to Gene Kim, DevOps thought leader, author of The Unicorn Project and coauthor of The Phoenix Project. “ITIL and ITSM still are best codifications of the business processes that underpin IT operations, and actually describe many of the capabilities needed into order for IT operations to support a DevOps-style work stream.”

    Kim, however, focuses more on human capabilities than on the ITIL processes and procedures themselves. “ITSM practitioners are uniquely equipped to help in DevOps initiatives, and create value for the business,” said Kim. “ITSM skill sets are ever more important in a world where there is an ever-quickening business tempo.”

    Phil Tee, CEO and co-founder of Moogsoft, agrees with Kim–and also echoes the experience of Heistek and Bouwman at ING. “ITIL is not in conflict with DevOps,” said Tee, “but it must be adapted to DevOps practices in order to define clearly where issues arise and how to solve problems efficiently.”

    Adapting ITIL to work within the context of DevOps–without slowing it down–has become the crux of the discussion. “ITIL is not explicitly opposed to Agile and DevOps,” explained Charles Betz, principal analyst at Forrester Research. And yet, he found that “the overall ITIL narrative is still sequential, plan-centric and deterministic.”

    Rock and a Hard Place

    Part of the DevOps way of thinking is to reevaluate how the organization makes the decision to deploy software into production. “By combining developers and operations into smaller, more agile DevOps teams, organizations can build software more quickly than ever, enabling them to respond faster to changes in the market,” said RJ Jainendra, general manager and vice president, IT business management and DevOps business unit at ServiceNow. “But, that’s a difficult challenge for larger companies, however, that haven’t been able to realize the full benefits of DevOps for a variety of reasons, including the complexity of manual processes they manage, and a shortage of DevOps expertise.” 

    There are many business contexts where internal process or regulatory compliance concerns are the issue, introducing requirements beyond what current DevOps approaches can satisfy.

    Jumping to the opposite extreme and requiring rigid change management procedures, however, can easily be overkill. After all, even for the most heavily regulated, quality-conscious enterprise, some of the changes they put into production don’t have the same stringent requirements as the rest. Not all software changes carry the same level of risk.

    The challenge, therefore, is telling the difference–and putting into place proactive, automated ways of handling different change scenarios that are subject to different levels of rigor.

    Judicious Use of Automation

    In spite of what many DevOps zealots may say, the approach is inherently flexible and human-driven. People still create software, after all–and DevOps is more about encouraging new ways for people to cooperate to achieve a common goal than it is about offloading human tasks to automated processes.

    As a result, DevOps is not nearly as black and white as those zealots might have you believe. For example, the “continuous” in CI/CD doesn’t mean “all the time” or even “as fast as possible.” In practice, continuous means “as fast as practical given the particular business requirements that apply in this situation.”

    Sure, Amazon may deploy several times a minute and be able to easily integrate compliance and governance into their technologies, but that doesn’t mean you can, or even that you must. After all, enterprises have a very different business and technology context from web-scale, born in the cloud companies such as Amazon.

    You may simply have different requirements–and even more importantly, different software will likely have different deployment cadences, even within the same organization.

    These principles of flexibility and human-centeredness apply beyond deployment to all aspects of change–and thus, they apply to the change management and release management practices of ITIL more broadly. 

    Sometimes you need a CAB, and sometimes you don’t. Sometimes you need to change windows, and sometimes you don’t. Sometimes fully automated quality checks are sufficient for giving the green light for deployment, and sometimes they’re not–and so on.

    And perhaps most importantly, sometimes humans should make approval decisions, and sometimes those decisions should be automated. 

    The more you can automate these approvals, the faster your deployment will be. But if you are able to identify those changes that require human approval and route those accordingly, then you’ll have optimized how you handle change in a way that pulls together DevOps and ITIL practices.

    Bringing ITIL and DevOps Together in Practice

    Traditionally, ITSM products are ticketing systems. When some incident occurs or someone calls for a change, they must create a ticket that then kicks off a set of manual tasks, often by different people.

    DevOps can bring automation to this traditional ITSM context. “One of the modern miracles of DevOps principles and practices is that many parts of ITIL processes can now be automated, solving significant challenges, especially in the configuration, release and deployment management processes,” Kim explained.

    Such manual workflows are typically well-suited to supporting ITIL practices, but fall short of the speed that DevOps requires. “ServiceNow DevOps leverages the data and metadata it already has on its platform, combined with new information from the DevOps pipeline to create, automate, and manage ITSM changes from within DevOps workflows on an enterprise-wide scale,” said Jainendra.

    In fact, ServiceNow can oversee the full automation of the deployment, integrating with other DevOps tools as necessary to effect the change, eliminating the need for any additional action from a developer. On the flip side, when the policies in place require a human approval of a change, then ServiceNow routes the change to the appropriate person. 

    The Intellyx Take

    Automation, for all its benefits, has never been about taking humans out of the decision-making loop. On the contrary, automation takes low-value tasks off of people’s plates, allowing them to spend more time and effort on more valuable activities. Decision-making is often among those high-value activities.

    That being said, automation is getting better at making decisions, both because of the breadth of machine-understandable policy representations and other configuration metadata, as well as the increasing prevalence and sophistication of machine learning.

    For DevOps professionals, it’s essential to understand this increasing level of sophistication for the automation available in today’s tools. The choice between automated or manual is no longer a black-and-white affair. Instead, there are different levels of capability for automated decision-making depending upon the situation at hand.

    — Jason Bloomberg

  • Crossing the Ecosystem Boundaries: How ServiceNow, Salesforce and Atlassian Work Together

    Crossing the Ecosystem Boundaries: How ServiceNow, Salesforce and Atlassian Work Together

    Although these platforms were originally designed to serve different functional roles—Atlassian’s help desk, ServiceNow’s IT service management and Salesforces’ sales and CRM—from the outset, they all addressed the evolving mega-management and leadership issue: collaboration across teams and business units.

    Independent action, siloed organizations and disconnected thinking was increasingly giving way to more agile, interdependent, collaborative problem-solving practices and methodologies. Whether the differences were political, cultural, intellectual or institutional, survival became progressively dependent on living, working and communicating more effectively across all boarders. It was in our individual and collective, both internally and externally, best interest to do so.

    Effective companies and the platforms that served them needed to promote a culture that collaborated with less friction across five boundary types (“CCL’s” Center for Creative Leadership’s Boundary-Spanning Leadership)

    • Horizontal: Expertise, function, peers.
    • Vertical: Rank, class, seniority, authority, power.
    • Stakeholder: Partners, constituencies, value chain, communities.
    • Demographic: Gender, generation, nationality, culture, personality, ideology.
    • Geographic: Location, region, markets, distance.

    Collaboration initiatives generally begin by focusing on existing boundaries within a specific business unit or team. Then they expand to forge common ground on specific projects across teams, and finally, moved across all five boundary types with multiple teams and interdependent projects which some refer to as complex adaptive systems. These platforms were launched, quickly developed and continue to evolve to meet this collaboration challenge head on.

    Making Sense of the Blurring Boundaries Across Convergent Platform Roadmaps

    Boundaries are difficult to identify when they are continuously moving and being redefined. Instead of taking a more traditional route of seizing mind and market share by differentiating and establishing/defending clear boundaries, these platforms are doing the opposite, they are converging. The ecosystems that support each platform are also beginning to look increasingly similar—but more on this in a future post.

    The convergence of frameworks such as ITSM and Agile represents a tangential and interconnected set of moving boundaries intersecting somewhere along the spectrum at ITIL—ITIL4 if you’re counting. As all three platforms seek broader market penetration reflecting this full spectrum of frameworks, consider using the ITIL4 Edition’s 17 service management practices as a cheat-sheet for their boundary spanning enterprise roadmaps:

    • Business analysis.
    • Service catalog management.
    • Service design.
    • Service level management.
    • Availability management.
    • Capacity and performance management.
    • Service continuity management.
    • Monitoring and event management.
    • Service desk.
    • Incident management.
    • Service request management–includes both request fulfillment and access management of ITIL V3.
    • Problem management.
    • Release management–includes an explanation about releases in waterfall driven environments and DevOps driven organizations.
    • Change control–formerly known as change management.
    • Service validation and testing.
    • Service configuration management.
    • IT asset management.

    As organizations prioritize and re-prioritize the list reflecting their Agile/ITSM journey, the boundaries between platforms will move, and in many cases, simply disappear. As this journey plays out in your company, the platforms and ecosystems that support each will need be rationalized. Said differently, you may be asked or told to choose one, but as our experience suggests, you won’t need to do that today.

    Instead of diving into the technical features and benefits of each platform and ecosystem, take some time to reflect the benefits of expanding your boundaries to address the business challenges you are facing now and expect over the next 18 months.

    Where does this leave you and your team today?

    While everything else gets worked out….

    • Review the ITIL4 Edition’s 17 service management practices and rank prioritize for your team and company.
    • Do a self-assessment on your personal commitment to, and comfort with, the benefits of expanding your boundaries.
    • Meet with your team and have each of the individuals do the same.
    • Encourage conversations about where the platforms appear to be focusing (e.g., Atlassian focusing more on ITSM and ServiceNow paying more lip service to Agile).
    • When the time comes to make recommendations on app consolidation or choosing one platform over another, your team will be well prepared to do so with open, informed and agile minds.

    One last note on the benefits of expanding boundaries: Leaders who effectively reach beyond their present boundaries have the advantage when faced with solving problems, creating innovative solutions and evolving to thrive in today’s interdependent, complex world. The benefits of boundary spanning leadership include:

    • Increased organizational agility to respond to a dynamic marketplace.
    • Advanced cross-organizational innovation processes.
    • Achievement of mission-critical, bottom-line results:
      • An engaged and empowered workplace at all levels.
      • Flexible, cross-functional learning capabilities to solve problems and adapt to change.
      • Better-managed risks and rewards through enduring cross-sector partnerships.
      • Higher-performing virtual teams.
      • Global mindsets and cross-regional collaboration.

    Use these bullets to get your team spanning conversation started.

    — Joshua Platt

  • Accelerating Software Delivery Doesn’t Mean Compromising on Quality

    Accelerating Software Delivery Doesn’t Mean Compromising on Quality

    Whenever we’re pushed for time and forced to rush, we know we’re entering an unspoken deal with the devil. Whether it’s cooking the family a last-minute dinner, ironing a shirt before a wedding or writing against a strict deadline, we’re acutely aware it’s highly unlikely the output will be a fair reflection of our best efforts.

    Seldom does “hurry” equal “success”; mistakes will inevitably happen–that’s all part of the age-old mission to maintain the equilibrium between speed and quality. But what happens if the work, such as enterprise software delivery, is perpetual by its very nature and the only goal is to deliver a continuously improving experience to discerning end-users? How can such a compromise exist in such a fast-paced environment?

    It’s a challenge, that’s for sure–especially for software delivery teams at traditional large organizations. Unlike tech giants and other digital natives that were conceived around the very idea of a business model driven by incredible digital experiences, mature enterprises–your banks, insurance companies, retailers and so on–are learning on the fly, and serve and support vast product portfolios from across the business.

    That doesn’t mean they can’t compete–far from it. They just need to rethink how product-related work flows across their value streams to better empower their talented test and quality assurance teams who, with the right information available in real-time, are able to ensure customers are regularly receiving high-quality products in a timely manner.

    Trust in Your Test and QA Teams

    In most instances, enterprises can dramatically enhance the quality and speed of their software delivery without heavily investing even more resources into their test/QA organizations. Their testing and QA teams can create order out of chaos, and are in a unique position to understand and assess the health of the product’s development and delivery to answer questions such as:

    • Are all the requirements fulfilled?
    • Are their implementations defect free?
    • Are the known defects tolerable if they’re deployed into production?

     In many organizations, it’s up to the testing team to declare whether a product is ready, or if they must stop-ship. To effectively handle this responsibility, the testing team must have access to the right information at all times. It was once hoped that test management tools could be the single source of truth (at least when it came to managing defects).

    Such a dream turned out to be dead in the water because all other specialists across the software delivery value stream use their own best-of-breed tools to create and manage their work (represented as artifacts such as requirements, features, epics, stories and so on).

    And because these specialized tools do not naturally integrate and automatically flow information, testers (and QA teams) end up on time-consuming scavenger hunts to find the most current information—which dramatically undermines their ability to quickly and accurately determine the health of any product. It’s a vicious cycle.

    There’s More to Product Development than Defects

    Each specialist in the software delivery process has their own point of view on the shared artifacts. Testers need access to requirements to create tests. But the business analysts, product managers and product owners that write the requirements do not use the test management system, preferring their own purpose-built tools for developing requirements and user stories.

    Similarly, project managers use PPM tools, while IT support uses ITSM tools. And so on for each discipline across the key stages of the value stream from ideate and create to release and operation. While each of these disciplines are linked together by their desire to create and deploy the highest quality product possible, their ability to work together is hampered by the fact that their tools do not work together. And when these teams don’t work well together, it’s end users and the business that suffer.

    Knowledge-Sharing Across the Value Stream

    Getting these tools to work together can be accomplished in several ways:

    1. A Manual Process: such as logging into another team’s tool, emailing a colleague for the information or consulting a spreadsheet.
    2. Batch Data Transfer: exporting defects and requirements from one system and bulk importing them into another. Of course, artifacts loaded this way have only static information; they are not continually updated with the most current status.
    3. Automated Integration Across Toolchain: If these systems are integrated and the information in them is continuously synchronized, everyone has access to the most up-to-date information in real-time. Practitioners can even collaborate with one another via this information, all while remaining in their tool of choice.

    The third way is the only way to obtain the end-to-end visibility and traceability that is required for the vital one source of truth into the health of your software products. Only then can you access a single collection of consolidated data to analyze and optimize the quality of the software delivery process.

    By connecting these tools and synchronizing all product-critical data across the value stream, the QA process is strengthened and streamlined. For instance, when a tester creates a defect in a QA tool, it’s automatically updated in the PPM tool and the Agile Planning tool. The same is true for user stories, requirements and test plans—a free-flowing, always up-to-date stream of information that makes or breaks the speed and quality of a product’s development.

    A Single Well-Oiled Machine for Quality Control 

    True value stream integration doesn’t just enhance alignment between testers, developers and business analysts, it empowers all specialists involved in planning, building and delivering a software product. Business analysts, product managers, product owners, developers, architects, testers, system administrators, project managers, scrum masters and help desk professionals are operating within a single unified system by sharing and collaborating on the same information.

    With the test management system synchronized to other systems, the testing team gains a centralized view on a product’s health.

    Testers

    • Have access to product information in their test management system.
    • Have access to the most up-to-date information, eliminating costly rework due to inaccurate information.
    • Can collaborate on artifacts by updating and augmenting them in their tool, knowing their updates will be automatically reflected in all other systems syncing that artifact.
    • Can better leverage the features in their tools when those features rely on artifacts created by other teams—such as automatically creating tests from requirements.

    Testing Teams and Managers

    •  Gain better visibility into their products by receiving reports that pull data from multiple systems, rather than having a siloed view of their product data.
    • Get more collaborative, efficient teams. Practitioners no longer use ineffective email threads to communicate, they collaborate on common artifacts in their tool of choice.
    • Achieve a strong return on investment—each practitioner can save 20 minutes each day by automating manual processes, which can add up to millions a year in productivity savings and avoiding wasting precious human intellect.

    Moreover, with a fully integrated value stream, the QA and testing teams can institute standardized processes and tools, without being undermined by the tools and processes of other organizations. The centralized test management system can become the single pane of glass into a product’s development, providing test managers and executives with the insight into the chaos, allowing them more control and better decision-making. And, crucially, ensuring products are not only delivered on time but that they’re also continuously delivering delightful end-user experiences. No more deals with the devil, just the benefits of knowing the devil in the details.

    — Jeff McCollum

  • Radical Transparency in DevOps and ITSM Helps Achieve Excellent Customer Experience

    Radical Transparency in DevOps and ITSM Helps Achieve Excellent Customer Experience

    Here’s what I’ve noticed after spending several years in service management: DevOps is coming up more in the conversations I’m having with service desk leaders. Usually, these conversations start with one of the similar questions: DevOps is going to be the death of ITSM, correct? Alternatively, some consider DevOps as a challenge, and ITSM doesn’t seem so relevant because you don’t have in-house development going on.

    I always answer these questions in the same way: ITSM is relevant, and DevOps is not a threat to it. There’s more to it, however. ITSM professionals can still achieve their most relevant goal–excellent customer service.

    If you allow me a moment, I’d like to offer some background as to why excellent customer service is essential for every ITSM professional, then walk through some of the ideologies or frameworks used and how they interact. I’ll close this piece by discussing what radical transparency means in practice and how it can help you achieve an excellent customer experience.

    Some Background

    When discussing DevOps, we usually see three parts: Development, operations and the actual business. The business demands different things from both development and operations. Development teams are asked to push out code as fast as they can, and operations teams must keep the existing services available and make sure everything is stable. Development is trying to fulfill as many business needs as fast as they can, while the operations team is accountable if things go wrong.

    These might be extremes, but these are the traditional silos that have their expertise, priorities and goals, but there is no holistic overview. These internal organizations also use their way of working, based on a framework or ideology: DevOps tends to use agile, the business uses lean and ops focuses on ITIL. These ideologies can clash and compete at times.

    Because so much is happening with DevOps, we see significant developments. The speed of development and deployment is increasing, leading to additional continuous delivery advancements and technology implementations. The collaboration and breaking through walls between the development team and the operations team for deployment has come a long way within many organizations.

    Meanwhile, ITSM professionals face more and more challenges. Apart from the existing incident handling, they encounter incidents about newer, faster releases. Also, how are they supposed to deal with knowledge management, an already complicated process in itself? The increased speed of development makes it look as if they are always running behind. Getting out of that reactive approach is not getting easier.

    Customer experience and satisfaction is the number one priority in ITSM, creating quite the challenge. In ITSM, all input comes in: If things do not work at all or break down; if things do not work as expected; and if users need help to get things working. Good feedback also usually comes in via the service desk. When examining customer experience, there is a thin line in how fast you can go: If functionality is delivered too quickly, customers will not be able to use it. When delivered too slowly, customers will be unhappy about it as well.

    You can argue that a new silo comes into the picture–namely support. The support team keeps things up and running. Likewise, there are communication links between the customers and the other silos where they can filter bugs to development, info on any outages to operations and feedback on how the customer perceives the value of the functionalities to business.

    What if you don’t have in-house development? Well then, DevOps and the link with ITSM can be even more challenging, meaning you only have part of your DevOps and some of your support outsourced. For one application, perhaps you are relying on one or multiple vendors, but it might be the case that your vendor is dependent on another vendor.

    In other words, the process looks more like a plate of spaghetti than a smoothly laid smooth IT process. There are significant benefits to outsourcing, which is why we keep using outside vendors for some of our operations. In these cases, consider the shift of responsibility, the extra expertise, stability and continuity you gain. However, there are also downsides, such as loss of transparency.

    A Shift in Responsibility

    Shifting responsibility does not mean the same as a shift of accountability. Your ITSM team will still have to take ownership because even if you are not controlling everything. You have to be in control. In the end, you are still responsible for your customer experience and happiness. Customers do not want to wait two years for new features because the update of the vendor cannot take place for whatever reason. Also, it would be best if you had insight into what is going to happen for your users, and you need extra insight regarding how everything is working.

    Silos make this a challenge without outsourcing and are even more so the case when outsourcing these responsibilities. Before we move forward with solutions, let’s first take a step back and look at the frameworks and ideologies the different silos are using. As discussed, first, we have ITIL, typically used in operations.

    “ITIL is the most widely accepted approach to IT service management in the world. ITIL can help individuals and organizations use IT to realize business change, transformation, and growth,” stated Axelos on their website. It’s about aligning services to the needs of the business and supporting its processes.

    Next, we have lean, which is about maximizing customer value and minimizing waste. Lean is where value stream mapping comes in. You identify what works then look at how you can improve flow. Finally, agile, the cultural aspect of DevOps.

    At first sight, each of these processes seems contradictory, but actually, this is not the case. The key is using each of these principles correctly. For example, consider CAB, which comes out of ITIL. In many cases, the A in the acronym stands for “authorization” instead of “advisory.” Knowing that might make things much better and can open up the possibilities of automation, which is crucial to improving things.

    Likewise, some people tend to say that agile can never work in an ITSM context because it is against processes, but that’s also not true. Agile speaks to individuals and interactions over processes and tools, not without appropriate processes and tools. However, if you take a step back, you see they have more in common than you might think and some changes coming to ITIL4, for example, already address how to achieve a better correlation between the three.

    Let’s look at all of them together. Usually depicted as a horizontal value stream, but looking at it as a continuous loop, makes things a lot clearer for me.

    When you start in the business with the idea, take it through the design, code, build and test phase, then move over to the release and deploy and then we get into ITSM territory with the support and monitor stages. Where you see the blue line is where DevOps focuses mostly, so this is also where you witness the creation of a new silo: support (where ideologies or frameworks come in the picture).

    Radical Transparency

    So how do we break through these silos? Radical transparency. First of all, silos have to share their common purpose, which in the end is excellent customer experience. You can change it however you want; but in essence, that is what the business, development, operations and support all strive.

    To accomplish this, we first must know what impacts the customer experience.

    Let’s break it down: There are visible and invisible effects for the customer that can either be positive or negative. Visible results on the positive side will be features; on the negative side, defects. On the invisible side, positive things include architecture and process improvements. On the negative side, technical debt.

    For excellent customer experiences, we need to focus on the visible effects. Invisible effects must be worked on, too; if completely neglected, these will become visible at some point. The most prominent and the first focus should be on the visible effect. To do that, we need insight. If we all have the same set of information, often we all come to the same result. Getting to that same set of information requires radical transparency and also sharing information and insights.

    Shared Workload Tooling

    First disclaimer: When I talk about sharing tooling that does not necessarily mean using one tool. I will specify. I mentioned before that ITSM professionals have to know what is going to happen that might affect the customer experience. They have to be aware of which new versions are coming out and which customers are going to be or are on that version. For that reason, you need to share relevant information from your release orchestration tool to your ITSM tool. For instance, in our service management tool, we can see who is on which version via an automatic integration.

    That is a flow from DevOps through ITSM. The return flow also is essential. Any feedback that comes through your ITSM process regarding bugs has to flow back as well. So, for that, you need an integration between your ITSM and bug tracking tools. I also have seen some examples within the ITSM process where a Kanban board is used to improve collaboration between development, operations and support.

    Just making visible those tasks that impact customer experience and being able to follow up on the progress made by all stakeholders is so valuable. It also gives the support team the necessary insight to be able to communicate with the customer.

    If you are working with one or multiple vendors and dependencies there, you will want to include vendors in this as well. Moreover, that might mean you even have to tie in your and their ITSM tools.

    Another thing you want to share is customer satisfaction insights. First, measure satisfaction throughout the entire chain. That includes employee satisfaction, as well. We have seen the proof that employee satisfaction has a direct impact on customer satisfaction, so make sure you have all those data available and insightful.

    Knowledge Sharing

    Next up is sharing knowledge, which requires proper documentation. Think of federating knowledge into a knowledge base to make relevant information available to the right people. Make sure you have a good understanding of each other’s processes, and the impact they have on one another is essential. As an example, we had some challenges in collaboration with one of our hosting partners. When we sat down to discuss this with them, we found out some choices we had made in the deployment and support process, were not as reliable because we had assumed things about how the hardware had been set up and those assumptions were not correct.

    Excellent documentation and communication are key. If you have things outsourced, you want to make sure your vendor is the right partner, and you have a common understanding.

    Another important thing that should be shared is dashboards, where you can have a total overview of all parties involved and the impact they might have. You especially want to have visible what the effect is on the customer experience. It is valuable to have insight into all things that need your attention, but for your shared dashboard, focus on those things that are not going well and that have an impact on the customer experience.

    When you work with one or more suppliers, you want to make sure they are also using these dashboards and actively monitoring these. For you to be sure they use that, add that in your vendor selection criteria. The only way this works is if there is that radical transparency, where all parties involved have access to your vendors, development, operations, support, business and customers.

    Takeaways 

    Hopefully, because of this article, you’ve taken some additional perspective about where DevOps and ITSM come together, why the silos have to be broken down and how working with one or multiple vendors can be especially challenging. Also, hopefully, I’ve provided a bit of background on the various best practices, frameworks and ideologies most used and how they share commonalities. Radical transparency means breaking through the silos and how this can improve your customer experience.

    Finally, to sum it up:

    1. Make sure all parties have a common purpose and are doing everything to achieve that.
    2. Share relevant information. All words here are significant: share to achieve radical transparency, applicable because you don’t want to flood people with things that are not of use to them, and sharing too much may distract them too much. Provide just the relevant information so everyone can focus on the common purpose.
    3. If you do all that, you will produce better value for your customers, all for excellent customer experience.

    — Jeroen Boks

  • IT Operations: PagerDuty Unveils Hybrid ITSM Platform

    IT Operations: PagerDuty Unveils Hybrid ITSM Platform

    PagerDuty today unveiled a framework intended to make it possible for organizations to bridge multiple styles of IT service management (ITSM) methodologies for IT operations.

    Rachel Obstler, vice president of product for PagerDuty, said PagerDuty Solution for HybridOps provides a comprehensive incident management framework capable of spanning both ITIL and DevOps processes for IT operations.

    PagerDuty Solution for HybridOps combines existing and new product capabilities such as Event Intelligence and Modern Incident Response with machine learning algorithms and bi-directional integrations the company has developed between its incident management software and more than 300 third-party products.

    Those capabilities make it possible to facilitate real-time communications between platforms that tend to be favored by IT shops relying mainly on ITIL processes, such as ServiceNow, and DevOps teams that rely on Slack to communicate with one another, Obstler said.

    IT Operations: PagerDuty Unveils Hybrid ITSM Platform

    Rather than forcing an entire IT organization to transition to single framework for IT operations, PagerDuty Solution for HybridOps allows organizations to selectively apply each model where and when they best see fit, she said.

    The latest version of the ITIL framework goes a long way toward injecting some flexibility into what historically has been viewed as a rigid approach to managing IT. The ITIL framework is still a long way from being as agile as the various forms of DevOps that many organizations have adopted over the last several years to accelerate application development and deployment.

    Obstler said PagerDuty is moving to bridge that divide by leveraging machine learning algorithms to group all the various alerts generated by all the tools in an IT environment. That capability not only reduces the amount of alert fatigue any IT operations group is likely to suffer, but it also makes it easier to identify the root cause of any IT incident, she noted.

    One of the primary reasons DevOps has been adopted evenly in the enterprise is that IT operations teams are expected to be able to programmatically adapt IT infrastructure to meet the demands of developers. The number of IT operations that have those skills, however, is limited. In theory, IT operations teams without programming skills could rely on automated frameworks to achieve that goal. But that approach requires IT organizations to standardize on a single IT automation framework across compute, storage and networking services. The number of organizations that have been able to bridge all the islands of automation that have been adopted across all the services they deliver are few and far between. Put it altogether and it’s clear that both legacy and modern approaches to ITSM will need to coexist well through the next decade.

    In the meantime, IT leaders might want to consider that old proverb about leading a horse to water. IT leaders can issue all the mandates they want. But when it comes time to accomplish a task, most IT professionals are naturally going to fall back on what they know. The challenge is to create ways to wean the IT operations staff off those legacy processes in a way that doesn’t necessarily result in everything grinding to a halt because nobody knows how to fix an issue that simply wouldn’t otherwise wait.

    — Mike Vizard

  • When DevOps and ITSM Collide: Mistakes to Avoid

    When DevOps and ITSM Collide: Mistakes to Avoid

    In many ways the DevOps movement evolved as a reaction against the worst elements of IT service management (ITSM). IT leaders wanted to get from under the yoke of overly complex processes, bureaucracy and red tape to speed up software delivery, and to just get stuff done. Now that DevOps has kicked into full gear at so many organizations, the question remains: What do we do about ITSM?

    While the instinct in some may be to completely ditch ITSM or to just let the ITSM team operate in a separate orbit from DevOps practitioners, experts say that would be a big mistake.

    “DevOps aims to deliver high-quality software to the business faster and in shorter cycles,” explained Krishna Mohan Reddy, vice president and deputy global head of Cognitive Business Operations at Tata Consultancy Services. “However, it still does not eliminate the need for controls.”

    In many ways ITSM is the yin to DevOps’ yang—the two operating philosophies do offer contrasting viewpoints but when the operate in a single system they can be extremely complementary and synergistic.

    “Maintaining the proper balance between the ITSM and DevOps helps the organizations to scale and grow and become more organized,” said Sachin Agarwal, DevOps engineer and solution architect for Mantra Labs. Operating at DevOps speeds with ITSM frameworks in place keeps finger-pointing at a minimum and reduces the risks of failed deployments. “Both in harmony will increase the efficiency and reduce the blame-game within the organization.”

    As organizations try to figure out how to achieve that harmony, here are some pitfalls they should seek to avoid:

    Letting Each Tribe’s Preconceived Notions Hold Back Overall IT Progress

    It can be easy to get wrapped up into dogmatic fervor that your particular philosophy is the One True Path for IT success, but that really does nobody any favor. Organizations that want to pick up the best of both ITSM and DevOps need to encourage stakeholders to approach the table with an open mind.

    “You need to compromise. A lot of the new, young practitioners in DevOps and Agile will pretty much automatically discount opinions coming from people who have got ITIL certifications,” said Andi Mann, chief technology advocate for Splunk. “And vice versa—a lot of traditional operations and development teams will look at the people in DevOps and Agile and think they’re all cowboys. But they all have something to learn from each other.”

    For DevOps practitioners, it’s important to keep in mind that ITSM controls such as service requests, change management or structured management of incidents and problems don’t have to stop a team from delivering quality software at speed, said Troy Vetter, COO of Coda Global.

    “In fact, speed and quality are actually helped by being closely monitored. In IT, just like in science, if it isn’t seen, measured, and “reproducible, it doesn’t really count,” he noted. “So, ITSM is actually the perfect complement to DevOps because it aids in the visibility, measurement and reproducibility of key DevOps processes.”

    Failing to Address the Elephant in the Room: Change Management

    Analyst Roy Atkinson agrees that ITSM has a lot to bring to the table for DevOps workflows. ITSM’s rich history in thinking about and tracking operational best practices offers tons of value in improving the customer experience with the software being delivered. But on the flip side, ITSM teams can’t continue to operate as they did in the past. They need to compromise and learn new ways of accommodating DevOps approaches—particularly in the area of change management.

    “Change management has often been where DevOps and ITSM collide,” said Atkinson, who analyzes the service management market for HDI. “The stereotypical Change Advisory Board must radically revise its approach to be in sync with the enormous amount of change that DevOps can produce in a day.”

    The good news is that thought leaders in the ITSM world have been thinking hard about this issue and have been evolving practices so they can embed change management controls into a DevOps framework without holding back continuous delivery.

    “There is some excellent recent thinking in the ITSM world about how change management can serve its intended purpose without being a roadblock by acting as an enabler of change and being involved all along the way, rather than a bolt-on quality check at the end of the line before the production environment,” Atkinson said.

    Maintaining Separate Toolchains

    Often times one of the big reasons ITSM will remain a roadblock for DevOps isn’t because the ITSM folks aren’t willing to collaborate, but simply because each team relies on completely separate toolchains.

    “You might have a tool that developers use for tracking bugs or product backlog and then there’s a completely separate IT service management tool,” said Donna Knapp, curriculum development manager for ITSM Academy and author of the DevOps Institute’s course on ITSM for DevOps. “So what you end up doing is forcing developers to use some process that’s outside of their norm in order to address issues.”

    As Vetter explained, a lot of the knee-jerk DevOps reaction against ITSM has to do with an aversion to the historical view of ITSM requiring manual inputs in monolithic ticketing systems. But the technology of ITSM controls has advanced—it just needs to be appropriately implemented.

    “Self-service requests, automation flows and IT orchestration are now our front door to actions, and IT service management can and should be happening in the background, automagically created, maintained and measured by our DevOps tools,” he said.

    — Ericka Chickowski

  • Bridging the Gap Between ITSM and Software Engineering

    Bridging the Gap Between ITSM and Software Engineering

     

    Considering the individual roles of IT service management (ITSM) and software engineers, it seems obvious they should work closely together. ITSM tracks internal and external customer issues, and engineering fixes code-related issues (such as defects) that IT cannot fix on its own.

    However, more often than not, coordination between these two departments is poor, which—critically—undermines customer response times and damages application satisfaction. It’s important to remember that the quality of customer response isn’t just about speed, it’s about giving customers insight into the state of the issue.

    The disconnect between ITSM and engineers—caused by individual priorities and semantic differences—makes this real-time insight difficult. Both teams have individual and shared concerns, and separating these while simultaneously improving collaboration is a big challenge.

    Addressing this relationship is an important step in optimizing ITSM and DevOps integration, alongside focusing on IT help desk enhancement requests to product management, and tracking code from build to release and back.

    The Flow of Information on Things that Matter

    Most of the tickets generated by the IT help desk can be handled internally with no help from engineering, but it’s the tickets that do need help that require consideration. For these issues, there needs to be an open flow of information on the things that matter between these two teams.

    IT help desk must give engineering enough information to understand the defect and its impact on the customer. Meanwhile, engineering needs to be able to give the help desk a sense of when to expect the fix, when the fix is done and be able to request more information when required.

    Information that should be shared from the help desk to engineering includes the following:

    • Severity – Engineering needs a sense of the importance of the defect. If everything comes in as “High Priority,” nothing is high priority. The help desk must understand that engineering already has its own internally generated set of defects, as well as defects found by QA and other sources. For these customer defects to be prioritized and fixed in a timely manner, engineering needs to know how impactful they are to the customer.
    • Description – This is perhaps the most important piece of information the help desk can pass along. The more contextual information that can be shared, the better. It’s immensely important to provide engineering with the necessary steps to reproduce the specific defect, which version of your tool the customer is using, the general environment, etc. Sometimes this is best in structured fields, whereas other times it’s important to simply write out everything.
    • Screenshots and other visual information – Along with the written description of the problem, engineering often requires logs and/or screenshots. As the saying goes, “A picture is worth a thousand words.”

    Now that engineering has the vital information it needs to fix the defect, it has a responsibility to provide useful information back to the help desk:

    • Planned release – This should not be a firm commitment, but rather an estimate to give the help desk general timing. While the actual date of the fix may vary, it’s still useful to be able to tell a customer,”This is coming soon” vs. “We realize this is a problem and it’s on our backlog to fix.”
    • Engineering status – While this is a single defect to your customer and to them only has one status, there are really two statuses your organization will care about:
      • Status of the ticket in your ITSM tool
      • Status of the defect in your defect tracking/agile planning tool

    It’s very important that the ITSM tool contains both statuses to provide more information and context to the help desk. Imagine the benefit of knowing that the defect is “In Triage,” “In Progress,” or “In Verification” and being able to provide that information to a customer.

    • Actual release/released – As opposed to the planned release information, this lets the help desk know that the customer’s issue has been resolved. Imagine running a report from your ITSM tool indicating the defects fixed in your most recent release. Your IT help desk can proactively reach out to customers to let them know to upgrade, enabling you to offer more proactive customer communications.

    Finally, and perhaps most important, you allow your teams to talk about the “same thing” even when it exists in different tools and they speak a different language. There are four core ways to do this:

    • Cross tool tracking – Each artifact in each system should have the ID (and ideally URL) of its twin artifact in the other system. If a help desk representative needs to talk to an engineer about a defect, the rep needs to let engineering know which defect it is in the engineering tool, not just in the ITSM tool.
    • Routing – IT help desks often support multiple products, each of which have multiple components that may belong to a different engineering team. The help desk needs some indication which component and/or team should work on the defect. This information will help the IT help desk know which team to reach out to for help.
    • Filtering – Not every ticket in the ITSM tool needs engineering help (that’s a good thing). However, there should be some indication on the IT ticket if it has been sent to engineering. You do not want to send the same defect to engineering twice (confusing) or to assume it’s been sent when it hasn’t (poor time to resolution or issue overlooked).
    • Communication – IT and engineering need a shared way to talk about a specific defect that they both care about. The closer this communication can be to the native commenting that already occurs, the better. Ideally this is not via email as that communication vehicle does not stay attached to the artifacts in question, meaning information can be hard to find or get lost.

    The Benefits

    Customers will love it – Improved communication means happier customers. Customers can plan their upgrades with more certainty, and their trust grows since your organization is able to deliver on its promises. No longer will they feel like their issues are being thrown into a black hole.

    Better engineering focus – Engineering gets pulled in a variety of directions, contending with feature work as well as internally generated defects. The more information it has, the easier it is to prioritize and deliver more value to customer. Without the ability to share the severity of a defect, you risk two undesirable outcomes:

    • The defect is fixed instead of more important work, which hurts all your other customers.
    • Other less important work is prioritized, which can threaten your relationship with this customer.

    Better trust across your organization – Open communication fosters trust and understanding. Providing insight into prioritization and status let’s your help desk feel part of the development process. No longer will staff feel like they’re sending problems into a black hole with no idea when they will be fixed. Enhanced cross-team communication also helps engineering to avoid feeling like work is simply being thrown over the fence. Obtaining more context around a defect is invaluable.

    Next Steps for Total DevOps Integration

    To fully integrate your ITSM and engineering teams, there are still (at least) two other processes to implement:

    • A method for the IT help desk to provide enhancement requests to your product team: These enhancement requests are similar, but distinctly different from the defects described above. Consequently, they need to be prioritized and triaged by a different team.
    • The other process to implement is the traceability from task to code to build and back again. In order to properly inform customers that their problem is fixed in this version of your product, it’s important to correlate features, stories and bug fixes with the actual version of your product that includes them for the first time.

    Bridging the gap between ITSM and engineering teams brings your company closer to customers. While making your organization work as a unified whole is an incredibly complex problem, addressing this relatively small—but vital—piece of the puzzle helps you on your journey to integrating your whole software value stream. This change of mindset—combined with connecting all teams, tools, disciplines and processes in an enterprises’ software value stream— optimizes collaboration, productivity, efficiency and, most importantly, value delivered to the customer.

    About the Author / Trevor Bruner

    Trevor Bruner is a Product Manager for Tasktop Technologies. His background includes experience in financial services, oil and gas and as a Navy submarine officer. Connect with him on LinkedIn and Twitter.

  • Bridging the Gap Between ITSM and Software Engineering

    Bridging the Gap Between ITSM and Software Engineering

    Considering the individual roles of IT service management (ITSM) and software engineers, it seems obvious they should work closely together. ITSM tracks internal and external customer issues and engineering fixes code-related issues (such as defects) that IT cannot fix on its own.

    However, more often than not, coordination between these two departments is poor, which—critically—undermines customer response times and damages application satisfaction. It’s important to remember that the quality of customer response isn’t just about speed, it’s about giving customers insight into the state of the issue.

    The disconnect between ITSM and engineers, often caused by individual priorities and semantic differences, makes this real-time insight difficult. Both teams have individual and shared concerns, and separating these while simultaneously improving collaboration is a big challenge.

    Addressing this relationship is an important step in optimizing ITSM and DevOps integrations, alongside focusing on IT help desk enhancement requests to product management, and tracking code from build to release and back.

    The Flow of Information on Things that Matter

    Most of the tickets generated by the IT help desk can be handled internally with no help from engineering, but it’s the tickets that do need help which require consideration. For these issues, there needs to be an open flow of information on the things that matter between these two teams.

    IT help desk must give engineering enough information to understand the defect and its impact on the customer. Meanwhile, engineering needs to be able to give the help desk a sense of when to expect the fix, when the fix is done and be able to request more information when required.

    Information that should be shared from the help desk to engineering includes the following:

    • Severity – Engineering needs a sense of the importance of the defect. If everything comes in as “High Priority,” nothing is high priority. The help desk must understand that engineering already has its own internally generated set of defects, as well as defects found by QA and other sources. For these customer defects to be prioritized and fixed in a timely manner, engineering needs to know how impactful they are to the customer.
    • Description – This is perhaps the most important piece of information the help desk can pass along. The more contextual information that can be shared, the better. It’s immensely important to provide engineering with the necessary steps to reproduce the specific defect, which version of your tool the customer is using, the general environment, etc. Sometimes this is best in structured fields, while other times it’s important to simply write out everything.
    • Screenshots and other visual information – Along with the written description of the problem, engineering often requires logs and/or screenshots. As the saying goes, “A picture is worth a thousand words.”

    Now that engineering has the vital information it needs to fix the defect, it has a responsibility to provide useful information back to the help desk:

    • Planned release – This should not be a firm commitment, but rather an estimate to give the help desk general timing. While the actual date of the fix may vary, it’s still useful to be able to tell a customer,”This is coming soon,” rather than, “We realize this is a problem and it’s on our backlog to fix.”
    • Engineering status – While this is a single defect to your customer and to them only has one status, there are really two statuses your organization will care about:
      • Status of the ticket in your ITSM tool
      • Status of the defect in your defect tracking/agile planning tool

    It’s very important that the ITSM tool contains both statuses to provide more information and context to the help desk. Imagine the benefit of knowing that the defect is “In Triage,” “In Progress,” or “In Verification” and being able to provide that information to a customer.

    • Actual release/released – As opposed to the planned release information, this lets the help desk know that the customer’s issue has been resolved. Imagine running a report from your ITSM tool indicating the defects fixed in your most recent release. Your IT help desk can proactively reach out to customers to let them know to upgrade, enabling you to offer more proactive customer communications.

    Finally, and perhaps most important, you allow your teams to talk about the “same thing” even when it exists in different tools and they speak a different language. There are four core ways to do this: 

    • Cross-tool tracking – Each artifact in each system should have the ID (and ideally URL) of its twin artifact in the other system. If a help desk representative needs to talk to an engineer about a defect, the rep needs to let engineering know which defect it is in the engineering tool, not just in the ITSM tool.
    • Routing – IT help desks often support multiple products, each of which have multiple components that may belong to a different engineering team. The help desk needs some indication which component and/or team should work on the defect. This information will help the IT help desk know which team to reach out to for help.
    • Filtering – Not every ticket in the ITSM tool needs engineering help (that’s a good thing). However, there should be some indication on the IT ticket if it has been sent to engineering. You do not want to send the same defect to engineering twice (confusing) or to assume it’s been sent when it hasn’t (poor time to resolution or issue overlooked).
    • Communication – IT and engineering need a shared way to talk about a specific defect that they both care about. The closer this communication can be to the native commenting that already occurs, the better. Ideally this is not via email as that communication vehicle does not stay attached to the artifacts in question, meaning information can be hard to find or get lost.

    The Benefits

    Customers will love it – Improved communication means happier customers. Customers can plan their upgrades with more certainty, and their trust grows since your organization is able to deliver on its promises. No longer will they feel like their issues are being thrown into a black hole.

    Better engineering focus – Engineering gets pulled in a variety of directions, contending with feature work as well as internally generated defects. The more information it has, the easier it is to prioritize and deliver more value to customer. Without the ability to share the severity of a defect, you risk two undesirable outcomes:

    • The defect is fixed instead of more important work, which hurts all your other customers.
    • Other, less-important work is prioritized, which can threaten your relationship with this customer.

    Better trust across your organization – Open communication fosters trust and understanding. Providing insight into prioritization and status let’s your help desk feel part of the development process. No longer will staff feel like their requests are being ignored with no idea when they will be fixed. Enhanced cross-team communication also helps engineering to avoid feeling like work is simply being thrown over the fence. Obtaining more context around a defect is invaluable.

    Next Steps for Total DevOps Integration

    To fully integrate your ITSM and engineering teams, there are still (at least) two other processes to implement:

    • A method for the IT help desk to provide enhancement requests to your product team: These enhancement requests are similar, but distinctly different from the defects described above. Consequently, they need to be prioritized and triaged by a different team.
    • The other process to implement is the traceability from task to code to build and back again. To properly inform customers that their problem is fixed in this version of your product, it’s important to correlate features, stories and bug fixes with the actual version of your product that includes them for the first time.

    Bridging the gap between ITSM and engineering teams brings your company closer to customers. While making your organization work as a unified whole is an incredibly complex problem, addressing this relatively small, but vital, piece of the puzzle helps you on your journey to integrating your whole software value stream. This change of mindset, combined with connecting all teams, tools, disciplines and processes in an enterprise’s software value stream, optimizes collaboration, productivity, efficiency and most importantly, value delivered to the customer.

    About the Author / Trevor Bruner, Product Manager, Tasktop

    Trevor Bruner is Product Manager at Tasktop Technologies. His background includes experience in financial services, oil and gas and as a Navy submarine officer. Connect with him on LinkedIn and Twitter.