Combining Agile and Heritage at Nasscom

Last week, I was privileged to help represent HSBC Technology at the Nasscom Technology and Leadership Forum in Mumbai. My friend and colleague Balasubramanian Ganesh and I gave a keynote speech on the topic of combining Agile methods and Heritage systems, and participated in a panel on the same topic. We were fortunate to have Rafee Tarafdar of Infosys, Sri Vidya Annapragada of Google, and Nick Patience of 451 Research on the panel, all of whom offered great insights.

Our presentation was a response to three ideas. First, the idea that the expectations of technology are now so great that we must deliver ever more quickly, and ever more reliably. Second, that our traditional ways of working can’t provide this pace or quality, and that we need to change: we need the tools, techniques and methods grouped under the headings of Agile and DevOps. Third, that many of the systems we run were developed long before these new ways of working were conceived, and were not designed for these new ways of working.

One way of responding to these three ideas would be to write those older systems off, and, by implication, the teams that run them. This response may be expressed expliciltly, as in the idea of ‘bimodal IT’: the idea that there are some systems which need to change fast (but may not need to be completely reliable) and some systems which need to be extremely reliable (and which therefore cannot change fast). Or this response may be expressed implicitly, by assuming that older systems will always be slow to change, and that we therefore shouldn’t do more than patch them up and keep them going.

Both of these responses are inherent in the stigma which has become attached to the word ‘legacy’. I’ve been around long enough to remember when the term ‘legacy’ first came to be used as a euphemism for ‘old’. Back then it was an attempt to express the value contained in older systems. Unfortunately, like many over-used euphemisms, it has taken on the negative characteristics of the term it was intended to replace.

We don’t believe in these responses. We don’t believe in bi-modal IT, and we don’t believe in the unspoken decision to let older systems decay. We believe that any software can be delivered and run using Agile and DevOps methods, whenever it was first written and whatever platform it was based. We take heart in observing that the Agile Manifesto values collaboration over contracts, working code over documentation and so on: not Python over COBOL or Linux over z/OS.

Ganesh and I tried to make these points on stage, but I think that they were made far more powerfully by the HSBC Technology team at our stand at the conference. That team told several stories, a couple of which I’d like to share here.

The first story is about quality, and about providing continuous feedback to developers. Our commitment to quality is expressed in the concept of Shunya, the Sanskrit term for zero. In software development, we aim for zero defects, zero incidents and zero vulnerabilities. We believe that the best person to achieve this goal is not an independent tester, or the members of a CAB, or an incident manager, but the developer. We give developers a set of tools to help them achieve this goal: code quality tools, automated testing tools and so on. But the most powerful tool we give them is feedback: we make sure that developers have all the data about the performance of their code, but also (if they want) how they are doing compared to other developers. Those developers who want to participate can compete for a position on the leader board where everyone can see who ranks highest. And this feedback is available to people working on our older, heritage systems as well as people working on our newest systems.

The second story is about automation. Part of the revolution in software development in recent years has been the use of technology to manage the development of technology: the conversion of enterprise IT from a largely manual industry to an automated industry, through automation and orchestration in the form of CI/CD pipelines. The challenge is that this automation is much more available for newer technologies than it is for older technologies. Fortunately, our teams working on these older technologies were determined not to be left behind. They worked with our partners built their own integrators and adaptors so that they had their own CI/CD pipelines, regardless of the platforms they were working with.

The team had many more stories as well, about the value they have delivered to customers, about the new features and functions they have delivered. But those achievements would not be possible without applying new ways of working all the way through our technology stack, from front to back and top to bottom, and refusing to accept that old technology must be slow technology.

One of the principles of our Technology Manifesto is that we should be proud of who we are. It was great to see our team showing their justificable pride at Nasscom.