Let’s conduct a little mind experiment. Suppose you have a great team of professionals that you cherish and respect. Something BIG is happening for your company–let’s say a product release–and you want everyone on the team to be on the same page: united, focused, aligned.
Except there is one obstacle. They are not in the same room. Worse yet, they’re not in the same office. Frankly, they’re not even in the same country. This is exactly what happened to this team of 10 engineers spread across Germany, the Netherlands, and the USA.
In this article we’ll tell you about a distributed team of engineers who, after a major release, struggled to make things better. We’ll also cover what helped them.
The Problem: Time difference
After a new feature was released, this company’s team of engineers had more questions than answers:
Why was the release delayed for 3 weeks?
Why are there so many bug complaints in support tickets?
How can we improve our development process?
They desperately needed to come together and discuss things but, due to geographical separation, they simply couldn’t. Spread across four different time-zones, by the time half of the team was ready to talk, the other one was getting ready for bed.
When they finally managed to assemble together, it was tough to get anything done: some voices were louder than the others and not every engineer could bring their perspective to help find the solutions. Later it was impossible to analyze hours of non-linear conversations.
The team mostly used Slack for communication, because conventional email never really worked for them and only ever added to the chaos. But that wasn’t good enough. The team had more than 10 Slack channels for development-related discussions alone, so the feedback every engineer provided was spread across all of them.
Worse yet, engineers sent messages at different times: while some engineers were active in the afternoon, others had to send them at night. Their energy levels simply didn’t match to have balanced discussions.
How can you collect everyone’s feedback in one place, at the most comfortable time, and then later analyze it without spending hours on separating wheat from chaff? The answer came in the form of asynchronous retrospective meetings.
The Solution: Asynchronous retrospective meeting
Before the need of retrospectives, the team started to run asynchronous standups on Geekbot. Each engineer would receive a set of typical standup questions directly in their Slack, like:
“How do you feel today? What did you do yesterday? Today? Were there any impediments?” and answer those at their own pace.
This helped immensely to align the team’s daily operations as everyone knew what the rest of the team was doing and how they could help them out. At the same time, there was no interruption to anyone’s workflow as you could answer the questions at the most convenient time. This was especially valuable for developers who always seek to minimize their distractions. Lastly, the manager could also monitor the happiness status of the team and take action if needed.
After that, the team decided to use Geekbot to help run their retrospective meetings as well. Given that a set of questions can be easily customized, the admin used a set of questions that agile teams run during sprint retrospectives and adapted it:
- What went well?
- What didn’t go so well?
- What actions need to be taken to improve the development process?
The important thing was that the admin could select the “user’s local timezone” option so that every engineer would receive this set of questions at 11:00 AM in their respective time zones.
There was no need for a Scrum Master to organize the process and coordinate the responses because Geekbot was pinging every engineer individually, and then organizing all responses in a separate channel while keeping historical data.
After every retrospective, engineers and managers could easily see not only what every engineer struggled with, but also their individual take on how to make things better. Finally, everyone was able to equally contribute to solving the team’s problems. Although the team was finally able to run efficient retrospectives, the benefits of such a solution went even beyond that.
Added Value
Let’s be clear, developers don’t like retrospectives that much. There are several reasons for it, but at the core of all is that they may seem useless. Although every participant shares their opinion, everyone does that differently. Some voices are louder, the information is fragmented, and it’s hard to tell apart subjective opinions from real experience.
With Geekbot, every engineer’s feedback was carefully organized into a single Slack channel. Managers and senior engineers were finally able to look at the whole picture. Apart from having a history of feedback from every single engineer, managers utilized this information to run successful Geekbot retrospective meetings.
Engagement & Productivity Reports
Geekbot was able to determine three key metrics that drove the team’s performance by using natural language processing:
- Happiness
- Engagement
- Productivity
In fact, Geekbot was tracking how the team’s morale was affecting productivity.
More importantly, senior engineers could track how the happiness metric changed over time, thus being able to pinpoint the exact days when it was highly affected.
For example, analyzing the prolonged stream of “happy” responses over a period of time, a manager found out that prior to the stream there was an internal contest with two Morrisey music tickets as a prize. The team leader then cross-checked this data with progress reports from daily standups, thus assessing the positive effect on the team’s productivity.
Team Alignment
Aligning remote teams around goals and culture is a crucial and necessary task that most teams address differently. Techniques range from organizing expensive group retreats to setting up often useless team-building group calls.
The key component that both of these approaches may be missing is that alignment is something that should happen during work and not outside of it. It’s only when people work together towards a common goal that they are at their most productive in a team environment.
Asynchronous retrospective meetings aligned the team of engineers around the common struggles they all shared. There was no more subjective perception of problems, as now everyone could see both problems and solutions offered by each engineer, in one place and organized.
Non-Intrusive Environment
On average, developers spend 10 to 15 minutes to resume their coding process after being interrupted. Couple that with an average of 87 interruptions per day, and you’ll get a programmer that is looking for a new job.
Asynchronous daily stand ups allowed engineers to report their progress after the work was done, without having to attend meetings in the middle of the day and then painfully trying to restore a working mindset.
This slight adjustment in reporting allowed engineers to focus on their work and effectively speed up the development of new features, while maintaining a positive mindset that comes from focused work.
Conclusion
Chaos helps no one, and this team of engineers was able to experience it first hand. Spreaded across two continents it was hard for them not only to organize their work, but to simply understand what was going on with their colleagues and company.
But even with one small adjustment to their tools they were able to bring people together and start improving their process collectively.
They were, in fact, able to conduct effective retrospective meetings just by using Geekbot. Aligning themselves around shared struggles and creating a non-intrusive environment where every engineer had a voice, this team boosted its productivity and morale, while keeping things simple and transparent for everyone.
