Multi-Speed IT Environment — Lessons from field

In majority of phased enterprise agile transformation programs, Multi-speed IT is unavoidable. When I say Multi-speed IT, I refer to a world where agile and waterfall (legacy) initiatives co-exist and need to work hand in hand to deliver business outcomes.

In last two decades, I had the opportunity to work with different enterprises in variety of industries helping their transformation journey. Every organization is different even if they operate in same industry. The business needs, enterprise portfolio and IT landscape vary from one organization to another. The agenda of transformation also differs from one to another resulting in different approaches, initiatives and timelines. No matter what the approach an organization adopts for transformation (change and growth), the journey from current state to future state requires innovative strategies to sustain business operations during the period of transformation.

In real world, no system works in isolation i.e. agile initiatives depend on integration with traditional legacy systems and vice versa. The pace at which you can deliver value from your agile initiatives is usually limited by how fast your traditional waterfall systems can unblock your integration touchpoints, release new features or patches etc. To make this more challenging, most enterprises have multi-vendor landscape with vendors who are locked into waterfall ways of working. It’s a complex world where difference in “ways of working” can cause undesired outcomes.

When leaders decides to roll out Agile / DevOps practices, the transition time to master the art of delivery is usually few months’ worth of collaborated efforts collectively by everyone involved. The questions that leaders should aim to solve is how best we can reduce the “duration” and “severity” of friction (read pain) in such Multi-Speed IT enterprise environment. Many people use the term “Bimodal IT” (popularized by Gartner) to describe this situation. I prefer to use “Multi speed IT” as it sounds more appropriate to depicts the complexities of multi-initiative, multi-method, and multi-vendor enterprises.

Collaboration and co-ordination is essential to prevail continuous value delivery. However, there isn’t an optimal solution that can address all aspects. You need to adopt a holistic approach with end to end consideration towards idea to production. I’ve compiled a list of lessons learned from my experience below which you could use as considerations for your transformation journey:

1. Establish Portfolio Cadence and fund Architectural runways

Traditional portfolio management practices are not designed to support the dynamic needs of new business world where customers are demanding instant gratification, faster services and never ending pursuit of a better experience interaction over interaction. A new portfolio management approach is required to support transformation needs of the business. From a centralized control and centralized annual planning, portfolio management need to shift to decentralized decision-making and decentralized cadence based planning. Hypothesis driven funding, innovative account etc. are hard and requires more rigor & engagement from everyone than traditional portfolio management. These changes can affect entire organization and many a times these are hard. One approach that worked well for me in past was to create a dedicated squad of leaders that can define the new ways of working for portfolio management practices such that it supports a balanced working model.

One of the major challenges enterprises face is creating an architectural runway that ties together the legacy world with new world. Architectural runways are critical for enterprise strategy realization. Without proper investment in architecture advancements, businesses suffer sub-optimal outcomes. Usually leaders only focus on funding new digital initiatives, overlooking the need to invest in back-end foundational layers towards currency, health and resilience. It is essential for leaders to allocate sufficient investment towards an architectural runway balancing innovations vs health/resilience.

2. Use Solid DevOps Engineering Practices everywhere

The gap between agile and legacy worlds can be minimized by applying solid DevOps engineering practices. There is a common myth that DevOps practices are not applicable in waterfall world. The underlying assumption people make is the legacy systems cannot take advantage of Agile and DevOps practices. In my view, such assumption is fundamentally flawed. Irrespective of the type of application / system, Agile & DevOps practices can help to speed up business outcomes.

DevOps practices can help streamline application lifecycle management when applied correctly in any environment, any methodology. Applying DevOps practices under each stage of application lifecycle can reduce waste and increase speed. Some of the most common practices are as below

• Development — code branching, versioning, API versioning etc.
• Testing — test automation, test coverage, load / stress test simulations etc.
• Build — continuous integration, build management etc.
• Deploy — automated deployment, provisioning, infrastructure as code etc.
• Operate — application monitoring, infrastructure monitoring, log analytics etc.

These practices could unblock traditional world from manual efforts and can help minimize scheduling conflicts with agile world. For agile initiatives, these practices should be applied as prerequisite. Without these practices in action, agile initiatives are bound to struggle to deliver desired outcomes.

3. Map dependencies during planning

Newly formed teams usually overlook the importance of mapping dependencies early. As a result, dependencies are discussed only as an afterthought (when I am ready, I will see who else is ready). Those who live with the myth that agile requires no planning — they become the prime victims of frustration when dependencies pull them off their release schedule and such experiences turn them into naysayers who criticize all good things in agile.

The degree to which dependency mapping is important is directly dependent on the nature of the integration layer between legacy and new age systems — if the integration layer provides sufficient decoupling from the legacy, then there is less emphasis on doing it upfront. In general, all initiatives should have a dependency map that clearly lists which applications they need integration to or from and sync their test and deployment schedules using checkpoints/planning meetings.

Journey maps provide a great tool for mapping end to end flow. As part of the dependency mapping, teams should use journey mapping to map out dependencies with underlying legacy systems.

4. Establish Release Planning Cadence

Release planning is another activity that needs major collaboration across teams. Out of sync releases, cause delays and even nullify the work in certain cases. Joint release planning is key to drive results in a Multi-speed IT environment.

As part of the work breakdown, the team should synchronize how epics / features / stories (that are needed in the Agile iterations) will sync with the underlying legacy apps. The size and shape of Release planning process could be defined by the level of coupling between your components / apps. For tightly coupled systems, release planning would require Product Owners and Scrum Masters from all the system areas. For loosely coupled systems, release planning can be done with representatives from the dependent systems. From an agile planning perspective — it is key to have the integration layer roadmap in hand as well as integration Product Owners in attendance at the Release Planning event — as typically the integration layer needs to commit on the fly to providing integration a sprint or two ahead of the consuming team(s).

Some teams use service virtualization tools to work around the tight coupling. However, what gets virtualized should follow a cadence to use “current” or “most recent” versions to avoid technical debt.

5. Creating Bridge or Abstraction Layer for decoupling

Whilst monolithic legacy systems are hard to decouple, it is imperative for the organizations to invest in creating a “Digital Abstraction Layer” of APIs, ideally built on micro-services and having a proactive approach to strangling legacy systems — either via a replacement approach (i.e. implement a next-gen equivalent that has native abstraction services) or else deconstruct the legacy system and then starved it of inbound transactions. Building the Digital Abstraction Layer is usually build on a cloud native platform and it requires long term commitment at the enterprise level. It should be a strategic imperative for organization to fast track build of such abstraction layer and fund it sufficiently to form the bridge that can accelerate business outcomes in a Multi Speed IT environment.

Note: During transformation period of an enterprise, Multi-speed IT is understandable. However, leaders should aim to consolidate and plan uniform ways of working across enterprise as the end state.

This article was originally published at http://www.sandeepmvp.com/multi-speed-it-environment-lessons-from-field/