Poole Consulting Agile on the Mainframe and Other

Poole. Consulting Agile on the Mainframe (and Other Odd Places) How Mainframe Agile Teams Are (not so) Different November 8, 2007 Charlie Poole Agile on the Mainframe (1/49) © 2007 Charlie Poole. All rights reserved

Poole. Consulting Introductions Agile on the Mainframe (2/49) © 2007 Charlie Poole. All rights reserved

Charlie Poole What I do… Languages… Cobol, PLI, Fortran, C, C++, C#, IBM & Intel assembler Platforms Mainframe, Windows, . Net, Linux, Mono, Cross-platform Coaching and Training XP, Agile, TDD, NUnit Open Source NUnit, NUnit. Lite, VSUnit, Fit Agile on the Mainframe (3/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Charlie Poole My dubious past… Languages… Cobol, PLI, Fortran, C, IBM assembly language Hardware Platforms Hardware: IBM, Dec, Honeywell, CDC, Univac Software Environments CICS, SQL, VM Agile on the Mainframe (4/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

About Mainframe Programmers n Take a card. . . q q q Write a word or short phrase that comes to mind when you think of mainframe programmers, who are still doing it today. Write several if you like. It’s OK to be unfair – we’ll try to be more reasonable later on. Agile on the Mainframe (5/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Discussion – Part I n What sorts of feelings are represented on your cards? q q q Admiration? Respect? Pity? Disdain? Puzzlement? Agile on the Mainframe (6/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Discussion – Part II n Have similar words, phrases, feelings been applied to programmers in your own company? q q q n By managers? By co-workers? By you? What does this mean for introducing Agile? Agile on the Mainframe (7/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Poole. Consulting A Mainframe Tale Experiences at Key Bank Agile on the Mainframe (8/49) © 2007 Charlie Poole. All rights reserved

Warning Label n This is a story about one of my clients and is included here with their permission, for which I am very grateful. n For obvious reasons, I will not be able to answer every question that pertains specifically to work being done for this client. n I request your understanding in limiting questions as much as possible to the general ideas this story illustrates. Agile on the Mainframe (9/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

A Mainframe Tale n Key Bank is a very forward-looking company in its software development and has introduced agile approaches company-wide over the past few years. n They have their own internal coaches and bring in other folks from outside as needed. n They have been very successful at it. Agile on the Mainframe (10/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

A Mainframe Tale n From the preceding, you can see that Key Bank are not amateurs at Agile. . . except on the mainframe. . . where we are all amateurs. Agile on the Mainframe (11/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

A Mainframe Tale - Details n Key has LOTS of mainframe work, even as they increase their use of desktop and distributed apps. n Almost everything else depends on the mainframe apps. n The programmer population is getting older. n Conversion is not practical for much of this work. Agile on the Mainframe (12/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

A Mainframe Tale - Details n Key has introduced Agile development in all technical areas except for the mainframe. n Management likes what Agile does for them, but they aren’t getting it from the mainframe. n Programmers don’t know how to give management what they want. Agile on the Mainframe (13/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Interlude: How I Got into This n Experience q n Attitude q q n Mainframe (years back) and Agile coaching Respect for Mainframe programmers Like a challenge Availability q Nobody else wanted to do it Agile on the Mainframe (14/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

A Mainframe Tale - Objectives n To support agile in the mainframe environment. In particular, mainframe development should not appear to be an impediment in the overall flow of technical work. n To be able to prioritize features and deliver them incrementally, rather than waiting for the end of a project. n To shorten final testing times after introducing more reliable testing into the development process. Agile on the Mainframe (15/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

A Mainframe Tale - Objectives n To identify the aspects of agile methodology, which are relevant to mainframe development – in most cases by actually trying them out. n To be able to estimate projects more aggressively in the future. n To be able to react quickly to problems and changes. Agile on the Mainframe (16/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Poole. Consulting Defining Agile What Do We Want? Agile on the Mainframe (17/49) © 2007 Charlie Poole. All rights reserved

Defining Agile - the Wrong Way n Agile is sometimes taken to mean practices q q q n Doing Test-Driven Development Using Scrum etc. Not a satisfactory approach q q It assumes Agile can be made into a recipe Doesn’t help us move across technologies Agile on the Mainframe (18/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Defining Agile Based on Results “Create real software in an iterative fashion, delivering small functional increments on a regular basis so that the team and the users can always see real progress” Agile on the Mainframe (19/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Top-down Agile – the Wrong Way n Tell the programmers to be “agile” n Tell them precisely how to be agile n Make sure they do it Agile on the Mainframe (20/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Top-down Agile – the Right Way n Tell the programmers why agile is important to the company. n Tell them what results you want to see. n Ask them to figure out how, providing them the time and support they need to do it. n Identify and remove obstacles. Agile on the Mainframe (21/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

One Good Thing About the Mainframe n We don’t have pre-existing tools and practices in most cases. n We can’t tell them how to do it. n We are forced to enable the developers to “invent” their own flavor of agile. Agile on the Mainframe (22/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Poole. Consulting Mainframe Obstacles Agile on the Mainframe (23/49) © 2007 Charlie Poole. All rights reserved

Mainframe Obstacles n Very large file sizes are the norm, leading to long run times for any tests. n Test runs consist of a number of interdependent jobs and it is often not possible to run tests of a single job step. n For many applications, programs are not run directly but are under the control of a third-party application (Hogan) which is widely used in the banking industry. Agile on the Mainframe (24/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Mainframe Obstacles n The need to submit jobs and then wait for them to complete makes mainframe development proceed at a much slower pace than desktop work. Developers must either wait or turn their attention to some other task while a test proceeds. n For test runs, job steps must often be staged manually, because automated scheduling is not available. Because of processing demands during the day, this is reported as frequently done by developers working from home. Agile on the Mainframe (25/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Mainframe Obstacles n Existing utilities, such as dump analysis and tracing tools are not always used systematically due to unfamiliarity or inconvenience. Practice in this area can differ significantly from developer to developer. n For most applications, there is no standard test bed used to automatically run tests and determine if regressions have occurred. Where such tests exist, manual review is usually required. Agile on the Mainframe (26/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Mainframe Obstacles n The verification of test results is often manual, although it may sometimes be assisted through the use of file comparison utilities. n Testing tools, such as exist in the worlds of desktop and distributed development, are not generally available for the mainframe, and would need to be developed locally. n In many cases, separate tools are needed for Hogan and non-Hogan applications. Agile on the Mainframe (27/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Poole. Consulting COBTEST A Low-level Test Framework Agile on the Mainframe (28/49) © 2007 Charlie Poole. All rights reserved

Second Warning This is more interesting than important! Agile on the Mainframe (29/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

COBTEST : a Prototype Test Framework n Works for both Hogan and non-Hogan Cobol programs. n Tests at a very low level – x. Unit style. n Building block for higher level tools. Agile on the Mainframe (30/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

COBTEST Structure Test Program Under Test Agile on the Mainframe (31/49) © 2007 Charlie Poole. All rights reserved Test Framework (COBTEST) Poole. Consulting

Using COBTEST CALL ‘COBTEST’ USING INIT-ACTION. PERFORM ACCOUNT-TESTS. PERFORM TEMPERATURE-TESTS. PERFORM FRAMEWORK-SELF-TESTS. CALL ‘COBTEST’ USING TERM-ACTION. Agile on the Mainframe (32/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Using COBTEST TEMPERATURE-TESTS. MOVE ‘BOILING POINT’ TO TEST-NAME’ MOVE 212 to F-TEMP CALL ‘TEMPF 2 C’ USING TEMPS MOVE 100 TO EXPECTED-PACKED MOVE C-TEMP TO ACTUAL-PACKED CALL CHKPACK … Agile on the Mainframe (33/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

COBTEST Entry Points n COBTEST q n CHKEQUAL q n Compare two alphanumeric fields CHKPACK q n Initialization and Termination Compare two packed fields CHKBIN q Compare two binary fields Agile on the Mainframe (34/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

TESTSPEC Copy Book 77 INIT-ACTION 77 TERM-ACTION PIC X(4) VALUE 'INIT'. PIC X(4) VALUE 'TERM'. 01 TEST-SPECIFICATION. 05 TEST-NAME PIC X(50). 05 USER-MESSAGE PIC X(50). 05 EXPECTED-VALUE PIC X(100). 05 EXPECTED-REDEF-1 REDEFINES EXPECTED-VALUE. 10 EXPECTED-PACKED PIC S 9(9). 10 FILLER PIC X(91). 05 EXPECTED-REDEF-2 REDEFINES EXPECTED-VALUE. 10 EXPECTED-BINARY PIC 9999 BINARY. 10 FILLER PIC X(98). 05 ACTUAL-VALUE PIC X(100). 05 ACTUAL-REDEF-1 REDEFINES ACTUAL-VALUE. 10 ACTUAL-PACKED PIC S 9(9). 10 FILLER PIC X(91). 05 ACTUAL-REDEF-2 REDEFINES ACTUAL-VALUE. 10 ACTUAL-BINARY PIC 9999 BINARY. 10 FILLER PIC X(98). Agile on the Mainframe (35/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

COBTEST as a Tool n Aimed at tests written by programmers before or during coding. q q Tests are of individual programs or routines. Test program supplies data, one case at a time. n Can also be used to find out how a routine responds to various inputs. n Need other tools for other purposes. Agile on the Mainframe (36/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Potential Extensions of COBTEST n Run tests dynamically, based on input q Possibly, separate Hogan and non-Hogan runners n Additional test predicates and data types n Data driven tests q n Test reads inputs and expected values Data interception q Test is inserted into processing flow Agile on the Mainframe (37/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

A Major Weakness n COBTEST enables running small, fast tests as you work. n Unfortunately, it can take 20 or 30 minutes to submit the test and get the result. n Two possible solutions… q q Come up with way to eliminate the wait time. Invent new patterns of working that take the time delays into account. Agile on the Mainframe (38/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Poole. Consulting An Agile Workshop Engaging Mainframe Developers Agile on the Mainframe (39/49) © 2007 Charlie Poole. All rights reserved

An Agile Workshop n Open Space Format n Approximately 70 mainframe developers n Approximately 40 sessions offered around our two-part theme. Agile on the Mainframe (40/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Workshop Theme What would it mean to be agile on the mainframe? How can we make it happen? Agile on the Mainframe (41/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

An Agile Workshop n Half day introduction to what agile means n Two Days of Open Space n Half day follow-through q q q Session reports and project organization Creation of project backlogs Top-level management acceptance Agile on the Mainframe (42/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

After the Workshop n Teams are organized as for any project, with a top-level manager as the Product Owner. n Mix of “low-hanging fruit” and projects requiring a long-term effort. n Quarterly two-day workshops will be held. Agile on the Mainframe (43/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Poole. Consulting Conclusions and Discussion Agile on the Mainframe (44/49) © 2007 Charlie Poole. All rights reserved

Conclusions n Agile on the mainframe has unique problems. n We are forced to rely on the programmers to invent the practices they need. n We hope that doing so will give us a better set of practices. Agile on the Mainframe (45/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Meta-Conclusion This is what we should be doing anyway! Agile on the Mainframe (46/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Odd Places… Are there other “Odd Places” where this approach might work? What about your project? Agile on the Mainframe (47/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Thank You Agile on the Mainframe (48/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting

Agile on the Mainframe (49/49) © 2007 Charlie Poole. All rights reserved Poole. Consulting