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. 

The Agile PM Toolkit Series - Holiday Wall

Our teams need some kind of visual indicator about availability of team members on a given day/week. In order to facilitate this, I have been using a holiday wall in order to bring this visibility on the table.

Below is a picture of holiday wall in 2 of my projects.

Add caption

A holiday wall is a very simple matrix with names of team members and dates. Team members indicate planned vacations/time off on this wall by marking a simple cross. We typically try to maintain a visibility of 2 weeks and typically update this on a Mon or Fri.

A visual wall is useful when,

• Signing up for stories - you wouldn't want to start a story by a pair where both are off for next few days or you will ensure that team member who has a planned vacation pairs with some one who is not on vacation at that time.
• Deciding in what to sign-up for an iteration - you will sign-up for less, if the number of people available on the team are lesser 
• Setting expectations with stakeholders
• Informing team of your plans in advance

A holiday wall is useful for planned vacation and any adhoc/unplanned leaves are not updated here. Its good to talk about them during standup.

For planned leaves which are beyond the period on the wall, we use a google calendar or put it as comments on the wall. 

A point to note is that this is not a substitute for communication, and team members definitely call out about their availability and planned vacations. The wall is just a visual indicator.

The Agile PM Toolkit Series - Capacity Planning and Tracking Tool

Today I would like to share an excel sheet that I use for creating my capacity planning, Burn-up and Scope tracking. 

My colleague Angela Ferguson had shared her planning sheet with me (thanks Ange). Over the years I tweaked it for my needs and added my specific flavors to it. The attached excel sheet is my version of capacity planning and tracking.

At some point while using this sheet, I needed scope tracking sheet and hence added it. The burn-ups from tools were not effective as I wanted to add scope lines and other things so also added a burn-up sheet. In some projects I needed finger charts and also have another version with finger charts as well. Drop a comment if you need the one with finger charts.

I use this excel to determine the capacity of the team and hence the velocity. I also use this sheet for regular tracking of leaves and determining the utilization so I can plan better for future.

Instructions for using the excel sheet are mentioned in the "Read Me" sheet.

Please download it as "Excel" and not as a google doc. The formulae and formatting will ONLY work on excel. Feel free to change it as needed and share it with others.  Please drop your comments on how you find this tool. Let me know if it was easy or tough to use and understand the instructions.

Capacity Plan and Tracking

The Agile PM Toolkit Series - River of Life/Time Line

Another tool in my PM Toolkit is the "River of Life". A fantastic tool that can be used for varied purposes. I have used it for retros, personal journeys, milestone celebrations, or even presentations.

Today, I would like to talk about the "river of life" as a tool in projects. Below is a picture from 2 different projects where I have facilitated/attended the "river of life". In one project (the picture with orange and pink post-its) I have used it as a mechanism to identify things that have worked for us(orange post-its) and things that have challenged/not worked for us (pink post-its). In the second project we used to to identify things that we "learned", "liked", "lacked" and "longed". 

Below I have tried to capture step by step flow of all the activities that I do when I facilitate a river of life exercise. The exercise listed below was done as a part of milestone check and the team wanted to reflect on past and take a stock of the current situation.

Step 1

To run a river of life exercise, first determine a timeline (1 month, 3 months, 6 months) and determine what is it you want to achieve - a retro, a celebration, just talk etc.

Step 2

Get the team to start identify key events that have happened during this time. The key events can be anything that is significant to the team - a milestone reached, a team outing, some one joining the team etc. The idea of identifying key events is for the team to recollect what happened during that time. One event per post-it. Get the team to put it on the time line 

Step 3

Now do a walk through of the events, this helps in the team talking about incidences and recollecting them. Some times just this activity is sufficient and you may want to end the river of life here itself. I have used this when I just want the team to talk about things that have not been spoken about, things that I want the team to "get out of the system" and move on. At times I have also stopped here when I just wanted the team to reflect on things accomplished and celebrate :)

But if you want to do more then go to Step 4. Based on what the aim of my session is I ask the team to do the next set of activity. As an example, I will talk about how I have used it to discuss things that have worked and things that are challenging.

Step 4

Once the team has spoken about the timeline, I distribute the post-its again and ask the team to now think about things that have worked for them, or made them happy or made their life simpler, anything that has benefited the team. All the things have to be in relation to the timeline. The post-its will be added above the timeline. The higher the happiness factor the higher the post-it is put on the time line. 

Step 5

Similarly we repeat the exercise for all the things that have challenged, made you go slow, made you sad/unhappy or disturbed. Again the post-its are added below the timeline. The unhappier the event the lower it is placed. 

Step 6

Once all the events are added, walk through the events and talk about them. Some times the team discusses action items for avoiding the mistakes, actions to continue the good things. Don't mandate the action items - let them flow on its own and if they don't, its OK. The aim is to talk about it.

Finally, this is not an every day activity. Use it once in a while after some significant events have happened. It can also be used as a end of project retro.

The Agile PM Toolkit series - The Release Planning Wall

I have started with the The Agile PM Toolkit series with the thought of writing about tools and techniques that I have found quite helpful while PMing Projects.  I have been using most of these tools quite regularly. Some I have learned them from my fellow ThoughtWorkers and adopted in my projects while some I have derived on my own. The idea is to share these and spread the knowledge. Please provide your valuable feedback and comments. Feel free to share this with others.

The first in the series is the "Release Planning Wall". 

The Release Planning wall is an outcome of the Release Planning exercise done during inception. It helps me in planning and tracking the project on a day to day basis. With a release planning wall, I am able to identify

• Number of Parallel streams planned
• Dependency of stories in a stream and across the streams (add small post-its of different color to highlight dependency)
• Priority of features/stories planned
• How a feature is being build (each story card for a feature can be of different color)
• How are next set of Iterations planned 
• Most importantly, the Big picture view. How everything fits in together

The release planning wall is a typical grid of story cards arranged in rows and columns. The columns represents iterations and the rows represents parallel streams of work. Most often one stream is equivalent to work accomplished by a dev pair in the project. Each card represents a story. The cards can be color coded to represent specific features.

Whenever possible, I try to setup this wall just on the left of the current iteration wall. This way there is a visual indication of work that needs to be done on your left, followed by work that is currently in play on your right.

As iterations are completed the stories on the wall move from the Release wall (future iterations) to the Current iteration wall. The Release wall is a  continues planning wall and work will flow as project progresses. The wall keeps on evolving as team starts delivering. It is flexible enough to change as per business needs. The focus is to ensure that the immediate set of iterations are planned really well. The future can be planned on rough assumptions and can be hazy. Things keep getting clearer as you move ahead. 


The wall can be made a lot more visual by color coding features, adding small post-its, adding a grid etc. The above pictures has pink post-its to indicate UX dependencies and yellow post-its for data dependencies. You can get as fancy as you want.

Planning and updating the wall is a team activity and you need inputs from from your team to identify dependencies and plan the work. The BAs, Devs, UX & PM can all work together to prepare the wall. The Product Owner can define the business priorities for the planning.

This wall is a physical wall and can be replicated in tools like Jira and Mingle for remote access or distributed teams. I understand that it is duplication of work to have the wall at two places. But the benefits of having a visual indicator in front of the team is so high that I do not mind the effort of duplication and keeping the electronic wall in sync.

Update: I have written about how to facilitate a release planning session during inception here. This is the first activity post which a release plan can be used as a tracking tool.