On Building a Team
Today marks the second week with my new team and I’d like to share some of the things I’ve done to get things going with them.
First, a bit of context. The team is actually 2 teams. One is developing a prototype for a new product and the other is finishing up work on another product that was started last year and released in Beta. We are all, for the most part located in the same physical office here in Barcelona. The exceptions are 2 people in Hamburg and 1 working in Madrid. And except for 1 person who just started working here, most of us have worked together before, albeit on different teams. And if not that, we are already acquainted since the office is still small enough that we know everybody’s name even if we are not on the same team.
Aside from getting everyone into a workshop, these are a few things I have done in the past two weeks to work on rapport with my new team.
Morning greeting — I actually do this with everyone in the office when I arrive in the morning. For myself I find it very energizing and also a quick way to connect with my colleagues. I do the greeting Spanish style with two cheek to cheek kisses and a little hug. I usually say “Happy Monday!” and “Happy Friday!” on those days and often ask a question or two to the person I’m greeting.
Getting us in the room — I use this as a quick way of getting the whole team connected with each other. At Monday stand-up I began the stand-up by asking everyone to share one highlight of their weekend (good or bad) with the rest of us. Once we all went around the circle we then began the stand-up. I find when I do this it helps put us in the frame of the team by sharing something personal with each other.
“EMO” check-in — I did this once last week before the stand-up to let the team know that I was feeling anxious about something. I’ve borrowed the check-in from the Core Protocols. I find it valuable as a way to let the team know how you’re doing on a personal level without leaving them guessing. It’s especially useful when one of us is simply having a bad day and knows they won’t be at their best that day.
Set the Focus
For any team to succeed they need to know their reason for being in the team. This is where goals/visions/missions become important. They are the means for orienting each person towards something bigger than themselves. Something that can be achieved only by working together on a team. The clearer the goals, the easier they are to embrace.
OKR — This week we had our Product Director visit and he walked the whole team through our “Objectives and Key Results” (OKRs) for this year. He listed 4 items in priority order. Each was representative of quite a lot of work, but the prioritization and the explanation as to why these were important were easy to grasp. Next week I’ll be following up by pasting a copy of the OKRs in our stand-up space so that we don’t lose sight of what we should be focusing on.
Focus Groups — Later on in the week I met with one of the teams to break an OKR down into even smaller chunks. We now, as a team, have agreement on what order we will be working on things and will also divide into pairs and trios to hone the focus even more. My objective here is that no single individual is working on his own, but always has at least one other person working on the same task. That way, the pair can keep each other in line with what they should be focussing on. Of course they’ll have as well the support from the rest of team during the stand-ups and during code reviews.
Daily stand-ups/idonethis — One of the teams has a daily stand-up. We “walk the wall” and ticket by ticket go through the items in progress. The people working on the ticket give a quick update, and also mention other people whose help they need to finish. To wrap it up we repeat the post-standup chats that need to happen and I ask everyone if they need anything else and anyone who is planning to be late/WFH/ etc. reminds the team.
The prototyping team has been using idonethis in lieu of a daily stand-up. They set daily goals and report their dones to each other asynchronously. We thought this would be less overhead than a stand-up. Since this has been the first week using it, it’s still too early to say if it’s working for the team or not. I’m planning to do a check in with them next week about it.
Establish Working Agreements
I intentionally waited until this second week to call the meeting about working agreements because first I just wanted the team to get some work done together and have the chance to see how it was to work on this team.
Here’s the agenda I used to organize the meeting:
- Expectations and behaviour protocols: Basically how we would behave with each other, what attitudes are acceptable, what behaviour is unacceptable. We are using the Core Commitments as a baseline. We agreed to “investigate” whenever a team member wasn’t behaving in line with the protocols. We decided to have a separate meeting about what our expectations of each other are role-wise. For example, what do developers expect from the PO; or what do the UX specialists expect from the developers, etc.
- Scrum or Kanban? We had the chance to test out some of the behaviour protocols, especially “Decider” when we were trying to decide whether to use Kanban or Scrum. From this decision came some other methodology-specific decisions.
- Rituals: Which meetings we would have, how often and at what time.
- PRs and Code Reviews: The developers decided to do this in a separate meeting and shared the link to the wiki they put together on GitHub.
- Communication Channels: what information get communicated in which channel.
Besides the above, and of course some topic-specific meetings about what the team is currently working on, I also organized a half-day team building workshop which I will talk about in my next blog post.
By far the most important task I had regarding building the team was to simply observe them in action. Some of the things I’ve been taking note of have been:
- Out of the big group, what pairs or trios are forming in work and out of work?
- Which of the team members tend speak up more in meetings? Which hold back?
- What kind of body language do I read in our meetings?
- How much conversation is going on in the team space?
- Which of the communication channels is being used the most?
I am, in a way, looking at the team as an anthropologist would, and staying curious about what I observe.
The techniques I’ve described above are just some of things you, as a scrum master/agile coach can do to get your team off to a good start. Of course there are many others.
Still the essentials matter for any team:
- Rapport: find a way to create a basic connection with one another
- Focus: make it clear for your team exactly why they’ve been brought together to work as a team. And remind them about it repeatedly.
- Working Agreements: establish some clear behaviour boundaries, and work with the team to define how they will work together
- Observe: try to understand what kind of people you are working with and what are their interpersonal dynamics. Then, adjust your leadership style to that. And remember to stay curious!