Give feedback for performance

Feedback is one of the most powerful tools a manager, developer or HR professional can use to reduce mistakes and increase performance. It is a key practice in Agile and Lean and, although it sounds easy it is quite hard. Read this post for a more detailed description of good practices for feedback inside a development team.

Consider the following:

• When is the last time you had a one on one discussion with your manager? How about with your team members?
• Do  you know how your colleagues see you?
• How fast can you find out if a change you made in the code was correct and didn’t break other things?
• Do you know how many users use a feature you added last year?

The difference between flying a space shuttle and a big BOOM!

Feedback loops are everywhere. They exist between people, between developers and code and between the product you’re creating and its users. The question is: do you take advantage of feedback? Or do you just ignore it?

In engineering, feedback cycles are used for reducing errors. Flying space shuttles, modern cars cruise control or increased sound quality are only few of the modern successes that wouldn’t have been possible without feedback. Inside a  software development team or when managing such teams, feedback can be used for improving the results by catching mistakes early.

Let’s take as example code review. Code review is the practice for one developer to read the code written by another developer and give feedback in order to eliminate potential programming problems. This simple practice applied on all production code has been shown to catch as much as 60% from total bugs, in some cases reducing maintenance expenses by hundreds of thousands of dollars. Yet, code review is nothing more than feedback on code from a colleague.

Not all feedback is equal

Two things differentiate useful from useless feedback:

• Length of cycle – the shorter the better
• Actionable or not

Let’s take as example performance reviews. Most companies since do yearly reviews, which means that each year you meet with your manager and she lets you know what you did well and what you didn’t do well the past year. There are multiple problems with this approach, including that none of you will remember exactly what happened 6 months before. Moreover, how often can you change your behavior based on the feedback, if you only get feedback once a year?

Reducing the feedback cycle for performance reviews ultimately turns them into bi-monthly one-to-one meetings. Managers would meet with each employee and discuss based on recent events, allowing both of them to adjust their behavior and strategy.

Early feedback is not enough if you can’t act on it. A typical example is a manager telling a team that “they must do better” without clarifying: what needs to improve, who will improve it and how.

How to give feedback to your team mates

Giving feedback to another person is difficult, especially for introvert personalities like most developers.Good feedback is based on facts, future-oriented and impersonal (related to an action/behaviour and not to a person). Starting with a simple feedback template and practicing it makes wonders and helps increase the quality of feedback inside a team. Here’s the template we usually use:

When you [Past Action], [Result of the Action]. What could we do to prevent it from happening again?

For example, using this template:

• When you arrive late at the daily meeting, you make all your colleagues wait for you. What could we do to prevent this from happening?
• Whenever you write code that doesn’t follow the coding guidelines, I have to work extra to change it before it’s done. What can we do to prevent it from happening again?
• The last time you finished a task and didn’t update the  board, your colleague started working on the same task as you. What can we change to prevent this from happening again?

How to get better feedback from the code

Agile, Lean and Software Craft practices are all about reducing feedback time and improving feedback quality.

For example:

• We create the minimum possible from a feature and ask users to try it and tell us how it works
• We have daily discussions about the development status
• We write automated tests to allow us to validate that any change we make in the code is validated in a matter of minutes
• We do pair programming so that code reviews are done during development and not after development
• We use test driven development to create the solution based on the feedback we get from the first user of the application: a set of tests

and so on.

In a later post we’ll cover feedback from a managerial perspective.

How helpful is feedback for you? Let us know in the comments!

If you want to better understand the performance for development teams, we can help you with:

• Learn more about unit testing development at the Test Driven Development workshop, also available in-company
• Learn more about Kanban benefits at the Lean-Kanban workshop, also available in-company
• Learn more about Scrum benefits at the Agile Development Using Scrum workshop, also available in-company

If you want to know more about performance, let us know and we will create a customized package for your needs.