In one of the recent conversations I had with an Agile practitioner, he was talking to me about his experiences of Agile practices in Mainframe teams. He mentioned that they were following a 2-month long sprint cycle and within every sprint, they were developing and delivering valuable content.
One of the key questions that came to my mind was why each sprint is 8 weeks long.
This blog is to help anyone who is practicing Agile in the mainframe context for their product goals. These experiences are from my many years in the mainframe world as well as my recent work as a coach for mainframe technology based products
“Agility is for a product and organisation goal and not towards a single technology”
Its important to appreciate that ‘Mainframe Agility’ is not a correct term as agility is geared towards the goals and mainframe is only a technology that aids the realisation of the goals.
First, the definition of mainframe. “Mainframe” implies physical servers that cannot be ‘moved’ by a single person and uses software and platforms such as COBOL, CICS, JCL.
Vertical Epic/Story Slicing: There are many agile articles dedicated to vertical story slicing and focus on I.N.V.E.S.T. criteria. Story writing is complicated due to the online/batch processing as well as lack of visualisation of many of the features.
User persona in most cases is another system or a back end job.
Image Courtesy: slidewiki.org
In the teams that I have coached, the critical area that they struggle with is that the number of applications that they interface with is large and that the completion of a feature is tied to multiple other ones. In a typical mainframe system, there is one fairly large application that does the centralised processing and 20+ upstream and downstream applications that are connected.
In such an environment, a Product Owner may feel justified in thinking that the capability is complete only if all the 20+ applications have the change that is requested. Hence for all the teams to orchestrate the change and integrate, it would take 6 weeks to sometimes several months to take a feature to completion.
A few very simple steps can reduce the complexity for each of the participating teams
- A capability need to have multiple epics and epics divided into stories. While a capability can be done by multiple product / application teams, epics need to be defined at an application level. This aspect of slicing a capability into an epic is not unique to mainframes, however, due to the lack of end user visibility, it is harder for the product owners to define such boundary conditions. In the teams that I have coached, this is the hardest step without getting into the implementation detail.
Copyright: PM Power Consulting
- Next step is to define the Acceptance Criteria (AC) at all the levels of capability, epic and story. While its common for all the stories to have an acceptance criteria, often teams do miss on defining at a higher level. Defining at capability and epic level provides a granular input and output expectations. The ACs for a capability need to be written such as ‘when I enter a data to STRT product, I need to be able to have the updated data (decision) in FNL product’ . For the EPIC for the FNL product, given conditions and expected results need to defined at a level that FNL product understands.
- At a story level, start writing them with the inputs and outputs rather than personas in mind . Stories can be written like control systems where input criteria and output expected is defined along with it, feedback expected as well. Other ways to look at a story is by way of a workflow.
Anti-patterns to watch for is to not describe the programs and jobs in the stories. What it means is that the implementation of the story is deeply embedded within the problem description itself.
Product & Development Leaders’ Role: In the non mainframe world, the architecture runway is predominantly determined by the system architect and most of the solution created by teams would follow based on that.
In mainframe environments, it is important to have a keen sense of understanding on the strengths of mainframe product is used. And that’s primarily the product and development managers in short leadership call. An example should help here:
Let’s say, there is a need for an analytic to be developed based on the data stored in order to improve decision making. In the open source world, the focus would be on what’s the best tool/language that can make it happen. In the mainframe world, the leadership needs to understand whether the solution needs to be:
- Developed outside of the mainframe (Can data be migrated outside and the solution developed) or
- Improved within mainframe (Can the calculation be improved and modernized)
For every idea to be conceptualised, within mainframe or outside of it, it is a question that needs to be answered by leadership prior to the solution development.
This kind of strategy would ensure that the core competency of needed for mainframe development, say, robustness of data processing, volume transaction etc.. continues to be retained inside and everything else is outside.
Having highlighted the differences, there are common behaviours to be expected across mainframe and open source teams
- Discipline brought with the teams to commit just enough for a sprint and celebrate the completion
- Scrum ceremonies help in giving visibility, transparency and ease of communication
- Retrospectives foster the inspect and adapt culture
- Availability of a product owner empowers the team to focus on right product
- Continuous and Quarterly innovation sessions to ideate, innovate and implement interesting and impactful code
While the leadership would need to understand the differences in mainframe and focus on the right product, at the team level, technology really is only a vehicle to achieve the goal. Self-organization and curiosity would move the teams closer to where business function needs to operate.
For agility to be successful in mainframe technology, the need is for the ability to leverage custom tools for code movement, validation and batch processing. What are the scenarios that you have seen in this area?
