The Ugly Duckling of Agile Rituals

Get your ducks in a row with a sprint review.

The scrum guide talks about how you should run the flavor of agile, known as scrum.  As part of the empiricism of agile the development team inspects and adapts depending on market conditions.  Some people feel that the most important meeting is the retrospective, where the team reviews how the sprint is going.  The sprint review meeting is the most important because the customer gets to see the development team's progress.  Today, we continue to talk about agile basics but take a closer look at the ugly duckling of scrum rituals – the sprint review.  

According to Scrum.org, a sprint review is when the scrum team presents the results of their work to customers and clients.  The meeting allows everyone to discuss how close they are to meeting product goals.  It can be as formal or informal as the team needs as long as it has three characteristics. 

The first characteristic is members of the development team should attend.  The purpose of this is to see how the customer or client uses the software.  For example, on a web application, the browser button allows you to go back.  If the page loads slowly, the user will instinctively click the "back" button.  The back button might change the application state of the data and corrupt information.  If a developer sees the customer's frustrations and challenges, they will program the customer's application in mind. 

The next characteristic is the sprint review should be led by a non-technical professional.  Non-technical people will use the application, so a non-technical person should lead the discussion.  The product owner or client should review the work and improvements to the software.  When this happens, it allows the client to experience the software as a typical consumer.  It also provides the development team with another perspective on how the software should operate.  

The final element is that the demonstration should be as close to a production environment as possible.  Plenty of things can go wrong when authoring software.  Often code that works on a local machine will break when promoted to a new environment.  It is why that code should be strong enough to be demonstrated in a testing environment as close to production as possible.  It avoids oversites of database connection strings, file pathways, and DNS entries not pointing to the correct settings.  It also exposes the team to the displeasure of the client who expects the product to work.  Host the product review in as close a production environment as possible. It will save you the financial and reputation embarrassment of a production failure. 

Having developers present during a sprint review, a non-technical person who leads the meeting, and has the environment as close to production as possible will make your sprint review informative.  A useful sprint review will inform the team retrospective and sprint planning.  It will also build trust between the software development team and the client.  Trust will be invaluable when things go wrong, which is inevitable in any software project.  

The sprint review is the ugly duckling of the scrum rituals, but if done correctly, it will make your agile process more robust and more resilient to change.  

Until next time.