Building a Feedback Culture in Teams with Feedback Fridays

I got my first exposure to feedback friday's in one of the first projects I did in ThoughtWorks. I was quite amazed to see how such a simple idea becomes a very effective tool for building a strong feedback culture within the team. From then on, I have used Feedback Friday whenever I am on new teams that are just starting or on teams where feedback is not one of the routines.

Here are few steps that I take to start & monitor feedback friday

Step 1: Day & Time for feedback
Identify a day a time for feedback. As the name suggests, we typically do this on a Friday but there is no hard and fast rule. It is just any convenient day for the team. The time should be such were the entire team is able to spare the time without being bothered for calls, meetings etc. I have found it ideal to devote time immediately after the morning stand-up as everyone is yet to start their work. Trying to carve out time in the middle of the day becomes tough, as people do not like to break flow of work, and by end of the day people are already exhausted.

Step 2: Duration & Place of Feedback
Duration of feedback should not be too long nor should it be too short. Starting with 45 minutes and gradually reducing to 30 minutes works really well as teams start getting into a habit of exchanging feedbacks. 
The team needs some place away from desks and laptops to focus only on feedbacks. I have typically booked big meeting rooms for entire team to sit. 

Step 3: The Feedback Process
Once the basic logistic are in place, the entire team assembles in the room. Each person picks-up a card and writes feedback for another person on the team. There are NO rules - the person decides for whom the feedback is to be written, for how many people, how detailed or short it needs to be. The only rule is to be present and think & write feedback for your team members.

As a guideline, I call out that feedback can be shared with people whom you have worked recently, people who might have asked for feedback or generally anyone on the team you have observed and would like to share feedback with.

After writing the feedback, the card is handed over to the person for whom the feedback is written. The team members are encouraged to discuss the feedback with each other either immediately or at a later time so there is more communication than just few points on a card. 

Step 4: Frequency
Since the main motive of feedback friday is to get people into a habit of sharing feedback. It needs to be done at regular interval till it forms a habit. It can be a collective decision of the team on what frequency they would like to conduct feedback fridays. I have found fortnightly frequency works pretty well. It gives sufficient time for people to observe each other and also the time is not too long that people forget incidences.  

It is important to make feedback friday a ritual like stand-up or showcase. Slowly it starts becoming a habit for the team members & feedback culture starts growing.

Step 5: Monitoring
I like to keep track if feedback friday is moving towards the goal the direction it is intended. I keep looking for signs that tell me if feedback culture is getting ingrained. 

• Are people exchanging feedback without waiting for feedback fridays?
• Is the time duration of feedback fridays getting reduced, because more and more people meet offline and exchange feedback?
• Are people getting comfortable with each other to exchange feedback more verbally and using index cards as just means of jotting down points?

It is then time to use feedback friday as a check point to remind people about feedback and not as a dedicated time to exchange feedback.

Step 6: Restart Feedback Friday
Any time you realise that the feedback culture is getting reduced, it is time to restart. 

Few other situations when you might want to restart feedback friday is if team size has grown quickly, or a lot of new team members have joined recently.

Other things apart from the above steps that can be taken to ensure feedback culture gets spread is identifying champions among the teams who can drive the activity. 

20 Things To Do with an Umbrella

Have you ever thought of a using your Umbrella for something other than protecting from rain or sun? That was what a group of 20 people did as a part of an ice breaker before start of a workshop. 

During an inception we had few months back, we wanted to run an ice-breaker that would help get a large diverse group comfortable with us & be prepared for a highly intense and creative workshop. We wanted the ice-breaker to be quick, light weight, fun filled & something that gets the creative juices out. 

We decided to use "What is the most Innovative use of umbrella?"

The participants were given one card each and a few sketch pens. The time limit was 10 minutes. The goal was to get as innovative as possible and draw out the idea.   

The results were quite creative and participants had fun trying to think of different uses of an umbrella. Once the time was up, each participant was asked to present his idea to the group.

Here are all the innovative uses the group thought of

We ended by asking participants to vote for best idea. The winner was an umbrella that can be used as a solar powered outdoor rotisserie

The Agile Lego Game with a twist of distribution

Two weeks back, we played the Agile lego game in office. The idea was to give a feel of how distributed agile teams works to our new Product Owner and few new team members.

A typical agile lego game consists of teams working for around 3 to 4 iterations and trying to build something using the lego blocks. A product owner is sitting with the team while they build and helps the team in understanding the requirements. He is right there to answer all the queries and the teams get a feel of how interactions help over documentation. The team also tries to builds incrementally and learns the value of being able to build small and change as needed.

We aimed higher, we wanted to give a feel of distributed teams and hence had to add the twist of taking the product owner away from the team and available only on calls :) 

We started by creating 3 teams with 5 members each. Each team had 2 product owners and 1 facilitator assigned. We called everyone and explained the rules of the game

• Planning Meeting for 3 mins (including estimation)
• Each iteration is 7 mins 
• Showcase to get stories signed off is 2 mins
• Post showcase everyone will come together for a huddle to discuss the learnings and observation
• The team gets 3 iterations to build an animal
• Since the teams were to get a feel of distribution, we had set-up 6 laptops with a gotomeeting (web conferencing and online meeting tool) which we use regularly on our project. The customer was available online through it. 
• A team could make 1 person travel once during the iteration to customer site (if needed)

The teams were assigned their Product Owners and facilitators and we started the first iteration. The teams were on one side of the office and the product owners were sitting in meeting rooms. Below is a picture of the teams trying to talk to the PO over a call.

The teams started by looking at stories and trying to talk to the PO to understand more details on each of the stories. Once call was done, the teams got head down building the animal. Here are some pics of teams busy building the animal using the lego blocks

In no time our facilitators called "time out" as time for development was over and it was showcase time. Since it would have been difficult to show a lego animal over call, we decided to have the PO visit the teams for showcase. The teams had to showcase the stories that they had developed and get it signed-off from the customer. A few teams managed to get a couple of stories signed off.

We called all the teams together and asked for observations/comments

• Communicating over a call: The first point was how difficult it was to interact over the call, all the teams & PO understood the challenges of communications that we face on an everyday basis and the importance of using the right tools - online meetings, speakers, camera etc.
• Availability of PO: Some of the PO decided that they were busy in other meetings and were not available for calls ( a very real life scenario) that gave a feel of what the teams face and how important is the availability of a PO for the success of the team.
• Not pushing back on design constraints: Since one story mentioned build the animal in a color, the teams just went ahead and built it in a color of customer choice. No one pushed back on this and later realized how much constraint it adds on the team since lego blocks of that color are limited. This is also a very real life scenario were you might end up making some design decisions that might put big constraints on you if you only think short term.
• Not deciding which stories are priority: Most of the teams just started working on stories immediately, they did not take advantage of planning meeting to discuss the priority of a particular story or the business value it might add. The customer was available and would have informed if they needed a particular story or not.
• No Collaboration between team members: Another challenge that teams faced was many people ended up doing the same activity (like building a fence for the animal). This happened because team members were not collaborating and there was lack of communication between them. This helped in understanding the importance of communication and collaboration between teams. The teams discussed how dining table setting for working helps in communication.

This session was very helpful to the teams as it gave them a quick feedback on how they are doing, and what they need to improve upon. This also emphasized the need of doing regular feedbacks in the team.

The teams then got into their next iteration. This time some of the teams improvised based on the feedback received. This time we decided to have the PO with the teams.

• Some teams planned well and decided on what they will pickup in the iteration. They got their PO to prioritize their stories.
• One team managed to collaborate really well - divided the tasks among themselves
• They got their PO to work very closely with them and managed to build the animal by second iteration.

Below is the picture of the team collaborating effective, working closely with the PO and the animal they build at the end of the second iteration.

It was now time for some twists, based on what we observed

• We decided to swap the PO of 2 teams. We just announced that both these teams now have new PO. It was exactly replicating our real life scenario where we had a new PO.
• We observed that the team which was collaborating well, was heavily dependent on one person interacting with the PO, we decided that he is out sick and took him out of the team
• We also decided that although one team had managed to build the animal in the 2nd iteration, due to business requirements we wanted lots of changes in it.

The idea was to give the teams a feel of real life situations and see how teams adapt to change of key stakeholders and change in business needs. We also wanted the teams to experience what happens if there is a single point of failure. 

At the end of 3 iterations the teams had some real fun playing the game & building the animal along with the an effective & long lasting learning experience.