“Software worth building is produced by teams…”
I was listening to Adam´s Grant Podcast “How to Design Teams That Don’t Suck“ last week. The main message of the podcast is that team composition and performance can be engineered. Thereby, the context can be designed so that a group of people can be led into a high-performing team. This context must focus on establishing shared experiences and responsibilities, rather than relying solely on team-building exercises.
In fact, the podcast highlights the ineffectiveness of activities solely aimed at building interpersonal relationships. As the podcast continued, I started to link it to the Team Software Process (TSP). The TSP is a software development methodology that guides engineering teams in developing software-intensive products. To me, TSP has always made a lot of sense, however, I believe history has not given PSP and TSP the recognition it deserved.
In this post, I’ll try to put these two (the podcast and TSP, in particular, the TSP launch process) together as a way of applying the principles in Adam´s Grant Podcast “How to Design Teams That Don’t Suck“ to building software teams.
Shared Experience, Shared Responsibility: The Foundations of Success
Two of the most crucial principles discussed in the podcast are the importance of shared experience and shared responsibility. While conventional wisdom might suggest that assembling a group of the most experienced individuals is the key to success, research indicates that teams with shared experiences often perform better, even if the individuals are less experienced overall. This shared experience fosters better communication, allows team members to leverage each other’s strengths, and facilitates the development of effective routines.
The goal of the TSP Launch process is to build a cohesive and effective working unit committed to a detailed plan for developing a software-intensive product. To do that, the team is presented with a time-boxed and challenging task (i.e the development of a plan for the delivery of a software increment).
A team that trains together, and is provided with a common framework and language for collaboration can ion can excel by leveraging each other’s strengths, compensating for each other’s weaknesses, by building effective routines.
The podcast describes that such activities drive the team towards a shared vision and responsibility emphasising the significance of a team’s bond around a common mission.
Shared responsibility is achieved by establishing a Clear ‘Who, What, and How’: The foundation of a successful team lies in defining a clear purpose, roles, and processes. This is the foundation of a defined process.
- Who: Ensure stable membership where possible, allowing individuals to develop a sense of belonging and ownership within the team.
- What: Articulate a compelling goal that resonates with the team members, creating a sense of purpose and driving their collective efforts.
- How: Define specific roles for each team member, leveraging their unique skills and ensuring a clear understanding of their contributions to the overall objective.
This process-based vision of team-building is inherent to modern software engineering and the foundation of the TSP.
Team Interventions
Even well-designed teams might require interventions to maintain their effectiveness. The podcast and the TSP emphasise the importance of team coaching, particularly at critical inflexion points. This coaching should focus on addressing system-level issues, promoting open communication, and refining/improving team processes.
Of course, regular monitoring and feedback allow the team to identify potential issues early. The TSP uses earned value, yet modern agile teams would likely be using velocity-based metrics.
Pre- and Post Mortem
We are all probably most familiar with team-post mortem. In Scrum, these are called retrospectives. The TSP embeds the concept of post-mortem in its iterations as the source of learning.
Interestingly, the podcast makes a case for pre-mortem analysis. This is a practice of “visualising the future”. A thought exercise where the team has failed and possible root causes are explored.
I thought this was an enlightening suggestion. In fact, I have never done such an activity with a team. According to the podcast, the benefits of pre-mortem include:
- Prevento overconfidence and establish control points in the process
- Uncover new ideas and foster innovation.
Closing Thoughts
The insights from the WorkLife with Adam Grant podcast offer a compelling argument: high-performing teams are not a product of chance but of deliberate design and ongoing support. This has been captured in software engineering and can be reproduced.
Are you looking to make your development team a high-performance team? Reach out to me. We’ll work together to improve your team’s performance.
