Most organizations have audits of some sort to ensure everything is going as expected and if any processes need to be tweaked. Especially if it is a regulated industry where external audits are conducted, some governance will always be needed to ensure corners are not cut.
Recently I had a discussion on SPaMCAST about a situation where in an agile environment, there was more governance put on a team than on a waterfall project. It was pretty amazing to hear some of the things that needed to be “signed off” by executives to pass. Here are a couple of examples that the Q.A. team needed to provide:
- A new test strategy and plan for each release.
- The fact that there needs to be a strategy and plan is not overly shocking as it is needed. It was shocking that they needed to use a waterfall template and document a detailed plan for the release. This could be an issue as most of the information at the time could be Epics or high-level stories that need to be ironed out, or a potential strategy change could make the plan obsolete.
- Now the other issue is if the release cadence is short, then a lot of time will be taken up writing up new documents over and over.
- A new test exit report for each release
- Again nothing shocking with that, with the exception that another template is needed and that links to tool summary reports (I.E., Jira/Zepher) could not be used and had to have actual numbers documented as we, as anything that came out of the retrospectives with regards to testing.
- Release sign-offs
- Although a definition of done published required executive sign-off, there needed to be individual emails to state that the work’s development, testing and reviews were completed and could go to production.
Imagine doing this if the release cadence was once a month.
These are just a few items involved in this particular audit a peer went through. They passed the audit after a scramble to get all the official documentation done. What was odd about all of this is that the organization has an agile Center of Excellence, and it was them that made the governance rules, and the rules changed a few times over the years. So a persistent team working on a product over those years would have to change their audit items with every governance change.
We didn’t get into where the root of this additional governance lay. Was the CoE cramming down waterfall governance onto teams without understanding what information is available from teams and adapting the governance to fit what is required, or was the organization pushing what they know due to decades of use in a waterfall in an agile environment?
In the end, a form of governance will always be needed to ensure corners are not cut. Knowing what is available is expected for an audit. And how to report it with minimal impact to teams best while still displaying that guidelines are followed will smooth audits in agile environments.