Working in the open eases collaboration

It is easier to collaborate when people know what other team members are doing.

Bob is on a team. He’s busy working on his tasks. Head down and focused. The team haven’t heard from him in days. They wonder how he’s getting on. They hope he turns up for the practical class this week.

This scenario is a common one in software engineering courses. A few teams will have their Bobs, who are there but don’t tell team members how they’re progressing. This makes it hard for everyone, not just Bob.

We teach teams the basics of software engineering, and project management. However, this isn’t always enough. We also need to teach people how to improve on the basics so that the teams do well now.

When I was a teen and then later, I’d make arrangements to meet friends at various places after we finished studying, or work. Then we only had the landline phone. You had to hope people would turn up as expected, or be able to send you a message via a friend, if there was a problem. Maybe you could phone them, and hope whoever answered (their parents, or siblings usually), knew what happened.

This is similar to situation with Bob. Team members are in the dark when they don’t know his progress. You probably assumed that Bob is struggling. He might not be. It doesn’t matter at this stage. The issue is that no one else knows what work Bob has done. They can’t provide feedback on his work. His work is invisible.

Now, of course, you can track people’s mobile phones if they let you. I remember sitting with a mom tracking her daughter’s first drive into New York City with a friend, while we sat in an Aberdeen cafe. Quite strange that we could see her progress from so far away. We had instant feedback. This is working in the open. All of the concerned people can see what’s happening, and reassure others of their progress.

Take steps to work in the open

In software engineering team members can work in the open in a number of ways. This means everyone is current with each other’s progress.

First, everyone can regularly work together on all of the tasks together as a mob, or ensemble. In this situation everyone knows the progress. Some work might be done outside of the ensemble, but this will probably happen frequently so everyone’s up to date.

Second, pair work can be done similarly to mobbing. If team members rotate their partners, then knowledge also spreads through the team too. This helps those who are struggling with new ideas.

Third, set up rules for the git repository. The team members will do the following:
a) push their work ‘at least’ once a day to the repo, but more frequently is better, even if broken.
b) there is only the main branch in the repo. Everyone works from this in ‘trunk based development’.
c) set a rule on when to ask for help from team members. For example, after working on something for 2 hours without making progress, then send a message to the team asking for help. No one knows everything. Don’t struggle on your own.

Fourth, the team can set up regular channels for communication to ask for help, and share ideas.

Teach your people how each of these work, and you’ll see teams make more progress as people struggle less.

These are the basics that we should teach everyone. Which ones do you already share with your people?

---