How to gain agility in mainframe environment
Hello,
We have a decent agility on the distributed side of the organization with good quality products delivered to use by team of teams.
However, the mainframe side is a problem from two counts 1. They hinder the distributed dev wherever there is dependencies 2. pure mainframe dev
Typically, there is an individual developer who analyses lengthy cobol modules, datasets and makes changes, then coordinate with other developers in moving the changes to a test region. testers run scenarios and we create move request for the prod. The knowledge of applications thus is localized to a developer in CICS or batch environment.
There is no automated testing (obviously due to lack of best practices and tools) or a continuous integration (how does it work in mainframe... with no advanced code version, automated build or deploy..?).
Majority of our functionalities are in batch and business changes on them impacts multiple source / target systems, many of which are ASP by vendors.
Could you recommend any ideas to achieve:
1. formulating the teams to remove silos and increase productivity
2. continuous reduction of tech debt
3. increased transparency of progress by automated tests for batches
4. any other 'we have figured out better way for this in mainframe' ....
Appreciate your help
I have the same questions so I'm disappointed that no one else has replied to this thread yet.
I do have some ideas. I work with both mainframe and Java teams and I have found that the mainframe team can be pretty flexible if they are skilled.
- They can certainly be part of an Agile team and explain how their programs work to the other team members.
- They can compile their changes multiple times per day for testing.
- They can, if they put enough thought and effort into it, create test jobs that can be run on demand using test data files. The test job can produce a report of how things went. I think creating the test jobs in many cases is more work than creating the production jobs, but it can be done and once you have it, it's very valuable. I created a lot of test jobs that mimic production back when I worked on the mainframe about 12 years ago and I was in charge of starting our QA team.
So, as long as their work is part of a group project, I see no reason why the mainframe guys can't be included and I believe that they can approximate a DevOps environment, although they will likely need to build their own tools using mainframe scripts and jobs.
My big questions about mainframe and agile are:
1) how do you involve the business stakeholders and let them see your progress every 2 weeks when you just have batch jobs that process files?
2) how do you even create deliverables every 2 weeks? In a lot of cases we have big complex projects and nothing works until you're about 80 or 90% done. It's not like designing a web page where you can create a blank page and then start adding features one at a time.
3) the mainframe teams at our company do a lot of small maintenance work. Oftentimes these are little 2 hour projects. They are not part of a larger group trying to achieve something. How do we include these people in Agile? Or should we just leave them to continue doing what they are doing?
In the situation you describe, where would the demand for an agile way of working actually come from? Are there significant risks that can be managed each sprint by means of empirical delivery, or opportunities for early return on investment?
Regarding your demand question, I agree that there wouldn't be stakeholder demand. That's one of the problems. But, if our CIO decdes that everyone is going to do Agile, then we have to find a way.
Also, if 80% of the other teams are Agile, and we're trying to work on a really big project that involves 20-40 application teams (we typically do 2 or 3 projects of this size per year) and we've adopted SAFE, then how would it work if most of the teams are Agile and some are not?
If the CIO believes that people must somehow "find a way" then that may be the root issue. The organization is very unlikely to achieve enterprise agility if the stakeholders aren't on board. There must be a clear vision for transformation, and sponsorship for it which is fit for purpose. Perhaps it ought to be a CEO responsibility instead, given that all of this is wider than IT. But whoever the sponsor is, I would expect that person to be accountable and able to address the concerns you have, as they ultimately own the transformation initiative.