In the previous Installment, I provided a summary of the background models (Tuckman’s stages and The five dysfunctions of a team), I also shared my summary notes from Coach K’s Masterclass. Coach K’s Masterclass emphasises values, people focus, culture, communication, and standards.
In this second instalment, I now bridge these theoretical and practical learnings to the specific context of coaching software development teams.
Let’s bring all this back to software teams
“All software worth doing is done by teams”, yet not all groups of developers are a Software Team.
To me, these frameworks, being agnostic to software development, help transition groups into teams. So, my goal with this article is to link what I learned from the Masterclass to what I know from Tuckman’s model. And hopefully, chart a path for myself and you on how I will intend to use these models in the future.
Stage: Forming
Goal of the stage: To establish the team structure, understand roles and responsibilities, set objectives and tasks, and establish ground rules and expectations.
In software, if you are following a methodology (say Scrum), these team roles might have been defined, however, the team should ask what these roles mean in the organization context. For example, is your team struggling with DevOps? Do all team members have the necessary training?
According to the models: These questions signal towards team members who are orienting themselves (personally and professionally) within the organisation and the organisations’ goals.
Forming teams tend to avoid conflict due to the need for acceptance.
Dysfunction: Absence of Trust. Team members may feel suspicious, fearful, and anxious and avoid controversy, which stems from an unwillingness to be vulnerable with one another about mistakes, weaknesses, and concerns. This makes it impossible to build a foundation for trust
Coach K path to overcome the dysfunctions:
Build Trust: Establish trust by being honest, communicating often and openly, fulfilling commitments, and nurturing relationships. Encourage honest conversations and create psychological safety where team members feel comfortable sharing ideas, criticisms, and concerns.
In software, we must use our ceremonies for much more than the transactional questions typically embedded in the methodologies (For a bit more of these in the daily meetings, see this post).
Set Clear Standards: Share values and standards with team members
As mentioned. Setting standards is much more than defining the process. It is deciding as a team what the expected behaviours for the team member are in predefined and expected situations. At this stage, “setting clear standards” is not about a written definition, but about determining the behaviour that will define culture. For instance, think of the retrospectives and establish a culture of root cause analysis and continuous improvement (If interested, take a look at my guide for getting actionable results out of your retrospectives).
Stage: Storming
Goal of the stage: To address interpersonal conflicts that arise as the team organises tasks and processes, navigate leadership and power issues, clarify and understand the team’s purpose, and re-establish roles and ground rules
In software:
Dysfunction: Fear of Conflict and Lack of Commitment. Observable behaviours include arguing, vying for leadership, power struggles, differences in points of view, lack of consensus, and resistance to tasks. Feelings and thoughts can include defensiveness, confusion, resistance, and questioning the team’s mission.
Teams that lack trust are incapable of engaging in unfiltered and passionate debate, resorting to veiled discussions. Without having aired their opinions and feeling heard, team members may not genuinely buy in or commit to decisions, even if they feign agreement.
Coach K path to overcome the dysfunctions:
Confront Challenges With Empathy: Address issues like friction among members or performance lacking by thinking about team members’ insecurities, life obstacles, or fears. Set the boundaries within which conflict is accepted. I have used tools like the Evaporating Cloud for addressing some of these issues in teams I coached.
Take Communication Seriously: Communication is the lifeblood, encourage connecting and communicating every day. Know your audience and adapt communication styles. In software, enhance the daily meeting, foster the one-to-one meetings to resolve technical issues (these will build up relationships between team members).
Emphasise Culture: Reinforce why the team is here, its principles, and non-negotiables
Stage: Norming
Goal of the stage: To create new ways of working together, develop cohesion, establish norms and procedures, solidify trust, and transition towards shared leadership
Team members agree upon processes and procedures and feel comfortable with relationships.
In software, I typically tried to get teams through the first two phases by setting challenges, or a well-crafted Scrum 0 phase. The TSP Launch, has been my source of inspiration when designing these interventions. And, also, it has been my source of BIAS, as I have relied on defined processes for getting teams through the initial phases.
Dysfunction: This stage is about moving past the initial conflicts and solidifying the team’s direction. The successful navigation of this stage solidifies Commitment and builds the foundation necessary to overcome Avoidance of Accountability. Team members start to focus energy on tasks, engage in effective conflict resolution, and make consensual decisions, indicating movement towards commitment.
In software, I like that the team dynamics that can be fostered with well-crafted Planning meetings. If managed right, and with the right amount of pressure, teams accrue risks during the Planning Poker, commit to outcomes, and the conflicts arise at the retrospective.
Coach K path to overcome the dysfunctions:
Set Clear Standards: Ensure processes and procedures align with the team’s standards
If you have not done so yet, It is time to start writing your processes.
Emphasise Culture: Continue to reinforce the team’s principles and non-negotiables as routines develop. In software, part of this can be captured in the Definitions of Done
Focus on the Next Play: Encourage team members to attack the moment and be present. This is new for me, but I envision myself referring back to this concept when Sprint Reviews don’t go as planned, when estimates are way off or when velocity suffers.
Stage: Performing
Goal of the stage: To function as a truly interdependent and highly productive unit, where roles are clear, flexibility is high, and members understand each other’s strengths. The team is working together smoothly to achieve project goals.
Dysfunction: Avoidance of Accountability and Inattention to Results. While functional, teams in this stage must maintain focus and high standards. Avoidance of accountability stems from unwillingness to tolerate interpersonal discomfort when calling peers on performance or behaviour that hurts the team. Inattention to results occurs when team members prioritise individual needs or division needs over the team’s collective goals
In software, I have experience with very few teams, and for very brief periods, performing at this level. Changing dynamics (turnover, health, changing business needs and life in general intervene) quickly move teams into previous stages. When this happens, documentation becomes outdated, and performance quickly erodes. With luck, you can take your team through an orderly adjourning stage.
Also, if you have reached this stage, then you know the feeling! When performing at this stage, things simply flow.
Coach K path to overcome the dysfunctions:
At this point, the role of the coach is to maintain the performance for as long as possible.
Harness the Power of Standards: Consistently live by the standards the team has decided upon. Maintain mutual accountability and a focus on results based on these standards
I reiterate the extent of the impact that Focus on the Next Play: Regardless of past success or failure, the most important play is the one right in front of you. Be present and do what it takes for the team to win in this single moment. As an amateur sportsman, this resonated a lot with me, yet I am positive I have not transitioned this to software.
Use Both Tactical and Emotional Motivation: Motivate the team every day, like a habit. I typically use the Sprint Planning, as I typically do not engage with teams I have coached in a daily basis. Coach K, mentions Tiered Leadership as a strategy to continue to develop leaders within each tier and empower individuals (like captains) who embody the team’s values and step forward to get everyone on the same page.
Finally, Focus on Results: The leader must set the tone for a focus on results. In sports, Results are the ultimate measure of a team. In software, Empirical methods, like Scrum, allow for scoreboard-like metrics to be gathered (with a word of caution as to what is worth measuring in software, and how these are used to evaluate knowledge workers).
Stage: Adjourning
Goal of the stage: To complete tasks, evaluate efforts, recognise team achievements, reflect on lessons learned, and manage the feelings associated with the termination of the team or project
This stage is not directly linked to Lencioni’s Five Dysfunctions, and the masterclass and Coach K excerpts focus on leading a team through its performance lifecycle and do not contain specific principles tailored to the stage of team dissolution.
However, there is ample literature in Project Management about team dissolution. In my experience, Projects will end, or wind down, and team members will be assimilated into other teams in the organisation. Turnover will make for abrupt departures from performing stages. So guiding a team through an orderly Adjourning stage is a privilege for a software coach.
Parting thoughts, where the sports analogy falls short in software development.
As an Educator, I have thought about the concepts in these articles several times. I am biased by my experience, and my recurring thought is that the experience of being part of a team is hard to convey to persons who have not engaged in competitive sports. In the classroom setting, we have come a long way. We can do games that simulate teams dynamics, and organise university modules around groups of people that resemble a team. We can do project-based learning, and create the stage so that part of what is described above can be experienced in the classroom. Yet, to my knowledge, the experience of being in a team FEELS different.
So I like to close this off with four points where I believe the sports analogy falls short when applied to software development teams.
- In software, there is a lack of training that resembles the match: Competitive sports often involve dedicated training and practice sessions specifically designed to simulate game conditions. In contrast, software development work is often continuous, and while teams engage in learning and process improvement, this is typically integrated into the ongoing development process rather than being a separate, simulated ‘match’ preparation.
Team building workshops provide an artificial setting, and so do workshops to foster group dynamics. These activities are usually detached from the regular day-to-day software development work. I still have not encountered an organisation that organised its internal training as if it were the “real game”.
- The value and pervasiveness of coaches: In many competitive sports, the role of a dedicated coach is fundamental and ubiquitous across all levels of play. From Sunday leagues to professionals, in team sports, you will typically see someone standing at the line. While leadership is essential in software development, the leadership style can evolve from a more directive approach in early stages towards shared leadership as the team matures and becomes high-performing. Coaching and the value of Team coaching in knowledge work is not as pervasive, and not all organisations and teams see the value of it.
- The nature of “Results” and the “Opponent”: In sports, the ultimate measure of success is often a clear, quantifiable outcome like winning a game or a championship. Coach K mentioned that wins were a by-product of setting standards, implying a focus on process, but the end goal is explicitly victory in competition. The “opponent” is typically a specific, visible team or individual. In software development, the definition of “results” can be far more nuanced and continuous, encompassing delivering business value, customer satisfaction, optimizing efficiency through metrics like lead time and throughput, and achieving strategic goals.
The “opponent” is less defined; it might be market dynamics, technological challenges, or internal complexities, not a single entity faced in a direct contest. This clearly dilutes the feedback loop. In knowledge work, we would rely on metrics and measurements to be able to observe the ”opponent”.
- The balance between Individual vs. Team Recognition and Performance: While teamwork is vital in sports, individual performance is often highly visible, statistically measured, and celebrated through accolades like MVP awards. Star players are a recognised part of the ecosystem.
In knowledge work, and in software, the emphasis should be on the collective results. As professionals, software developers should be given the tools to be able to measure their individual performance. But they should not be measured or evaluated. Demming is quoted for saying, “no individual consistently outperforms the process”.
If you got to this part. Thank you for reading the whole article. While the principles discussed here are straightforward, their effective implementation often requires a nuanced understanding of your team’s unique context. That’s where evidence-based coaching makes the difference, accelerating your journey to sustainable productivity. I would be honoured to coach your team through the stages outlined above and reach together stages of high performance. Reach out today, and let’s map out the first steps towards your next level of productivity.
Discover more from The Software Coach
Subscribe to get the latest posts sent to your email.
