Daniel Pinho

§ 8 Team Players

Context

Software projects are often collaborative efforts, with multiple people of varying backgrounds, roles and skill sets working together.

Problem

It can be intuitively inferred that teams are made of people working to reach a common goal, but there are intricacies in the difference between a group of people and a team.

What factors should developers pay attention to when working in teams?

Forces

  • Teams need a clear direction and shared goals to align efforts, but those goals may shift or conflict, requiring ongoing negotiation and adaptation.
  • Leadership can provide necessary guidance and decision-making clarity, but centralized control may reduce team autonomy and flexibility compared to self-organization.
  • Team composition influences outcomes through skills and personal dynamics, but diverse backgrounds and working styles can create misunderstandings or friction.
  • Team organization and processes promote coordination and efficiency, but overly rigid management structures risk inhibiting creativity and responsiveness.

Solution

Team members should come together with an aligned approach, working together, sharing knowledge, supporting each other, and applying a process that works for them.

A team aligns itself towards a common objective or goal, often the project’s completion. This alignment can be guided into other goals that are smaller in scope, as is the case for the Sprint Goal in Scrum teams. The team’s leadership can influence their direction. Some teams are self-organised, collectively making decisions, assessing tasks, and setting goals. In contrast, others may have their leadership concentrated on one person, as for team leaders in enterprise contexts. Both team types can suffer through poor leadership; a supervisor or a team leader may lack the necessary skills or a cohesive vision to guide their team members best, while self-organised teams are challenging to implement[1].

Honesty and respect are the at the base of effective teamwork, with them even referenced as foundational concepts different codes of ethics[2][3]. Without these values, trust would not emerge within the team, and knowledge sharing and collaboration can break down into competition or guarded behaviour. When team members feel respected for their contributions, they are more willing to support one another, to give and receive feedback, and to commit to achieving results together. Respect also encourages having different opinions, since individuals feel safer expressing differing perspectives without fear of dismissal[4].

Developers should consider working with their teammates on the same tasks, such as performing pair programming. It enhances their skill-building and enables the easy spread of tacit knowledge within the team. The role played by relationships is also of note; building relationships can help with productivity[5], and working together is an easy way of doing it through frequent interactions facilitated by pair work[6].

Distributed or hybrid teams add another layer of complexity, as not all team members work together in the same space (or even in the same time zone). To stay aligned, they need to take care to keep information visible and accessible to everyone, regardless of their location: this can be done through regular stand-up meetings, shared task boards, or other asynchronous communication methods. Communication tools play an important role, as they potentially are the backbone of the team’s collaboration: synchronous check-ins and calls help with team cohesion and help reducing the distance, while asynchronous practices reduce disruption and ensure that everyone stays on the same page even when schedules do not overlap[7].

Working together can additionally pay dividends whenever a team member is away and requires someone to back them up by continuing their work; team members will feel more at ease with such a task if they have prior knowledge (coming from already having worked together on the same parts of the project) and are invested in supporting their colleagues[6][1].

Examples

  • Feature teams include a mix of expertises within its members so that they can cover a wide gamut of development tasks, being able to work on a single feature completely on their own. The teamwork necessary to achieve this output encourages shared ownership and open communication[8].
  • Co-located teams (i.e. those that share a physical space) have an easier time with sharing spontaneous discussions and quick conversations. These face-to-face interactions facilitate building trust, giving feedback, and sharing knolwedge informally, which in turn helps with team alignment. Face-to-face interactions are also more charged with information than distance-based communication methods, both synchronous (phone or video calls) and asynchronous (email or instant messaging)[6].
  • Distributed teams can collaborate even when separated across distance and time zones through digital platforms that facilitate code reviews, chat, and planning[7]. %If the team’s working hours overlap (for example, if they’re in close time zones or even in the same one), they can also approximate the feeling of being in the same space by being connected to a voice call system.

Consequences

  • Positive interpersonal contact helps with productivity by fostering effective knowledge transfer and skill building among team members.
  • Good working relationships within the team help developers feel more satisfied and comfortable in their work environment.
  • Teams are complex systems, requiring strong soft skills to manage cooperation and collaboration.
  • Diverse backgrounds and worldviews in the team create challenges that require ongoing efforts to harmonize and collaborate effectively.

The patterns §9 Stakeholder Relationships and §10 Breathable Atmosphere are similar patterns that affect the developer’s feelings about their work, focusing on the relationships between developers and stakeholders and the overall workplace culture and psychological safety, respectively. These patterns all contribute to §3 Good Feelings.

Good teamwork can affect a developer’s motivation; the pattern §11 Intrinsic Motivation discusses this factor. The team can also help with skill building; see the patterns §5 Adequate Skills and §14 Learning From A Master for more details.

The concept of teamwork and how team members should interact is also approached in other pattern languages. The patterns Community of Trust, Sacrifice One Person, Developing In Pairs, Manager Role, and Self-Selecting Team are examples of patterns that dive deeper into the intricacies of teamwork from Coplien and Harrison’s Organisational Patterns[9]. One can also find examples of teamwork-related patterns in the Scrum Patterns[10], such as Colocated Team, Self-Organizing Team, and Autonomous Team.

References

  1. N. B. Moe, T. Dingsøyr, and T. Dybå, “A teamwork model for understanding an agile team: A case study of a Scrum project,” Information and Software Technology, vol. 52, no. 5, pp. 480–491, May 2010, doi: 10.1016/j.infsof.2009.11.004.
  2. Association for Computing Machinery, “ACM Code of Ethics and Professional Conduct,” Association for Computing Machinery, 2018. Accessed: Nov. 04, 2025. [Online]. Available: https://www.acm.org/code-of-ethics
  3. Project Management Institute, “PMI Code of Ethics and Professional Conduct,” Project Management Institute, 2006. Accessed: Oct. 31, 2025. [Online]. Available: https://www.pmi.org/-/media/pmi/documents/public/pdf/ethics/pmi-code-of-ethics.pdf
  4. J. Katzenbach and D. Smith, The Wisdom of Teams: Creating the High-Performance Organization. Harvard Business Press, 1992. Available: https://books.google.com?id=OH9JwM8XCdcC
  5. R. Elizalde and S. Bayona, “Interpersonal Relationships, Leadership and Other Soft Skills in Software Development Projects: A Systematic Review,” in Trends and Advances in Information Systems and Technologies, vol. 746, Á. Rocha, H. Adeli, L. P. Reis, and S. Costanzo, Eds., Cham: Springer International Publishing, 2018, pp. 3–15. doi: 10.1007/978-3-319-77712-2_1.
  6. A. Cockburn, Agile software development: The cooperative game. Addison-Wesley, 2006.
  7. M. R. Thissen, J. M. Page, M. C. Bharathi, and T. L. Austin, “Communication tools for distributed software development teams,” in Proceedings of the 2007 ACM SIGMIS CPR conference on Computer personnel research: The global information technology workforce, in SIGMIS CPR ’07. New York, NY, USA: Association for Computing Machinery, Apr. 2007, pp. 28–35. doi: 10.1145/1235000.1235007.
  8. N. B. Moe, T. Dingsøyr, and T. Dybå, “Overcoming Barriers to Self-Management in Software Teams,” IEEE Software, vol. 26, no. 6, pp. 20–26, Nov. 2009, doi: 10.1109/MS.2009.182.
  9. J. O. Coplien and N. B. Harrison, Organizational Patterns of Agile Software Development. Prentice Hall, 2004. doi: 0131467409.
  10. J. Sutherland, J. O. Coplien, L. Heasman, M. den Hollander, and C. O. Ramos, A Scrum Book: The Spirit of the Game. in The Pragmatic Programmers. Raleigh, North Carolina: The Pragmatic Bookshelf, 2019. Available: https://scrumbook.org

Last updated: December 18, 2025