As we all know, nowadays, one of the most widely used methods or manners of work in order to manage project teams is Agile. Agile can be successfully implemented by using Scrum (in my opinion, one of the most widespread approaches), Kanban or others. Everybody does Agile, everybody knows the Agile principles and everybody implements them. Due to the nature of my job, I have been through many projects, from the smallest ones to the biggest ones, from the easiest ones to some of the most difficult projects. In time, I have read a lot about Scrum, how it is implemented, or about its principles or best practices, etc. In all of these situations, I have found very little information on how Scrum can be optimised when working in distributed teams, located in different areas of the world, working on the same project and trying to implement these principles which have turned Scrum into one of the most popular methodologies.
If we are talking about success, compared to the previous years, we can notice an ascending trend of the success ratio of the projects using Agile, but not only in their case can we see this trend. Below, there are the statistics of the last 2 years.
Projects using Agile (2012 vs. 2013):
Projects using V-model (2012 vs. 2013):
Projects using Waterfall (2012 vs. 2013):
Legend
Source: http://www.planittesting.co.nz/resource/industry-stats-project-outcomes-based-on-primary-methodologies-2013/
Most of the project teams I have worked in were distributed. I’ve encountered a situation when the client was located in the USA and the entire development team was located in Romania, but I have also seen more complex cases, when the development team was located in Romania but also in the USA, with the client. I think this is one of the most difficult situations to manage and I will later explain why. Let’s move on now to discuss a bit about the advantages and disadvantages of a distributed team. Let’s take an objective look on the advantages offered by a distributed team. First of all, the different time zone must not be seen as an impediment (which usually happens), but rather as an advantage. Why? For the simple reason that when one part of the team is not available, the other part is working and it can solve tasks, possible problems emerging in the production system and so on. In an overview on this situation, we can notice that, indeed, the difference of the time zone is an advantage, as it ensures the presence of support over a great part of the day. If they are working on a project that is already in production, this advantage may become even more important.
Usually, on most of the projects, people work with Scrum or, more recently, with Kanban. So far, everything is ok, but have you ever asked yourselves how well the client knows the Scrum methodology? It is a very important aspect, with a major impact in the future development of the project, having rather ample consequences. Firstly, some of the clients we are working with do not know very well what Scrum means, which its basic principles are and how exactly it is implemented. Moreover, if we are working with a big enough organization, we will notice that there are other roles and responsibilities. Surely, you have come across clients who have project managers, or the so-called Line Managers. The question is: how do these roles fit into Scrum?
It is very important, when a new team is created and they start working on a new project, to define all the roles for all the individuals involved in the project, right from the beginning. Furthermore, my recommendation is to also draw up a short list of all the responsibilities for each of these roles. These responsibilities will shed a little light and will level some connections within the team, so that each of the people involved in the project know what they have to do. Good, we have established that it is very important to define the roles and responsibilities on the project, but, what can we do when we come across some reluctant clients, who are extremely difficult to persuade regarding these aspects? The answer to this question can be reduced to a single thing: TRUST.
At this significant point, when the team is created, it is very important for the project manager, the one in charge of the entire development team, to begin playing his part. We were talking about roles, right? Well, which is the main role of a project manager in this phase? Building-up the team, adopting a common procedure for everybody and, most of all, developing their trust. Nobody tells us this: it is very difficult to succeed in building-up people’s trust in a short period of time, but it is not impossible. My recommendation in order to facilitate this thing is to have a “face 2 face” meeting with the client, to discuss all these aspects.
In time, I have encountered different forms in which a team would function and I am referring here strictly to the roles and especially the responsibilities of each member of the team. Do not forget, we are talking here about distributed teams and within these teams, you will be surprised to see that each member has his own way of understanding the role he is playing within the team and especially his responsibilities. It is very important that in a distributed team these roles and responsibilities be clearly established right from the beginning. We know very well who the main players in a team that adopts the Scrum are. But is this situation always the ideal one? I will tell you, in most of the cases I have seen people involved in the development of a project who simply cannot identify with any of those actors we are used to in Scrum. Let’s take a practical example: a client comes and tells you he has a Business Analyst available, who will want to work with the team in all the steps of the product development. Instinctively, we, as managers, could come forth and try to analyze if this BA position fits anywhere, or if we can find solutions to optimize the Scrum. Moreover, I have seen cases when certain conflicts would arise because things are not like that; we have no BA in Scrum. Let’s see how this situation could be solved as efficiently as possible for everyone. I see things in a rather simple manner in this case, and usually my suggestions go towards turning that BA into a Product Owner, and if we already have a Product Owner, why not have the two work together?
Let’s come back a little bit to the roles and responsibilities. Most of the times, in distributed teams, and especially when there are individuals involved in the entire development process, both from the client as well as from the developer, certain conflicts may appear. Why do I say this? Well, it is somewhat natural for some clients to try and place their people in some key positions, people who will want to be in charge of the development process and so on. Of course, conflicts emerge once again. It is not a bad thing for clients to wish to participate effectively in the development of their product, but we should try to approach these issues directly and make them understand that, for instance, as their partners, we may have more experience in developing a product and we should try to bring arguments as to why it would be better for them to let us coordinate some activities.
Some clients, due to the fact that they are the clients, think they have all the right to lead the entire development process. Well, in order to avoid these unpleasant situations, it is very important to discuss clearly what the roles of all the people involved in the process are and especially, it is very important to establish a minimum set of responsibilities for each of these roles. Who is responsible for adding new tasks in the backlog? Who should facilitate the communication among the team members? Who is responsible for leading the technical discussions? etc.
Once these roles and responsibilities have been established, chances are that things go very well within the team and, thus, you will have a happy client. This is what we all want, isn’t it?
Well, we are getting to the communication part. Many of you may ask yourselves sometimes how we could communicate more efficiently within the team and not only. Communication plays one of the most important parts in a distributed team. If, in a team that is located in the same place, osmotic communication comes naturally, in the case of a distributed team, things are no longer that easy and we should focus on how we could overcome those barriers which will inevitably emerge during the development of a product.
Some might say, well, ok, it is very good to communicate as often and as much as possible with the members of the team, since we can do no harm, right? Well, that’s totally wrong. Don’t forget, we are talking here about being efficient. If the team members begin to communicate excessively, using every opportunity to communicate anything that is related to the project, we are no longer efficient. An efficient communication involves a direct approach through which we are trying to solve any encountered situation as quickly as possible. This is efficient communication.
I am sure you have encountered situations when you felt or heard from the others that “we are wasting too much time on conferences and meetings with the client”. When you hear something like that, you should know that, most probably, there is a communication problem. You will now come and say: well, we are spending time in meetings with some of the clients because certain requirements are not clear. You are right, it is quite a usual situation, but this doesn’t mean we have to waste the time of the entire team in long, endless meetings. Why not select 1-2 members of the team to participate in turns to such meetings? Are we a little more efficient? I would say yes. Or why not have in every sprint a person responsible with such a task, of clarifying some of the requirements? We could go on with other situations, but what I am trying to stress here is the fact that we can be efficient just by making small adjustments.
Source: http://www.agilemodeling.com/essays/communication.htm
In addition, before a major release or an important deadline, try to gather all the team in one place. What can be more efficient than having the entire team in the same place so that they can communicate face to face? It is often quite difficult to do this, especially when we are talking about big teams. And we know very well that there can also be certain budget constraints. But, where this is possible, I strongly recommend that you try to gather the team in one place.
If it is not possible to gather the entire team in a single location, try in all the conferences you have online with the rest of the members to turn your web cams on. Sometimes it helps a lot to see your interlocutor, to observe the body language and facial expression of the person you are talking to. By doing this, the discussions will become friendlier, more open, and you will notice for sure that they will become even more efficient.
I would like to make one more suggestion: encourage everybody in the team to approach directly a person who can help. I have seen situations, even with some managers, who, out of the desire to have everything in control, demanded that the people in his team communicate their problems to him and he would solve them with the client or with other members of the team. Facilitate direct communication: you have a problem to solve and you know for sure that somebody from the client can help you out or someone from another location, then go directly to them. Moreover, encourage people to use direct communication whenever possible, namely telephone, skype or any other direct means of communication. E-mail should come as the last solution. You will be surprised with the results that can show up when communication is carried out using this approach.
Example of a burn down chart:
Example of a burn up chart
I would also like to say a few words on “active listening”, “information radiators” and negotiation. All these things lead to an efficient communication, and if we understand these concepts a little bit, we will be able to deal more easily with some tense situations or, at least, we will be able to bring more light upon a status required by a manager or a client.
Information radiators normally represent any screen or chart that is visible at all times where the team works. Normally, if the team were in a single place, an information radiator could be a board in the office, for everyone to see. What does this board look like when we are working in distributed teams? Well, it is very simple, this board is transposed into the online environment and it is given by several types of reports which are generated automatically by that instrument used by the team to measure progress, for example JIRA. In this case, the information radiators can be: a burn down chart, burn up chart, cumulative flow diagram, velocity chart. These types of graphics help the entire team, no matter where it is located, to see at any moment what the progress of a sprint is, for example. Furthermore, you know too well the questions of the type: “how are we doing with this sprint?” or “are we on track with the sprint?”. Well the answer to these questions can be seen by anyone who is looking at one of these reports, which are very nicely represented from a graphical point of view.
I was mentioning the “Active listening” somewhere above. In distributed teams, this concept plays a very important role. Normally, when we are listening to somebody, we are doing it in a passive way. In the Agile methodology, this active way of listening refers to the fact that everybody is involved actively in a discussion, meaning that everybody has to ask questions and give answers. Do not picture a chaotic thing, where everybody is talking. No! Actually, this active manner of listening and being involved in a discussion has to follow certain rules.
We are talking here about 3 levels when it comes to Active listening:
All of the above mentioned things, through communication eventually lead to negotiation. Negotiation is extremely important in Agile, as you well know. I think I ought to mention it here, for the time being, although in my opinion negotiation deserves a special and dedicated article. There are many interesting things about negotiation, but the most important aspect that I would like to mention is that negotiation has to be based on respect, understanding of the interlocutor and it is necessary for you to bring valid arguments that can draw the attention of the person you are talking to on a given topic.
There is one more thing I would like to add here, namely: you should, as managers, try to integrate in the team, and I mean try not to be seen as some bosses. Most of the times, this would only place more barriers in the way of an open and, most of all, efficient communication.
This is a very wide topic and maybe it requires a lot of debate. What I have tried to do was to put down some of the real problems that maybe many of you deal with when working in distributed teams. We should take into consideration, at all times, several aspects in order to facilitate this manner of interaction and especially to optimize some of the already known procedures which do not refer to this very important aspect: working in distributed teams. The past few years have shown us that more and more companies are opting for teams made of members from different corners of the world, out of different reasons. This represents a challenge both for the managers and for the actual team. The way in which people manage to interact, the way in which they succeed in overcoming certain obstacles and especially the value they manage to bring within a development team, turn the entire team into a work model. Projects evolve, methodologies evolve, the world around us is in a continuous movement, and this thing can also be felt in the mechanisms that turn a simple team into a successful one.
by Ovidiu Mățan
