Software approvals – a wide field of common misconceptions and misunderstandings.

Firstly – why approve of a piece of software? And what does „approving“ mean in that context?

For every release, albeit a direct push to production by an individual developer needs to be approved before it runs in production. Why? Because somebody is also responsible for the functionality of that piece of software or change that is running in production. Approval also doesn’t need to be an official meeting or process, it can also be an individual developer deciding on his or her own, that his change is production worthy. However, once a project and team working on that software is growing larger, the approval process will tend to grow and encompass more and more steps.

So how does approval usually work and what is an ideal process in my opinion. My opinion is, the approval process should be different for every product and every organization. Let’s explore three typical organization sizes who for the sake of our examples follow an agile mindset.

• single developer project
• single team project
• multiple team project

As usual, the more people are involved the more complex an approval will get. Keep in mind, it needn’t necessarily be a person who looks at a metric and puts his thumb up.

So let’s iterate through the three organizations.

Single developer

Simple – a developer has a certain piece of software he is developing. Whenever he deems appropriate he can develop a change and commit it, build a new release or push to production. However what will he most likely do before committing it.

• automatic checks performed by the IDE
• automatic tests like junit / postman collections / selenium
• visual checks whether or not the change is working correctly

As he is solely responsible, these checks would most likely suffice and he can agree with himself whether his change is successful. Whether or not he thought about it that way – he has approved the software.

Single team project

Assuming we are working in an agile setup a scrum team is itself responsible for delivering value and thus working software. All above mentioned checks will be performed, but additionally there usually will be a sprint review. The sprint review in my opinion works as a meeting where changes are presented and everybody agrees that the job is done well. It also is a stage to present the change and possibly gathering feedback that tells us not to ship the change. In that sense the sprint review serves as a regular and simple approval meeting.

Multiple team project

Adding teams on a development projects brings in a noticeable rise in complexity. Not only is most likely the code base larger but also more people need to talk to one another before, during and after development.

So which additional steps come in handy. We keep in mind the automatic checks, automated tests and visual checks – these will be more complex, more automated and more numerous than in smaller projects but essentially similar.

In my example below (see image) the three teams work on the same product, however they might work on different parts of the codebase.

But when how and who defines now that the iteration was successful and the software is working alltogether. There are different options available that jump to my mind

• Individual sprint reviews of each team: Also fine for smaller changes, however extra communication across teams will be necessary. Therefore I assume more time will be needed here to do the extra overhead communication (image 1)
• A joint sprint review of all teams: Fine for all smaller changes that can be finished within the timeframe of a sprint and focus solely on our own software (image 2)
• Regular joint sprint reviews and additional feature reviews (dual reviews): This is my favorite choice. We can approve and present all smaller features within the joint sprint review. However when larger changes are done that also influence the integration with other systems, more testing is required and approval cannot be done team internal. I will explore these additional feature reviews later on in a different post (image 3)