Five Tips for a More Productive Team

Imagine if you could save 30 minutes per day for each member of your team with better tooling and processes. For a team of six, that adds 15 hours to the week, and with a full 15 hours, we can optimize other parts of our system. Let's take a look at how just a few changes can lead to a more productive team.

Peer-reviews are proven processes to share knowledge and find issues. It doesn't matter if we work on configuration management, middleware, or frontend, code reviews are an essential part of our workflow today, so let’s see how we can improve them.

Checking out code for reviews can be tedious. If everyone's not using the same origin, you have to manually add every fork for a review. Forks are common in both open- and closed-source projects. Luckily there's an easier way. By adding a single line to the config file .git/config within a repository, we can make it easy to check out pull requests.

Enter the following:

$ git fetch
$ git checkout pr/8

And we have PR #8 of the repository checked out on our machine.

Most teams operate with the following workflow for reviews:

1. Bob opens a pull request as soon as he thinks his code is ready to merge and deploy.

2. Bob notifies Alice that he needs a review.

3. Alice stops thinking about her current task and switches context. She adds the review to her schedule and continues her work. As she works on a complex problem, it takes some time to get up to speed again.

4. Later during the day, Alice runs the code from the pull request on her machine. Alice finds some issues as she reads the code. She comments on the pull request and returns to her own project, again spending some time to get back into her work.

5. Bob fixes the issues.

6. The workflow begins again at step 2 until all issues are solved, including anything that's introduced throughout the process.

A review needs two people coordinating their time. Every iteration means context switches for the reviewer; they have to spend time after each interruption to get up to speed again.

To make reviews more efficient, we can try to avoid unneeded iterations. One way to reduce iterations is add static code analysis to unit and integration tests to test the pull request before the review. Style guides are a good example where automatic tests make sense, and we can also test for antipatterns, like global variables.

This way reviews get leaner. The team is able to merge earlier, and newcomers don’t need pages full of specs that nobody can remember when they're new to a project. An automatic check helps to fix the code while we're writing it.

Interruptions are kryptonite for developers. After every interruption, a developer needs around 20 minutes to get back into the zone. Four interruptions in three hours leads to a loss of 80 minutes. Clearly, limiting interruptions is the key to getting work done.

Of course, that doesn’t mean you should go into hiding for a month and simply not be available any more. Defining a “makers time” can help; a block of time set aside for productivity with no interruptions.

For some people, it's enough to turn off their chat and email client for a few hours. Some work from a different room where they won't be interrupted. Others prefer to block off a distinct time in their calendars and go to the coffee shop around the corner. Not being fully available to the rest of the team can make us more productive, even if it sounds counterintuitive.

More and more people are working in distributed teams, but working remotely can be challenging. Maybe a few members of the team are located in Europe, but the other half of the team is on the west coast. Fortunately, we can turn most weaknesses into strengths.

One productive pattern for remote teams is handovers. Imagine a team with a designer in San Francisco and a developer in Europe. While the San Francisco-based designer sleeps, the developer in Europe applies the designs. In the hours that both are online, they play with the results and share their feedback. While the person in Europe is calling it a day, the designer has a full day to work further on the design. When the team member in Europe wakes up, they already have updated designs in their mailbox. The team iterates on the feature until everyone is happy with the results.

Handovers between timezones can potentially enable a team to work around the clock on a project. Teams perfecting this workflow are able to get much faster results.

Colleagues and coworkers are a great source for possible improvements. We might hear a question like “why does the CI take so long?” The watercooler discussion continues: "It runs twice, and I have no idea why."

That’s a really good question! Why does the CI run twice? Further investigation reveals that the two runs were a default setting of the CI server to test both the merged controller branch and the pull request. Disabling the former leads to a 100 percent increase in speed, all the result of a conversation.

Be interested in what your colleagues are struggling with. Sometimes a fix is just around the corner, and the whole team profits from the solution.

There are many possible improvements that can aid productivity across a team, and quite often they hide in our daily tasks. By observing and reflecting on our workflows and processes, we can make note of simple opportunities that don’t require expensive tooling or a lot of development time.