BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Continuous Feedback in Agile Teams

Continuous Feedback in Agile Teams

Agile teams work in a highly collaborative self organized environment. An individual’s ability to adapt to new practices and processes plays an important role in his or her success in the team. Timely feedback on the person’s actions from fellow project team members can really help the person to course correct to help meet the objectives of the project, while also helping keep the team environment and culture positive and supportive.

Such feedback provided much later during annual or half yearly performance reviews is seldom useful in helping the person succeed on the same project. In self organized teams the practice of continuous feedback can drastically shorten the feedback loop for individuals and put them on the path of continuous improvement. It also fosters a healthy environment of openness and honest feedback among team members which is critical for an Agile team to learn and adapt quickly to perform at their best potential.

How to structure feedback ?

Feedback can be loosely defined as information about past behaviour delivered in the present, which may influence future behaviour.

Interpersonal feedback could be both positive or constructive of the behaviour of the receiver. While positive feedback is easier to share, it is often missed in the midst of project delivery pressure, when it could become vital encouragement for team members to continue their hard work.

On the other hand constructive feedback about a person becomes difficult to share and needs the right time and place to be delivered correctly.

Well structured constructive feedback should be about the behaviour of the receiver based on past instances. The giver should be able to objectively articulate the impact of past behaviour of the receiver based on instances and provide his/her opinion on how the situation could have been dealt with better.It is important to not pass a judgement on the behaviour itself.

Badly formed feedback

Giver : "Your updates in the daily standup are not very useful"

Better formed feedback

Giver : "I feel that you could provide us with a crispier summary of your previous day during the daily standup. An update at a high level on the progress of the story and any blockers that you need help with will be a good start for content. "

Best time to exchange feedback

Finding the correct time and place to exchange feedback is as important as the content of the feedback itself as it will have an impact on how the feedback is received. On a typical agile project there are many situations where one on one feedback can be given immediately.

Developer to developer feedback is best exchanged during a pair programming session when the code is in front of both the giver and receiver. The pairing opportunity could be used by the giver to demonstrate improvements around the coding style, guidelines, technical design etc... for the receiver.

In a cross functional team it is equally important to exchange feedback about process improvements across roles. As an example a developer might feel that a user story’s acceptance criteria could be refined or a user story sliced into several smaller ones. This could be useful feedback for a business analyst / product owner who can then adapt himself/herself to the style/preferences of the development team or vice versa.

Fred (Developer) to Product Owner : "These user stories are way too big in size and hard to develop."

Fred (Developer) to Product Owner : "I feel that these user stories are quite big and can be split into smaller stories. Smaller stories will help us develop them quicker and showcase it to you at regular intervals for feedback."

Feedback should not be delayed for too long after a concerning event. It is however important to find the person receiving the feedback in the right frame of mind before delivering it.

This is however not always possible in teams working under tremendous delivery pressure. Teams should then make use of end of Sprints or end of Releases as triggers to exchange feedback amongst themselves.

As an example, a team I had worked with used 15 minutes towards the end of a sprint retrospective to exchange positive feedback about each other. However waiting for a retrospective to exchange feedback all the time should be seen as an anti-pattern with people being encouraged to do it more often.

Techniques for exchanging feedback

There are many formats in which feedback could be exchanged, both formal and informal.

One-on-One feedback

Having a one on one meeting with a team member is probably the best way to initiate feedback. This could be done at regular intervals during a project. Some teams find it useful to maintain a feedback matrix to track the one-on-one meetings.

Group feedback

It is important for the team to be comfortable with the basics of exchanging feedback before trying it out in a group setting. Team could start by exchanging positive feedback during group meetings such as retrospectives. Constructive feedback is best delivered outside of a group setting.

Written feedback

Some people are not immediately comfortable in exchanging feedback verbally with each other. This is common among people new to a highly collaborative and open environment like Agile. It is important to encourage them to the regular practice of feedback. As a first step, they can choose to write the feedback down in some form and share it with their team members.

Teams could block sometime during a Sprint or a Release to exchange written feedback (on an agreed format) over email or even in sealed envelopes .

As an example technique one could use two index cards pink and green for constructive and positive feedback respectively. Give one of each to everyone in a stand up and ask them to write feedback about a team member chosen for that day. The receiver can then collect the cards directly or even choose them to be read out loud if he/she is comfortable.

Feedback coaching

Coaching people on the essence of continuous feedback is key to building a good feedback culture in a team or an organisation. It is important to develop a shared understanding of what constitutes "well structured" feedback.

A team will usually consist of different personality types. Extroverts may find it comfortable in voicing their opinions but introverts may find it tough. Some people might be quite open to criticism but others maybe go onto the defensive at the first hint of constructive feedback coming their way.

Body language is also crucial in determining how the feedback is perceived. For instance, making eye contact while delivering a critical messages is important to convey the seriousness and belief in the message.

Choosing the right time to exchange feedback is equally important. A team member could be having a hectic bad Monday at work and is probably not in the right frame of mind to hear feedback about how we could improve his skills. One should try and find a suitable time for the giver and receiver when a detailed discussion could be had without outside interruptions. It is important to "Ask before you Give" feedback by turning it into a request like below.

Chris: Steve, I would like to talk to you about yesterday’s pairing session. Would now be an okay time to discuss it? Or is there a better time that would work for you?

Coaching should also include providing a safe environment where different personality types can practice exchanging feedback. Mock feedback/role playing sessions between team members could be used as a framework for coaching people.

It is important to cultivate a continous feedback culture within agile teams over a longer term. Feedback received should be viewed as a gift from someone who genuinely cares about the receiver’s work and professional growth. Over a period of time exchanging feedback should become a habit amongst team members.

References

What did you say : The art of giving and receiving feedback - Seashore, Weinberg

About the Author

Anand Vishwanath (@anand003 on Twitter) works as an Agile Coach , Project Manager with Thoughtworks where he started his career as a Java and .Net developer way back in 2002. Anand actively consults and executes Agile projects for clients all around the world. He also blogs about his experiences from the trenches here.

Rate this Article

Adoption
Style

BT