Can Agile work for mainframe projects?
A recent coaching client is a small company that wanted to transition their entire development department to Agile. It was an easy sell to the applications people, harder to the maintenance people (until I told them about Kanban). The ones in the middle were the mainframe programmers. This company is in insurance, an industry that has lots and lots of legacy backend systems.
I have met mainframe programmers in my Agile travels before who were resistant to an Agile approach. The reasons are many but mostly based on the constraint that legacy systems take longer to change and mainframe systems in particular are not amendable to Agile development practices.
In this particular case, I was pleasantly surprised to see interest, even enthusiasm, at tackling a project using the Agile framework even though the systems involved were RPG, COBOL and CICS. I want to summarize the experience by describing what Agile practices we implemented, what challenges we faced and what successes we saw.
Standard Agile Practices
- The team was small: 3 developers and a QA specialist also playing the ScrumMaster role. There was a dedicated Product Owner who was a Business Analyst familiar with the problem to be solved. The sponsor, a Product Manager, was also highly involved.
- The team chose a 3-week Sprint length based on unfamiliarity with Agile in general , the observation that tasks and stories might be larger (in hours required) than in other projects and the realization that team members could not cover for each other well due to specialization.
- Detailed design was incremental.
- Features were prioritized and done in priority order.
- The Product Owner and end-users were involved on a daily basis.
Challenges to Standard Agile Practices
- The developers were highly specialized in their technologies. Cross-training was limited by a steep learning curve. Yet there was some.
- Automated testing was considered to be impossible. We brainstormed this at great length. At the unit level, well – what is a unit in COBOL? It is a structured language. Programs are huge, monolithic. Compiles take a long time. It is tough to run just part of the code. Testing is done by stepping through a debugger and fiddling with variable values in memory. This does not lend itself to automation. We looked into screen recording and playback, which is possible, but the resulting scripts are extremely fragile. In the end, the relative cost of investigation was too high for the short project timeline.
- Having a small team did cause some delays when people were absent.
What We Got
- During backlog estimation, elaboration of a story was short-circuited when it became apparent that the business was asking for something that was technically impossible within the downstream host system. The story, initially estimated to be quite large, was simply dropped. The Product Owner was not concerned at the loss of the functionality given the essentially infinite cost of the story even though it had originally been prominent in the original project BRD. Cost savings were estimated at about $10,000.
- While planning Sprint 2, another large, high priority feature evaporated when the PO realized that the work done in Sprint 1 resulted in a sufficiently useful solution to the goal of the story. The feature was a real-time update of data from one backend system to a front end on another system. User testing of the first sprint product showed that batch updates had sufficient value and were much simpler to implement. Poof, another $10K saved.
- The team felt that these savings would not have been realized in a traditional project approach. The requirements would have been baked into a design document and implemented as well as possible without any discussion with the Business.
- Changes in other requirements resulted from continuous review by the PO (“Now that I see it…”) and were not an issue for the developers .
- The project was short, but still completed so quickly compared to pre-Agile expectations that the team stayed together to implement another set of features out of the scope of the original BRD and budget.
- The team, some of who were skeptical, had fun and enjoyed the success. The Business was very pleased as well.
- The pre-Agile estimate of work was 2 years elapsed time in this highly multi-tasked environment. The Agile project was completed in less than 3 months thanks to a focused effort. Time value of money, anyone?
- Thanks to executive story pruning by the Product Owner and Sponsor, the product shipped earlier than even the original Agile estimated release date.
- Management had a greater knowledge of status without having status reports simply by attending the daily stand-ups.
Conclusion
So, did Agile work out well for this all-mainframe project? Indeed it did. Even though it was not full XP in technical practices, using a Scrum approach and Agile principles resulted in both earlier ROI (cost savings for end-users) and lower cost (thanks to evaporating features). Oh, and everyone had fun doing it – always a good sign.
