 Before I begin, I would like to thank Manoj Agarwal and Akshay Ayer from CA Technologies. They have helped me convert my story, my experience story into this presentation. My name is Pooja Apalapati. I am from CA Technologies Hyderabad and currently I am the Scrum Master there. The reason we thought that this transformation journey would be interesting to you is because, you know, we had a lot of different kind of challenges going through this. The reason being we were implementing Agile on the mainframe technology stack. Okay, so generally people perceive mainframe product development to be bulky, to be old. It takes a lot of time. There are not much choices in terms of tools and applications. I see people nodding. This is the picture that you have. Over the past few years, we wanted to transform from being something like this to being this. You know, we wanted to reach the market faster. We wanted to give the customer what he wants quicker. And of course, it also comes to bringing in more agility to how the teams work. Okay, so this journey of mine, I am here presenting it as an intermediate experience report. Some of you must have experienced this. Some of you might be knowing about these already. But it is for those who are going through these challenges and who might benefit from this. Okay, to understand this transformation, you need to have a certain picture about the scale of the transformation that we are going through. So for that, you need some information about the organization itself. So the agenda of this talk is to first take you through what the technology is, what do we work on, what are our strengths. And then I'll take you through the transformation journey, which I have divided into four phases. Okay, so the first phase was majorly about how we were reading through the books, learning Agile, stabilizing ourselves. And then there was a lot of confusion. So after we started Agile, we had a lot of confusion. And then how we learned about team bonding, how we started actually getting benefit from it. And then where we are today, that is where we are continuously improving and we are challenging the status quo. Okay, so this will be the major part of the talk. I would like to invite Mr. Ravindra Chabhyam, Senior Director at CA Technologies, to take you through the first two segments of the talk. Good afternoon, folks. This is Ravindra. Thanks, Pooja. So like what I want to say is how important is this for CA at the global level. And as you may be knowing, already it's a 30-year-old company. We have a lot of experience managing IT across a lot of the computing platforms, mainframe being the primary one. And then as we are seeing and trying to evolve, we're looking to broaden and come up with solutions focused around cloud, right? DevOps and security. Security is a very big business line for us, right? And DevOps and cloud is something that we are very aggressively going into. And our intent is to help reduce complexity for our customers and drive business value from whatever investments they have made on our platform. So mainframes, as such, is a mission-critical platform. We are building the best-of-breed products on top of the mainframe, actually, as a market cap as of January at $13.5 billion company, right? And to give a context, our revenues of mainframe itself is $2.5 billion, right? So what we are trying to say is that huge revenue base, very sustainable base of customers, right? We have an existing franchise that goes up like we have 90% of fortune-finding companies. $6 trillion of annual credit card transactions flow through the mainframe, right? So it's so mission-critical and very important to sustain that base and develop on top of it, right? So it's important that we don't lose what we have and then we still look at our growth path. So we believe overall $10 billion market for mainframes. We are having 24% of the market share. And given the market scenario, the mainframe market, per se, itself is slowly declining. So we want to grow on top of it. So we're looking into expansion into the cloud by doing big data workloads and looking at infrastructure which is converged and consolidated, right? All of these on top of the platform, which is the mainframe. And system Z, that's what we call it. So I'll pass here. So while we go through this experience report, which is specific to one of the teams or actually a lot of teams at our development center in Hyderabad, I wanted to also say that we did a lot of corporate changes also to manage this transformation and make it successful. Some of, like, two or three key points where we started something called the NPS, Net Promoter Score Survey with our customers quarterly, trying to get customer feedback on the products that we are delivering on. And then second is we reduced the number of development centers, actually, development centers because we had people spread all across the world. With a few guys like a product manager staying in some remote location, our UX designers are working out from a remote location. We are trying to do co-locations, right? And we did that very aggressively. We brought it down to, like, six or seven major development centers and Hyderabad being one of them. So it's changed over the last two, three years, still continuing, I would say. So Puja will take you through the transformation that we went through from a local perspective. Locally also, Hyderabad, we have, like, 26, 25 to 28 Scrum teams, right? And we've been trying to do this as much as we can across all the teams. Thank you. Just a context, and Puja will go through some of the challenges and learnings from all the phases that we are going through. Thank you. Thank you. Okay. So we begin our journey. So this is the first phase of the gel transformation journey that the teams were going through. The major part of it was learning. So we were introduced to the concept of agile Scrum. What a Scrum master should not do? What a product owner should do? You know, what are the roles and responsibilities? Teams were going for training, you know, understanding what this is. And we were hearing a lot of new terms, retrospective review, standards, all of these. So this phase was basically to, you know, setting up the foundation for our journey to go ahead. Okay. Like most transformation journeys, we had challenges. We had lots of them. I would like to concentrate on the top four that we had during the first phase of our journey. Okay. So we had, now we have roles in place, right? We have a Scrum master role. So who should, who should actually start, you know, who would start being the Scrum master? That was the biggest question. And the natural transition was the functional managers became the Scrum masters. As these were passing, we started noticing that, you know, the same person who would do my appraisal was also helping us plan the sprints. There was a lot of conflict in terms of assigning tasks than picking up tasks. The side effect to that was there was no collective ownership. So if something went wrong, suppose something went wrong during the sprint, you go to a team member and ask, why did you think we did it this way? They would all point back to the functional manager and say, he said so, so we did it. So they were, they were waiting for instructions from the functional manager. And not knowing, you know, this, this whole vicious circle, we were into it. So that was the major key challenge that we had. The second thing was, so we were telling the teams, actually on this slide, it's the third one. So we told the teams to work together, right? We are asking them to collaborate, to communicate. But then we were assessing them in terms of their individual characteristics. We were telling them to be, you know, we were asking them, so what are you doing above and beyond your responsibilities? But then in the sprint, we were asking them to, you know, work together and get, you know, reach the goal. So that, there was a confusion in those terms. There was no co-location, it's self-explanatory. So the prior owners were working elsewhere and the development engineering team was here in India. So what did we do in the next phase of our journey that helped us resolve those challenges? Okay, the first thing was, organization-wide, we made job architecture changes. So now we had separate role for a scrum master, separate role for a product owner. So now who would be the scrum master is, somebody from the team was identified with those skills. You know, who could take up the role of the scrum master and the role of the product owner. And if there was nobody from the team who wanted to step up and be in those roles, we were recruiting people with those particular skills. So we wanted to make sure that there's no conflict, there's no one person doing two things at the same time. So we wanted to remove that. While we were doing that, we also got co-location in place because while we were also hiring for scrum masters and looking for those skills, we also started looking for product owners skills. So instead of having the product owners in the US, we now have all the product owners here with us sitting in the same base. So we got co-location in place. We had an agile consultant, external agile consultant, reach out to different teams across the globe. Like Ravindra mentioned that we operate from different places across the globe. So he came to all of us, did some workshops so that we are all on the same page. We were going to the next level of learning how to slice stories, vertical slicing. There's no new answers for the next step. While all this was going on, HR went through a lot of, you know, change as well. You know, they're an important part of this entire journey. So the HR said, now you're, because you're doing all of this, how will we do the appraisals? So earlier the appraisals were that, so what is a manager's feedback or opinion about the individual, right? But HR told, now you're working a lot with your team. So why not we take feedback? Let's put feedback in place. Let's see, let's ask the teams to, let's ask the individual to identify a few people from his team to actually get feedback from. And the manager was consolidating the feedback and giving it to the individual. Okay, so this was going on. Yes, there were challenges in this phase as well. So now the main challenge again was, so now we have Scrum Masters in place. What do we do with the functional managers? We told the functional managers to be away from the Scrum. We told them to be the observers. We told the other chickens. We told them not to talk. You know, ours was a product development organization. The managers came with strong technical background. Their inputs were valuable, but we did not know how to channelize it. Which, at what platform should they put their points? So there was a lot of confusion in those terms. Confusion and uncertainty. The managers did not know when to put forth their points and when to step back and let the team decide. The other challenge was that we had pretty much stabilized on prioritizing our new feature work. When to do what, what is dependent. So we were very good at that, but technical debt was neglected. Nobody was bothered about the technical debt and we were piling up on that. The other challenge that the team was facing is, whenever there was a retrospective, the top item on the impediment list was lots of meetings. We spend more time in the meeting rooms than at our desks. When do we do the work? So that was a constant challenge. So what were these meetings? We were planning for four week sprint. So there was a lot of grooming that we had to do ahead of time. Grooming multiple times within the sprint to be ready for the next sprint. Then have a huge planning session because we have to plan for four weeks and make sure we meet the commitment. So really the time that we were taking for planning and grooming was much more. The next challenge was that, so now we are going through a four week iteration cycle. So what happens if a customer issue comes in the second or third week? You know it disrupts the whole plan. So you had so many meetings to come up with the plan and now it's disrupted because of that one or two customer issues that came in. So that was the challenge as well. So now what did we do in the next phase? Which is phase three of the journey to actually overcome those challenges. We had external agile coaches. So this is not training model. They were embedded into our team. So they came in, they looked at our product. They were working with us in our office space. And we went from wave of change. They came up, they came with a lot of market knowledge and they were helping us go through this transformation. The first thing we did was we got a hold of how to involve functional managers in this program. So how we did that was we involved them during release planning. Release planning happened over few days. We were doing product discovery. We were doing user story mapping. All that was happening and we had functional manager involved with us day in and day out. So if the team couldn't figure out something, the functional manager would go back and come with that input the next day. So that was the level of association the functional manager had with the scrum team. And to keep this going, to keep this association going, what we did was we started triage meeting. Meetings between the scrum master product owner and the functional manager to help get a bird's eye view of where the team is going. So it was helping the team to know what are the challenges that were coming next to them. So that's how we got functional manager into the team. He knows the roadmap. He knows what the team is working. So now it makes sense for him to be, you know, just walking through the standards maybe some time. Even being an observer, there's a lot of information that he has now. So that's the model we came to. To solve a lot of meetings problem, right? So we reduced the sprint iteration. And that's not an easy thing to do. Moving from four-week iteration to two-week iteration, being able to deliver value at the end of second week on a mainframe product was a challenge in itself. So we went through deliberate practice sessions. We were introduced to the concept of pairing. How can we speed up things? How can we cut down stories to a much granular level so that towards the end of the second week we have something to deliver? So those were the changes. There were changes in the project process. So we have now solid multiliter feedback system in place. And it is the system. So I get to see the actual comments my team members write about me. I don't see the names though, but the actual. So there's no middleman trying to interpret the data and tell me what it is. I see what the team is telling, and I know my areas of improvement looking at that. So that is in place. Instead of having functional, instead of having managers aligned to functions in terms of dev manager and QA manager, we now have a manager taking care of the entire scrum team. So he owns the scrum team. The entire team, there's only one manager. So there's a lot more bonding between the manager and the team. So there's a lot more bonding between the manager and the team. So we have a lot more communication. So we have a lot more communication. We wanted to let the teams know that we were serious about this transformation. So the way to tell that was to appreciate them when they were showing those behaviors. So rewards and recognition, we now have a quarterly team award in place. So it is not a competition between teams. So we evaluate teams as a success story and spread it across the organization. Those parameters by which we judge the team are customer engagement. So what are the new ways you have taken to increase customer engagement? Have you taken any risks that got us business value? Have you tried out something innovative? Are you continuously improving? So all these are the parameters we are judging the team with. And it's not individual, it's the entire team. So there's a lot more bonding now with the team in terms of individual awards in place and we are still appreciating people who have done something great. But because of these team awards, there is a lot more reason why the team wants to work together and do something better. In this journey, in this phase of the journey, two major challenges, they're almost getting towards the end of it. So the first thing was that when a customer comes and asks us for a feature, even though it was ready a few months later, we were only giving it back to him after a year. We had long release cycles. The time to market was much longer. The second one was whenever we see something nice, a process, something new, we were adding it to the existing process. We were making it bulkier. But there was no mindset of looking for things that are not useful and eliminating it. There was no mindset, we were only adding on and making the system more bulkier. So these were the two challenges and this is where we are today. Right now, the team has adapted to incremental releases. So as and when a feature is ready, we are able to deliver it to the customer. And how did we get to that point? And getting to this point, for those of you who know a little bit about the mainframe product development, getting to this point was a very, very enriching journey for us. I did not envision in reaching this point so soon. So how did we get to this was because we had a lot of other things put into place. Since we did not have unitest automation in place, so we were relying on the QA to test whatever code I have written. But now we have unitest framework in place, something that runs on the ZOS, something that evaluates my code every day. So I write in some code, I check in, go back home and come the next day to see an email which says your unitest is passed but there's one unitest that failed. You know, we didn't have that level of quality check earlier. Now that we have it in place, it's kind of helping us move faster. Identify, you know, early feedback. You're getting early feedback and it is helping us to move to the next level easily. About driving down waste, we have identified like I told you previously, there was a challenge in identifying waste. We are still overcoming the challenge. But one, we identified a challenge and I just wanted to put it in front of you here. So we take a lot of time to merge code in the sense that's why I take a lot of time to make some changes. My colleague takes the same module and he's making changes. At the end of the sprint when we have to merge, it's manual merging. I cannot rightly can say merge and the system doesn't take care of it. I have to do it manually. And it used to take a lot of time. We thought that was waste, right? I mean, we are not doing anything creative. Why are we spending time merging code? So what we decided is we will do continuous integration. We will check in code every day and how do I make sure that my unit tests are taking care of doing that check. So we are now working at the level of sophistication where I'm checking code every day, merging code with my colleagues that are working parallelly and running tests on them and getting feedback on it. Coming from the mainframe development background, this was a big deal. Coming to this point was tough. There was a lot of mindset change that required in terms of technical excellence also, right? So it was not just... We were going through the agile journey but technical excellence also, the fact, the will that we can do this on the ZOS was also, you know, this difficult to transform. We are at the end of the journey and for me, a key takeaway from this journey that I have been through was at some point in your agile journey while you are improving your practices, you need to focus on the technical excellence part. You know, the more you keep on trying to improve your agile practices and you don't have the right platform for the people who are working, the people who are testing, the people who are developing code, if you don't have the right things for them, you know, you will still stay back at the same place and you will not see the outcomes that you're expecting. So it should be a combination of agile practices and technical excellence and that's where you will see the outcome of... the kind of outcome that you're looking for, the kind of improvement that you're looking for. So the conclusion is that we are very close to being the cheetah. We are very confident now about the code that we write. We are... we are very confident about delivering something to the customer when he asks for it, a few months after he asks for it, you know, whenever we are ready. It's not that the customer asks something and he forgets and then we are delivering. So we are happy to be at this stage. We are much more confident and I think that is pretty much it. That is pretty much the talk and if you have any questions, we would like to take them. And for those of you who are... who would leave the room early, if you're interested to know the products that we work for, if you want... if you know of any teams in your organizations that work for mainstream products, you know, it's a very small segment in the industry, right? So we would like to get some customers for our reviews. Some place where we have more people to collaborate. So please drop down your visiting cards in the bowl here. I'll collect them. I promise not to spam your email box. We'll... we'll... Network can see if it could be of use to each other. It'll be nice to have your contacts here. Mr. Timajit, thank you, thank you so much for that. Every time, like, what we do is we, you know, in the open system or the new technologies, they come up with the presentable features, which can be, you know, demoed and tested. But in the case of mainstream, it doesn't happen. So how do you... It's a green screen, yes. It's not a presentable feature, something like, you know, how do you manage to, like, plan the stories which can become a presentable, you know, or, you know, testable the item. So, like, how do you plan it? Okay, you know, earlier we had this major issue about this. So we want to demo something, across our stories horizontally. So I have the UI ready. It's not going to go back in, so I don't know how to test it. Then we started, you know, slicing the stories in a way that it touches every element in depth, and something comes back from the database. It's not the right information though because it's a two-week sprint. So I'm not capable of building all the three layers completely and demoing something. So at least it touches... It's not probably giving back the right information that it is supposed to, but at least I know deep down and coming back. So that's what we started demoing it to the product owner. And when we had some useful information that it was showing back, that is when we called the owner, that is when we called the customers and told them, so this is what you do and this is what you get back. Is that... Kind of a vertical slice across all the layers and we did a product discovery workshop where we had to do this with the product owners, product managers and the team. And it is a big, big, big discussion. And in a lot of discussions the first time we were trying to figure out how we can give a slice of value in what we call an incremental release, hopefully once a quarter. And then give out something every sprint if we can. It's a lot of technical discussion with the architect, product owner, product manager and key members from the team. And one more thing, most of the time what happens is in a sprint we can plan to update the database because from a mainframe point of view I'm telling you. Which is not presentable for QA testable I would say. So how have you managed that? Do you plan to put it in the individual iteration? How have you... So you're asking about how do we test something? Yes, exactly. Just the database update or you run the jobs and the database get updated and how you do it. It is tested in a single iteration and it's based on the user story that we pick up. We are able to come up with tasks related to development and to a test engineer. Based on that we could come to a level of granularity where we can say this part we would test. Sometimes if there's interdependence, so be it. And the accepted or at least known by the product owner, product manager that it could come later as well. That's fine. That's a key. When we did the product discovery workshop we were trying to figure out what can we do that we can have whole team involvement that includes including the testers and what can we test. If not every sprint at least the next alternate sprint. Your question was that I have the database layer ready and I want to test that but the one that calls the database is not ready. How should the QA test it? What we were doing in our product was that we were simulating that layer. It was an extra effort but to call whatever the developer has done to call it done done we needed to test it. We were simulating that layer and then testing it. We did not want to leave it there. There are instances where you cannot write tests because the previous layer is not ready. We were simulating that layer. We called them test drivers in the main train world so we were writing those test drivers and the QA was using them and once the previous layer is totally ready to give the parameters to the next layer that's when we integrated we used to do integration testing. Just one example is we had a customer on nonstop HHP nonstop platform and that's very very difficult to actually get access to machine. In that case we wrote a stub as much as we can mimic and try to see what could be the response and then go through it. As we get closer to having access to the production like server then we go and do all the tests. I have a couple questions for you. One of them is were you able to take on any agile engineering practices at all on a mainframe team? Were you able to practice any XP practices or anything like that? XP practices would pairing qualify to be well it could be pairing it could be you know like in the mainframe world there actually are unit testing tools and continuous integration tools and things like that. I mean there are unit testing frameworks for COBOL. That's what I'm curious about. We've tried using G-Test and extended that for unit testing on the system C. That's some customization that one of the teams did and that's helping us go faster in terms of unit testing. We've tried that. That was the unit test when I told you we started implementing the unit test. So G-Test is what we have started using now. It's just from when I worked with mainframe teams before that term unit test means something completely different in their world to what I would mean on a Java team. It's a completely different unit test we were doing from the beginning which were not the actual unit tests the one that you're telling they were different. But now we have this in place which are the actual ways of doing it. We now have that in place. Actually that's a lot of learning even for us. I mean we did one technical session with the guys out of U.S. and the guys in India tried this out with extending the G-Test for the mainframe and I mean the first reaction was there's a lot of information there. We need to go review the recording again and come back to U.S. That's the kind of thing that we're trying to look at and change. The other question I had was having coached mainframe teams in the United States before I'm kind of curious how much experience did the developers on your team had for me the teams I worked with that ranged anywhere from 2 years to like 20 or more. Yeah we have I think maybe like average could be 2 years but we have some folks who have been like some of our architects I think at least like 7 to 8 years local. We have senior developers who are about 10 to 11 years experience they were working in the mainframe from the beginning. So we had them but we also had the younger lot. We had a lot of people who were ready to change and who wanted these things to happen. So there was a mix of it but like not 20 years and who were you know bent on those black terminals we did not have so much resistance. So while we get set for the next one feel free to ask more questions. Just that you know that we have mainframe developers plus also folks working on it. So it's a combination and we're trying to build that next layer like I said moving into cloud and DevOps. We're trying to have teams that do both. Thank you.