Agile feedback loops
May 31, 2016 COBOL 0 Comments

The 2-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:

  • Customers
  • Scrum Team
  • Operations
  • Tools
  • Testing

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 2-Week COBOL Sprint” blog series here, or follow the links below:

Flickr: Fondo Antiguo de la Biblioteca de la Universidad de Sivilla

The following two tabs change content below.

Glenn Everitt

Glenn Everitt joined Compuware as part of a startup acquisition. He was the Chief Architect of the startup’s core application. Glenn has architected products that run on Mobile, Windows, Linux and Mainframe platforms. He is actively involved in technical due diligence of Compuware acquisition efforts. Glenn is currently working with Product Management on product strategy and its technical feasibility.