Agile on the Mainframe (and Other Odd Places)

1. Agile on the Mainframe(and Other Odd Places) How Mainframe Agile Teams Are (not so) Different November 8, 2007 Charlie Poole

2. Introductions

3. 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, NUnitLite, VSUnit, Fit

4. 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

5. About Mainframe Programmers • Take a card... • 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. 

6. Discussion – Part I • What sorts of feelings are represented on your cards? • Admiration? • Respect? • Pity? • Disdain? • Puzzlement?

7. Discussion – Part II • Have similar words, phrases, feelings been applied to programmers in your own company? • By managers? • By co-workers? • By you? • What does this mean for introducing Agile?

8. A Mainframe Tale Experiences at Key Bank

9. Warning Label • This is a story about one of my clients and is included here with their permission, for which I am very grateful. • For obvious reasons, I will not be able to answer every question that pertains specifically to work being done for this client. • I request your understanding in limiting questions as much as possible to the general ideas this story illustrates.

10. A Mainframe Tale • Key Bank is a very forward-looking company in its software development and has introduced agile approaches company-wide over the past few years. • They have their own internal coaches and bring in other folks from outside as needed. • They have been very successful at it.

11. A Mainframe Tale • From the preceding, you can see that Key Bank are not amateurs at Agile... except on the mainframe... where we are all amateurs.

12. A Mainframe Tale - Details • Key has LOTS of mainframe work, even as they increase their use of desktop and distributed apps. • Almost everything else depends on the mainframe apps. • The programmer population is getting older. • Conversion is not practical for much of this work.

13. A Mainframe Tale - Details • Key has introduced Agile development in all technical areas except for the mainframe. • Management likes what Agile does for them, but they aren’t getting it from the mainframe. • Programmers don’t know how to give management what they want.

14. Interlude: How I Got into This • Experience • Mainframe (years back) and Agile coaching • Attitude • Respect for Mainframe programmers • Like a challenge • Availability • Nobody else wanted to do it

15. A Mainframe Tale - Objectives • 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. • To be able to prioritize features and deliver them incrementally, rather than waiting for the end of a project. • To shorten final testing times after introducing more reliable testing into the development process.

16. A Mainframe Tale - Objectives • To identify the aspects of agile methodology, which are relevant to mainframe development – in most cases by actually trying them out. • To be able to estimate projects more aggressively in the future. • To be able to react quickly to problems and changes.

17. Defining Agile What Do We Want?

18. Defining Agile - the Wrong Way • Agile is sometimes taken to mean practices • Doing Test-Driven Development • Using Scrum • etc. • Not a satisfactory approach • It assumes Agile can be made into a recipe • Doesn’t help us move across technologies

19. 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”

20. Top-down Agile – the Wrong Way • Tell the programmers to be “agile” • Tell them precisely how to be agile • Make sure they do it

21. Top-down Agile – the Right Way • Tell the programmers why agile is important to the company. • Tell them what results you want to see. • Ask them to figure out how, providing them the time and support they need to do it. • Identify and remove obstacles.

22. One Good Thing About the Mainframe • We don’t have pre-existing tools and practices in most cases. • We can’t tell them how to do it. • We are forced to enable the developers to “invent” their own flavor of agile.

23. Mainframe Obstacles

24. Mainframe Obstacles • Very large file sizes are the norm, leading to long run times for any tests. • Test runs consist of a number of interdependent jobs and it is often not possible to run tests of a single job step. • 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.

25. Mainframe Obstacles • 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. • 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.

26. Mainframe Obstacles • 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. • 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.

27. Mainframe Obstacles • The verification of test results is often manual, although it may sometimes be assisted through the use of file comparison utilities. • 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. • In many cases, separate tools are needed for Hogan and non-Hogan applications.

28. COBTEST A Low-level Test Framework

29. Second Warning This is more interesting than important!

30. COBTEST : a Prototype Test Framework • Works for both Hogan and non-Hogan Cobol programs. • Tests at a very low level – xUnit style. • Building block for higher level tools.

31. COBTEST Structure Test Program Program Under Test Test Framework (COBTEST)

32. Using COBTEST CALL ‘COBTEST’ USING INIT-ACTION. PERFORM ACCOUNT-TESTS. PERFORM TEMPERATURE-TESTS. PERFORM FRAMEWORK-SELF-TESTS. CALL ‘COBTEST’ USING TERM-ACTION.

33. Using COBTEST TEMPERATURE-TESTS. MOVE ‘BOILING POINT’ TO TEST-NAME’ MOVE 212 to F-TEMP CALL ‘TEMPF2C’ USING TEMPS MOVE 100 TO EXPECTED-PACKED MOVE C-TEMP TO ACTUAL-PACKED CALL CHKPACK …

34. COBTEST Entry Points • COBTEST • Initialization and Termination • CHKEQUAL • Compare two alphanumeric fields • CHKPACK • Compare two packed fields • CHKBIN • Compare two binary fields

35. TESTSPEC Copy Book 77 INIT-ACTION PIC X(4) VALUE 'INIT'. 77 TERM-ACTION 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 S9(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 S9(9). 10 FILLER PIC X(91). 05 ACTUAL-REDEF-2 REDEFINES ACTUAL-VALUE. 10 ACTUAL-BINARY PIC 9999 BINARY. 10 FILLER PIC X(98).

36. COBTEST as a Tool • Aimed at tests written by programmers before or during coding. • Tests are of individual programs or routines. • Test program supplies data, one case at a time. • Can also be used to find out how a routine responds to various inputs. • Need other tools for other purposes.

37. Potential Extensions of COBTEST • Run tests dynamically, based on input • Possibly, separate Hogan and non-Hogan runners • Additional test predicates and data types • Data driven tests • Test reads inputs and expected values • Data interception • Test is inserted into processing flow

38. A Major Weakness • COBTEST enables running small, fast tests as you work. • Unfortunately, it can take 20 or 30 minutes to submit the test and get the result. • Two possible solutions… • Come up with way to eliminate the wait time. • Invent new patterns of working that take the time delays into account.

39. An Agile Workshop Engaging Mainframe Developers

40. An Agile Workshop • Open Space Format • Approximately 70 mainframe developers • Approximately 40 sessions offered around our two-part theme.

41. Workshop Theme What would it meanto be agileon the mainframe? How can we make it happen?

42. An Agile Workshop • Half day introduction to what agile means • Two Days of Open Space • Half day follow-through • Session reports and project organization • Creation of project backlogs • Top-level management acceptance

43. After the Workshop • Teams are organized as for any project, with a top-level manager as the Product Owner. • Mix of “low-hanging fruit” and projects requiring a long-term effort. • Quarterly two-day workshops will be held.

44. Conclusions and Discussion

45. Conclusions • Agile on the mainframe has unique problems. • We are forced to rely on the programmers to invent the practices they need. • We hope that doing so will give us a better set of practices.

46. Meta-Conclusion This is what we should be doing anyway!

47. Odd Places… Are there other “Odd Places” where this approach might work? What about your project?

48. Thank You