Everyone knows their company is far from perfect, but how do you ensure your team is consistently improving? One common answer to this question is with scheduled feedback or retro sessions.
For those who don’t use Agile methodologies, retros or retrospective meetings are held after every software release to assess and improve the product and process.
Atlassian has created a culture where inefficiencies are continuously identified and improved. One aspect of this culture involves feedback mechanisms to gather subjective and objective information. This means anyone can (and does) speak out about problems.
Ashley Faus, Content Strategy Lead at Atlassian, was kind enough to share her team's practices for improvement. In this article, you’ll get practical advice on:
In her time at Atlassian, Ashley Faus has served in three departments in different senior communications roles. Today, she currently leads the team responsible for microsites, newsletters, community posts, social media, and the overall content strategy for software teams.
One of Atlassian’s core values on their website is “Be the change you seek” — for Ashley’s team, this means identifying “antipatterns” and constantly improving how they work together.
Figuring out what’s not working is the first step in problem-solving, and Atlassian follows a number of practices that encourage — or even requires — people to indicate what parts of their day are getting them down.
Ashley cited three tools that teams use for getting people to speak up about the superfluous and despised:
If you use certain tools to drive parts of your process, start there. Check the evidence about which tools are actually being used, and how the output could be improved.
The antipattern is our willingness to do retros and say, “Is anyone getting anything out of this meeting? If not, maybe we should kill this meeting.” My team used to do daily stand-ups, and then we realized: we don't really need this because we talk all the time. So, we moved to holding stand-ups three times a week, but people still felt like, “We literally just talked to you about this an hour ago.” Now, we've actually consolidated to doing virtual stand-ups, where everybody puts their status for the day into a chat room so that we can all see it, and people comment if they need something.
In other words, nothing is done because it’s the way things have always been. Every process is questioned for its effectiveness.
For example, let’s say you are using a combination of Trello and Asana for task management and find out nobody is really creating tasks in Asana. You probably don’t need to continue making Asana part of your process.
Only use what’s needed, when it’s needed.
Ashley mentioned that her teammates feel free to speak up if anything isn’t working for them, and if others feel the same, the problem gets addressed as a retro.
It's pretty rare that something's broken and only one person notices it. It's just somebody has to be willing to say it.
If someone isn’t engaged at a meeting, that person might speak up and say the meeting doesn’t apply to them, or someone else might see others are zoned out on screen and speak up.
When it’s clear that a process isn’t working, the team schedules time to fix it or handles it on the spot.
Monitoring how people feel is another way that teams at Atlassian identify issues that need to be addressed. Different teams do this in different ways.
Ashley’s current team uses emojis on Slack and in other channels to indicate how they are feeling about particular tasks or as a project progresses.
My previous team held a monthly retro to do a broad team-health check-in. Using Trello, we added projects and events to the calendar, marked with a due date, and labeled with a feeling. It sounds kind of touchy-feely, but it's actually really helpful to look back over, say, a quarter’s worth of retros, and you see, “Wow, this one project, every time I have to deal with it, it causes frustration. Or, this type of work always makes me feel proud.”
Along with more traditional retrospectives, Ashley referred to health check-ins as another way to look back on how your team is performing and working together.
While most teams don't evaluate projects, processes, or team health metrics after every sprint, Atlassian encourages teams to hold regular retros. The cadence depends on the size and complexity of the team, and the areas they want to improve or celebrate.
Retros go beyond identifying "problems" — they're meant to help the team share insights, celebrate wins, and work better together. As it turns out, they come in several flavors.
Here are three of the retro types the company uses regularly in addition to the regular Agile software retros. If you like these, you might like Atlassian’s Team Playbook as well with a bunch more resources.
At the end of a project or launch, the team hosts a project retro to review:
The Start-Stop-Continue retro is used for ongoing projects or at a team or departmental level. Like the project retro, the group will look at what went well, what didn’t, and what to improve.
This should be scheduled at regular intervals or at milestones for ongoing work that doesn’t have an obvious end date for doing a retrospective.
As mentioned earlier, activities retros can also be done periodically. Atlassian encourages teams to run review 2-3 times per year. These are a way to look back on how your team is performing and working together.
Start by adding projects and events to the calendar, marked with a due date, and labeled with a feeling. Then go through and discuss as a team why you labeled things a certain way. Try out the All Activities Retro with your team using the template below:
Being explicit about roles, responsibilities, communications, and norms is essential to team and company success. Knowing who is responsible for what allows the company to operate smoothly.
When you don’t have clearly defined roles, some say, “let’s do x” and everyone agrees during a meeting. But, when you discuss it in your next retro, it turns out that nobody did it because nobody was assigned the role, and it wasn’t clear who should be responsible.
Often, the team manager knows who gets what and so they become the bottleneck, because everything has to flow through them. Instead, publicize roles and responsibilities both within your team and cross-functionally so everybody knows who to ask for help. For example, this team handles marketing content versus another team handles user documentation and release notes. That's great. We know exactly who owns what. If I want to coordinate with somebody, I know exactly which team member to go to.
Likewise, Ashley stressed getting to know the people you communicate with and how they prefer to get notifications.
Some people prefer e-mail and others want to communicate on Slack or in-person:
“Knowing what your manager wants communications-wise is important. When I switched teams, obviously I got a new manager, so we worked out the frequency and format for our communication. I prefer a weekly one on one, but I've had other managers that prefer a simple email at the end of the week with bullet points on the status of all the projects.”
This goes to show that even the most experienced companies, teams, and contributors constantly iterate on their workflow. I know I have some changes to experiment with after this interview. I hope you do too.
In this interview, we spoke to Brittany Sudlow, Product Marketing Manager for Confluence at Atlassian, about how their team uses an internal blog and videos to go deeper than threaded text without overloading team members.
Aubrey Blanche understands the nature and future of gender equity and is in a unique position to talk about the direct impact (or lack thereof) of the #MeToo movement on tech.
In this interview, we had the opportunity to speak with Brendan Fortune about his role at Customer.io as a Principal Product Manager. Brendan walks us through how Customer.io structures the Product team such that they are able to immerse themselves in the customer’s challenges and desires.