Mike: Hey, everyone, this is Mike and I’m here with Compuware Vice President of Product Development David Rizzo. David, thanks for joining me.
David: Thank you for spending time with me.
Mike: Always happy to. So, we’re kicking off a series on The Modern Mainframe called “10 Steps to True Mainframe Agility” based on our eBook of the same title. In our first episode of the show our CEO, Chris O’Malley, really set the stage for why the mainframe is important and why you need to mainstream the platform. This series is about what steps you take to actually do that.
So, I’m hoping you can help us kind of kick this off because you’ve been so close to Compuware’s transformation and our success in following a lot of these steps. So, maybe to start, can you explain the origins of our eBook “10 Steps to True Mainframe Agility” and why we really created this guide for customers?
David: Sure. So, at Compuware we started our transformation to mainframe Agile development—now it’s been about five years—and about two years ago, as we were two and a half years in or so, we discovered that we were sharing our experiences with customers.
I was talking to customers and they wanted to start their own journeys and transformations and they were asking how it was done and some of the things we encountered, the good and the bad. And as we continue to talk to our customers, we realized that we could share our experiences and give them somewhat of a playbook and a guidebook of things they can do to make their transformation more successful.
So, we went on the journey to write what is now “10 Steps to True Mainframe Agility” so that we could share our experiences so that as our customers and other companies went through their transformation, they wouldn’t have to go through some of the struggles that we went through and they would be more prepared so that they could have a more successful or smoother transformation.
Mike: Yeah, and a lot of the information in the eBook, is it all pretty much based on our experience or is it also, you know, curated in a way from other companies who have gone Agile or from Agile experts in the field that we learned a lot from on our transformation? How did we really compile that information?
David: It’s compiled through all of that, through conversations with customers, industry experts, and a lot of it is based on our own experience. But as we went through our transformation, we consulted with those industry experts. We consulted with other companies that had tried or who were doing things in an Agile way. So, it comes from all of that input that we received and our own experience of what we’ve done.
Mike: Okay. And so, there are 10 steps obviously to this process, and we’ve talked a lot about how you can sort of rearrange a lot of the steps that are in the middle, but the stuff on the ends, it has to stay put. So, when it comes to the first step, “Determine Your Current and Desired State,” what does that look like? What are goals you have to set? What does that take, that first step?
David: So, the first step is where you are currently. The first thing you have to do is understand where you’re at today, how your set up to do business. And it’s kind of a self-check, right? Look in the mirror and really see what’s there. And that’s something, again, from our experience at Compuware. We looked at where we were at and saw what we were doing.
And then the other side of that is, where do you want to be? What do you want to do? So again, for Compuware, we want to be The Mainframe Partner for the Next 50 years. We want to be an innovator in the mainframe space. And what does it take to get there?
So, setting those expectations for yourself of what you want to be and really identifying what are you today, what do you want to be in the future. And then you can move through the process of getting there and setting goals based on what you want to be.
Again, for us, if we look at how we want to be an innovator to be an innovator in the mainframe space, we identified more frequent delivery of new feature functionality, new software. We set our objective to be doing that every quarter, which we continue to do successfully. But that sets what we want to be and the things that we need to do to get there. And then the rest of the steps will be in support of meeting that objective and those goals that you set.
Mike: Okay. So, it’s really about defining what kind of business or what kind of organization—if we’re talking about a mainframe organization within a company—what kind of business or organization you want to become, versus you know, a more of a technical approach to that perhaps.
David: Right. So, the first part of it is from a business perspective. We’re a software vendor, so we obviously have customers that we work with, but everybody who’s in technology has a customer. So, whether it’s an internal customer or an external, it’s looking at what are your objectives to meet for your customer. And really, the first part of it is your business goals, your business objectives, not the technical way to get there.
The next steps are the technical way to get there and how you can help meet those business goals. Because doing Agile development for the sake of doing Agile development is going to be difficult to get acceptance, get buy in from the teams. When they have a reason to be doing it and there’s a purpose, then they understand what they’re trying to achieve.
Mike: Okay. And so, when it comes to setting those goals, those objectives, it’s really all about looking at, like you said, the customers you’re serving, whether they’re internal or external, and then trying to align yourself with meeting those needs, right?
David: Correct. Who are you doing work for? Who are you meeting the needs of? Which, again, we all have customers, whatever business we’re in. It’s the customer that we’re working for and trying to fulfill our mission as a company. Because, as part of a larger organization, you have to think of the mission and objectives of the company overall and how you fit into that and how you contribute to achieving those company goals at a higher level. And then bringing that down to the individual group goals and achieving those.
Mike: Okay. So, what are—and maybe we can use Compuware as an example—some challenges that you end up running into as you start to define these goals or as you start to try to work towards them? Is there anything particularly challenging that we ran into?
David: So, the first biggest challenge for us at Compuware, and I think for any organization is, people and their resistance to change. That’s number one. You can’t get away from that. But, and you know, everyone knows, that people are resistant to change. It’s commonly accepted that people resist change. But when you think about trying to make a big transformation, it’s getting the people to come along with you and helping them to understand the need for it.
Again, that goes back to goal setting. And number one, identifying what you’re truly out to do. What are your objectives? As we went through our transformation, we realized there’s a tendency to go backwards. You’re going to meet struggles. Something’s not going to work right. And so, as you try and change, you’ll encounter a problem that you didn’t encounter before because of the way you’ve changed. For us, as we were going faster, we encountered issues that some of our processes took longer. For example, to package some of our software would take longer than what would fit into, now, a 90-day cycle. So, we had to make changes.
David: The tendency is to say, “Well, this worked well in the past. We should go back to that and not change because we don’t want to disrupt anything.” And if you continue to let the past draw you backwards, that obviously doesn’t allow you to move forward and meet those goals and objectives. It’s the past that holds you back.
And whenever you lose a focus of those goals and objectives that you set, as you start working down that path, you get six months away and sometimes you’re working and you forget what the real goals and objectives that you were trying to accomplish where, and you lose that focus.
So, regarding the focus, at Compuware we really drove that home every two weeks in our Town Halls. We realized that we needed to remind people what the goals were, what the mission was, the vision that we were trying to go for as a company to keep them focused, what they were doing—and from a development perspective, understanding how they were contributing to the whole of the organization and the benefits that we gain from it.
Mike: Okay. So, as I said earlier, we say that you can implement the rest of the steps pretty much in any order that makes sense for your organization. And we’re going to get into those in future episodes in this series and delve into those. But from your perspective, what do you think is the most critical next step?
David: So that’s an interesting question because each one of those steps is unique. But I think the most critical next step that we have listed as number three is automated testing, and as it goes into deeper in the eBook, automation in general. I think is the key first step, is to automate what you have. The number-two step we have as your development environment, which is important. But what we found is you start to automate, you start to realize where some of your bottlenecks are.
For example, when we started to do our automation and we wanted to automate our build processes and wanted to get things done, kind of push-button builds and working with different lines of code, we realized that our source change management system was inhibiting our ability to automate and move faster, which is step number eight, to look at your source change management system. But that was driven by our automation and trying to go faster.
If you’re going to be successful with automation, testing is part of that, is critical. For building software, if you want to deliver more or you want to deliver faster, you have to be testing thoroughly and you can’t do it manually. If you’re going to move at more frequent intervals, it has to be automated.
So, I think automated testing and automation in general are the real keys that will drive a lot because that will give your organization, as it did for us, some clarity into your shortcomings from a testing perspective and from a process perspective. If you can’t automate a process, that indicates that it’s not really repeatable. So, from a technology standpoint, if you have a process—like to build a product, to put a release together, to put a package together for deployment to production—that should be a very repeatable, automatable process. If you can’t automate that process, then, as we did, we identified where it truly wasn’t the right process. So, it made those better.
Automation forces you to look at those things and testing, of course. When you think about things like code coverage and how much of your code you’re really testing, as you force people to look at that, they see the need to do more of that and the importance of that and the other things. Then we’ll start to build out for the other things that you need to do to understand your applications and to build software, build better software and do different things. That will come, but I think if you started with the automation, it will help you see, provide clarity and drive what is the future.
Mike: Awesome. So, David, thanks a ton for sharing your insights, as always. Everyone listening, if you want to read “10 Steps to True Mainframe Agility,” the eBook, you can find the link in our show notes. Otherwise we’re going to keep moving through this series and really explore a lot of the other steps with some of our other experts. Thanks again, David.
David: Thank you.