Since transitioning from a technical job (QA, Developer – a story for another time :p), I’ve worn many hats (Project/Program Manager, Scrum Master, Iteration Manager, Agile Coach), and one common thread, regardless of the company, project, or role, has been forming new scrum teams.
In this article, I’ll share my experience and my list of best practices that have helped me form cohesive and high-performing scrum teams. I’ve learned that a good start accounts for at least half of a team’s success.
Simply putting people together and giving them a common purpose doesn’t mean you have a team or that there’s inherent organization. A team also entails collaboration, psychological safety and the ability to rely on each other’s strengths. That’s why I believe team-building activities are crucial in the beginning.
The evolution of a team and your role in it
In the picture above, I attempted to illustrate the stages a team goes through, according to Tuckman. Although the length and order of these periods vary greatly depending on the team, context, and other external factors, we can agree, at least as a baseline, that all teams go through these stages and the goal is to reach the Performing phase or maturity stage.
Unfortunately, every change has a high chance of reverting the team to a previous phase.
No team starts from Day One as productive and self-organized. The team goes through a process. It begins a journey with many bumps and difficulties. The Scrum Master, Iteration Manager, or generally the team’s leadership, is responsible for guiding the team through these periods to experience as little pain as possible.
Although many people say Agile requires very little Project Management, if any at all, I disagree. Agile software development entails a fast pace and increased adaptability; it is highly disciplined and requires constant attention to process, results, and team to remain efficient.
Get to know each other
Here are two dimensions you need to consider. On one hand, the leader needs to know their people. On the other hand, team members need to know each other.
As a leader, you need to know your people and their traits. It’s useful to detect early on what management style each prefers, what triggers each individual has, who is a team player, who is more withdrawn, and use all this information in the team’s interest.
People need to know each other to become comfortable, to create a safe space to share diverse opinions, discuss uncomfortable situations, etc. Team-building activities can be done so people can present another identity of themselves beyond their role in the team. I prefer a simple but immensely effective exercise: “Who am I?”
You can use Miro, Mural, etc., or any free online tool. I start this exercise by giving the audience 5-10 minutes to complete all categories (and the facilitator participates too!) and then each person presents themselves in turn.
It’s very important for the facilitator to mediate conversations, to make people share beyond what’s written on the card (such as what it was like growing up in their hometown? How did they get hired in their first job? How much time do they have for hobbies?). I never fail with this exercise, and I feel that people get closer. Additionally, you can add as many categories as you want; I usually have a minimum of 10.
Roles & Responsibilities
What I’ve noticed over time is that people have different understandings of roles and responsibilities. This happens either because some people have shorter experience in Agile, or because in previous projects, there were different boundaries for roles, or different labels. Of course, there’s nothing wrong with that, but as a new team, you need to agree on all these things to have a common understanding.
For this, I organize a mini workshop, facilitated by me, as follows:
Roles and Responsibilities Workshop
As a general rule, we spend time on each step, timeboxed, where people provide input, and then we discuss as a group.
(1) Firstly, we look at what roles people believe should be in a team. We see if we have any extras or gaps, discuss them all, and agree on the starting formula.
(2) Then, for each role, each person writes down on cards what responsibilities they believe it should have. After 5 minutes of gathering ideas, we all discuss and agree on where the responsibilities for each role should begin and end.
(3) Finally, we try to have a brief team brainstorming session to see if there are any uncovered responsibilities, and then we return to step (2) to see which role we’ll map it to.
Definition of Ready, Definition of Done
Usually, these definitions naturally emerge after a few sprints and some lively retrospectives. However, I prefer to discuss them from the beginning and keep the list open for updates.
Similar to Roles & Responsibilities, I facilitate a session where I present what “ready” means, what “done” means*, and then gather input from colleagues for each and together we agree on the final definitions.
*The key difference between the definition of ready and definition of done is that: the definition of ready covers the requirements coming into the sprint, the definition of done covers the product coming out of the sprint.
Team ceremonies and cadence
There’s a set of standard ceremonies and others that may arise to address various team impediments or to improve team efficiency.
I prefer to agree from the outset on which ceremonies we’ll hold, their purpose, duration, who facilitates, and the frequency with which we hold these ceremonies. It’s important to respect these agreements we make together.
I believe we can all agree that the standard ceremonies are: Daily Stand-up, Backlog Refinement, Sprint Review/Demo, Sprint Planning, and Retrospective.
My experience at Thoughtworks has taught me about many new ceremonies, but in this article, I’ll introduce only two: Tech Huddle and Speedback Session.
Tech Huddle:
It often happens in Scrum teams that the daily stand-up extends due to technical discussions, going into too much detail. To ensure that the Daily remains only for status updates, we can start a new ceremony after the allocated 15 minutes for Daily, called Tech Huddle. The audience consists of technical individuals, and topics such as advice on a particular task, code issues, etc., can be discussed. The facilitator of the Daily will ensure that topics not related to status updates are moved to the Tech Huddle.
Speedback session:
Inspired by speed dating but focused on feedback 😊 The facilitator must create breakout rooms, with sessions of 5 minutes each, so that every 2 people meet to provide reciprocal feedback on their collaboration. This ceremony complements the retrospective and doesn’t replace it, so it can be done once per quarter.
Onboarding checklist
The lifespan of a team can be quite long, and often members change. For a swift and organized onboarding process, it’s beneficial to have an updated onboarding checklist.
During this initial stage, there are many new and fresh pieces of information that can be captured in this document (such as necessary accesses, applications we use, repositories, etc.). It’s our duty to create it and revisit it periodically for updates.
Team Vision or Manifest and (bonus!) Elevator Pitch
A team vision or manifest typically outlines the team’s shared values, goals, and working agreements. It can serve as a guiding document that helps team members understand their collective purpose, priorities, and how they intend to work together to achieve their objectives.
If a team decides to create its own vision or manifesto, it’s essential that it reflects the team’s unique context, goals, and values. This can contribute to a shared understanding among team members and promote a collaborative and productive working environment.
An elevator pitch is a brief (think 30 seconds!) way of introducing your product, getting across a key point or two, and making a connection with someone. It’s called an elevator pitch because it takes roughly the amount of time you’d spend riding an elevator with someone.
Although this workshop falls more within the responsibility of a product person, it’s useful for an agile leader to know as well, in case they need to facilitate it in the absence of a product owner/manager. Such pitch helps the team have a common vision and consistent dialogue with stakeholders.
Team Contract
After gathering outputs from all the workshops listed above, this information is stored in the form of a Team Contract. It’s a living document that can be updated anytime but serves as the starting and returning point.
Have you tried implementing any of the team-building activities or workshops shared in this article? If so, how did they work out for your team? I’m curious to hear about your experiences and any adaptations or additional insights you might have!
