Mainframers are more Agile than they think and here’s why
The skillset of mainframers puts them in an ideal position to embrace the Agile way of working. So why are people still the biggest barrier over processes and technology?
Agile is a concept that is not only being embraced by IT but the entire world. Our clients, partners and employees want things to simply work in the easiest, fastest and most enticing way possible.
For independent software vendors like CA Technologies, this requires flexibility and being able to respond quickly across IT services, apps or any other business service we offer.
But there are barriers to agile working: old habits, procedures and technology die hard. And especially in IT, where a lot of this legacy sits in decades old applications with millions of lines of code, adopting an agile way of thinking and working seems more difficult than in other industries. But is this really true?
More and more we’re seeing that what we thought would never change is changing faster than ever. New applications that require access to legacy systems are often developed using the Agile methodology. This was touted by CA CEO Mike Gregoire and CTO Otto Berkes at CA World’15 last November, who both emphasized Agile as a critical component for success in the application economy. My colleague Priya Doty recently blogged about getting Agile on the mainframe and you can read more of her post here.
When the people who are managing these legacy back-end systems are confronted with minor changes that have been accepted by the scrum teams in the latest sprint for the third or fourth time, they will often scratch their heads and think, “We won’t be seen as ‘enablers’ by the scrum teams if they have to wait for us every time they require minor changes to our systems. We don’t want to be caught off-guard every time they come to us.”
There’s no better reason to adopt new ways of thinking and working than moments like these.
Although, when you think about it, mainframe specialists have a big advantage already. Working with controlled releases, emergency fixes, rigorous testing and digital approvers as well as release automation is in their DNA – simply because they have done that with solutions like Endevor and Harvest for decades already. All they have to do is think in smaller releases that happen more frequently.
Instead of six-month release cycles, now they have to work with six or even three-week cycles. It’s all in the mindset – but that’s easier said than done.
It’s not the tools that get in the way of working agile on mainframes, it not the mainframe technology either, it’s often the people working with the mainframe.
It takes courage and confidence to walk up to a scrum master and agree to attend their daily scrums so you are not only aware, but also give input to how any change may or will have an impact on your mainframe. And that’s only the beginning…
Many mainframe teams have told me that once they started attending scrums, they soon started their own scrum teams. One of the main reasons being once you start to open up your mainframe applications, many new small development projects will pop up and these can be managed best by using the agile methodology.
At CA Technologies, we started long ago with agile development. In fact in the last year, for example, 251 unique customers participated in 56 product releases.
By now, many of our solutions, including the mainframe portfolio, are built, enhanced and improved by small scrum teams. It wasn’t easy and we made mistakes along the way. But like I said before, we already had a very structured way of managing our release cycles.
Not only did this help us, it gave us an advantage over other teams who never had the robust type of software lifecycle management or release automation solutions that we have worked with for so many years already.
We live is a disruptive world and the demands are high. There is no reason why the mainframe and the people working on it shouldn’t be seen as enablers. We have the right technology – all it needs is a little flexibility and the will to change. We have done it before and I am 100 percent convinced we can do it again.
How has agile working affected your mainframe team and how has your team been able to overcome the people barriers. We’d love to hear your feedback below or get in touch with me on LinkedIn.