Agility is built around people and interactions between them. This is highlighted by the first Agile value ‘Individuals and Interactions over Processes and Tools‘. The below mentioned Agile principles also highlight the importance of stakeholder engagement, motivation, communication, empowerment, autonomy, trust, and transparency.

“ Business People and Developers must work together daily throughout the project “

“ Build Projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done “

The above principles further highlight the importance of Agile team members and Business Stakeholders sharing ideas, information, and progress and supporting each other when performing work in an iteration. This further highlights the importance of the 3 pillars of empirical process control namely; transparency, inspection, and adaptation.

What does the above mean for an Agile Team? How can stakeholders of an Adaptive change driven engagement work together? How would opinions, ideas, feelings, sentiments, and views about the work be shared with each other? How can feedback be provided in a transparent manner without hurting someone’s feelings and also encouraging individuals to take responsibility and immediate action?

The above is mainly done through the feedback provided during various Agile events, namely the backlog grooming, daily scrum, sprint planning, and the review & retrospective sessions. The feedback provided during these events could be about the product or the solution being developed and also about the agile process being adopted. However, communication and collaboration are not limited to these rituals only but during every minute of work during an iteration. Hence, providing clear, fact-based, actionable feedback becomes critical for the success of Agile engagements.

Let me explain the type of feedback provided about the product and process and the importance of it a little bit more. Agility is about breaking a large piece of work into smaller manageable quantities and then building, delivering incrementally and iteratively. The highest priority or valued list of backlog items are taken up from the top of the product backlog and elaborated further by the product owner and the agile team. Feedback is provided during backlog grooming on the acceptance criteria before the story is marked as ‘Ready for Development’. A collection of backlog items will form the MVP for the solution. The team keeps on developing this MVP by taking up feature stories from the backlog and implementing these during an iteration. The work done is demonstrated at the end of the iteration for which the product owner and other stakeholders will provide their feedback. The whole objective of this process as per lean startup is to develop the MVP faster, show it to the customers or end-users, and get their feedback on usability and user experience. This ultimate feedback will guide the implementation team on whether to continue developing the solution as is or to ‘pivot’ as required.

Feedback is not always about giving negative criticism. Traditional managers make the mistake where they sandwich a negative feedback between two compliments. Look at the example below.

“Hey John, I am very happy about the way you did the design for the customer management component. However, the form is lengthy and lacks basic user experience aspects. However, everything else is up to the mark in terms of colours and visual aspects.

The recipient of above feedback will most probably remember the negative comments given. The importance of the positive feedback given and its impact on the mental well-being of the receiver is forgotten here. In addition, traditional feedback like this does not give any direction to the recipient on how to rectify the situation.

Providing feedback to teams and team members is tough even when everyone is able to meet face to face. Now, we are faced with a unique situation where business people and the Implementation Teams are self-isolating at home due to the Coronavirus pandemic. Teams are compelled to collaborate using communication and collaboration tools and there is a high chance of delays in feedback or responses, or in terms of lack of clarity or detail in feedback. How do we enable fast and effective feedback loops for remote teams to ensure quicker decisions? How can we ensure that this information is adequate for the individuals and the teams to move forward with their work? In this article, I am going to discuss how I coached a team to practice the feedback wrap even when communicating via a chat or web conferencing tool.

What is the Feedback Wrap?

The feedback wrap is an ideal technique to be used in a trust-based environment. It helps individuals give facts and feeling-based, constructive, actionable feedback to individuals and teams. The technique goes beyond a traditional direct blunt way of giving feedback, and the misleading ‘compliment sandwich’. The feedback provided as a ‘wrap’ induces positivity among the recipients, thus promoting self-motivated action that is desired by both parties. In a ‘compliment sandwich’, some negative feedback is sandwiched between two compliments which will make the recipient still feel disgruntled and unhappy. The feedback wrap ensures that the feedback giver explains the current situation, the consequences, emotions felt before providing feedback along with a set of suggestions to help the recipient. This makes the receiver feel obliged to take the initiative to rectify the situation.

The Feedback Wrap requires the person who provides feedback to follow these 5 important rules.

1. Describe the context

Describe the context with details about the situation. Give details about what you are facing or have done, how the issue or the problem affects you.

2. List observations

List observations providing facts, examples, and instances without any finger-pointing. Evidence about the situation and its impact helps the other party visualize the problem and empathize with the difficulties you go through.

3. Express emotions

Express emotions by letting them know what you feel or go through. This is important to get the feedback recipient on to the same page in terms of the emotional space and make him or her feel part of the problem.

4. Sort by value

Sort by value by explaining your expectations and highlighting why it is important for you. A clear indication of the desired state is important as it clearly indicates what is expected from the other party. Here we are focusing on elements that will enable a successful future state.

5. End with Suggestions

End with Suggestions providing feedback, alternatives, and in the form of offering help. This is the differentiating factor when compared to traditional feedback. The recipient is given clear guidance on what must be done, and what should be tried out to make things better. Feedback is not just about giving advice but also offering a helping hand to make the other party understand that we are there in this together.

The feedback wrap is important for remote teams. Early response to resolve problems, or conflicts or attention to make key decisions is of utmost importance.

How did I use the Feedback Wrap?

Most of the feature teams in my current workplace are distributed, teams. They work from different parts of the world and work during different time zones. The teams work on components of large products with multiple dependencies between the teams. Even though the teams manage the projects independently using separate iteration backlogs and ceremonies a lot of communication and collaboration are required in order to iron out dependencies, uncertainties, and integration issues.

Some background information about the situation is as follows. The teams work in the same development environment. The team from Russia normally commits code when the team from Sri Lanka is offline and vice versa. The code committed though independently tested breaks the overall solution as no integration testing is done after merging to the master branch. No comments are put when committing the code which makes debugging hard for the team from Sri Lanka. This situation has existed for multiple times and there is tension between the two teams.

Here is how the team applied the feedback wrap when sending a chat message to the developer from Russia.

Describe the context – “Hi XYZ, I just took an update from the main development branch and was just trying to build product ABC. The build failed a couple of times and was throwing some errors. I just hope that I have got all the details right.”

List observations – “I saw that you had committed the code for RST Java class last night. I couldn’t find any code comments and any details on whether the unit tests have passed.”

Express emotions – “I have updated the functionality for the LMN module which has a direct dependency. However, I am unable to test the functionality, and this is due to be demonstrated to the product owner on Monday. I now feel anxious about going ahead with the demo.”

Sort by value – “What I want is traceability so that we can pinpoint where exactly there might be a problem in our codes if and when this type of a situation arises again.”

End with Suggestions – “How about putting a comment against the relevant user story in JIRA whenever you do a commit to the main development branch along with a quick comment on Slack? Can I know what is required from my end to make this happen?”

Learning & Actions

Key learnings and action items from the exercise are as listed below.

• A feedback wrap is a subtle and constructive way to provide feedback
• It helps provide direct, fact-based, emotion-driven feedback without finger-pointing or hate
• Makes the recipient understand the importance and makes him obliged to respond or help – In the above instance, the developer from Russia suggested a call as soon as he came online within 4 hours of sending the chat message.
• Gets both parties onto the same mental state and the offering of help galvanizes the team increasing morale and teamwork. The team from Russia felt that the team in Sri Lanka is not challenging them or blaming them but are trying hard to make the solution work together.
• In terms of next actions,
  • The participants decided to practice using the feedback wrap to provide feedback for multiple situations such as providing comments on products, features, tasks, progress, designs, teamwork, performance, and levels of collaboration.
  • The team decided that capturing the feedback recipient’s reactions is important. For this, they decided to try and apply the Niko Niko Calendar.

Do you have any experience in using the Feedback Wrap to provide feedback? Have you used this in your projects? Do you know of any other effective methods and techniques of providing feedback, especially in a remote distributed team context? I would like to hear your stories in the comments section.