5 Tips to Accelerate Adoption of Rational Developer for System z

Reasoning

We've been involved in several large scale deployments of Rational Developer for System z. The product is an incredible piece of software that can drastically improve software development productivity. It also will drastically change your development organization's culture (usually for the better). However to have the best culture change, you need to be prepared to implement the product correctly. We've seen it implemented poorly, and have cleaned up after the product was improperly installed or the students were insufficiently instructed. If you follow these five tips, you'll have about a 97% chance of a successful adoption. 

1) Automate Deployment of the client to the Desktop

Rational Developer for System z is a large, complex tool. Most mainframe organizations (banks, insurance companies, financial institutions, governments, etc) often need to restrict what software is installed on the developer's workstation. Fortunately, this can all be automated and scripted. Further, it can be combined with other IBM tools (such as IBM DataStudio), as well as the current fix packs in one single package using the Packaging Utility. Once packaged, it can be installed using scripted methods and automated using tools such as Microsoft SMS, or IBM Endpoint Manager (now BigFix). 

 Even before you begin the packaging, you'll need to spend time to understand all the tools that the developers currently interact will, or will need to interact with after it is deployed. This may include any of the following:


Take a survey by your development teams. Do NOT assume you know all the answers; we've seen career sysprogs surprised by the results. 

 2) Provide Just-In-Time Training

Training is absolutely critical for success. An ISPF developer will be hard pressed to adopt RDz without it (and there is ZERO evidence that any ISFP developer actually has adopted it without training). 

 As such, you need the right training, at the right time. The right training is a minimum of 2 days in person classroom training, adjusted and or customized for your environment. Yes, you need to budget for this. If you are budgeting for RDz and not budgeting for training, I recommend you not purchase the product. In fact, please don't buy it if that is the case. Your team will fail to use it, you'll waste money, and everyone will have a bad taste in their mouth afterwards.  

 So now that you've read that, and you've included some budget room for training, you need to schedule it for the right time, and find the right RDz partner who knows the product well. That is typically the week you expect your ISPF developers to begin actually using the product. You can do a week before, but never earlier than that. That means you need to have the product installed, configured (on both the host and the client) and ready to go on day 1 of training. It needs to be integrated with all the critical systems including SCM out of the gate (see #1 above). An alternative to classroom training is on-demand Computer Based Training. Our organization is currently developing this exact course with videos, interactive quizzing, and lab exercises. CBT based curricula would allow a student to revisit the course several times. 

 Training should also be multivariate as your personnel will learn at different rates. Provide classroom training to everyone at the start, but then provide additional training for laggards, and for new hires (those people hired after the original training finished). Provide interactive lunch-and-learns hosted by your RDz business partner, or your team champions (see #3 below). 
3) Cultivate Mentors

To cultivate a product mentor in your organization, you'll need to train them ahead of the rest of their team. Typically, this person would be involved in the initial pilot or sales demo process and have prior experience with Eclipse. These are the people who will eventually conduct lunch-and-learns post implementation, interact with the IBM support team, and attend conferences such as COMMON or IBM InterConnect or Edge. To cultivate, you need to ensure these folks schedule time in their calendars to interact with the product, read up with its integrations and go through advanced tutorials and product literature. Budget for their attendance at conferences. Provide them a Wiki or Connections site to host so they can interact with other students and share their knowledge. Most of all, make them feel appreciated and reward them for positive efforts.

 4) Uninstall the terminal emulators on the desktop


This is an effective motivator as exemplified by Cortez in 1520 when he sunk his ships to avoid mutiny by his men. As a result, his men were well motivated. To access it, just right click on your host lapr in the Remote Systems Explorer view.  Yes, you read that correctly! You may not know this, but RDz includes a terminal emulator as part of the product. Its baked into the IDE and provides all the core functionality of the IBM PCOMM emulator (note that it does not include FTP or macro functionality). Click on Host Connection Emulator and it will bring up the emulator as shown below. 


This GUARANTEES that the developer will have to use RDz just to get to their precious emulator. By the time they get in and are connected, they'll just as likely go into the other RDz views rather than have to log into the emulator and navigate to their ISPF panels. 

 5) Adjust the Developer's Expectations

One of the most common excuses I hear is that "we have to deal with production issues fast, so I don't have time to use it", or "my boss expects this to be done now, and won't wait".  This is of course a bogus excuse. RDz makes the job of the COBOL development more productive, but it does have an initial learning curve. Once past that learning curve the productivity accelerates. So how do we combat this issue? First, we need to coordinate executive sponsorship from the C-level down through middle managers. The middle managers are critical on this. They need to set the expectations to their teams that using RDz to solve critical issues is paramount to just "going with the devil that you know". Thus, the developer should have the expectations, that they are not just the fixing the problem like putting on a bandaid, but applying proper medicine such that the problem never manifests itself again. Ensuring that the middle managers expect them to use their new DevOps tools is a key part of its successful adoption. We're not just using a tool for the sake of technology, we're using technology to vastly improve our business outcomes and our productivity. 

Labels: , ,