Learning to improve — consistently Link to heading
How many people does it take to complete a software project?
The answer of course is — it depends. A single engineer can complete a small project on their own. Larger and more complex projects, however, require a multifunctional team of engineers, designers, and product managers. The downside of growing a team is that, as it grows, it becomes harder to communicate and settle on the right direction for a project.
In order to overcome this challenge, good teams build software in large groups, in an agile fashion, by responding to changes as soon as possible in the software development lifecycle. This means releasing new versions of working software, as often as possible, as a way of gathering feedback from the project’s stakeholders and users. Rapidly incorporating feedback results in software that is aligned with what the customer needs by quickly identifying features that are left unused or inadequately implemented and removing or fixing them.
Great teams, however, take this to the next level by having a retrospective so they can adapt their processes based on feedback from the team. These teams communicate well with each other and are consistently making small course corrections to stay on track. But it isn’t easy to gather feedback and improve if your team doesn’t already have a culture that rewards candor.
So how do you encourage open communication and use that to drive continuous improvement?
The team I work with does so by following 3 simple rules:
1. Create a safe space
Retros need to be a safe space to talk about everything, even things that aren’t going well. Some teams use a Trello board to gather feedback anonymously throughout the sprint. Other teams leave 10 minutes at the start of the meeting where team members post notes on the wall with their thoughts and feedback. Each piece of feedback can be as vague as “Congrats to the team on the release” or “Uncertain about the overall vision.” Alternatively, they can target particular pain points such as “How should we handle Design QA?” Having a mix of good and bad comments encourages team members to raise issues and concerns as soon as possible without looking like they are complaining. After everyone on the team has had a chance to participate the team can focus on prioritizing and categorizing the comments.
2. Prioritize the most pressing issues
On many teams, these comments are then categorized into Good 😄 , Bad 😞 , or Uncertain 😑. Once these comments are consolidated and themes begin to emerge it is important to identify the most important and impactful change that can be made. Some teams do this by discussing each comment with the group and spending more time on comments that raise concerns or have suggestions. Another way teams identify important issues are by asking everyone in the meeting to vote on what they think the 3 most important issues are by placing a +1 next to that comment.
3. Communicate action items
Once the most impactful issues are identified and resolutions proposed it is time to create action items. It is important to give each action an owner. A good action item is both actionable and ownable. The issues, ownership, and proposed action items should be communicated clearly and as soon as possible so that everyone knows what steps need to be taken. On most teams, there is one person who takes notes and sends out an email with this information, but it could also be a rotating position so that everyone gets a chance.
Profit!
By following these simple rules, teams can take full advantage of their retrospectives to identify areas of improvement on a consistent basis. Most importantly the teams make sure to do the action items because nothing kills team morale quite like having the same old issues come up over and over again and doing nothing to fix it.
This article was originally posted on Medium