5 Tips for Maximizing Value in Multi-Speed It Environments
While some parts of your IT infrastructure adopt Agile and leave those using waterfall behind, how do you get the most out of a fragmented process?
Join the DZone community and get the full member experience.Join For Free
In the 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 the last two decades, I had the opportunity to work with different enterprises in a variety of industries helping their transformation journey. Every organization is different even if they operate in the 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 the real world, no system works in isolation; 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 a multi-vendor landscape with vendors who are locked into waterfall ways of working. It’s a complex world where the difference in “ways of working” can cause undesired outcomes.
When leaders decide to roll out Agile/DevOps practices, the transition time to master the art of delivery is usually a 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 depict the complexities of multi-initiative, multi-method, and multi-vendor enterprises.
Collaboration and coordination are essential to maintaining 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 the 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 the new business world where customers are demanding instant gratification, faster services, and the never-ending pursuit of 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 needs to shift to decentralized decision-making and decentralized cadence based planning. Hypothesis-driven funding, innovative account, etc., are hard and require more rigor and engagement from everyone other than traditional portfolio management. These changes can affect entire organization. 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 the 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 the waterfall world. The underlying assumption people make is the legacy systems cannot take advantage of Agile and DevOps practices. In my view, such an assumption is fundamentally flawed. Irrespective of the type of application/system, Agile and 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 the application lifecycle can reduce waste and increase speed. Some of the most common practices are as below
- Development — code branching, versioning, API versioning
- Testing — test automation, test coverage, load/stress test simulations
- Build — continuous integration, build management
- Deploy — automated deployment, provisioning, Infrastructure-as-code
- Operate — application monitoring, infrastructure monitoring, log analytics
These practices could unblock the traditional world from manual efforts and can help minimize scheduling conflicts with the Agile world. For Agile initiatives, these practices should be applied as a 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 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 the 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 microservices 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 the 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/
Published at DZone with permission of Sandeep Joshi. See the original article here.
Opinions expressed by DZone contributors are their own.