devopsy.kinsta.cloud

Tag: customer experience

  • Using Product Experimentation for Continuous Improvement

    Using Product Experimentation for Continuous Improvement

    Organizations are embracing product experimentation as a tool for continuous improvement

    Companies that embrace product experimentation are able to capture highly accurate data about markets and product ideas and gain intelligence about market trends. As a result, these companies are able to continuously deliver innovation and measure business outcomes.

    Industry leaders such as Netflix, Instagram and Facebook have used product experimentation to maximize a positive customer experience, increase their user base and elevate their market positions to the highest of levels.

    Let’s say you want to be one of those companies—or at least you and, hopefully, your team, want to experiment with product features in hopes that your company will embrace experimentation on a larger scale to achieve continuous improvement.

    Great. But now what?

    Just thinking about learning the basic concepts of experimentation and figuring out where to start can seem like an overwhelmingly daunting task. Fortunately, there are a few tried and true steps you can take to get on the path to product experimentation for continuous improvement.

    Measure First

    “You have to walk before you can run.” That old adage certainly applies here. Rather than attempting to jump headfirst into experimentation, organizations first must ensure they are measuring things. Are you tracking things such as users per day, trends, dates and conversions? The idea here is to become data driven, because before an organization can run effective experiments, it first must gather quantifiable data; understand what this data means for overall growth, user retention and long-term projection; and then base business decisions on this data.

    Buy or Build 

    No matter the size and scope of the experimentation throughout the organization, even if it is just one team or department, you need a platform or tool to experiment on. Many of the most progressive organizations that have based their growth and continuous improvement on experimentation have built in-house solutions to facilitate this. However, this can be time-consuming from the start and the platform will continue to require attention as it evolves. This evolution also requires a specific skill set to make it happen—specifically, data science and engineering—to ensure the experimentation platform is statistically sound.

    For most, investing in a robust tool or platform built specifically for experimentation is the best option. Most experimentation platforms allow you to plug and play, which provides the right features and capabilities to get an experimentation started quickly.

    Hypothesize

    The next step is to create a testable hypothesis and then record and analyze the data during testing. It’s important to begin thinking in terms of hypotheses, as framing plans and ideas in this manner makes them easier to reuse. In other words, being able to say, “Based on this, we predict we can move that metric,” makes your processes very repeatable. Getting into this mindset and having a standardized format—in terms of how things are designed and reported on—makes the lives of everyone on your team easier, as they can simply replicate similar experiment designs. And they will have fewer excuses not to.

    Keep It Simple

    Now that you have quantifiable data and some hypotheses to work with, you are ready to dip a toe into the experimentation pool. It is always a good idea to start with a single simple experiment first, no matter how small. For example, experimenting on a known pain point in your product is a nice place to start. Once you can successfully run an experiment that allows you to fix something in your product that you know is a problem, then you are ready to move on to bigger things such as revenue creation.

    Choose the Right Metrics

    As your team’s product experimentation efforts become more sophisticated, choosing the right metrics—and more importantly, your overall evaluation criteria (OEC)—should become a top priority in continuous improvement. Your OEC comprises the most important metrics of your experiment and it’s a measure of long-term business value or user satisfaction.

    In choosing which metrics to use, there are three essential characteristics of an effective OEC to consider.

    The first of these is sensitivity. This means the metrics you have chosen should be adjustable due to small changes in business value or user satisfaction, which helps ensure the result of an experiment is clear within a reasonable time period. For example, let’s say a customer only buys something from your website once or twice year. That’s not a very useful metric for an experiment since it would be difficult to influence.

    Next is directionality. Your metrics should be moving in one direction or another based on whether your overall business value increases or decreases. That said, the direction some metrics take can be ambiguous. For instance, say you are attempting to measure customers’ engagement with your support team. An increase in that metric could be a positive thing because it might be an indication that more people are engaging with your core product. On the other hand, a decrease in this metric could be an indication that your core product has become easier to use and therefore now requires less support.

    The third characteristic to consider is understandability, meaning the metric should be easily understood, both in terms of its direction and its definition, by your entire organization. Moreover, you should ensure it ties the experiment directly to business value.

    Of course, much more will need to be done to transform your organization into a place that truly embraces an experimentation culture and reaps the benefits that it brings in terms of customer experience and beyond. But these steps should set you and your team down the right path.

    — Sophie Harpur

  • Adobe Strategy Revolves Around DevOps

    Adobe Strategy Revolves Around DevOps

    At the Adobe Summit 2019 conference this week, Adobe detailed that its Adobe Experience Cloud customer experience ecosystem is reliant on a set of best DevOps processes that is wrapped around a modern microservices architecture and layered on top of big data platform deployed on the Azure cloud.

    Adobe last year acquired Magento, provider of an e-commerce platform, and Marketo, provider of a marketing automation platform. Since then, Adobe has been working to integrate those offerings with its existing marketing application to create the Adobe Experience Cloud.

    Anjul Bhambhri, vice president of platform engineering for Adobe, said this set of software-as-a-service (SaaS) applications are being integrated around a shared common data model that is layered on a microservices-based architecture of containers running on Kubernetes clusters. On top of that, Adobe is layering a series of machine learning algorithms, dubbed Sensei, to embed artificial intelligence (AI) across the entire portfolio, he said.

    As that work progresses, Adobe plans to allow customers and partners to leverage the data stored in the Adobe Experience Cloud to train their own AI models using data curated by Adobe, Bhambhri noted. That data model, known as the Experience Data Model (XDM), is also being shared with partners including Microsoft and SAP, which last year committed to an ambitious initiative to build a common data model in collaboration with Adobe. XDM makes use of open source Kafka messaging software to integrate the various data pipelines that are required to integrate these applications at scale in near real-time, Bhambhri said.

    Those efforts complement an existing initiative under which Adobe is exposing open application programming interfaces (APIs) to encourage developers to build applications that extend Adobe Experience Cloud.

    Rather than building their own customer data platforms, organizations can drive their digital business initiatives using a big data platform managed by Adobe on their behalf. Many organizations have been building their own platforms to achieve that goal with mixed success, first deploying a data warehouse on top of a big data platform and then working to integrate various applications to provide a richer digital customer experience. Bhambri noted Adobe is pouring considerable resources to obviate the need for organizations to acquire, deploy and manage their own IT infrastructure to achieve that goal.

    IT leaders must decide whether they want to reduce the time, money and effort required to build these custom platforms in favor of using a managed service from Adobe—which, arguably, would enable them to pour more resources into developing applications that, as a result, would come to market faster.

    In the meantime, it’s clear the need to embrace digital business transformation will drive more organizations to embrace DevOps processes. The question now is to what degree they need to define their own set of best DevOps processes versus simply lifting the DevOps best practices that organizations such as Adobe have already proven.

    — Mike Vizard

  • DevOps Chat: Customer Experience and DevOps with Cyara’s Alok Kulkarni

    DevOps Chat: Customer Experience and DevOps with Cyara’s Alok Kulkarni

    In this DevOps Chat we speak with Cyara CEO and co-founder, Alok Kulkarni, about how DevOps is helping in the customer experience arena. Cyara has carved out a leadership role in bringing DevOps to CX. Alok is a delight to speak with and very wired into this space.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.


    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat features Alok Kulkarni, CEO and Co-founder of Cyara. Alok, welcome to DevOps Chat.

    Alok Kulkarni: Hey, Alan. Great to be here.

    Shimel: It’s our pleasure to have you here. So, Alok, let’s—before we jump right into what I wanted to talk about today, I think the first thing we should do is a little level set. Maybe we have some folks who are familiar with Cyara, maybe we have some folks who are not. Why don’t you give us kind of a quick background on Cyara?

    Kulkarni: Sure, Alan. So, Cyara is a customer experience assurance platform, which allows customers to accelerate their CX development right from the design through to testing and all the way through to customer experience monitoring for customers’ journeys end to end.

    And so, what’s different about us is, we support the entire software development life cycle from the design through the functional integration testing right through to user acceptance testing, including load testing and production monitoring. And, in the CX world, we’re able to do this from an end customer perspective across all the different channels that the customer might be interacting with the organization. So, that’s just a brief summary of what we do.

    Shimel: Sure. And you are the Co-founder and CEO.

    Kulkarni: Mm-hmm.

    Shimel: And just, while we’re here—

    Kulkarni: Yes, and—

    Shimel: —give us a little bit of your own personal journey. How did you come to be the co-founder and CEO at Cyara?

    Kulkarni: Sorry, go ahead.

    Shimel: Oh, I’m sorry. I was going to say, if you can give us a little bit of your own personal journey, how did you come to be the CEO and Co-founder of Cyara?

    Kulkarni: Oh, great question, Alan. Sorry, I lost you there for a bit. I was working at another software company, which is currently the leader in customer experience management technology, and one of the things I found in those days—this was in the late 2000s—was, every time we put the technology in production, the customers, the end customers used to deal with this new technology and the enterprises would be sitting there with white knuckles hoping and praying that it would all work—because there was no platform in those days which would enable them to test and monitor the technology that they were putting in for the customers from the outside in. So, essentially, it was like playing Russian roulette.

    So, I felt, being an architect at this company and managing the solutions engineering group at this technology company called Genesys that, there had to be a better way. And one of the—the idea came to me when we were rolling out a large implementation for an Australian government organization when it failed. I thought that there must be a better way of doing this.

    So, hence, I felt—imagine if there was a cloud-based platform that was technology agnostic which enabled enterprises to just use and simulate customers from the outside in to be able to test and monitor, not only the infrastructure, but the applications from an end to end customer journey perspective. It would really take the risk out of deploying new and innovative solutions in the market. And so, that’s how it all happened. So, I got together with my buddies and we built Cyara.

    Shimel: Excellent. So, you know, in so many ways, there’s so much DevOps there, if you will, Alok. And first of all, the idea of—and we see this in security, we’ve seen it with other forms of QA—the idea of waiting ‘til after something is deployed to see if it works or not, you know, that white knuckle moment? Why?

    Kulkarni: Mm-hmm.

    Shimel: I mean, why, in this day and age, do companies still want to do stuff like that, right? And this is, especially when we talk about sort of the modern software factory and CI/CD pipelines and so forth, right? We shouldn’t let software out there that hasn’t been fully vetted and tested. Why would we let software and things in the wild, where we haven’t already tested what our customer response, and our customer experiences are going to be and whether they will work?

    It just seems like such a no-brainer. Why do you think it took so long for people to come to this realization?

    Kulkarni: So, I think that’s a great question, Alan. And, you know, when we were sitting there noodling on whether we should start this, I remember going to my co-founder, Bonny, and asking him, “Hey”—because he wasn’t from the industry, and when we came up with this idea, he goes, “Surely, there’s somebody doing this.” Because it’s exactly what you said—it’s a no-brainer. And I said, “No, there’s actually no one doing this.”

    And I think the reason for that is, one is, I don’t think people in the—if you’re not in the industry, you don’t even know that this is a problem, that’s one. Second thing is, even if you were in the industry, it is so complex. I mean, there are so many different moving parts, so many technologies. Then you have enterprise processes and systems and systems integrators and so forth.

    So, by the time you’ve put that whole, all those components together, it becomes very difficult to build something simple that would solve these problems. So, when we did it, it just took off. And now, like you say, I think customers are realizing that there is a technology or a solution out there that can help them. So, we’ve had a tremendous, I guess, following of customers who actually just continue to expand what they do with Cyara and we’re signing new customers on as we go along.

    So, just this last quarter, we signed about 25 Fortune 500 companies to our platform. So, I think it’s catching on, and now, what we’re seeing is the next wave, like you mentioned, this whole DevOps wave that’s really taking firm hold in the way that more and more organizations are putting out a software or capability. And I think in the CX world, that’s changing as well. So, I think, we’re also creating awareness that you can bring DevOps to CX and although the tool set might be a little different, you can actually do it. So, we’ve had a tremendous amount of traction in the market with that.

    Alan Shimel: Absolutely. You know, Alok, it talks to something else that we’ve seen in DevOps. When we first started devopsy.kinsta.cloud on March 11th of 2014, I think it was, so it’s almost five years now—the whole, “What is DevOps?” argument was raging. And there was a large percentage of the community that had a very orthodox view of DevOps, that if it wasn’t purely about software development and deployment in terms of operations and APM, it wasn’t DevOps, right? That’s what—there was a very narrow definition of DevOps.

    We’ve seen that expand, right, to what I call DevXOps now.

    Kulkarni: Mm-hmm.

    Shimel: We’ve seen DevSecOps, we’ve seen DevBusOps, we’ve seen DevSalesOps. It’s really taking that DevOps mindset that DevOps can do and applying it to everything.

    So, really, we’re almost seeing here DevCXOps, right, if you will.

    Kulkarni: Yeah, totally. Yeah, I think we are in that era now of DevCXOps, just like you mentioned. Because, just like software organizations were putting out new capabilities in a rapid manner, I think customers were expecting customer facing technologies, and the way they’ve been—the way that they’re interacting with organizations to change rapidly as well. Because everyone’s time poor, they need the answers as soon as something goes wrong or if they want to buy something, they’re impatient, because we all have things to do and we’re on 24/7.

    So, it’s imperative for companies providing customer experience to keep up with that. And I think DevOps provides a great framework to do that, and it’s aligned so, as you say, if you’re already in DevOps and the digital world, you can bring it to the CX world. And I think it’s really catching on.

    Shimel: I don’t disagree. I think another thing, Alok, and you hit on it there, is customer expectations. You know, one of the sort of forgotten heroes or the forgotten catalyst behind all of the DevOps kind of movements is what really—people don’t go fast just to go fast. Well, maybe some do, right? There are speed freaks, right? [Laughter]

    But, you know, people who adopt agile DevOps and these sorts of frameworks and methodologies do so to be more responsive to customers. And that’s really—and it’s nitty-gritty. That’s what it’s about. Because that’s why companies do things, to serve their customers better. And that’s really the guiding principle behind CX as well, right? How do I respond to customers better, especially in a world where customers demand more? They want 24/7 support and response, and they want it right away, and they want it now and they want it to work, right? There’s a low tolerance if your cellphone coverage is not good, or your internet—as we spoke about—your Internet at 30,000 feet on a plane is not working, and people get really upset about that now. And in so many other ways, customer demands are driving this. Correct?

    Kulkarni: Yeah, totally. And you know, what’s sad is, we’re fickle. You know, we’ve been conditioned to now have choice. So, if we don’t like the service a particular company is offering, you know, we switch, and switching is so easy, because it’s very easy to find another provider who provides a similar service and offering and then if they have a better customer experience, you think when you actually have that moment of need where you actually need help and they’re providing it to you promptly and they’re resolving your issues quickly and they’re doing it how you want to be treated, maybe it’s a late night chat or a phone call because it’s super urgent or it’s complex. Or maybe it’s like, “I don’t want to talk to anyone today, but I need the information for my support, because one of these technologies that I’ve got isn’t working, so I need a knowledge base that I can refer to.”

    Any of these customer-facing technologies play a very important part in customer loyalty and thereby, shareholder value for the company that they’re dealing with.

    Shimel: Agreed, agreed. So, Alok, if you don’t mind, I want to talk a little Cyara—I’m sure you don’t mind. [Laughter]

    Kulkarni: [Laughter]

    Shimel: So, do you offer this as more of a Platform as a Service or as a SaaS based offering?

    Kulkarni: Yeah, it’s a SaaS-based offering, so we have a cloud infrastructure environment which spans, which goes across the globe. Just last year, we placed 4.4 billion call seconds’ worth of synthetic interactions to assure customer experience around the world, and some of the largest brands of the world use it.

    So, some customers, they use our platform to provide the whole design experience—like, the design, the customer experience in Cyara is able to, as a result, get a full automation and regression test suite that they can run as part of their DevOps factory, and then we have a real time customer experience monitoring platform.

    So, for example, if you put something out in production, our platform actually is able to generate synthetic customer interactions from the outside in. So, we can actually emulate, Alan, contacting an organization on your behalf and actually see what experience you’re going to get, whether your interactions or your calls connected on time, whether the web chat gave you the right responses, whether the screen froze or not, and you can do this all in real time.

    So, customers have a direct feedback loop that they can implement. So, as soon as something goes into production and it doesn’t work, before a real customer is able to have a poor experience, we’re able to detect it early on and the customers can then roll back the technology that they had implemented and then roll the previous last known good version out so that they maintain the sanctity of the customer experience.

    So, it just—to me, that just goes hand in hand with the whole DevOps paradigm.

    Shimel: I agree. It certainly does. So, Alok, if I ask you to kind of peer into your crystal ball of the future, where do you see this going now?

    Kulkarni: So, as you mentioned, Alan, there’s a lot of companies out there who are not even aware that they can apply the whole DevOps—they can bring CX to DevOps and, as you call it, DevCXOps, and make it happen. So, I feel, over the next two years, we’re going to see a tremendous wave of customers adopting this framework, because they’ve already done it on the digital side and the CX side tends to be—I think they’re in an adjacent area and I think they are moving to this new model.

    So, we’re going to see a lot of customers offering it, and I think we’re going to see a lot of new, innovative technologies coming out with integrated solutions for that. So, I think for Cyara, we want to support our customers as they go on this journey. So, we’re integrating with a number of platforms out there that enable the whole CX DevOps pipeline scenario. For example, we’ve just integrated with Splunk, we’ve integrated with ServiceNow. So, in Cyara, you can actually get real time incident notification of any technology that you’re implementing and automatically create service requests so that you’re able to keep ahead of the whole customer experience pipeline.

    And the other thing that we’re doing is also investing heavily on the design aspect of it. So, we’re working with companies like Amazon and so forth to offer a platform that is able to take customers that are moving to the cloud or moving to cloud contact centers, which is becoming, which is a new wave that’s still catching on and enable them to essentially drive this whole assurance through to all their customers.

    Shimel: Excellent, excellent, excellent. Well, Alok, as we—I think I told you before we started, the time goes really quick. We only have a few minutes left. I wanted, also, I’d like to finish up with kind of wrapping this whole thing back into the DevOps, back into what Cyara is seeing from customers.

    Companies I’ve been involved in, and I’ve founded a few, you know, we had sort of a customer support, a customer help team. It was separate from developers, it was separate from Ops. It was part of the engineering team, but it was almost a red-headed stepchild within that engineering/IT team. Is that still the case? Is that a problem? Is that something Cyara runs into when you’re talking to folks? What’s the story?

    Kulkarni: So, I think you, again, Alan, are right up there with it. So, I think one of the decisions organizations that we deal with are grappling with is, do they make engineers who understand software and make them CX developers, or do they make CX developers who have real code domain expertise and bring them onto the DevOps world?

    And I think that’s a question a lot of companies are asking themselves—like, do we need to really understand this space from top to bottom, or do we get developers? Is it easier for developers to learn this versus the other way around?

    And I think that’s currently in the experimentation stage. So, a lot of companies who have tried the old model feel that it’s just very hard to change the mindset of the old engineering folks to—you know, who’ve been traditionally used to waterfall and doing large scale implementations and using systems integrated to put those out to really just come onto this whole new, you know, go fast, break things mentality versus getting those guys to understand CX.

    So, I think there are two horses running right now, and I think we’ll see the results of that in the next year or two. But what I am seeing is a lot of companies trying to get their developers onto the CX world, because they’re finding that that seems like a much easier path.

    Shimel: I don’t disagree with you. Crazy. Interesting times.

    Kulkarni: Yeah.

    Shimel: Anyway, Alok, I know we’re doing some other, you’ve published some more—well, not you, but Cyara has published some nice articles on devopsy.kinsta.cloud lately, we’ve done some other activities.

    Where else can people find out more information, though, about Cyara?

    Kulkarni: Well, they can obviously come to our website, so Cyara.com, that’s C-Y-A-R-A dot com. And I think we have, we’ve built a huge library of resources thanks to our fantastic team that we have at Cyara, and they can also—I think over there, there’s a whole library of collateral that they can view. We’ve got a YouTube channel that they can subscribe to.

    And we also have Cyara Academy. So, as part of that, they can go in and if they want to actually get trained on Cyara, we offer that on demand as well. And you don’t—I think there are some courses where you don’t have to pay. So, I think you can, if you’re new to this space, I think it’s a great place to get scaled up, because I think this is a very exciting space. Because, as you’ve said, Alan, every company, to be successful, needs to really deliver a superior customer experience to their end customers and I think it’s just the core of any fundamental for any company to get this right.

    So, come on over to Cyara.com and get yourself educated.

    Shimel: Cool. Well, Alok Kulkarni, CEO and Co-founder of Cyara, thanks for being our guest on this interview, on this episode of DevOps Chat, and we hope to have you back on again soon.

    Kulkarni: Thanks, Alan. Would love to come back.

    Shimel: Alrighty. Hey, this is Alan Shimel for devopsy.kinsta.cloud, Security Boulevard, Container Journal. You’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • How to Apply Agile and DevOps Principles to Accelerate Customer Experience Innovation

    How to Apply Agile and DevOps Principles to Accelerate Customer Experience Innovation

    These days, it’s not enough for companies to offer quality products or services; they must deliver an exceptional customer experience. In fast-changing environments, continual innovation on the front lines of customer service requires an agile and nimble approach.

    How important is the automation of development and monitoring for accelerating customer experience (CX) innovation? I recently posed this question to Dr. Nicole Forsgren, research and strategy expert at Google and former chief scientist at DevOps Research and Assessment (DORA). Her response:

    “I would say that, today, this is almost just a given to operate effectively. DevOps is definitely more than tooling, but you can’t do it without strong technology solutions that provide automation, monitoring and visualization to people throughout the value chain. This gives visibility to key stakeholders, so you can ensure you are delivering value and your feedback loops are happening.”

    This is not a simple concept to execute well. The diverse array of applications and systems that organizations deploy to engage their customers is complex and spans many different technologies, platforms and channels. Ensuring all those applications and systems work together seamlessly to enable customers to consistently accomplish their goals is a daunting challenge. What’s clear today is that how customers perceive their interactions with businesses, shapes brand loyalty.

    It’s interesting then, that while most companies recognize the importance of providing an outstanding experience, many have yet to embrace an automated approach for the development of their CX applications. Those enterprises that have successfully accelerated their CX innovation share a common attribute: They have automated both the testing and monitoring of their CX development projects.

    DevOps + CX = Faster Speed, Higher Quality, Fewer Failures

    Customer-facing applications, such as call center technology, websites, SMS and even chatbots, are the central artery of customer experience. If these applications are not designed, built and deployed properly, it will be costly. To ensure success of CX innovation projects and reduce the risk associated with development/deployment, we must build solutions with testing and monitoring in mind, automate deployment and configuration, and use test data in production to accurately monitor variance from the design.

    What’s holding your organization back? There are four important steps organizations can take to boost the speed and quality of CX software development, while reducing their failures.

    1. Strive for automation, anywhere you can find it

    Aim high—strive for 100 percent automation and take a creative approach to integrating different phases of development. Whether it’s JIRA, Bamboo, Udeploy, Cyara or any other technology that helps automate different parts of your software delivery life cycle (SDLC), have a vision that automates and integrates wherever possible. Success here will deliver smooth and seamless movement of work and deployments into various environments.

    2. Don’t underestimate the importance of the feedback loop

    In order to improve our CX, we must first understand what challenges customers are encountering right now. This requires real-time monitoring of the actual customer experience—but from the customer’s perspective, not from a hardware perspective, as is traditionally done. If you can monitor and measure customer interactions in the moment and capture them concisely, then you can channel this critical information back to business decision-makers, so changes can be implemented quickly. It’s one example of a feedback loop, and if you can repeat it over and over, you can significantly improve and refine your CX.

    3. Take the time to reflect, align and improve

    Instill a culture of learning and humility—not finger-pointing and blame. For example, I recommend teams adhere to well-defined Agile Retrospectives, a ritual that enables teams to create a continuous improvement culture in which they reflect on past experiences and define future actions. Retrospectives are only one of the many ways to instill an open-minded culture, constantly focused on improving collective capabilities.

    4. Integrate business objectives and measurements with the technology side of the house

    I see this as a two-way street. First, help ensure the technology teams understand the impact of their work and give them access to the metrics that are important to the business team, through regular progress reporting. Second, make sure the business team shares their goals and key objectives with the technology teams, rather than simply specifying a requirement. I think it’s important that developers and operations teams understand the business impact of success and failure—and, therefore, the importance of their work. This is a great motivator. Plus, more visibility and tighter integration with business objectives can also result in more creative problem-solving from the innovative thinkers on the IT side.

    A Parting Thought: Find Your Anchors

    The right decision or strategy is not always clear, but finding two or three pillars as your anchors can be clarifying during decision time. In the CX innovation space, I find two anchors are particularly helpful:

    • The customers are the reason why we are in business. Are you prioritizing the end-customer experience in this decision? Are you improving it, understanding it better or measuring it more effectively?
    • What is the business goal you’re aiming to attain? No matter how granular the technical change you’re making, there is almost always a business reason driving it from the top down. Do you know what that driver is? How, exactly, will your change move you closer to that business goal?

    — Amy Hudson

  • Using DevOps to Be an Innovation Champion

    Using DevOps to Be an Innovation Champion

    Innovation, which increasingly is cited as the competitive advantage businesses need to meet their digital challenges, is widely misunderstood; it’s mistakenly reduced to the sophisticated features of a technology or a service.

    As a competitive matter, innovation is more than that; it’s primarily the process of translating ideas or inventions into high-value technology features or added-value services. In other words, to be called innovation, a technology or a service must satisfy a specific need and create value for customers.

    DevOps is very often seen as the perfect means to make an IT organization an innovation champion, it’s true. Yet, many CIOs and their solution vendors and consultants have failed to achieve that goal because they’ve oversimplified the process. DevOps is part of the process, not the process itself. DevOps isn’t the end but the means.

    In this article, I share two fantastic concepts—Innovation Virtuous Circle (IVC) and Value Stream—we leverage at ITaaSNow to enable DevOps and transform in a record time IT organizations into innovation champions.

    Define Your Strategy with the Innovation Virtuous Circle

    Making innovation your organization’s main competitive advantage isn’t as simplistic as investing in the most sophisticated technologies; it starts with defining your strategy, continues with implementing it throughout your IT organization’s value stream, and ends up with getting it adopted across your business.

    Improvisation and organizational transformation aren’t good friends. Rely on proven frameworks that safely guide the effort step by step; it’s the purpose of the IVC—it facilitates and accelerates the innovation strategy definition effort:

    The Innovation Virtuous Circle (IVC)

    The principle underneath the IVC is the notion that keeping customers loyal through innovation guarantees continuous revenue. The idea is, the more innovation, the more loyal customers and the more revenue.

    Put together your business and IT stakeholders to discuss the means by which customers will be kept loyal to ensure continuous revenue. Follow the steps suggested by the IVC:

    1. Clarify the agile processes and practices, the tools, skills and partners by which customer data will be captured and tracked for analytics purposes.
    2. Identify the agile analytics processes and practices, the tools, people, skills and partners that’ll help to spot innovative ideas, solutions and technologies.
    3. Clarify the agile processes and practices, the tools, skills and partners needed to ensure high frequency, high quality and speedy innovation delivery.
    4. Identify the agile processes and practices, the tools, people, skills and partners that’ll help to monitor customer satisfaction and improve customer experience.

    What you get out of this step is a comprehensive strategy including the targeted customers to keep loyal, the estimated expected revenue along with the organizational capability to achieve them.

    Reconfigure Your IT Value Stream with DevOps

    Once your innovation strategy is defined, the next step is to use the value stream framework to deploy it throughout your IT organization.

    The value stream represents the added-value interactions, people and skills, processes and practices and tools mobilized throughout your IT organization to deliver innovation:

    The Agile IT Value Stream

    It conceptually structures the IT organization’s value stream into a four-stage agile process. Each stage is associated with a specific goal and mobilizes specific elements of your innovation strategy.

    Again, put together your business and IT stakeholders to address the following:

    1. For Plan & Measure, discuss your future governance’s structure, members and roles, agenda along with the tools and infrastructure supporting your analytics-based innovations screening and prioritization and portfolio management processes.
    2. About Develop & Test, get a consensus on the staff to assign, the agile methodology along with the continuous testing and integration infrastructure that will support your innovation development processes.
    3. Regarding Release & Deploy, discuss the staff to assign, your release management and launching processes along with the continuous deployment infrastructure needed to support them.
    4. As for Monitor & Improve, discuss the staff to assign, your service continuous improvement processes, along with the analytics technologies intended to support them.

    What you get is a comprehensive and documented blueprint of your IT organization’s value stream transformed to DevOps. Use it as a baseline to hire the solution vendor and consulting firm that’ll concretely reconfigure your IT operational model to innovation.

     Wrapping up

    Using the concepts of IVC, Value Stream, and DevOps to establish IT operational models that boost innovation is a transformation approach we’ve been using to make businesses innovation champions.

    All of the companies that replicated the organizational transformation approach described in this article are:

    • Rolling out per year more than 20 services and products qualified as innovations
    • Either doubling or tripling their revenue
    • Keeping loyal 98 percent of their customers

    That’s the kind of contributions and impacts your business unit leaders expect from you as the CIO and your IT department.

    — Philippe Abdoulaye

  • Why Financial Companies Love Continuous Delivery

    Why Financial Companies Love Continuous Delivery

    The other day I was on the American Express website paying bills and browsing around the benefits and services afforded me when I ran across a “who we are” section. It read:

    “We’re a global services company that provides customers with access to products, insights and experiences that enrich lives and build business success.”

    Surprisingly, the term “financial” was missing from the description. This led me to wonder if other financial institutions are evolving how they think about themselves. Here are some other examples:

    • Bank of America: “Here to help connect you to what matters most.”
    • ING: “Empowering people to stay a step ahead in life and in business.”
    • MasterCard: “As a technology company, we connect individuals, businesses and organizations around the world, creating greater opportunities for all.”

    Financial Companies Love Their Customers

    My unscientific assessment of various financial services companies suggests that they are centered on delighting their customers. They are transforming who they are by altering their customer engagement models and essentially becoming better software companies. MasterCard has even reclassified itself as a “technology” company. These companies are transcending the role of transaction engine to offer seamless, intuitive digital experiences for their customers.

    And the proof is in the performance. According to Forrester’s Customer Experience (CX) Index, financial services firms, including retail banks, credit card companies, investment firms and auto and home insurers, are some of the top brands worldwide when it comes to CX.

    You might think that large financial institutions would be digital laggards because of legacy infrastructure, regulatory compliance pressures and overall risk-avoidance. But you’d be wrong.

    In another study, 81 percent of financial services firms said they are embracing digital to redefine their businesses, and 87 percent are on the DevOps bandwagon. Sixty-one percent even said they are disrupting their industry with advanced digital initiatives.

    To stay competitive and improve their customer experience aptitude, financial services firms are undergoing significant digital transformation.

    Getting the Pulse of Fintech Continuous Delivery Adoption

    But how progressive are these firms in terms of their application delivery practices? Working with CA, Gatepoint Research recently surveyed more than 100 IT executives from financial services companies to take the pulse of where they are in continuous delivery adoption. Results can be found in this report and infographic.

    First off, to see if these companies might be considered unicorns or stragglers, they were asked the total volume of monthly deployments in all environments. Forty percent fell at the low end with fewer than 50 deployments per month. Now, lower deployment numbers could mean that these are less agile organizations or that they have fewer applications in general. Somewhat correlative to lower deployment numbers, the survey found that 48 percent currently are not using an application release automation (ARA) solution. Without automation, it’s tough to scale release processes—particularly to keep up with agile development.

    Moving up the spectrum, 41 percent are moderately prolific at 50-500 deployments per month, and then 15 percent are what I would consider rock stars with more than 500 (7 percent of those over 1,000). Those doing hundreds of deployments a month often have agile development teams and more modular applications. They likely have continuous delivery practices in place that push more frequent, iterative deployments left, helping higher-quality applications to move through the pipeline to production.

    The primary application delivery goals for financial services firms for the next 12 months are to get better control of release processes, tools and environments; to reduce risk and failures; and to release applications more frequently. All of these needs typically stem from companies undergoing digital transformation—it feels more chaotic and disconnected, manual processes are breaking under the weight and there’s intense pressure to move faster.

    Compliance was not a top goal, and the majority (83 percent) claim that their current release process is adequate to meet regulatory requirements. However, they did acknowledge that they could improve in terms of knowledge safekeeping and auditability of the release process.

    The data certainly shows that financial services companies are adopting continuous delivery practices in some form and exploring solutions, including many open-source tools, to help them get the job done. They currently are focusing continuous delivery practices on tracking and reporting releases, planning and scheduling releases and automating test deployments. These practices ultimately help financial services companies to release high-quality applications anywhere at any time.

    How Continuous Delivery Helps Fintech Win

    Continuous delivery sits at the heart of many digital initiatives because of what it enables these companies to achieve for their customers:

    • Delivering features and updates that customers need when they need them
    • Delivering applications that meet performance and quality expectations of customers
    • Delivering secure, compliant applications (for external and internal customers)

    Continuous delivery enables continuous devotion to the customer experience.

    Continuous Release: Fast Customer Response

    With continuous delivery, you establish an application release workflow that automatically connects a developer’s update to parallel testing to staging and ultimately to production release. Because of the underlying end-to-end automation technology, these steps can happen quickly, seamlessly and with little to no manual intervention. Some might call it “push button release” or “zero-touch release.”

    It’s a controlled, tracked, governed, collaborative process. Application stakeholders stay aligned as application changes traverse the pipeline. Your customers can have access to fixes, updates and new innovations in days instead of weeks or months.

    Continuous Testing: Building in Quality

    In contrast to the significant time penalties and shortfalls that can happen with manual testing, in the continuous delivery pipeline, testing is shifting left and happening in parallel. Hand-offs and feedback loops are automated and efficient.

    Testing can happen earlier and without delay with the help of test environment simulation. Testing is on target through automatic test case creation, even from requirements. Testing is real-world with on-demand test data generation. And testing is rigorous with developers able to performance test apps at their end. The continuous testing that occurs as part of the process helps to build in quality and ensure top performance before reaching the customer.

    Continuous Compliance: Audit-Ready Processes

    Ensuring applications are compliant and secure is critical for your customers. It’s making sure customer information is safe and that application changes are tracked sufficiently for SOX or other reporting. It’s also about helping out those internal “customers” like auditors to prove compliancy and easily build reports.

    An automated continuous delivery pipeline can track releases, apply role-based governance, orchestrate proper data masking, deploy security policy updates and provide an audit trail for application releases—who did what, when and why. All this data can be collected and reported easily, which saves time and effort for auditors. You essentially stay compliant and secure all the time.

    Customer Satisfaction Through Automation

    Financial services companies are laser focused on using technology to delight and retain customers. And continuous delivery is the application delivery practice that’s underpinning these efforts. The companies that are exceptional at this, with thousands of deployments per month, are using automation tools such as Application Release Automation (ARA). These tools are the backbone of continuous delivery, providing the automated orchestration, governance, tracking and reporting for your pipeline—development through production.

    That’s why I’m not surprised that leading financial services companies make up a large portion of CA’s release automation customers, including Euroclear, GM Financial, ING, Jewelers Mutual and Western Union. Our customers put high value on delivering excellent customer experiences and are implementing modern software delivery methodologies, practices and associated tools to support their efforts. GM Financial recently said it is “the software company that does auto finance.”

    If you are serious about customer satisfaction and staying ahead of nimble competitive threats in the market, you must get serious about end-to-end automation. It’s time to truly embrace the practice of continuous delivery to be able to consistently release applications that are progressive, always compliant and completely customer-satisfying.

    — Patricia Johnson

  • Predictable Progress: Tracking DevOps Maturity Metrics

    Predictable Progress: Tracking DevOps Maturity Metrics

    As DevOps methodologies continue to evolve, we’re naturally seeing an increased emphasis on the cultivation of related maturity metrics.

    For instance, in the 2016 State of DevOps Report, researchers with DORA took an initial stab at creating relevant ROI measurements.

    Similarly, a new report issued by researchers Coleman Parkes, sponsored by CA Technologies, offers additional evidence that as agile and DevOps processes continue to expand, today’s practitioners are increasingly employing metrics to optimize their efforts.

    The report, titled, “Accelerating Velocity and Customer Value with Agile and DevOps,” finds some form of adoption among nearly every enterprise, with 87 percent having adopted agile to some degree and 73 percent leveraging DevOps.

    Related to the overall maturity of these practices, those organizations that are moving to embrace the techniques most broadly are predictably seeing greater returns. Yet, despite the widespread adoption, only a third have deployed either practice widely, according to the research.

    Percentage of Advanced Adopters Reporting Improvements in Customer Experience

     

    Based on a survey of 1,770 senior business and IT executives, the study also closely investigates the specific KPIs that organizations are using to gauge how agile and DevOps initiatives are translating into customer interactions.

    Most notably, “advanced” agile and DevOps adopters have observed more than an 87 percent improvement in overall customer experience, compared to “basic” adopters.

    In terms of how those efforts are affecting business drivers, Coleman Parkes finds:

    • Advanced agile practitioners are experiencing a 40 percent improvement in time-to-decision, compared to 33 percent for basic users.
    • Advanced DevOps adopters have noted a 42 percent improvement in speed-to-market, compared to only 24 percent for basic practitioners.

    Key Performance-Invoking Indicators

    To that end, the research highlights specific KPIs that organizations are using to measure the impact the agile and DevOps practices are having on customers. In fact, the study finds that between two thirds and three quarters of all the organizations surveyed have established such measurements.

    At least half of these focus on business or customer-related metrics, reflecting how “critical software has become to businesses’ ability to achieve their core mission,” Coleman Parkes researchers note.

    Among the mostly widely invoked metrics, include:

    • Business growth (specifically revenue): over 73 percent
    • Operational or process efficiency: over 73 percent
    • Employee productivity: over 73 percent
    • Customer experience: over 71 percent
    • IT-related costs: over 71 percent
    • Speed-to-market: over 71 percent
    • Customer satisfaction (via NPS): over 70 percent
    • Time-to-decision: over 70 percent
    • Quality of development: over 70 percent
    • Employee retention: over 64 percent

    If increasing applications delivery speed and overall organizational velocity are, in fact, the primary goals of engaging agile and DevOps, the research bears out that the techniques are having the desired effect. After all, the survey finds that time-to-decision and speed-to-market are being accelerated among approximately a third of the organizations studied.

    Related to other notable KPIs, Coleman Parkes highlights that a full three-quarters of adopters have moved the needle on overall customer experience, along with employee recruitment and retention, a significant benefit that was also highlighted in the State of DevOps Report.

    Along with positively impacting customers, the reality is clearly that agile and DevOps are also making a big difference in allowing companies to improve the atmosphere for their workers—a huge benefit when you consider the shortage of talent in IT today, and how much it typically costs to attract new employees, just as DORA’s researchers noted.

    Other key findings by Coleman Parkes include “before and after” metrics that many organizations are observing related to their continued adoption and advancement of the involved methodologies themselves.

    I encourage you to download the entire report, and leverage it to measure how far you’ve come with Agile and DevOps transformation—and where you may need to re-examine your efforts.

    — Aruna Ravichandran

  • Automic Helps DevOps Transformation Sparkle

    Automic Helps DevOps Transformation Sparkle

    Working closely with Automic, an international wholesaler and retailer of jewelery transformed a department of project managers, developers and operations responsible for all of the customer-facing websites into a DevOps organization. As a result, project delivery was completed with 90 percent fewer delays, and first customer-facing releases of projects could be delivered in less than half the time. The usability of its websites increased significantly, resulting in more customer traffic, longer average time spent on the sites and increased revenue.

    Haphazard Development

    Prior to the DevOps implementation, new projects were delivered by “waterfall” project management means. The cyclical resource planning process was based on the project portfolio and business priorities. Project managers then planned project milestones working closely with business stakeholders, business analysts and application developers. Analysts created specifications and developers were assigned to work on packages and tasks to implement them.

    Different web technologies were used with varying levels of dev and ops expertise in each technology. The  Operations team members usually fulfilled requests made during the course of a project as part of their overall daily tasks—for example, to provision a new environment, deploy a package or change the environment configuration.

    This approach had a major disadvantage. Delays in one project impacted the overall resource planning and could have a cascading effect on other projects. Delays in projects could be for multiple reasons, such as waiting for business stakeholder impact, frequently changing requirements, unexpected sick leaves of developers or poor estimates. Other frequent causes included delays in operations tasks such as a deployment or provisioning of a new environment. These delays were caused by unaligned planning as well as a mismatch in priorities between projects and operations. Besides delays, some developers were underutilized, which also was exacerbated because they were specialized in a technology or component.

    DevOps Transformation Solution

    Working closely with the customer, Automic restructured dev and ops by:

    1. Switching the development from a project to a product mode (cross-project development teams based on capabilities rather than assignment of individual developers to projects).
    2. Moving project managers from development micromanagement to focus on major milestones and deliverables to the business.
    3. Enabling some project managers as product owners (project management remained necessary).
    4. Providing developers with agile methodologies through initial training plus ongoing coaching (six to 12 months).
    5. Providing ops with an agile methodology.
    6. Organizing both dev and ops into multiskilled teams focused on individual products rather than technologies.
    7. Aligning ops into delivery teams, initially part-time and later full-time.
    8. Giving delivery teams the end-to-end responsibility for their products, including their operations.
    9. Standardizing the technology stacks within teams (but not across them) over time.
    10. Delivering projects into production (or alpha, beta) in slices (releases) instead of just once to get early feedback and improve.

    Results: Fewer Delays, Better Usability

    By standardizing, this customer has transformed its dev and ops teams, creating an agile, scalable environment that can drive the business forward. The company achieved the following specific results:

    • Project delivery are now completed with 90 percent fewer delays. First customer-facing releases of projects now are usually delivered in less than half time.
    • The usability of websites has increased significantly, resulting in more customer traffic, customers remaining longer on the sites and increased revenue opportunities.

    About the Author/Michael Schmidt

    Courtney-Glymph_avatar_1435225162-96x96Michael Schmidt heads DevOps Practice at Automic, a management and technology advisory service established to help Automic customers to prepare for and transform their organizations toward DevOps. Michael spent his carrier as consultant, entrepreneur and in several product-related leadership positions. He has a passion for building lean IT organizations. Michael holds a joint MBA from New York University, London School of Economics and HEC Paris and a Master of Computing Science.

  • Overcoming Objection to DevOps Adoption

    Overcoming Objection to DevOps Adoption

    The advent of the application economy has made software arguably one the most critical and valuable assets of organizations across a broad spectrum of industries—financial, telecommunications, entertainment, and government, just to name a few. In the era of “app store ratings” and an unprecedented ability of the consumer to easily switch suppliers of whatever they’re consuming, delivering application feature updates as quickly and as safely as possible while maintaining high quality is absolutely critical.

    Most of us with a pulse in the IT world are aware that the concepts and practices we know as “DevOps” and “continuous delivery” continue to dominate the software delivery conversation in IT organizations everywhere. Almost every business my company works with has some sort of continuous delivery or DevOps initiative in flight (with, naturally, varying degrees of maturity and success). And yet, we frequently encounter organizations where these ideas are anathema to many within, are considered overhyped buzzwords from consultants and vendors or, most frequently, simply do not apply to their organization in meaningful way. Others maintain that they have tried and failed so it’s back to business as usual. Many are swayed by a number of DevOps “myths” that often stop initiatives before they even get started. So, what is the objection over and some myths about DevOps that keep some organizations from taking the steps to improved software delivery? We’ll take a look at a few that we have seen firsthand and, in subsequent posts, suggest some ideas and strategies for getting past them.

    Objection: “DevOps may work for some greenfield apps or startup but that’s not us.”

    Many of our most reluctant customers acknowledge the benefits of DevOps and continuous delivery but maintain that their systems are too old, too monolithic, mainframe-dependent, etc., to reap any tangible benefits from a transformation. In other words, “it doesn’t apply here.” This point of view is especially frustrating because the benefits to organizations like these can be just as dramatic and transformative to the culture and IT “psyche” as found among the “unicorns.” Maybe even more so. As the 2015 “State of DevOps” study stated, “It doesn’t matter if your apps are greenfield, brownfield or legacy—as long as they are architected with testability and deployability in mind, high performance is achievable.”

    Sometimes these groups will look to hybrid strategies such as bimodal where greenfield projects, innovation labs and other internal IT incubators are chartered to use new technologies and methodologies such as DevOps while the rest continue on as always. Opinions differ here, but these strategies generally are fine as a “way station” within an overall transformation road map with the potential to impede progress if accepted as the status quo. If legacy applications still change with some frequency and if deployments are painful for those involved, then those, too, should be included in the DevOps road map. We’ve done it at my company, a 40-year-old software company, and our mainframe team led the way.

    Objection: “We are doing fine as we are.”

    Another common category we encounter is the sense that, after some measure of improvement, perhaps the successful adoption of a toolset, that we’ve done enough. Things are better than before, our deployment pain has diminished so we have accomplished what we set out to do. A corollary to that is “we’ve implemented [Jenkins/Chef/Puppet/Cloud/etc.]” implying a belief that implementing one or more of these  tools is, in effect, “doing” DevOps.

    Successful DevOps is not about adopting a tool or even making measurable progress in organizational goals. DevOps is actually about embracing a culture of continuous improvement, collaboration and, perhaps most importantly, focusing first on maximizing value for your customers. It’s about adopting patterns such as the Deming cycle—Plan, Do, Study, Act—as a core tenet of the way you approach how you think about what you do. No matter what we do, no matter how well we do what we do, there’s always an opportunity to do better.

    Objection: “Implementing a major change like continuous delivery is simply too large and complex an undertaking.”

    When large, well-established organizations seek to undertake a major change, it’s often a task so daunting, so frequently met with skepticism and cynicism across the spectrum of stakeholders, that the initiative, no matter what it is, appears doomed from the start. Couple that with the culture-shift generally required to affect a successful and genuine DevOps transformation, and it’s no wonder that some senior IT leaders either severely limit the scope of these initiatives or, in some rare instances, veto DevOps outright. Regardless, the belief that their teams are too entrenched in current methodologies to make meaningful progress and the seemingly overwhelming weight organizational inertia stops change cold.

    Transforming organizations that have functioned in, more or less, the same fashion for years, even decades in some cases, is practically incomprehensible for many. Organizational cultures generally evolve over time and changing them is not something that can be accomplished by decree and certainly not overnight. The barrier to even starting is often the sense that “we have too much work to do right now and balancing that against some intangible future state is not something we can take on.” Of course, the problem with that line of thought is that there will always be too much work to do now.

    And, of course, there are many other obstacles. Barriers to entry against meaningful transformation like DevOps frequently emerge when new ideas and thinking collide with the status quo, especially pre-existing processes governing the software development and deployment. These processes generally emerged from the best practices of the recent past coupled with reactions to major problems encountered years ago that linger on as faint echoes of bygone errors. Most of these rules were put in place with good intentions, applicable at the time of implementation but may have outlived their relevance. Others may be regulatory and not optional. Regardless, if there ever was an area where DevOps and continuous delivery can deliver benefits, this is it.

    Many large “traditional” IT shops have, indeed, transformed their culture and fostered environments that continuously improve. So, what do you do? Perhaps the most important step is to decide to take the first step. First, understand why you are seeking to change in the first place. What is the ultimate driver and does everyone, top to bottom, the organization have a clear understanding of that “why”?

    Recognize that transformation is an ongoing process where successes and failures are to be expected in equal measure. Learn from both. Don’t attempt to roll DevOps out as a big bang strategy. Work incrementally.

    In upcoming posts we’ll explore some strategies for moving past objection and making real strides toward meaningful and lasting change. What are some of the challenges you have faced in your company’s transformational journey? How did your teams get past the obstacles that inevitably appear?

    — Jeff Bradley

  • A Ferrari and DevOps: More Similar Than You Might Think

    A Ferrari and DevOps: More Similar Than You Might Think

    In a world where customers aren’t short of options, all businesses are characterized by the need to achieve customer delight. From a technological standpoint, a large part of that hinges on fast-tracking the release of high-quality software. A release every quarter is being replaced by a release every week and sometimes even sooner. Expectations have skyrocketed while the timelines have shrunk even more. It is now imperative for all the different components to sync together effectively to create a competitive advantage for the business that can be sustained over a period of time.

    All the water-cooler talk around DevOps notwithstanding, it’s true identity still varies vastly based on the passionate opinions of participants with varied schools of thoughts. It also bears mentioning that while all of their varied opinions carry a sliver of truth, they also are significantly separated from the heart of the matter.

    To better understand the situation, let’s jump into a story: Once upon a time there was a monk who owned a Ferrari and had no interest in selling it. Every morning when the monk left to teach his mindfulness class, there were three blind men who were captivated by the sound of its engine and the smell of burning rubber. And, yet, they couldn’t see the very object that had captured their fancy. So, one fine day they decided to touch the Ferrari and exchange notes.

    The first man touched the broad wheels of the Ferrari and exclaimed that it was a large contraption made of soft rubber. The second man ran his hands across the exquisite curves of the car and said it was like an ancient Greek statue, while the third one placed his hand on the Ferrari’s windows and concluded it was a moving glass palace on wheels. Although each was right in his own way, none came even remotely close to capturing the essence of a Ferrari.

    By now, you don’t need a monk to tell you that the story of DevOps is very similar. For some, DevOps is all about inculcating the right culture so that different groups can work together seamlessly to achieve a unified goal. For others, it is about establishing the right processes and practices that are in sync with an organization’s business goals. And for those with an axe to grind or proprietary tools to sell, DevOps is all about achieving automated nirvana.

    However, the ground reality is that software development teams constantly are facing increased pressure from business leaders to deliver faster than ever before. The business leaders, in turn, are under the hammer of market forces that require them to accelerate or die. The need of the hour is to deliver high-quality software at the rate of knots, while untangling any that might impede the time to market.

    Continuous Everything

    We at Happiest Minds believe the simple approach to DevOps is one that is “continuous” and at its core has the agile mantra of “people over processes and processes over tools.” The idea of continuously evolving and adapting to changing requirements and demands has been captured in what we call the 7Cs of DevOps:

    picture1The main objective is to ensure agile delivery by embracing continuous planning, continuous development, continuous Integration, continuous deployments, continuous testing, continuous monitoring and continuous feedback.

    However, the cultural component of DevOps cannot be overemphasized. A large part of the success or failure of any DevOps engagement depends upon how willingly it is embraced within an organization and the kind of executive sponsorship it receives from the powers that be. The three widely recognized cultural models that most organizations come under are pathological, bureaucratic and generative. Needless to say, organizations that are riddled with a pathological or bureaucratic culture are likely to experience the least amount of success with DevOps because such organizations tend to cover up failures and eventually pin them on the most susceptible scapegoats.

    The breeding ground that DevOps needs to flourish is a generative culture where information is shared freely and openly, the leadership encourages employees to learn and experiment with new ideas and failure isn’t looked at as the end of the world but rather an opportunity to learn and grow.

    Eventually, organizations will have to embrace DevOps as an integral part of their strategy and not just as a liberal, forward-thinking experiment that scores them some brownie points. But it will take some doing, both at the grass roots and in the board rooms. One has to remember that a lot of people are easily attracted to a Ferrari, but perhaps not to the grind that goes into owning one.

    The idea of having a successful DevOps program is much the same—it’s not just about engaging the best vendor or choosing the right tools or paying lip service to creating the right culture; ultimately, it requires overcoming organizational inertia, resistance to change and making a long-term commitment to the philosophy that takes a larger view of how DevOps can help businesses stay one step ahead.

    About the Author / Arsalaan Kashif

    arsalaan-kashifArsalaan Kashif is associate director of Marketing, Product Engineering Services at Happiest Minds Technologies and has a keen interest in all emerging areas of technology and innovation. Having worked with Unisys, Oracle and HCL Technologies for over a decade, he has experience with taking to market products and services across areas as diverse as application services, cloud computing, DevOps and big data analytics to name a few. Outside of work, Arsalaan enjoys watching noir films and reading John Irving classics. Connect with him on LinkedIn.