Pillars to build Agile strong distributed team
During my previous experience as engineers manager, I learned that the pillars to build a strong, performant distributed team, are first of all trust and respect. Then you need to know the competencies and skills that the team have, to improve what is missed in your team, with new people, or create the right growth path for your teammate, a path that surely must fill the company requirements in terms of projects and roadmap, but it must be able to respond to the ambition of every person to give them a clear vision of their future inside the company.
The process that helps the team to reach its targets is a natural consequence of the pillars listed before and, until now, I found in Agile methodologies the right elements that can help in building a remote team
Trust and respect can be built only with the right communication, with ceremonies scheduled according to a calendar that a team create in order to take into consideration that people don’t live in the same country, so they can have a different lunchtime, start work at a different hour, have different mandatory work hours.
The cohesion between people is born when you create the right environment and the right mood to share feedback, which isn’t always is good feedback, and when they aren’t good, they became the source of actions to improve something inside the team. In other words, you do a SCRUM retrospective meeting.
Working in different places removes the opportunity to have a chat in front of a coffee machine. So a good practice that helps people to feel less isolated, is to reserve between 5–10 minutes to talk about weather, family and all that have no contact point with the normal job. For example, you can also use a different platform to have a remote coffee break between people.
But why do we need to worry about all that? The response that I found in my experience was that writing code and building software is based on collaboration, and so you need to create a good relationship inside a team. But this isn’t still enough. It is important also to be able to coordinate how the task must be correlated to achieve the goals. How to evaluate the effort for each step, user story, to achieve the target; decide the priority of each step listed in the analysis that came from the business, backlog, through someone that is able to protect the developers team, from business noise, but also know the power and the capacity of his team, the Product Owner.
The relationship isn’t problem-free, scheduled meetings and ceremonies in not always so simple, and the normal activities can find some impediments. Meetings that go always overtime is a signal that it needs to have a moderator, someone that gives the right interval for each topic and avoid people going off-topic. The role that has all that responsibility in the SCRUM world is the SCRUM Master.
What I learned is that a developers team drives by clear goals, that are able to run great meetings and that base all their collaboration on clear, simple and transparent communication bring the opportunity of leveraging team member’s individual and collective strength, and so it becomes a strong and performant Team!
What I mention is only a short part of the rules and definitions given by SCRUM methodology, because I think that SCRUM gives rules and definitions, but it is a team responsibility to decide when and how to apply that.
Originally published at http://www.llamanna.it.
