The Two-week COBOL Sprint: Developing a Process of Continuous Builds
To compete in the digital economy, Mainframe shops must commit to an Agile culture and processes like the two-week COBOL sprint. If you’ve been reading my blog series, by now you understand how important the two-week COBOL sprint is for accelerating the pace of mainframe software development and delivery at your organization.
In my last post, I wrote about how to build your scrum team. After you do this, the team needs to familiarize itself with a few components of the two-week COBOL sprint that enable it to function. Imagine these components as Agile gears contained within the two-week COBOL sprint. The first gear I want to review is a process of continuous builds.
Developing a Process of Continuous Builds
Most IT teams use a lengthy process that hides broken builds and software integration issues until the end of a release cycle. By then, identifying people responsible for breaks and diagnosing their missteps is an exhausting chore—the contractor left, the developer moved onto another project, the person was fired. There are no tracks to trace, stretching build-completion time longer and tension between team members tauter.
Developing a process of continuous builds will help your team more quickly identify the origins of broken software because it requires correcting errors along the way instead of letting them accumulate. But just as there are steps to completing a two-week COBOL sprint, there are micro-steps involved in developing a process of continuous builds, including:
1. Tune Up Your Source Code Management
When reviewing your source code management (SCM), ask questions like: What triggers a build? How long does a build take? Who is authorized to start a build? Are the builds frequent enough? Is your code organized in a way that multiple people can work on it at a time? Is there enough information logged to diagnose a build problem? Reviewing the build processes in your SCM is a great place to begin moving towards a process of continuous builds. Many mainframe shops drive their build process from their SCM, which demonstrates the importance of having a quality SCM solution in place. If you have a “home built” SCM system, replace it. Such systems are difficult to use unless you’re one of the people who developed it, and chances are those people are retiring soon.
2. Develop a Culture of Constantly Checking in Units of Working Code
The more frequently developers commit their code, the less frequently they have code collisions requiring code merges. Some mainframe developers have an ingrained behavior of performing giant code commits at the end of development cycles. The developers on your scrum team must change their behavior and begin regularly checking in units of working code.
This behavioral change will require continuous reinforcement: discuss the positive aspects of frequent code commits; make it a criterion for good performance reviews; emphasize the benefits of regular check-ins when a team member finds and fixes bugs earlier in the development cycle; point out how much easier it was to find problematic code while it was fresh in everyone’s minds; and, finally, celebrate the improvement.
3. Identify Team Members in Need of Coaching on Check-Ins and Organization
Some team members may find it difficult to adjust to frequent check-ins and will struggle to organize their work into logical units. Regardless of how willing scrum team developers are, their habits will be hard to break. To identify struggling team members, take into account who breaks the build. Make an effort to coach them through adjustments.
4. Review How Many Pieces of Configuration Are Managed
In DevOps, “configuration as code” means you treat configuration files and definitions as tantamount to source code. Like source code, configurations change over time and are tuned to fit with specific software versions. When developing a process of continuous builds, version and deploy configuration in a similar way you would version and deploy software components.
Preparing for the two-week COBOL sprint requires adjusting processes and outlooks. Developing a process of continuous builds will help get your team get fit for the two-week COBOL sprint, but you’re going to need more than that for success. My next post covers how to implement Agile feedback loops, the next Agile gear of the two-week COBOL sprint.
Before we move on, if you need to recap read my other posts from “The Two-week COBOL Sprint” blog series by following the links below:
- “The Two-week COBOL Sprint: Why Mainframe Shops Need It“
- “The Two-week COBOL Sprint: How Agile Mends Broken Trust“
- “The Two-week COBOL Sprint: Having a Critical Conversation About Agile“
- “The Two-week COBOL Sprint: How to Build a Scrum Team“
- “The Two-week COBOL Sprint: Agile Feedback Loops“
- “The Two-week COBOL Sprint: Deployment Automation“
- “The Two-week COBOL Sprint: Software Development Bottlenecks“
Latest posts by Glenn Everitt (see all)
- Reducing the Danger of Shadow IT with DevOps - May 15, 2018
- Living in a ‘More Data, More Problems’ World with Unit Tests - September 6, 2017
- No Mock Objects for Your Mainframe? Create COBOL Program Stubs - March 23, 2017