Minimizing Undone Work when Working with Regulatory Departments

Tags:
2016 01 01 head

The Scrum and agile mantra is to have a ready-to-ship product each time a sprint is completed. You must avoid any incomplete activities at any price.

Incomplete activities are also called Undone Work. They are technical debts in your software, hindering its delivery to users. They are spending money you cannot invoice to your customers.

Regulatory and traditional quality insurance departments request all kinds of documents, such as review, test results, risk analysis matrix. They want insurance that their view of quality is fulfilled.

Scrum sees the importance of quality like the lean production approach [1].

Quality is built into the product.

You do not need any documents proving you have fulfilled this goal.

Your sole goal is to optimize the process to produce the best products, not to repair them after production.

It is the sole responsibility of the Scrum team to guaranty the quality of their product [2]. Scrum teams also learnt you cannot win against big corporations. So you have to define solutions satisfying the QA departments with minimal overhead and almost no undone work. We have experience working with quality insurance and TUV or FDA regulatory departments. We use the following approaches to handle the needs of the regulatory departments, seen as stakeholders in the Scrum terminology.

  • Use static analysis tools such as PMD, Checkstyle, Findbugs [1] to create quality gate reports for your QA department. Thousands of checks and hundreds of pages of reports will satisfy any QA department. Plugins exist for Eclipse [2] and continuous integration servers.

  • Use review plugin such as Eclipse Jupiter to create these still mandatory review reports on the source code. These reports are useless in an agile team working with techniques such as refactoring and pair programming. But they are still mandatory for most of the traditional quality assurance QA departments. The plugin allows you to generate nice-looking reports and to implement the findings at the same time.

  • Use Test-Driven Development approach and create a lot of unit tests. By slightly extending the logging features of JUnit and by using code coverage tools, you can create reports showing which source code was tested. Add some annotations to your test cases, and you have full traceability to your stories and associated software requirements. With a small amount of work, you can generate thousands of pages of information and provide the PDF documents to the regulatory department. These documents are also TUV and FDA compliant.

  • Use Behavior-Driven Development approach and create acceptance criteria for all your stories. Using the reporting features of easyb footonote:[The website of easyb is no more available therefore no link can be provided.], you can create acceptance test reports for all your stories. It generates hundreds of pages of information and provides the PDF documents to the regulatory department. These documents are also TUV and FDA compliant.

  • Use continuous integration servers to run all the above measures and generate the documentation at the end of each sprint or release.

  • Link your version control system with your continuous server, issue-tracking application, and unit tests. So you can generate release notes stating the list of closed issues with the associated source code and unit tests verifying the correctness of the change.

Similar tools are available in Python .NET, or C++ communities.

You can satisfy your QA and regulatory stakeholders with a lot of reports nobody will ever read. A real Scrum team corrects weaknesses during the development process and always deliver software of the highest quality. The reports can only show the inherent quality of the software and are not worth the paper they are printed on.

But you satisfy powerful stakeholder groups and can more freely work on the most important goal. Deliver on time and in budget the best software the customer wants to have.

References

[1] G. Verheyen, Scrum - A Pocket Guide, Third. Van Haren Publishing, 2021 [Online]. Available: https://www.amazon.com//dp/B0DFHNW45Q

[2] S. Ockerman and S. Reindl, Mastering Professional Scrum. Addison Wesley, 2019 [Online]. Available: https://www.amazon.com/dp/B07XTLNPTC

1. The successor of FindBugs is SpotBugs
2. A more popular IDE is IntelliJ IDEA with similar plugins.