Solo work is slow work

Learn to collaborate instead of delegate for effective team work

Students do lots and lots of solo work at university. This is to be expected. For their team focused software engineering, or software development work, we should teach them to work in pairs or as an ensemble.

Students tend to do team work the same way they do other university work. They break it up into individual contributions, which can be combined later. This is also sadly, how it is often taught too, as it reflects the project management background of the process with Gantt charts, work breakdown schedules, milestones and deadlines. This is wrong.

All of these get in the way of doing the actual work. We should not be teaching students these poor processes. We should show them what does work reliably. What is proven to work.

Solo work is slow work. Stop teaching teams to use solo work. Teach them to do the work together.

Team collaboration requires different skills

We should teach students to unlearn what they did before. That solo work that got them to uni will not help them as much as they think in software development. Stop working on your own: always be collaborating. This speeds up feedback, and spreads knowledge within the team, while building a shared vision of your work.

Solo work leads to delayed feedback. The person’s work is invisible to the rest of the team, and that person also doesn’t know what the others are doing. Yes, there is a plan of what people said they’d be doing, but that is different from reality. The ‘map is not the landscape’ and the implementation details are important too. Stop working on your own: work in the open so people can see what you’re doing, and keep you on the right path. By working in pairs, or as an ensemble or mob, you build more quality into your work at a faster pace, than if you work solo.

Solo development often means multiple branches of code. This slows down everyone. No one knows who is doing what as that work is invisible to the team, and the team’s work is invisible to that branch too. The longer the branch lives the more it diverges from the main branch. Stop using branches: use trunk-based development for fast feedback on your collaborative work.

Solo work provides false feelings. You think you’re making progress on good days, and feel horribly stuck on bad days. The reality is a Schroedinger’s box. You don’t know how well you’re doing until your work is integrated with the rest of the team’s work. Until then you could be doing well, but going in the wrong direction. You could also be doing poorly, but that’s ok, as someone did something that makes your work irrelevant. Stop working on your own: use a better cadence for collaboration so everyone’s work is synced more frequently to provide a true state of development.

Teach people to do the work together

Stop asking students to break up the work into solo tasks, or for them to be a ‘front-end’, or ‘back-end’ lead, or whatever. By all means ask them what their personal goal is for the term, but don’t ask them to become the team’s expert on something. This forces them to become a bottleneck, which slows down the development.

Guiding students to organise ‘working’ meetings instead of ‘status updates’, will fix most of these issues. Meeting to do the work together so that all of the people are there, who need to decide the issue, speeds up work unbelievably, as shown repeatedly by others. By doing the work together at the same time, you avoid waiting. You cut out task switching. You do the work. Together. You learn about each other, and co-create a shared understanding of what you’re building too.

We should teach them the better way of doing the work. Show them why and how this is a better way of doing software development. Send them off onto their careers as ambassadors of better ways of working.

---