devopsy.kinsta.cloud

Tag: customer-first

  • Spurring the DevOps Adoption Journey

    Spurring the DevOps Adoption Journey

    Every few years, the IT canvas is splashed with a new initiative that sparks enthusiasm among businesses and technologists alike. DevOps is one such philosophy gaining significant momentum in today’s digital transformation landscape. At the same time, the concept remains misunderstood and adoption is slow.

    DevOps embodies Development plus Operations within software development. Traditionally, these two parts of an organization have operated siloed from one another with marked differences in both ethos and approach. The result: delays in launching products and releases to the market. The fundamental principles of DevOps are to reduce barriers between Development and Operations; increase Development autonomy; and to automate Development and Operations activities to reduce wait time (and waste from a customer’s perspective), thus enabling faster time to market—all while keeping the end customer at the center.

    Planning the Adoption Journey

    Here are four different aspects an organization should consider before starting the DevOps adoption journey:

    Conduct an as-is continuous delivery assessment on product development practices and processes within the organization

    This will best determine an organization’s current maturity level across several different parameters, including:

    • Culture and organization
    • Build management and continuous integration
    • Environments and deployments
    • Release management
    • Testing and verification
    • Data management
    • Design and architecture
    • Information and reporting

    This process also includes identifying current automation levels and opportunities to automate, inclusiveness of tools and environments supporting continuous delivery, and an assessment of existing product design to determine if it lends itself to frequent and fast deployments.

    Map the journey of a piece of code from a developer’s desk all the way to when the consumers use it

    Utilizing a development pipeline assessment to study the life cycle of a piece of code through its journey from a developer’s desk to production will best identify “waste” during the life cycle. This assessment should bring out critical information, including the number of environment hops, test pyramid maturity and level of continuous testing, level of provisioning and deployment autonomy and its automation.

    Establish a culture of inclusiveness, autonomy and a sense of a ‘common goal’ within the organization

    Product management, development and operations teams should have a common mission and goal for the product, sprint or release they are working on. The definition here should be the value delivered to the customer as opposed to the value of code, test results, or individual deployment steps. Including operations roles within a close-working scrum team benefits this cause by:

    • Bringing in common views on what a product, release or sprint is intended to deliver.
    • Creating an opportunity to bring forward and address operations needs during the development cycle.
    • Creating a better understanding of mutual expectations and empathy for delivering outcomes that meet customer expectations.

    Measure and track

    Finally, determine parameters the organization would like to establish to track progress towards a successful adoption. The key here is to have a few, simple metrics that truly reflect “value to the end customer.” Here are a few commonly considered metrics:

    • Production deployment frequency: The number of product releases within a specified time.
    • Average lead time for a production change: The typical amount of time it takes for a piece of code to traverse from a developer’s desk through production.
    • Average production recover time: The time taken to bring back production systems after an incident involving a release, release rollback or system outage.
    • Change failure rate in production: The number of releases that did not stick in the live environment and needed either a rollback or an immediate emergency fix.

    The goal and a true measure of successful adoption would be an improvement of all these parameters over time. Internally, they would require strong engineering rigor and cultural realignment to be able to improve these customer-facing metrics.

    Navigating DevOps adoption successfully is neither easy nor fast for a number of reasons. DevOps encompasses different parts of the organization, which historically may have operated in silos and with different ethos. DevOps also questions the status quo regarding engineering roles and practices, and focuses on automation and reskilling, all of which need both upfront time and effort investment. Finally, DevOps believes in and propagates continuous learning and improvement, whereas many organizations may have more stepwise-based programs in place.

    For a midsized IT organization, it could take anywhere from 18 to 24 months or more to be able to reach a reasonable steady state. That’s why it is important to carefully craft a charter that encompasses the above parameters before embarking on this DevOps adoption journey.

    About the Author / Amit Gupta

    Amit Gupta is leader of Ness Digital Engineering’s DevOps practice. He has several years of software delivery background. He has keen interest and has developed deep expertise in establishing practical software development processes especially for globally distributed teams. Amit currently leads Ness Digital Engineering’s DevOps practice, and engages with several customers on such areas as improving engineering effectiveness, engineering tools and process transformation. Connect with him on LinkedIn.

  • Bucking Bank Bureaucrats: From Convergent Thinking to Divergent Doing

    Bucking Bank Bureaucrats: From Convergent Thinking to Divergent Doing

    As customers, longstanding and new, the way we interact with banks and manage our personal spending, borrowing and saving is experiencing drastic change. New digital offerings in the form of apps and online banking show commitment to customer centricity, but overall, banks are slow to adapt to the pace of change. The vast majority of bankers do recognize the strategic need to respond to their industry’s digital disruption, and are busy assessing and developing transformative technologies such as mobile, blockchain and artificial intelligence, trying to find an emerging market need and a robust business model.

    How Should Banks Adapt?

    The operating environment of banks is unpredictable and, therefore, requires organizational agility. This agility requires a careful analysis of customer needs and (potential) capabilities. Bankers must ask, “How can my bank move from convergent thinking to divergent doing?”

    picture1

    From a strategic perspective, it’s essential to understand whether the person/organization wants to be a disruptor, innovator, ideator or bureaucrat. This differentiation defines the right strategic options available to them.

    N.B.: A quick proxy answer to the above question is the design of the bank’s reception and organization of the people working there, to see if it is like every other bank, or is in some way distinctive.

    Value Triangulation and Differentiation

    Every banking CEO needs a clear strategy that addresses their organization’s internal and external challenges. There is one global commonality for a strategic foundation: Every bank needs to deliver change rapidly and frequently. The better a bank is at improving customer experience, the more likely it will survive the onslaught of disruptors and innovators. Additionally, most banks must deliver cost reduction and drive income. Customer desire, the third corner of the triangle, is not a familiar banking concept, but a successful value triangulation delivers customer desire in the most efficient way possible.

    picture2

    This isn’t about value chain mapping and cost re-engineering; it’s about creating great customer experiences with adaptive capabilities and capital-light business models. All three values must be understood and practiced throughout the entire organization, especially among boards, chief executives and key decision makers to make adaptive banking possible.

    Customer Experience Comes First

    A culture of centralization, product-centricity and control-via-process stifles change. To be adaptive and create their own Digital DNA, banks must form new work spaces and ways of working. When bank employees don’t use their own company’s products, they are out of touch with the customer experience. They also may excuse customer complaints based on their organizational knowledge. Employees need to be the bank’s most critical customers, and ought to feel fully connected to other customers and their experiences.

    New, lean business models should flow through the organization and align to the desired customer experience. The business leaders who identify the “priority customer experience features” will focus the organization on accelerating delivery momentum. Rather than requesting large-scale, product-led programs, leaders need to focus on continually launching and redefining small-scale features.

    picture3

    Doing so moves away from the grand strategies or silver bullet approach so often prevalent during annual planning cycles and shifts toward agile, customer-centric strategies. Organizational change is fundamental for creating adaptive banks with Digital DNA.

    Fail Fast, Succeed Even Faster

    To accelerate growth, adaptive technology architectures and agile software delivery methods need to be available to deliver the relevant features. A “deliver, measure and learn” approach will amplify feedback across the organization to drive commercial decision-making. This will allow banks to fail fast, yet succeed even faster. The ongoing cycle—ideating, designing, building, shipping, measuring, learning and (of course) adjusting customer features—needs to become the norm.

    By becoming adaptive, the bank’s capabilities (people, methods, technologies, values) become more attuned to customer needs, making it far easier to deliver personalized offerings. For example, the bank’s data can be used to create feature personalization, allowing customers to pick and choose the right features for their needs. A customer should always be able to overwrite the choice an algorithm provides.

    Innovation, Transformation and Beyond

    Currently, the most apparent transformation desire and delivery exists in IT departments as opposed to business departments. Agile ways of working are often still alien to most bankers in product, finance, compliance, marketing and front-line teams.

    The banking playbook has already been rewritten for the digital age. It’s an exciting time to realize great change and how disruption/innovation can become commercial reality—this means bucking the system.

    About the Author / Darren Oddie

    Alistair Bayliss

    Darren Oddie is strategy director at Wipro Digital, where he works with global financial services companies on digital transformation and innovation. He’s had hands-on experience of designing and building financial services brands from a blank sheet of paper to industry leading propositions in both corporates and startups. He’s delighted that banking and customer experience are now regularly mentioned in the same sentence. Connect with him on Twitter.