About an year-ish ago, I was invited to help building a new team out of complete strangers which would be responsible for owning and maintaining some existing software components of the company.
As a technical lead and Scrum Master, my responsibility would be to provide mentorship, create opportunities and remove the blockers, so the team could be built on solid foundations of trust and cooperation.
It’s rewarding that today, the team is on the front line of one of the most important projects for the company in terms of revenue. Of course this success is due to the great effort of the team members and everyone that contributed to the team.
The challenges: An overview
There are some things to consider when building an multidisciplinary team from scratch.
- Diversity: 4 software development engineers (myself included), 1 quality assurance engineer, 1 delivery manager (also team’s line manager) and 1 product owner;
- Each person has different skills and expectations;
- The role of social development and team building;
- Advocacy of continuous improvement;
- Involvement of other teams.
Create an identity: Share a name, a motivation and a goal, aligned with company’s values.
How Scrum will help you out
Having a solid process like Scrum helped us through the journey.
Many companies combine the roles of the Line Manager and Scrum Master. Merging both roles will create some sort of restrictions when it comes for people to expose ideas, opinions and feedback. In this sense, separating these roles may actually benefit team’s empowerment.
In any case, it’s important to gain the respect from everyone by showing that you care not only about the product but also about them individually and as a group, and that you are nothing more than anyone else (because you are not, really!). Gaining respect means that you become a technical reference inside the team, but not a bottleneck.
If you are familiar with Scrum, you know it has a natural way of providing you quick feedback. At each sprint, you are able to evaluate the team’s progress with a high degree of confidence through KPIs extracted from velocity, retrospectives or the quality of the delivered products.
The below are examples of what had a positive impact on the team:
- The daily stand-up is one fundamental communication channel. Ensuring it happens regularly with everyone present will improve team’s understanding of what’s going on;
- A physical story board improves visual communication. Using colourful stamps to identify blockers and having pictures of assignees provides useful and quick feedback to everyone;
- Everyone in the team may create user stories, not only the product owner. This improves the richness of the technical user stories and the ability for the team to contribute proactively to the backlog and overall quality of the product;
- Communication of stories pior to backlog refinement at a Grooming meeting will make it more productive as everyone starts from the same page;
- Getting actions out of retrospective meetings and monitoring its progress afterwards will help improving the team. Documenting the lessons learned is also important to help other teams.
How others will help you out
If, for some reason, you ended up being the only person that has been in the company for a while inside the new team, it should not stop you from involving anyone else in the process of building it.
Let the other teams know what the new team will be doing and how they can help you out on achieving a great result. Get them to participate in code reviews, knowledge sharing sessions, events, etc. This will certainly give you a hand.
It will reduce the amount of pressure on a single person, will help the team growing with a less degree of subjectivity and will also help the other teams to develop as well.
As many of the team members came from different companies and professional cultures, code reviews and knowledge sharing sessions played a fundamental role on helping spread the culture and standards of the company across everyone.
It should be considered though, that a fresh perspective is also a great opportunity for improvement, so it’s really important to motivate the new team members to contribute back to the process and to the other teams, allowing them to help shaping the company’s culture having in mind continuous improvement.
Show the others how to fly by themselves. Being a mentor to such an heterogeneous team is something that should not be taken lightly.
You should be able to coach not only the technical side of the team, but also the product and management aspects of it.
This requires you to travel through a giant spectrum of skills without compromising the responsibility of anyone else.
To achieve a common understanding, the team were able to create a balance between the delivery of technical improvements and product features. All members should be made aware of the importance and particularities of both.
You are most likely out of your comfort zone. That’s where magic happens! Take the opportunity to learn and let the others learn as well. You know you succeeded when you are no longer the reference inside the team, instead, everyone is.
Team building activities
It’s important to have team building activities, but it’s also important to carefully plan them. If you are building trust and cooperation inside a team, a competitive activity (e.g. Kart racing) may not be a smart move.
Giving a competition to a team that is not yet built on solid foundations of cooperation may have the opposite effect of what’s trying to be achieved.
Instead, why not cooperation activities as orienteering, geocaching or anything else which leads everyone to communicate and cooperate in order to achieve a common goal? Save the competitive activities for a later stage.
Communication is probably one of the greatest faults of all companies. There’s no recipe for this, so ideally we should do our best to make it happen the best way possible.
Don’t hide any piece of important information. Share everything, keep documentation up to date and as much organised as possible. Talk and let everyone talk!
Avoid too much or duplicate information. No communication at all is bad, but so it is too much of it. Never spam the team, spam is always ignored!
Get the process to be on your side. Scrum is very helpful on providing healthy communication channels and opportunities.
It’s important to consider though, that these tools don’t replace inter-person communication. Before an e-mail thread or chat discussion gets too long, it’s better to get the team to discuss in front of a whiteboard and summarise it afterwards.
1-on-1 meetings are not restricted to line managers and it represents a powerful communication channel. Constructive (and immediate) feedback is important, as well as making sure that everyone in the team gives and receives it.
Things to avoid
There’s a thin line between being a Scrum Master (or a technical lead, for what that matters) and performing micro-management. The latter may and will conflict with the team’s empowerment and self-organisation.
Paper work is necessary, but it represents only a small percentage of what you need to do to build a team. Don’t let the process or the bureaucracy impact the team negatively, as it will block the beauty of its natural evolution.
Competition will happen naturally, you don’t need to provide it and there’s no way of fully eliminating it. A basis of trust and cooperation needs to be built for competition to be healthy, otherwise it would be like drinking with your stomach empty, harmful.
The team should be protected from external noise so that everyone is able to keep focus and commitment. There is a sensitive balance between the amount of involvement of external teams/individuals and the amount of noise it produces inside the team.
A big thanks to each member of the team and to each person that contributed into it in some way.
Note: All pictures in this post were taken by me.
subscribe via RSS