“It’s only after you’ve stepped outside your comfort zone that you begin to change, grow, and transform.”
― Roy T. Bennett
Digital transformations are keeping businesses alive and fueling their future. In turn, corporate leaders are discovering that transformative change is built on a strong vision of improving value, efficiency, customer experience and loyalty. These goals are realized when an organization drives end-to-end change through service design, product innovation, operational improvement, technology deployment and talent development. Yet end-to-end change is not easy and requires massive effort.
IT initiatives like DevSecOps, cloud and legacy modernization underscore the scope of such an effort and rolling out these projects requires enormous time, money, and buy-in. Is there a case for business and IT to unlearn how transformation is conventionally delivered and make way for fresh approaches? Our experience of working with leading global businesses suggests that the answer is a resounding yes. A change in the approach can reduce effort and accelerate transformation while delivering target value.
With this new approach, organizations identify their desired business outcomes, apply the most appropriate foundation technologies to produce those outcomes, and use a collaborative approach rather than one that is business- or IT-led. This paper will present some areas where a change in mindset and approach can simplify and shorten the transformation process.
Unlearn the program mindset; embrace a product mindset
Gone are the days when the business side of an organization outlines a five-year-plan and IT creates long-drawn projects to support it. Today, new businesses models, technology, and customer demands challenge us continuously. To maximize the value of an end-to-end application transformation, organizations should not leave programs and priorities to the product owners alone. Instead, they should enact programs of continuous change using inputs from customers obtained through research and data collection.
This is not as difficult as it sounds. Customers have proved willing to use fewer features while providing inputs that help prioritize the creation of additional features. Consider the Apple Watch Series 4, released in September 2018. Customers started buying the watch immediately, but one of its most talked-about features—the ECG app, which allows customers to take an electrocardiogram from their wrists—was delivered as an update later in December. Organizations can apply this same model to transformation, beginning with the minimum number of features necessary to obtain feedback then adding or transforming features as responses come in.
Unlearn building a team based on experience; focus on learnability
In most organizations, processes and systems are built over decades and result in monolithic platforms in the front, middle, and back offices, raising barriers to change. While the front end attempts to innovate, breaking away from the established and familiar processes of the middle and back offices can be overwhelming.
Across scores of transformation initiatives, we have observed that culture presents a major obstacle. Leaders need to accept this and show their teams how new ways of working can drive business goals more efficiently. New ways of working can make some older project delivery roles redundant. To balance this, the focus should shift to re-skilling teams and helping them adapt to new ways of working.
In an environment of continuous transformation, those who can’t be re-skilled can continue to support legacy systems, then either be re-skilled over a longer period or find a more suitable role.
Unlearn the traditional team composition; learn the right mix of model, method, machine, and manpower
Tech teams have traditionally driven transformation, which frequently results in pure technological ingenuity, with the business seeing little or no value. To ensure that transformation produces value, organizations must align transformation to value streams from the get-go and ensure that product owners are in place to prioritize and track the transformation value. As long as the transformation is business led, the delivery can be through a macro, a batch, or a microservice. The key is to build machines and models that can support the transformation at scale.
Unlearn target architecture; learn Agile and responsive architecture
In the new `fail-fast, fail-often’ paradigm of development, many IT teams struggle to adjust to the cultural and skills needs of Agile, DevOps, Microservices, Containers and Responsive Architecture that drive rapid, feature-focused and iterative development. Agile adoption flies in the face of target architecture, and recognizes that the development team cannot plan for everything in advance. In contrast, traditional development teams don’t begin until all the requirements are finalized.
The traditional approach was viable when the shelf life of technology was between 12 and 15 years. Today’s shelf life is between two and three years at most, making it essential that organizations do not delay releasing new features. Target architecture risks just such delays, which can diminish the value of the features themselves. A shorter shelf-life demands rapid, feature-focused, and iterative development – responsive and reactive architecture and an Agile approach. This responsive approach to development also eliminates the pressure to predict from the outset every feature a customer will want.
The above is also true for technology selection. While organizations must have foundation technology to start building, architecture and design should be agile and replaceable as transformation moves forward.
While Agile has been deployed by software development teams, business leaders can also benefit by adopting this iterative technique. Indeed, Gartner has observed that “top-down strategic adoption of agile is now growing, driven by digital business initiatives that demand the quick delivery of solutions to new types of problem.”1 Moreover, the ability to better align development teams and business needs was a reason for adopting Agile, according to 49 percent of the respondents in a survey commissioned by VersionOne.2 There is no transformation without Agile, DevSecOps, Cloud, APIs, Microservices, and other essential frameworks and tools. Building the right enablers at right time is important. Rather than finalize the target architecture at the start, organizations must first put in place only the architecture needed to get started in their Agile adoption and then add enabling capabilities.
Stepping up to success
Transformation is everywhere. It is the approach to transformation that will separate winners and losers.
Our experience shows that a delivery model that is design-led, value-stream driven, and based on minimum viable product (MVP) best enables organizations to get products to market faster, correct course, and scale up. We have also seen that transformation models have to be customized for organizations based on multiple parameters. For example, an organization with offices in San Francisco will transform at a different pace than one in Sao Paulo. Likewise, an MVP model that will work for an organization with a loyal customer base may not for an unknown startup launching a new product.
The crucial step to success is to boldly unlearn traditional end-to-end transformation paths, let go of the ways things have always been done, and replace those ways with methods, models, machines, and manpower that can deliver within a framework that is fail-fast, learn-fast, and recover-faster.
2 The 12th Annual State of Agile Survey https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report