How to Successfully Scale Agile and DevOps – Part 3: Driving Success with Technology

Welcome to my third blog post in the “How to Successfully Scale Agile and DevOps” series. In my previous blog post, I covered key propositions of the “People” dimension of driving agile at scale. In this blog post, we will deep dive and look at the critical “Technology” dimension and discover important elements that I believe can be leveraged to implement process automation and strengthen the digital strategy from a technology perspective.

The technology dimension of scaling Agile hinges on two ‘prerequisites’ and two ‘continuums’.

Prerequisites

There is a common pattern of two prerequisites in the technology area that successful organizations have driven:

1. Technology Standardization

One of the prerequisites for the continuums to be successful is to reduce the number of technologies that enterprises must manage. In a large bank, I noticed that they had around 5 business process management (BPM) tools for process automation and case management and were evaluating a sixth one to be onboarded. This is a recipe for disaster as the more technologies such as BPM tools are utilized, more will be the need to have DevOps pipelines and more difficult will it become to drive continuous delivery. 

One standard technology, say one BPM tool if we take the above instance into account, for each area in the simplified reference architecture given below would be ideal:

My suggestion while embarking on this journey would be to standardize on scaling Agile and DevOps tools and technologies that provide the ability to code rather than configure because the future is about running “everything as a code”.

2. Legacy Modernization

Legacy modernization has become mainstream because of the advent of agile methodology, DevOps tools, and more importantly, micro-services architecture which demands monoliths to be broken. There are many digital strategies that pundits profess for legacy modernization but the ones I have found to yield benefit are:

• Wrap-around strategy where we wrap the legacy architecture with a modern layer which could be a micro-focus layer, an application programming interface (API) layer, or a data lake layer.
• Rebuild strategy where we identify digital use cases in the legacy applications and rebuild them in a modern way or rebuild the whole legacy infrastructure in a modern way.

Whatever be the digital strategy that works for you, please embark on a legacy modernization drive. Value is not realized just by changing things at the front-end layer, value can only be realized if it trickles down to the lowest layer of the reference architecture.

Continuums

Now that we have seen the prerequisites that can define your overall digital strategy, let’s come to the interesting part of ‘continuums’. I termed these ‘continuums’ because I don’t believe there is an end to these tenets. I am seeing them evolve rapidly and taking different forms and shapes.

Enterprise DevOps

According to the State of DevOps report by DORA, there is a direct co-relation between driving high maturity in DevOps and organizational performance, which thereby, creates better business value. The report found that enterprises that are performing well on the two key DevOps metrics of ‘throughput’ and ‘stability’; including faster lead times from commit-to-deploy, lower change failure rates, and faster incident recovery times; have a significant edge over low performing businesses.

To drive improvements in the above metrics, the most effective way of implementation that I have come across is to adopt the strategy of waste elimination from lean management. What is waste in software development lifecycles? Handoffs. Every handoff is a waste as it reduces throughput, increases the risk of quality, and creates differences. Given below are the different hand-offs that happen in a typical software development lifecycle (SDLC) and the DevOps tools and techniques that can be adopted to eliminate these handoffs.

H = Handoffs

Problems

• People-dependent
• Information leakage
• Competency leakage
• Accountability issues
• Too many touchpoints for business
• Cultural issues
• Higher cost
• Longer go-to-market (loss of competitive advantage and opportunity)

Each of the tools and techniques to reduce handoffs can be categorized into following areas of DevOps: Continuous planning, continuous integration, continuous deployment, continuous inspection, continuous provisioning, and continuous monitoring. Some of these areas are evolving, for instance, continuous monitoring is evolving into observability as a code. If you have not commenced your DevOps journey, then the best place to start would be in an area closer to production. 

Since we are talking scale here, the key point to note on DevOps is to drive it at enterprise level and not at a project or program level. I strongly believe that enterprise DevOps definition available as a platform should be centrally driven while its realization can be done by the feature teams or squads. Though the initial few months (max. 6 months) can be driven through allowing closely monitored experiments across the enterprise, the learning of these experiments should be brought in to the central enterprise DevOps platform. Apart from implementing the tools and techniques called out earlier at an enterprise level, the enterprise DevOps team would also look at improving developer experience through developer portals which can be one-stop-shops to educate on the tools and pipelines in the platform.

I don’t think any enterprise can realize the true value of scaling Agile if they do not mature on their DevOps practices at an enterprise level and across all DevOps areas.

Platform as a Marketplace

Interestingly, as we speak of feature teams and squads, platforms are also becoming one of the key needs to drive Agile at scale. Though I will focus here on technology platforms, the same applies to business platforms like pricing, contact centers, and KYC platforms, among others. At an enterprise level, there are always redundant things that teams end up implementing. Reducing this waste of redundant code is important to drive reusability, leading to standardization, higher efficiency, and improved governance and control. This can be achieved through enterprise platforms.

Below is a summary snapshot of possible platforms that I envision in an enterprise:

In a digitally mature enterprise, enterprise platforms need to be subservient to feature teams/squads. Platforms should exist to make the life of feature teams easier and simpler to add value to business. Thereby, platform backlogs must be filled by feature teams (specifically chapter leads) and platforms must be rated by feature teams for their ease of use and ability to add value. This inverts the pyramid of a platform setup which is important to drive digital at scale. Likewise, to setup a platform, a platform team must be equipped with the following squads (2-4 people per squad):

• Onboarding and governance squad: The mandate of this squad is to onboard new tenants into the platform and define standards and guidelines that tenants must adhere to. In its matured state, this squad develops a developer portal with a predefined DevOps pipeline.
• Business acceleration squad: This squad can be directed toward developing reusable business components by continuously looking at new components introduced into the platform.
• Technology acceleration squad: The purpose of this squad will be to develop reusable technology components by continuously looking at new components introduced into the platform and happenings in the industry.
• DevOps squad: End-to-end DevOps pipeline to take any code introduced into the platform from the time of check-in all the way deployment and then monitor continuously.
• Operations squad: This squad supports the platform and ensures that all environments (development, testing, preproduction, production) of the platform are running per the defined SLAs. This team is also responsible for upgrades, patches, SRE, and chaos engineering.
• Innovation squad (Optional): This squad keeps experimenting to discover new things for the platform.

Finally, enterprise platforms should not be content with just driving reusability and standardization across the enterprise. In its mature form, I have seen them work as marketplaces— marketplaces where anyone in the world can contribute code to the platform. It derives its ability from the open source world but there is no reason why this cannot be repeated in an enterprise provided the platform squads called above can reach a high state of process automation maturity. I have seen at least three instances of platform marketplaces in large enterprises namely an enterprise DevOps platform as a marketplace, an API platform marketplace, and a digital component library platform marketplace.

Measuring effectiveness

As we embark on the two continuums, it is imperative that we baseline certain primary and secondary metrics at the beginning of the exercise and keep measuring them at regular intervals.

Primary metrics

I would lean heavily on the State of DevOps report on the primary metrics to measure. They would be:

• Deployment frequency
• Lead time for changes
• Time to restore service
• Change failure rate
• Availability

I would suggest a useful, sixth metric:

• Lead time to quality:
• Time taken by a team or a developer to pass a quality threshold set in the DevOps pipeline. This metric allows us to measure the time taken to pass each quality gate which, in turn, helps us to take corrective action and improve the gating policies themselves. 

Secondary metrics

These metrics can be many though I have called out a few basic ones to start with. These metrics give us further insights on where exactly the problem is which is impacting a primary metric, and thereby, helps us to take the suitable corrective action:

• Code churn rate
• Build rate
• Number of pull requests
• Number of code merges
• Code smells and warnings
• Low level design analysis – CAST, JDepend

It is important to note that none of the above metrics (both primary and secondary) are derived or calculated manually. All are derived automatically through data available in the DevOps pipeline across the different areas. This will be a key implementation objective of driving continuous planning area of DevOps maturity. At HCL, we have a tool named Application360 that seamlessly integrates with most of the industry standard DevOps tools and thereby makes it easier to generate the above metrics.

To conclude the blog post with a quote from the continuous delivery book, “Hope is not a strategy”, and unless we drive the people, process, and technology aspects together, scaling Agile and DevOps and achieving digital maturity will prove to be an uphill task. However, while achieving this state may prove to be complicated, difficult, and resource intensive, the journey is well worth the effort and the rewards along the journey are immense. In the next and final edition of this series, I will be discussing the “Process” dimension of scaling digital successfully. See you then!