The Two-Week COBOL Scrum: A Gutsy New Years Resolution for CIOs
Yes, I’m blogging about a New Year’s resolution. But, no, this is not just another vacuous end-of-year blog from a tech-sector exec hopping on some buzzword of the moment. In fact, It’s just the opposite.
This blog is about resolving to try a two-week COBOL scrum.
Why try such a thing???
You may be a bit surprised to see the words “COBOL” and “scrum” in such close proximity. And even before doubting the feasibility of such a thing, you may even wonder why it’s even worth discussing.
Two realities make the COBOL scrum not just worth discussing, but also an absolute necessity. The first reality is that the world still runs on COBOL. I know Walt Mossberg and Charlie Rose work themselves into a frenzy because you can use your iPhone to hitch a ride with an under-employed liberal arts major or find a place to couch-surf in Navarre, Minnesota. Way cool, dude!
But global capitalism still relies almost entirely on mainframe applications to transact business. So COBOL is not only “still relevant” to the digital economy. It remains its foundational language.
The second reality is that COBOL owners are in huge trouble. Their veteran COBOL gurus are nearing retirement—and cannot be replaced in kind. Their obsolete tools and archaic development lifecycle processes are non-Agile in the extreme. And if your core business logic isn’t agile, your business can’t be agile. That’s a fatal flaw in fast-moving markets where smaller, nimbler disruptors are constantly sniffing for blood.
The answer to “Why try a two-week COBOL scrum” is therefore “Because your future depends on it.”
But can it be done???
Now that we’ve established the absolute urgency of the COBOL scrum, let’s discuss its feasibility.
Yes, it can be done. There is nothing inherently non-Agile about COBOL or the platform it runs on. Code is code. Its logic and plasticity is independent of its idiosyncrasies of syntax. So the obstacles to mainframe application agility aren’t in the COBOL language. They are in the tools, processes, and people we use to manage applications written in that language.
Change the tools, transform the processes, and inspire people—and you make your mainframe codebase Agile + DevOps-able.
Of course, it’s not easy to change your tools, transform processes and inspire people. That’s why the COBOL scrum model is for gutsy CIOs only. If you’re not a strong, egg-breaking, omelet-making leader, you won’t be able to adapt any of those three things—let alone all three at once. But if you are, then 2016 could be quite a year for you.
Is O’Malley completely full of s^&%^???
This is a perfectly natural question to ask. And I am not offended by it in the slightest.
I will answer it in two parts.
Part 1: No, because we’ve successfully done it at our company. You can read about a particular example here. It wasn’t easy. There were people that fought change at every turn. There were risks that had to be taken. But we did it. And we are now officially the world’s most innovative mainframe software company.
Part 2: No, because we are here to help you do what we’ve done—and with an approach that makes complete sense for today’s mainframe owners, whose DevOps teams probably know little about the mainframe today and aren’t the types to easily concede that mainframe development can be remade to thrive in a DevOps culture.
If you’re curious about Part 2, watch for Compuware's first big announcement of 2016. You see, we’ve made some New Year’s resolutions of our own. And I think you’re going to find them both gutsy and compelling.
