How to Make a More Effective Software Team?
By: John Au-Yeung
Tags: Product Management, Programming, Software Development, Productivity, Web Development

Photo by Dylan Gillis on Unsplash

Writing software is often a team effort. It takes effort to make a team effective.

In this article, we’ll look at what makes a team effective.

No Broken Windows

The whole team has to focus on quality. If something’s broken, everyone has to be proactive in fixing issues.

Even if they’re small, they add up faster. Some teams have a quality officer to look for issues and delegate people to fix them.

The whole team needs to focus on quality.

Boiled Frogs

The boiled frog analogy is where the frog slowly boils in the pot as the water inside gets hot slowly.

After a long time, the pot’s water is so hot that it boiled the frog.

In the same vein, we don’t want our software to get gradually worse in quality that the quality issues will become a big issue later on.

Everyone is assuming that everyone else is handling those issues while everything hasn’t changed.

We should actively monitor the environment for changes.

Also, we shouldn’t let scope creep slide if we ever want to finish a project.

Even if some change has been approved by the team, we still need to review if we can do all the changes required.

We should look for things that aren’t in the original requirement and think if we can do them at all.

Then we’ve to take them out if they aren’t.

Communicate

Communication is always important. Without it, we’ll step into each other’s toes.

The team also needs to communicate clearly to people outside the team.

People look forward to meeting with teams with a distinct personality because they’ll be prepared to make everyone feel good.

They produce easy to read and clear documentation.

They speak with one voice and may even have a sense of humor.

We got to generate a brand so that we’re seen as one outside the team. May come up with a logo or a name to make our team memorable.

Don’t Repeat Yourself

Duplication is always bad. Duplicated work between different members doesn’t help us and leads to wasted effort and a maintenance nightmare.

We need communication and project librarian. The project librarian tracks the work that is done by people so that we won’t delegate work twice to different people.

They’ll spot impending duplication by reading material they’re handling.

The librarian is the go-to person for tracking the work. If the task is too big for one library, then different people should be appointed to focus on different parts of the work.

Orthogonality

Different functions of a software team like analysts, architects, designs, programmers, testers, etc. can’t work in isolation.

It’s a mistake to think that they can all work without talking top each other.

Therefore, it’s better to organize around functionality rather than job functions.

We should split the team functionally so that each small team is responsible for a particular functional aspect of the final system.

Then the teams can organize internally as they see fit to get things done.

Functionality doesn’t have to be use cases. They can be technical functionality like data manipulation, user interface and things like that.

These teams can do their things and then they won’t be too coupled to each other if we make our software systems orthogonal and decouple modules from each other.

Then if we decide to change anything worked by those small teams, then the changes are done by those small teams.

This is because the change won’t affect other teams because of the orthogonality.

We can reduce the number of interactions between individuals’ work,m reducing time to delivery, increasing quality, and reducing the number of defects.

Everyone in the team is responsible for a given functionality, so they feel more ownership.

This works well with responsible developers and strong project management. Then the project world needs one technical and one administrative lead.

The technical lead would look at the big picture and eliminate duplicate effort. The administrative head would schedule resources for teams' needs, monitor progress and decide on priorities in terms of business needs.

Photo by You X Ventures on Unsplash

Conclusion

We can create effect teams by eliminating duplicate effort and communicate effectively inside and outside of the team.

Also, splitting teams by functionality make more sense since software modules are supposed to be designed orthogonally so that one part doesn’t affect another.

Therefore, they can be built without much coupling between each other.