Continuous Improvement

Continuous improvement is strongly linked to one of the principles of the Agile manifesto which states that "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly". The improvements you want to achieve can be split into two distinct areas:

• Improvements to the software being produced.

  The following sources of information could all be used to help you target improvements to your software:

  • Test failures. If a particular area of code regularly causes test failures, is there the potential to redesign that section of the code? Test failures would be flagged by the unit and integration testing carried out in the continuous integration and continuous delivery processes of the modern application development process as well as by the acceptance testing carried out in the continuous delivery process.
  • Code coverage. The code coverage capabilities of Visual COBOL will highlight any areas of your code that aren't being executed as part of your testing, giving you the opportunity to update your tests to ensure that every line of code is thoroughly tested.
  • Customer feedback. Any feedback that you get from your customers about your software can be fed into the requirements gathering step of the Agile development process, giving you the opportunity to assess the feedback and quickly make changes based on it if appropriate. The rapid iterative nature of Agile development ensures that any changes you do make will quickly be delivered to the customer.
• Improvements to the process used to produce the software.

  A convenient opportunity for a team to have this discussion is the sprint retrospective that is a part of the Agile development process. There is no fixed format to determine exactly what is discussed at a sprint retrospective, but in general, variants of the following questions are asked:

  • What went well?
  • What didn't go well?

  The scope of these questions is not limited to code-writing activities but covers the whole development process, so from requirements gathering to release. For any aspects of operation that are deemed to have not gone well, solutions can be discussed, and any changes can be implemented for future sprints. If substantial changes are required, they can be handled in the same way as any other requirements, with a tool such as Micro Focus ALM Octane.

  As sprints are very short, typically two weeks, any changes that are made to the process will be put into practice very quickly, and future sprint retrospectives will provide opportunities to discuss if the changes made had the desired effect or if further changes need to be made.