How mainframe software development teams benefit from using Rational Team Concert for System z

Get full value from process improvement by using agile techniques and automation

Learn how deploying Rational Team Concert for System z provides benefits in collaboration, planning, and agile processes for mainframe software development.


Chris Trobridge (, Product Line Manager for Rational Team Concert for System z, IBM  

Chris TrobridgeChris has more than 25 years of experience with software configuration management (SCM) tools. He has managed, recommended, and successfully implemented SCM solutions for all sizes of organization on most platforms and technologies.

08 October 2009

Also available in Russian

Develop skills on this topic

This content is part of a progressive knowledge path for advancing your skills. See Agile software development

If you want to improve your mainframe software development process, there are two things to consider.

First, consider the differences between software development on mainframes and in distributed environments, which can be characterized by these factors:

  • More mature applications in maintenance
  • Longer application life
  • Larger teams
  • Lower staff turnover
  • Older tools
  • Older processes and procedures
  • New projects often involve cross-platform collaboration with other technology

Aside from these differences, mainframe development shops have the same drive and desire to improve the cost effectiveness and productivity of the software development process.

Second, to recognize the value in any process improvement exercise, it is essential to be able to measure the impact of any change. The complex nature of software development means that it is not practical to reach an optimal state in a single activity; therefore, a phased or iterative approach to change is necessary. This makes a measured iterative approach to process improvement is essential, and that is exactly what is proposed by the IBM Measured Capability Improvement Framework (MCIF).

If you consider both of these factors, you can see that you need to look at how process improvement is affected by the mainframe environment.

The process improvement cycle

In his article titled Does Agility scale? Wrong question!, Gary Pallis entreats us to base our development practices on iterative models wherever possible. He tells us that all modern methods are all based on iterative, incremental development. He advises us to use this as a base and then to add the agile practices that are compatible with our organizations and project cultures.

Therefore, it is logical to approach process improvement in this iterative and incremental fashion. This leads to the characteristic process improvement curve that is illustrated in Figure 1.

Figure 1. Typical process improvement iteration
Graph: Productivity improvement cycles over time

Each cycle goes through three phases:

  • Dip: This is usually the planning, evaluating, piloting, and installation phase, and the dip can vary in severity and duration. Typically, involuntary changes to process often have a greater impact. An example of this would be a legislation change that requires additional information to be collected and corroborated. In these cases, the change does not always have a net positive effect on productivity.
  • Rise: This is the rollout and education phase.
  • Fall: The process changes have been implemented, but the effect degrades over time due to factors such as staff turnover, lack of enforcement, lack of ongoing education.

What we would like to see, instead, is Figure 2.

Figure 2. Optimal process improvement iteration
Target productivity improvement cycles

To achieve this, you need changes at several points:

  • Minimize the dip by finding ways to make process changes easier to select, plan, and prepare.
  • Get a rapid rise by identifying manageable process changes that can be easily implemented.
  • Maximize the height of the rise by getting the optimal implementation of the process change.
  • Eliminate the fall by ensuring that the development process is accepted and used, which also means that ongoing assistance and education need to be available to offset staff turnover.
  • Shorten iterations so that all parts of the development cycle can be fully utilized and there are more opportunities for process improvement, which minimizes the impact on development.

Using IBM Rational Team Concert for System z can help you achieve these goals for your software development cycle. Let’s look at the four areas: dip, rise, fall, and development cycle length.


Rational Team Concert for System z includes a set of process templates that are ready to use, but you can tailor them to the model that you require. Immediately, you are a long way toward achieving the first goal of making process changes easier to implement. You have a set of recommended processes that can be easily tailored to suit your situation, and they can be introduced and enforced at any suitable boundary in the development cycle. The software is simple to use, which helps people become productive quickly and results in a high level of acceptance. This means that the users can concentrate on the essential part of successful process improvement which is incorporating knowledge and experience into the new process by using various experts:

  • Process experts, such as agile process coaches
  • Application experts who understand the development process and what is being developed
  • Business experts who understand the administrative processes and requirements

Time and cost pressures are the enemy at this early stage. Do not be tempted to assign all process improvement tasks to external or junior staff. The people you need are usually the most experienced and least accessible, but they must be used. You cannot be completely successful without their expertise. Rational Team Concert for System z is an automation tool, so if you do not invest in expertise, then you will automate a less-than-perfect process and, inevitably, achieve less-than-perfect results. Doing that faster will be no comfort!

The dip will never be totally eliminated, but having a framework that can easily be modified to accommodate new practices removes the implementation barrier.


Rational Team Concert for System z is a simple-to-use tool that can be picked up rapidly by users. Initial education is simple, and after the tool is in place, any process changes simply require education in the process, not the tool. This means that the implementation phase, where value is realized from the process improvement, can be achieved with minimal effort. As more tools from Rational business partners and users appear on the Jazz platform or work with Rational Team Concert for System z, the process improvement can be extended seamlessly into those areas, as well. For the IBM System z® development platform, for example, IBM® Rational® Developer for System z adds a powerful integrated development environment onto the management capabilities of Rational Team Concert for System z.

To get the rise as steep as possible, it is essential to get the maximum benefit out of any process change. Let’s look at an example of breakdown of work for a development team before a process improvement cycle. In Figure 3, we have broken the development effort into three categories:

  • Work is new productive development
  • Rework is repeated development work (bug fixes, maintenance, and so forth)
  • Admin is the administrative part and nondevelopment work (education, procedural overhead, and so on)

The effect of process improvement will be to improve the work-to-rework ratio.

Figure 3. Before process improvement
Pie chart of activity before process improvement

If you implement a process change with manual procedures, what you typically would see is what Figure 4 shows: The proportion of work done has increased, but the administrative overhead introduced by the process change has restricted the benefit available. Process improvement changes that might show this pattern include things such as introducing regular building of the application or holding scrum meetings.

Figure 4. After process improvement
Pie chart of activity after process improvement

If you look at what happens if the process improvement is automated (Figure 5), you see that automation cuts down on the administrative work, so the development team can take maximum advantage of the process improvement. Rework is reduced, because automation reduces the opportunities for manual errors and prevents deviation from the process.

Rational Team Concert for System z provides this automation for heterogeneous development environments that
include System z.

Figure 5. After process improvement with automation
Pie chart of activity after automation

Also relevant to how Rational Team Concert for System z assists in minimizing administrative overhead is considering some of the agile techniques that an organization might look at when planning process improvement. One of the most widely recognized techniques in agile development is scrum project management (see Resources for a link to "Scrum project management with Rational Team Concert, Version 2"). Scrum meetings work best when development operates on the Agile One Room philosophy and development is co-located with the user or customer. Scrums are designed to be short, regular, meaningful meetings where participants raise a maximum of three points with the group. This works only if there is constant collaboration during the development process. Achieving this with manual techniques or nonintegrated tools can be difficult, time-consuming, and expensive.

It is not usually possible in large or cross-platform projects to co-locate staff, so Rational Team Concert for System z provides powerful collaboration tools in a simple unified environment. This enables all users to see and track the progress of others and to interact with them, thereby permitting the scrums and the Scrum of Scrums to focus on essential issues. Scrums can be run efficiently with all participants accessing their Rational Team Concert for System z Taskboards (Figure 6).

Figure 6. Rational Team Concert for System z Taskboard
Sprint Backlog screen

Agile development has a people-centric philosophy, and Rational Team Concert for System z empowers every user, giving each person visibility, connectivity with the rest of the team, and automatic accountability.


If you look back at Figure 3, you can see the preimprovement state. After improvement, you move to Figure 4. If the process is not policed then, either through choice (users take the route of least effort) or lack of knowledge, development will gradually revert to its state before the improvement. Manual policing and enforcement is expensive to implement, and inefficient to maintain, and time-consuming to teach. So an automated environment that can enforce, track, and provide contextual assistance is essential to maintain the benefit from any process. Rather than having to consult documentation and remember what processes you should follow, Rational Team Concert for System z uses the process knowledge that it is configured with to automatically detect violations of your team's process the instant that they happen. It also provides feedback whenever the team's process is violated. This feedback (Figure 7) is often accompanied by proposals for automated fixes to speed the developer along. If desired, you can allow process preconditions to be overruled. That way, you can encourage best practice yet remain flexible.

Figure 7. Rational Team Concert for System z process advice
In-context assistance from the Process Advisor

Development cycle length

All modern development processes are incremental and iterative. Agile development is just one example. A sprint will typically be working from a feature or work backlog and involve only the minimal amount of planning to set the context of the sprint. Although the chosen process model may not be agile, similar issues affect the duration of all development iterations:

  • Content for the customer to review
  • System operational (each iteration must deliver a working system)
  • Experience level of the development team
  • Availability of the customer
  • Knowledge for planning
  • External dependencies (hardware and such)
  • Length of testing cycles
  • Planning and administrative overhead

One advantage of shorter development cycles, though, is that they force regular early and quick evaluation and allow continual interaction with the customer. Assuming that the project is suitable for shorter development iterations, then the critical factor in being able to achieve this is the ability to plan with minimal effort. If sprints are adopted, then the work backlog needs to be composed of work items of at most two days in duration. The product owner and the architects are responsible for implementing this. Failure to break the work down into these small pieces results in lack of flexibility, traceability, and independence (a work item that is active for a long time is likely to acquire dependencies on other items and is, therefore, likely to require more integration work and testing in its development). It makes progress monitoring hard, because work items are typically the units tracked.

The main controllable factor, which affects the length of the development cycle, is the overhead for planning and administrative. The integrated planning tool in Rational Team Concert for System z helps you minimize this cost and the risks involved. For example, when building and tracking a sprint with Rational Team Concert for System z, the plans can be assessed for risk of completion problems, and during execution, the owners of the items can update the completion risk information. This provides a very clear indication of whether the contents of each sprint are likely to be completed. The user is then able to take action and adjust the plans as required.


There is no dispute that process improvement delivers value to any organization. Automation enables you to realize the full value of that improvement sooner and to maintain it without losing potency. The difficult part is implementing process improvement and automation when faced with the challenges of mainframe development. Rational Team Concert for System z provides an automation framework for process improvement across heterogeneous development environments that include the System z platform. This means that Rational Team Concert for System z can allow agile techniques to be employed in previously hostile configurations by providing an enterprise-wide planning and collaboration environment for software development. As a result, all modern development processes are now practical propositions for organizations that have IBM System z environments.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

Zone=Rational, DevOps
ArticleTitle=How mainframe software development teams benefit from using Rational Team Concert for System z