The Two-week COBOL Sprint: Agile Feedback Loops
Agile and DevOps on the mainframe stress the value of Agile feedback loops that transmit valuable information from your continuous build process to your scrum team, such as alerting them of unmet customer needs, neglected software components and incorrect coding causing a broken build.
To intercept mistakes early on and redirect development, developers can capitalize on feedback from various areas of the development process, including:
- Scrum Team
Customer Agile Feedback Loops
Customers are your primary source of feedback, and whether the software implemented is valuable and works the way it’s intended to is at the core.
A great time to get customer feedback is during your sprint review by structuring it into two parts: the software demo—when you get customer feedback—and a second half reserved for detailed questions and technical debt discussions. The more frequently customers attend sprint reviews, the better feedback becomes.
Here are some things to keep in mind when you invite customers to sprint reviews:
- Show customers you’re listening. Nothing is more discouraging than having insightful feedback ignored.
- Document customer feedback as a backlog story, get it prioritized and build something.
- When you review or demo a story feature, indicate that customer feedback drove the development.
- Encourage customer participation with open-ended questions: What frustrates you about using the product? Do error messages make sense? Does the product feel consistent?
Customer feedback directs the development of valuable products and limits options to those that customers endorse, rather than overbuilding options customers won’t use, requiring unnecessary time and support.
Scrum Team Agile Feedback Loops
Scrum teams provide feedback on the Agile process during retrospective meetings, often surrounding these basic questions:
- What should we stop doing?
- What should we start doing?
- What should we continue?
- What should we do more of?
- Are there bottlenecks in the existing process?
Scrum teams are comprised of unique people with specific strengths and weaknesses, making it easier to creat an Agile feedback loop on areas needing adjustment to accelerate development.
Operations Agile Feedback Loops
Operations provides feedback in several forms, beginning with how easy it is to install and configure software—if it takes days, it needs more work. Operations also provides product log files for review after software problems occur, and answers questions about the log file, like:
- Does it provide enough information about the problem?
- Does it help with problem diagnosis?
- Does it indicate on which system the problem occurred?
- Does it provide a timestamp?
- Does it indicate if a user was involved?
- Does it indicate network connection usage?
Usually, operations will run performance monitors to ensure everything operates efficiently, enabling them to spot unusual application performance characteristics, such as long start-up times, CPU usage spikes and high rates of disk access. Performance monitors also provide information about inadequate SQL statements, leading database administrators to collaborate more closely with developers.
Getting Feedback from Tools
Code is highly complex. Code metrics provide feedback about your average program size and help you determine adding sprint backlog items to refactor large programs to manageable sizes.
Code complexity measurements, like cyclometric complexity, provide information about numbers of pathways through the code. More paths mean more complexity, a higher likelihood of bugs and harder-to-test code. These measurements should be used thoughtfully. Sometimes code is complex to satisfy complexity requirements. These measurements do help identify places to look for issues and can help identify, with code coverage, where additional testing efforts should be done.
Other interesting code metrics measure coupling and cohesion, which are somewhat opposing forces. Coupling indicates how independent code is. High coupling is bad because the code is very dependent and would be hard to reuse in another module. Cohesion indicates whether module programs are similar and perform similar function towards a common goal. A highly cohesive module is good because a module works as a unit and is reusable.
Getting Feedback from Testing
Do you incorporate feedback from failed tests into your sprint backlog as technical debt? If it’s difficult writing tests for product parts, perhaps they’re poorly architected and difficult to use. If you keep a feedback loop open between developers and test developers, testing can give you more than a pass-fail diagnosis, for example:
- Unit testing: isolates problems to specific application parts, providing fast feedback with pinpoint accuracy
- Automated functional testing: provides less precise feedback, but a better idea of product functionality and whether to grant user access to a build for acceptance testing
- Code coverage: more information is available if your continuous build process measures code coverage information indicating how much product code was tested
In essence, don’t simplify your measurement of testing; leverage the various testing perspectives available to you. These are good indicators of whether a product has been fully tested and is ready for production.
Choose Your Feedback Loops Wisely
Consider which Agile feedback loops for mainframe development will help your organization move faster, but beware that slow feedback loops result in slow progress towards improvements. A word of advice: I’d make sure you have feedback between customers and development, development and operations, QA and customers, and QA and development. Having multiple feedback loops circling between these groups will yield some amazing results, enabling your mainframe shop to develop and deliver software at a remarkable pace.
My next post will cover how to implement automated deployment. Before we move on, recap with 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: Developing a Process of Continuous Builds”
- “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