Skip to main content

How do Mainframe Batch Teams fit in an Agile world?

Last post 11:39 pm March 15, 2018 by Ian Mitchell
2 replies
08:32 pm December 27, 2016

Our company is going Agile and I've been reading a lot about it. I have read that you shouldn't fall into the trap of bi-modal IT and that all software development teams should be Agile, no exceptions. We have successfully converted a few of our teams to Agile already over the past 2 years and it's working out reallywell. Typcially these are teams that can work directly with the users to define the scope of a Sprint that is then delivered every few weeks.

But how does Agile work with batch software teams or middleware teams where there really aren't any users or any wireframe screens or user stories to share? A typical project might be to take a new input file containing millions of records from another company, do some transformations, combine it with another large file and send the resulting new file to another company. While maybe this sounds simple and straightfoward, some of these types of projects are very large, the files are described in hundred page specifications documents, and the projects can take hundreds of man hours to complete.

We have a lot of teams that do projects like this (normally mainframe teams) and sure enough, we are able to take the specifications for these files, write the code, do the testing and implement the solutions. We do all of this very successfully using a waterfall model. There oftentimes is no way to break this work into smaller chunks and deliver it in iterations - either you support the new file formats or you don't. You can't partially adhere to a file standard. And we can't test with the external companies until our code is complete (or at least, mostly complete). And sometimes it costs money to test at hundreds of dollars per hour, so we want to minimize the amount of testing, and therefore we wait until our code is complete before testing it with these companies.

I know that there are thousands of COBOL programmers out there doing this type of batch programming work. Can you please refer me to any information that you know of that addresses how to do Agile in this type of environment?

As it stands right now, our mainframe teams are resisting the push to go to Agile because they think it doesn't make any sense for the way they work, and they've been successfully delivering software for 30-40 years using their current model.

I have to say that I tend to agree with them that if it ain't broke, don't fix it. But I want to see what the Agile experts have to say on this subject.

Most of the time these teams are working on 20 small and unrelated projects. You could call those a backlog. We assign 2 or 3 small projects to each developer and they crank them out on their own over the period of a few weeks. I'm not sure how a daily scrum meeting or user stories would help these guys since they normally work independently and don't need to collaborate with each other. I think they would just look at Agile as unnecessary overhead.

If we implement SAFE at our company, how are these non-agile teams going to fit in?



06:46 pm March 15, 2018

I'm in this boat right now and was really hoping I'd find some pearls of wisdom from those who came before me. :)   Steve, if you're still out there.. what did you guys figure out?


11:39 pm March 15, 2018

If there is no uncertainty to the business or development and delivery process, then there may be little point in using agile techniques to control it. A stage- gated approach can work fine.

Is certainty really there though, even with batch processing and middleware? The people involved may see their *own* part of the value stream as being low-risk and well-defined, but what about those who consume or depend on the outputs?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.