Deconstructing Agile Reviews: Three Effective Practices

One of the many questions we often get asked is — Why Agile? What are its benefits? Although, the answer can lead to a never-ending debate, let’s begin by saying — Agile helps to improve quality.

Software Quality reflects how well a deliverable complies with the functional and non-functional requirements. Agile teams shoulder the responsibility of maintaining this quality, but they aren’t alone. Customer representatives and end-users collaborate with Agile teams to provide rapid feedback to correct any mistakes early in the project. This is one of the main reasons for improved quality and a Review meeting is one Scrum ceremony where feedback can be received efficiently. The challenge is to extract it from right individuals, more importantly, when they are introverts.

When it comes to feedback, humans rarely provide positive ones. We all do it, whether it’s a recent purchase or a service received; software reviews are no different. When demonstrating an iteration’s deliverable, all the relevant stakeholders are invited. Many attend and many don’t. A Product Owner (customer representative) accepts or rejects the deliverables during this meeting. Change requests (mistakes) are noted and added to the product backlog to be revisited later. But is it enough to make these observations and move on? Well, in an ideal world, yes! In the real world, we forget to capture the positive feedback that identifies the good practices to be continued (which can be discussed during the retrospectives). No bad feedback is not good feedback. A bigger challenge is to obtain information from introvert end-users who are like dormant volcanoes waiting for post-production crisis.

Below are three practices that can help teams overcome these challenges and execute a Review meeting in order to receive constructive feedback.

1) Demo Preparation:

Most Agile teams spend an hour or two planning the demonstration — what they can demonstrate, how to demonstrate, who demonstrates, sequence of demonstration, test data collection, and so on. But since teams demonstrate deliverable after each iteration, chances are that the team members become comfortable (or bored) with it and start cutting corners. Not enough preparation becomes their Achilles heel and a recipe for disaster. Scrum Masters must make sure that this doesn’t happen. A good way to avoid this is to ask the team members to prepare questions to be asked to the stakeholders during the review meeting. After all, reviews are for validating the deliverable against the requirements. These questions can be directed to (introvert) end-users to verify if the deliverable helps them fulfill their job. Getting an explicit thumbs-up from the stakeholders matter.

2) Usability & User Testing:

Not many teams (Agile or otherwise) perform usability tests post implementation. Although the current trend is to begin focusing on UX (User eXperience) much prior to implementation, post implementation usability tests with real end-users in a staging environment has its own benefits. To start with, users can provide their comments on the non-functional requirements like performance and intuitiveness of the deliverable. Many agile teams automate their functional tests and simulate load for stress tests, but not all human emotions can be automated, that’s where usability and user tests come in. It can be a good practice to invite two to three real end-users before every Review meeting and to ask them to run a few scenarios designed by the team, without any intervention or help. The team members can silently observe the happiness and frustration levels of the end-users and discuss it during the Review meeting

This process does require time in recruiting new users for each test session and formulating the scenarios, but reduces the need to train end-users later. Worth it!

3) Post Review Survey:

Surveys are a good way to gather more focused feedback from customers. Scrum Masters can formulate a small (online) survey post the Review meeting to make sure that the stakeholders have left the meeting in a happy state. A good mix of closed and open-ended questions designed specifically around the iteration’s deliverable can help collect positive and negative feedback from the stakeholders. Care must be taken to design questions around the deliverable and not the team member’s performance with the deliverable. Although data collected from a survey will not impact the accepted or rejected deliverable, it can help the Product Owner and Business Analysts to start a conversation with the stakeholder to improve the quality further.

These three practices can help improve Reviews and make them more productive. Although these may require some changes in current processes, the benefits far outweigh the investments. And since one is improving the interaction between the team and the stakeholders, individuals and interactions over processes and tools is enough to motivate and move the big rocks.

Comments

Your email address will not be published. Required fields are marked *