devopsy.kinsta.cloud

Tag: cxo

  • How DevOps Can Address CX Challenges

    How DevOps Can Address CX Challenges

    Delivering a seamless customer experience (CX) has become a top priority for companies undergoing digital transformation initiatives, as 85% of buyers are willing to pay more for a great customer experience. However, customers aren’t only willing to pay more for a positive experience–they’ll go elsewhere if their experience isn’t positive. In fact, 33% of customers will leave a brand they previously loved after just one bad experience, and 92% of customers will completely abandon a company after just two or three negative experiences. So, delivering a positive CX has become a major priority for companies that want to retain their current customers while winning over new prospects from competitors.

    To assure CX quality for customer-serving technology products and services, established DevOps processes and strategies should be applied to the unique aspects of customer experience software. DevOps for CX enables the delivery of software where the customer’s experience is paramount and quality is imperative. However, there are six major pitfalls in deploying DevOps for CX that customer-serving organizations must overcome.

    What is DevOps for CX?

    To understand the challenges, we must first understand the purpose of DevOps for CX.

    DevOps for CX refocuses the DevOps software methodology on the unique aspects of CX software to enable greater efficiency and quality. The constant delivery of expanded CX capabilities through new software developments and features has become a priority in organizations undergoing digital transformation. But when it comes to software products for CX and customer services, quality cannot be sacrificed for speedy development. At the same time, companies must still meet the demand for rapid innovations and tight deadlines on software delivery.

    Customers have higher expectations than ever before. These days, there aren’t any second chances when it comes to a customer’s experience. Social media has empowered customers to broadcast CX failures for the whole world to see. Due to the visibility of CX mishaps and negative customer interactions, a brand’s CX reputation depends on flawless execution from the customer’s first impression.

    The customer is always right; so, the customer’s perspective must be the primary consideration in software development and testing. This puts significant demand on the DevOps solutions and processes specific to user experience (UX) design, as well as CX testing and monitoring. Software must be designed, developed and continuously tested and monitored in real-time. Companies need to know all the different ways a customer might use the software to accomplish their goals and quickly identify and fix any potential issues before the customer experiences them.

    6 Potential Pitfalls of DevOps for CX

    Underinvestment in Executive Sponsorship and Cultural Evolution

    For CX transformation initiatives to succeed, they must be empowered by an executive leader who can champion the need to drive cultural change and strategic investments. An executive leader is necessary because CX initiatives typically span multiple departments: Operations, development, marketing, sales and services, for example.

    Whether the leader taking on this responsibility is an existing executive or a brand new position will depend on the company’s organizational structure. Some companies assign this duty to the COO, CIO or CMO, while others create an entirely new chief CX officer role so that the leader can give their full attention to the CX transformation initiatives at hand. Regardless of the DevOps for CX champion’s title, they must have a broad authority over budget, people and processes to make their role effective.

    Competing and Misaligned Incentives

    DevOps is a multi-team effort. Ensuring that the teams’ objectives and incentives are aligned is key to ensuring that DevOps for CX projects are executed harmoniously. Each team should have objectives that fit their team function but do not oppose other teams’ objectives, such as speed or a low defect rate on the development side and high reliability for the operations side. These functional team objectives should be centered around respective business objectives for customer satisfaction.

    Unclear Key Performance Indicators (KPIs)

    Adopting DevOps forces organizations to take on a more collaborative mindset. Due to the multi-team, collaborative nature of DevOps for CX initiatives, it’s critical that KPIs are clearly communicated, widely understood, and monitored across teams. KPIs should also be widely distributed so CX can be viewed at an operational level.

    Lack of DevSecOps Prioritization

    Many organizations fail to recognize the importance of DevSecOps from different aspects of DevOps. Not only must customer data be protected, but larger organizations that operate globally must also ensure they are complying with regional data privacy regulations. Organizations that don’t comply with regulatory requirements risk fines and other punitive setbacks.

    You must be able to test security features in production to protect both customers and your organization itself. Unfortunately, security is too often one of the last DevOps aspects to be discussed.

    Different Configurations Across CX Delivery Environments

    Shifting between development, quality assurance, staging and production is a major source of frustration for DevOps teams, as the environments are often configured differently. As code moves through the software life cycle and different environments, having a consistent approach to the solutions and environments via deployment automation will prevent wasted time fixing bugs that suddenly pop up when the code is moved.

    Errors Introduced by Manual or Outdated Processes

    Manual processes introduce opportunities for human error, causing delays and defects that result in unplanned work. Performing software testing manually is a sluggish process that not only causes quality issues and delivery delays but also reduces the amount of time developers have to execute any unplanned work or rework that must be done post-testing. Automating the CX systems’ testing results in higher quality and reliability at faster speeds, providing more time post-testing for developers to ensure the product meets quality requirements.

    DevOps for CX enables companies to innovate CX rapidly by delivering high-quality software and maintaining exceptional customer interactions. As CX leaders innovate new products and services through software, DevOps for CX practices will continue to be honed over the coming years. In the meantime, following the best practices outlined here to avoid the six major pitfalls of DevOps for CX will ensure customer experiences are maintained at an elevated level.

  • For more mobile wins, enterprises must find their MVPs

    For more mobile wins, enterprises must find their MVPs

    The demand for enterprise mobile apps just isn’t letting up. The research firm Gartner expects that by the end of 2017 enterprise user thirst for mobile apps will be growing five times more quickly than internal IT organizations can deliver those apps. And a recent Opinion Matters survey found that enterprises are already hitting deep backlogs, with 85% of enterprises surveyed reporting that they already have a significant mobile app development backlog.

    Such a backlog, as we’ve covered earlier, suffocates an enterprise’s ability to innovate and be competitive. When enterprises take too long to give development teams the app specs they need, and those apps take weeks and months to build and ship, the enterprise just lumbers along in its digital efforts. That means worker productivity lags, too. Most of the time customers aren’t happy with their experience, either.

    Why are enterprises having difficulty fulfilling their app demand? There are a number of reasons, notably that enterprise development teams often work the way things were accomplished a decade ago when IT was more centralized. First, the app needs approval from IT and then timelines are set. And the app needs to be prioritized along with everything else on development team’s plate. When apps are approved, everyone tends to try to shove his or her pet features into them and the apps end up trying to achieve too much right out of the gate.

    Enter the MVP

    The result of all of this, of course, is that the time between the app request and its delivery is extended considerably, and when the app finally does arrive – if it doesn’t meet the required needs or is less than optimally executed – a big and time-consuming effort turns into a big and costly setback. It’s one of the reasons why so many enterprise mobile apps fail, with 50 percent of respondents to a recent survey saying that their mobile apps failed because of poor user experience.

    It’s also one of the reasons why more enterprises are embracing the Minimum Viable Product, or MVP, as a way to get try to get apps with the features users need as quickly as possible, while not investing too much time in apps that users don’t desire. “In the strictest definition of MVP, it refers to a product that delivers the highest ROI relative to risk,” says Scott Amyx, CEO at Amyx McKinsey, a smart wearables and Internet of Things strategy and development agency.

    What does that mean, practically, to CIOs and development teams trying to develop more apps that are more on target to user needs? Asaf Yigal, cofounder and VP of product at data analytics platform provider Logz.io, says it means that developers should start with a minimalist, but useful, definition of the app that is to be created.

    At Logz.io, Yigal explains, the company develops with an agile methodology. “It’s critical for us to be able to define the MVP before we start a project,” he says. “There are two key objectives when defining a MVP. The first objective is that the majority of the users need to be able to benefit from a new feature – this means that we don’t address edge cases in development at all. The second objective is that we need to be able to analyze how users will be using the new feature. We are a data-driven company, which means that we log all relevant events in every feature we develop and build internal dashboards that display how users are interacting with a given feature,” he says.

    Small teams, small apps, tight focus

    Greg Archbald, founder & CEO of oil and gas industry software provider GreaseBook, has worked with dozens of oil and gas companies, ranging in size from those with tens of billions in revenue to those with less than one billion in revenue. Archbald explains that while the “super majors” of the industry have plenty of success extracting hydrocarbons, they don’t necessarily excel in building software. “Even the companies that have managed to land themselves some really strong development talent tend to struggle with project scope,” says Archbald.

    Why? It’s the sheer number of people that become involved in the development process, he explains: ”I’ve seen first hand how layers of management, engineers, and production supervisors (all with the best intentions) become involved, and this is where issues begin. Everyone needs the app to do something different, and pretty soon feature creep settles in.”

    This is especially true for development teams that find building systems easy, but dealing with people more difficult. “For much of software to be successful, it must focus on the human elements, not the technical. And, most larger companies don’t realize this soon enough and ultimately set themselves up for failure,” Archbald says.

    So who’s going to keep app development on track? It could start with learning when to say “no,” Archbald says. “This is very tricky because, as part of a development team working for a large company, you’re paid to develop, not to tell upper-management “no,” he says. But to be able to succeed with the MVP and clearing app backlog, it’s about clearing both unnecessary people and features. “The word ‘no’ is exactly what MVP stands for. And at larger companies, a successful MVP isn’t just about a limited set of features, but also about a limited number of people involved.

    “It sounds counterintuitive, but many projects in the development succeed not in spite of the limitations but because the limitations were put on them. Limitations of the amount of input, manpower, beta-testers, and even funding – all of which are unheard of at the enterprise level – force a team to figure out more creative solutions.”

    Jordhy Ledesma, CEO at creative design, information architecture, and custom programming consultancy Information Providers would likely agree. “Keep the development team to less than a handful of teammates. Develop using the SCRUM project management framework (which advises to code in sprints and ship functionalities in batches) and limit the project duration to less than six months,” says Ledesma. “What is sometimes misconstrued by the DevOps community is that MVP is about a tangible, minimal product more than a methodology to leverage. In other words, it’s an iterative process that helps us to refine our concepts, prototypes, data, analyses, and learnings to deliver high value to our target customers. It’s a framework.”

    It’s not just about enterprise software; as more things and devices become interconnected, it’s going to be even more important that enterprises reduce risk with apps. “Our agencies work with both large enterprises and startups. When they come to us to conceptualize and develop wearables and IoT products and services, they almost always start with an aspirational vision. Sometimes, that means a laundry list of sensor technologies or data analytics capabilities,” explains Amyx.

    “We work with them to understand, from the customer perspective, what is the biggest pain point and then to focus on delivering a focused solution that addresses the top problem statement. After we learn from an iteration, we do it again to incorporate customer feedback into the product roadmap. A tight MVP methodology turns a potentially daunting process into doable mini-sprints while helping our clients to focus. They are often surprised at the nth iteration how their product/service is vastly different from what they had originally envisioned,” Amyx says.