Mob programming on the mainframe
March 13, 2018 Mainframe Agility

Three Benefits of Doing Mob Programming on the Mainframe

It’s no secret: We at Compuware have embraced Agile and DevOps with open arms and with a level of enthusiasm that has revitalized the company and led to amazing results on a day-to-day basis. We’ve also embraced Agile methodologies often-unused in the mainframe world, such as mob programming, to accelerate our software delivery.

I’ve been so impressed by the work being done at our Detroit headquarters that I just had to be a bigger part of it. A year ago, I ended my role as a Compuware Technical Account Consultant in Australia and joined the Compuware Product Management team in Detroit.

Since the change, I’ve had a lot of fun working with amazing development teams that are responsible for helping us maintain and advance our record of delivering new and updated mainframe software for 13 consecutive quarters and counting (and to think we were once a waterfall-based mainframe shop).

For example, recently, we had to make a major change to a piece of software that is central to most of our products, and, of course, any change made could potentially cause major issues. Three years ago, this change would have meant weeks of planning meetings, a detailed design document too big to staple together and then more planning before a long development process spread over a year or so.

Instead, using our Agile framework, an epic was created, then stories, which were eventually refined. The initial part of this was done in less than half a day. To accomplish the necessary changes in the given time frame, it was recognized multiple programmers would need to work on the same stories, so a mob programming approach was taken.


Three Benefits of Mob Programming

Instead of one programmer working on one story, we had three programmers work on one story with multiple associated tasks at one time. Using mob programming led to three great benefits:

1. Faster Knowledge Transfer

Acquiring the knowledge necessary to complete a task was much faster. Instead of learning everything about a program or process, the programmers unfamiliar with a part of code only had to understand the function and flow at a high level—the bit that went with the task they were accomplishing.

In some ways, this aspect of mob programming sounds bad, but over the course of the story, we achieved a level of knowledge transfer that would not normally have been possible without long sessions spent teaching and learning, taking time away from coding.

2. Instant Decision-making

The team could hold short, concise planning sessions to map out the best way to achieve a story or task and utilize each other’s unique perspectives, ideas and knowledge to come up with the best way to achieve the goal.

3. No Delays

If a team member was absent or had to work on a problem, someone else could pick up their task. This would not have been possible without changing our source code management tool two years prior from CA Endevor to a modern alternative that could handle Agile development: ISPW.

Six Reasons Compuware Replaced Agile-barring CA Endevor with Innovation-enabling ISPW

With CA Endevor, programmers checked out code into their own libraries and basically locked that code until they finished working on it. This and other major drawbacks led Compuware to migrate to and eventually acquire ISPW, which allows the code to be in a container that anyone can take over where a teammate has left off.

Agile at Its Best

Working with this Scrum team to deliver, in under three months, the minimum viable product of a major change to the way a core system operates, I have seen Agile at its best. As one of my colleagues on the team said, “The development team definitely captured the essence of Agile Development. We build infrastructure software, we build it fast and we build it right.”

It is truly an impressive group of people who provide fast turnaround, meet goals they help set for themselves in our fortnightly planning sessions and embrace new concepts like mob programming.

They do this across five distinctly different code bases, switching hats and mindsets often, and, of course, dealing with the day-to-day interruptions and emergencies that are part of a programmer’s life.

I am proud to say I work with a team that is a shining example of how true mainframe agility can and should be achieved. Agile on the mainframe is more than possible: it is something everyone should embrace.