What Makes Software Development Teams Effective

I was recently asked what qualities made a software development team effective. In the moment I answert quite spontaneously and without thinking about the subject too systematically. I have previously given the question of what makes an individual developer effective a great deal of thought, and my thoughts on that topic are presented in What Makes a Senior Software Developer?, so I thought it would be worthwhile to approach the question of team effectiveness systematically. It is obvious that teams which are composed of individuals with the variety of competencies described in that article will be more effective than those that do not; the interesting question is how those competencies can be more fully understood from the perspective of the team as a whole. It seems that there are three main qualities in team members that can serve to augment the team's effectiveness: attitude, technical skill, collaboration.

Attitude

The most essential quality is attitude. Attitude includes dedication to the project, desire for its success, willingess to accept critique of one's ideas and to take initiative to share one's own ideas. The most productive teams are those with a high degree of trust, and trust can be established when each team member is confident that the others are working toward the same goal, for the success of the project, rather than for each individual's narrow self-interest. If there is an absence of trust, then it becomes necessary for the team leader to keep close track of the work of their team members, rather than depending on their self-direction and their willingness to be proactive in reaching out when obstacles are encountered. In the extreme case, this will turn the team lead into the least productive team member instead of the most productive, since most of their time will be spent making sure the rest of the team is working productively. One possibility is that team members will slack off, but another possibility is that, left to their own devices, team members will work on aspects of the project which they find personally rewarding, rather then doing what leadership has determined should be prioritized. This latter case is problematic only if the majority of one's time is spent on such non-priorities, it is natural and desirable for team members to take the initiative to autonomously find and resolve problems some of the time. To be clear, I am not saying that assistance by leadership or other developers is unproductive, rather that if intervention by team mates or the team lead is required to ensure that productive work is occurring, then you have a problem.

Trust is also necessary for productive exchanges of ideas. Good developers should be opinionated, and should be willing to share and defend their ideas, including when these ideas contradict their peers or the team's established practice. For this productive exchange to occur, team members must be confident that disagreement, which takes energy and can be stressful even when productive, is occurring to advance the project, and not because a team member wants their own idea to win (such as so they can bring it up in management one-on-ones, or because they want to learn a specific tool (resume-driven development)). It is also necessary to approach disagreement with tact and humility, keeping in mind that our peers might have very good reasons for their disgreements. It is productive to base disagreement on facts and data rather than opinion.

It is also necessary for team members to be eager to learn and improve. Our field advances in technology and practices very rapidly. If a team is stable in its membership over a long period of time, then even if it is initially technically strong, its quality will be reduced compared to the industry standard if the team members are unwilling to learn new skills and practices. This also has a cumulative effect across multiple team members. Peers should learn from and teach each other, if one member is not interested in actively seeking out new knowledge, then other team members will have less to learn from this individual. Similarly, if more junior team members are not actively soliciting knowledge from more senior members then over time their effectiveness may be less than what their years of experience on paper would suggest.

So far we have already touched mentioned technical skill and collaboration, it is clear that having the right attitude augments the impact that skill and teamwork have on team effectiveness. Now I will explore these aspects in more detail.

Technical Skill

As recommended in The DevOps Handbook teams should be built so that team members have T-shaped skillsets. This means that they should have broad knowledge of many relevant areas, but specialize in one. For example, it is beneficial for a team to have a database specialist, but they should be encouraged to also learn about UI design and infrastructure, and their assigned tasks should reflect this. They should also be responsible for teaching the other team members about subjects such as schema design, query optimization, etc. A consequence of this principle is that teams should be cross-functional, not specialized, although there may be exceptions. Members of cross-functional teams will be more able to cover each others weaknesses and consider all sides of an issue during design sessions, swarming, or peer programming. Aside from these team-wide considerations, all of the considerations mentioned in What Makes a Senior Software Developer? also apply.

Collaboration

Teams should actively find ways to work together in various ways when working on a project. Whereas organizing cross-functional teams is useful to ensure that productive disagreement and exchange of ideas happens during collaboration, it is still necessary to be proactive in aranging opportunities for collaboration and collective work. Such opportunities include pair programming, retrospectives, design sessions, code review, and post-mortem meetings.

Pair Programming

Some companies value pair programming so highly that they insist that all implementation be done through structured pair programming, alternating the roles of navigator and driver. I personally find this extreme, more common in my experience is unstructured and unplanned pair programming. In this case, one developer reaches out for help, and the navigator joins the driver in a call. During the call the navigator shares tips and suggestions until the immediate problem is solved. This practice is productive, but organizations should also consider whether more planned and structured pair programming is also useful.

Retrospectives

Retrospective meetings are extremely useful. If a team practices retrospectives, then the team will regularly (perhaps at the end of each sprint) meet to discuss the recent development cycle: what went well, what went poorly, and what changes the team should consider for future dev cycles. The aim is that developers should all adopt a critical approach to the existing development practice, and that this practice should evolve over time to increase efficiency and reliability. Ideally, the team should also use DevOps metrics to measure objectively whether any specific practice results in improvement. I have also heard tales of situations where retrospectives have been useless. From these anecdotes, retrospectives become useless when there is no trust in the team that ideas will be taken seriously. It is the team lead's responsibility to ensure that the conversation is concrete, and results in one or a small number of specific change recommendations, which the lead is responsible for implementing.

Design Sessions

At my previous company, we would tend to have spontaneous design sessions in the middle of sprint planning. This had its benefits and drawbacks. The main drawback was that too many people were involved in the planning than was really productive, and also that the sprint planning meeting went far longer than necessary. The benefits were that multiple designs for a complex change or feature could be considered by the most experienced developers; and the best design would rapidly be agreed upon. More junior developers also benefited from being exposed to the conversation. Some improvements I can think of, or have heard of are:

• specifically soliciting design ideas from junior developers, and explaining the resulting flawed ideas
• the reduced effectiveness of the practice I experienced may have been mainly due to the large team size at that time. For smaller teams it may be fine to do sprint planning concurrently with design, without needed separate meetings.
• document the design alternatives as Architectural Decision Records
• it is also beneficial to avoid all sources of ego. For each design, the team should elaborate their benefits and drawbacks, and decide whether these match the overall project goals for any specific solution.

These collaborative design sessions are superior than the alternative practice: delegating all design work to the developer assigned with implementation. I have often seen that major design decisions can be made in this way and then not discussed, since depending on the team's code review practice it is more common for code review to focus on correctness and syntax readability instead of high-level design. The result is that a project's design becomes increasingly incoherent over time.

Code Review

The use of asynchronous code review tools is omnipresent today. They are integrated into all major repository platforms. I'm referring here to synchronous, and potentially in-person code review. This practice of code review is far more thorough, since it is much faster to speak abstractly about larger code diffs verbally than over github comments. The goal should be for the reviewers to:

• more rapidly develop an understanding of the merge request
• more rapidly establish whether there are fundamental errors that must be addressed, rather than continuing with a full review
• convey a deep understanding of the merge request's problems to the implementer, and to avoid miscommunication
• review code comprehensively, including high-level design, rather than confining the review to syntax and correctness, which is quite common

Post-Mortems

Post mortem meetings accomplish a similar goal as retrospectives, whereas the latter aims to find small issues, inconveniences, pain points with the development project, post-mortems seek to permanently resolve big issues. To be clear, post-mortems do not aim to solve individual issues, but to rule out entire classes of issues permanently. For example, if a type safety bug is encountered in a JS codebase, that task would be assigned, investigated, and resolved through a merge request and deployment. A post-mortem meeting is not necessary to find the specific line of code where the bug was generated. A post-mortem meeting should ask: "what changes to our technology or development process will make this kind of bug from occurring". For the type safety example, such possible solutions from a post-mortem meetings are to adopt TS, or to implement code coverage requirements, or to make code review more strict, etc.