The 2-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 2-week COBOL sprint. If you’ve been reading my blog series, by now you understand how important the 2-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 2-week COBOL sprint that enable it to function. Imagine these components as Agile gears contained within the 2-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 2-week COBOL sprint, there are micro-steps involved in developing a process of continuous builds, including:
Tune Up Your Source Code Management
When reviewing your 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 Source Code Management (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.
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.
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.
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 2-week COBOL sprint requires adjusting processes and outlooks. Developing a process of continuous builds will help get your team get fit for the 2-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 2-week COBOL sprint.
Before we move on, if you need to recap read my other posts from “The 2-Week COBOL Sprint” blog series here, or follow the links below:
- “The 2-Week COBOL Sprint: Why Mainframe Shops Need It“
- “The 2-Week COBOL Sprint: How Agile Mends Broken Trust“
- “The 2-Week COBOL Sprint: Having a Critical Conversation About Agile“
- “The 2-Week COBOL Sprint: How to Build a Scrum Team“
- “The 2-Week COBOL Sprint: Agile Feedback Loops“
- “The 2-Week COBOL Sprint: Deployment Automation“
- “The 2-Week COBOL Sprint: Software Development Bottlenecks“
Latest posts by Glenn Everitt (see all)
- 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
- Why You Need Automated Unit Testing on the Mainframe - January 5, 2017