How to effectively manage globally distributed teams?

There are two twists to this question. One is how to effectively manage teams distributed across the world; another is how to do that in Agile mode.

Managing distributed teams is hard irrespective of whether you use Waterfall or Agile. Communication is the key. It may seem obvious. But, you will be surprised how many managers consistently mess up in that area. It is easy to assume a lot of things about stakeholders who are not physically present in your office. I have witnessed incidents where a product owner in London assumed that developers in India would work non-stop, in varying shifts, for few days before the launch. We had a client in Caribbean islands who assumed that modifying UI for iPhone app is just a matter of adjusting  some CSS; he thought his change request would take only few hours whereas the development team took more than a week. The list goes on and on.

If the team is multicultural, that adds more spice to the project manager's life. Remote teams in India, Japan, France or Dubai have holidays that may totally surprise project managers in U.S. It is not uncommon for remote teams to assume that everyone in the world know about their traditions. Some countries have Fridays and Saturdays as their weekend. Some have Thursdays and Fridays. Project managers need to educate themselves on culture and tradition of all stakeholders while managing distributed teams.

When we first started Agile, there was a lot of apprehension about using Agile with distributed teams. It turned out that Agile would actually make project management easier compared to Waterfall. If the offshore team is going to have religious holiday on a Monday, that discussion will come up in daily scrum many days before that Monday. Ideally, that would come up in sprint planning. Scrum masters may need to move around sprint meetings (sprint planning, sprint retrospective, etc.,) to suit the timings for all stakeholders. But, that's part of the game anyway.

To effectively manage globally distributed teams, following are vital:

1. Team collaboration software - Example: Confluence, Asana, Basecamp, Google Docs, etc., These tools help the team to collaborate on the project requirements and other project documents. Asana and Google Docs are free.

2. Backlog management tools - Example: JIRA Agile, Rally, etc., These tools will help you to maintain your product backlog and sprint backlog. These products are not free, but worth the price.

3. Web conferencing software - I would use GoToMeeting whenever possible. It's a paid product, but does the job very well. If you don't have budget for it, join.me is a good free product to use.

If your stakeholders are not familiar with any of these software products, train them before starting your first sprint. That will save you lot of headache.

Before concluding, an important point about daily scrums for distributed teams: 

Set a time for daily scrums, ask all teams including remote team to participate and stick to the time. This is a tricky part. Timing may not work out well depending on where your remote teams are. If your team is in San Francisco and your remote team is in Ireland, holding daily scrum at 8:45am PST would make sense for all team members. However, what would you do if your remote team is in Japan? I have seen companies doing 4pm PST scrum to accommodate both U.S and Japan teams. One of those companies are having two scrums every day -- 10am PST scrum for teams in U.S. and 5pm PST scrum for Japan team. That is very unusual, but happens. 

Scrum Room

You probably heard about Panic Room. Have you ever heard about "Scrum Room"? Instead of having daily scrums in different places every day, I believe that it would be more productive to keep daily scrums in one place consistently. If possible, use a conference room just for Daily Scrum and other scrum meetings. I find that the dedicated scrum room is extremely beneficial for the following reasons:

• It shows the commitment (for Agile process) by senior management to the entire team
• No need to worry about losing the conference room for other important meetings
• You can use scrum room's wall to display release chart, sprint chart and other charts to show the progress. 
• Two weeks before the release, we start to keep release countdown counter on the white board. Seeing it on the wall with big fat numbers make a difference to instill some sense of urgency.
• JIRA-like tools miss some important charts. For example, JIRA does not have burndown chart for multiple projects. You can create these kind of charts on the wall and update it every day during the scrum.

Are you a good Scrum Master?

Scrum Master is not supposed to "command and control" the team. The team is supposed to be "self-managing". That is the crux of the scrum process. Lot of new Scrum Masters can't comprehend the fact that team does not need to "obey" their orders. Scrum Master's job is to create a good collaborating environment in which the team members self-organize to create the best product possible. When a person makes a transition from typical Project Manager role to Scrum Master role, it's frustrating for him/her to understand that Scrum Master should not make decisions but only provide guidance. I have seen lot of Project Managers in waterfall environment have demanded "do this because I said so". That will not work in Scrum. 

I have played various roles in my career. I was a Project Manager for many years in waterfall environment. I worked as an Engineering Manager as well. When I made the switch to Scrum Master role, it was hard. I could only guide the process. I could not demand something from the team. At the same time, I was accountable for the success of the project. I was like... "what I got myself into?!". The success of the scrum process lies in the self-organization of the team. If the team needs to be directed by Scrum Master or Engineering Manager, the company will not see the benefits of Scrum. I will discuss more about self-organization in the following posts.

First thing a good Scrum Master needs to do is to drop the ego. It's easier said than done! If the team fails to deliver potentially shippable product at the end of the sprint, Scrum Master can not fire the developer and definitely can not scream at the team. Scrum Master needs to be diplomatic and understand why the team failed to deliver. A good Scrum Master discusses with the team and understand what caused the failure and will correct the root cause in the following sprint. Scrum Master's authority is limited. It takes experience, maturity and empathy to succeed as Scrum Master.

Another thing I want to point out is "Part-time Scrum Master". If your company has part-time Scrum Master, you are not really following Scrum. I have seen Tech Leads and Engineering Managers acting as Scrum Masters. That arrangement always failed because they have no time to manage the scrum process.  If a Tech Lead plays dual role of Tech Lead and Scrum Master, can you guess what will happen if something is broken just before the product launch? Dual avatar will disappear. Tech Lead will be coding aggressively to fix the code. Scrum Master will be missing in the crisis. Ironically, Scrum Master is most needed in a crisis. There is also another problem that happens periodically when Tech Lead acts as Scrum Master. If there is a production issue or some important meeting, daily scrums will not happen because Tech Lead will be busy with other meetings. 

Scrum Master's job is to make sure team is following Scrum process and there are no hurdles that prevent the team from honoring its commitment for the sprint. Scrum Master needs to do whatever it takes to accomplish that.

How to overcome resistance to Agile process

Change is hard. You can expect resistance if you introduce change. Adapting Agile is no exception. You will get resistance from all levels -- developers, business partners, managers and clients. First step in overcoming resistance is to get the buy-in from senior management before even announcing your intention to adapt Agile. If you can't get that buy-in, all bets are off. Do not even try making the transition to Agile. The transition will invariably fail if there is no support from senior management.

Team members will resist the change because of various reasons. It could be due to lack of job security, lack of awareness or just plain old political reasons. If someone is going to lose his/her hold on the team, that person will possibly resist. This is why support from senior management is vital.

We can categorize the people who resist Agile into two categories. Skeptics and Saboteurs. Skeptics are easy to manage. However, Saboteurs will try every day to make sure your transition to Agile fail miserably. One example of Saboteur -- Developer who is afraid that daily scrum will let people find out how slow (and unproductive) he is.

It's better to listen to the arguments from both skeptics and saboteurs. Make sure that their valid concerns are addressed. Training is essential to make sure that there are no misconceptions about Agile or Scrum process. Skeptics may bring some good points to consider. If you are new to the company, Skeptics may point out potential traps. They may discuss why previous attempts to adapt Agile failed. If you listen patiently, you will gain good insights from Skeptics. In case of Saboteurs, you need to be more patient. Try to address their concerns. If Saboteurs continue to make attempts to derail the transition, you have few choices.

1. Take it to senior management and let them deal with Saboteurs.

2. If you work in big organization, transfer Saboteurs to different departments

3. If you work in start-up, make sure that Saboteurs understand they have no option other than following Agile. If all of your efforts fail, fire Saboteurs. 

Once you change or get rid of Saboteurs, convincing Skeptics is easy. Do a pilot project to implement Agile. Success in that project will get everyone on-board. Success in one project will influence the whole company to adapt Agile. When you introduce Agile, you will hear objections like "It may work in Salesforce. But, it won't work here". Once you succeed in pilot project, all those objections will disappear into thin air.

You should also get the help from people who support Agile in your company. Identify the decision makers and influencers in your company and convince them about the benefits of Agile. If you get few key managers to support your cause for Agile, you should be able to easily handle Saboteurs.

The Scrum

Scrum is one of the Agile frameworks. In other words, Scrum is a conceptual structure intended to serve as a guide for implementing Agile. If you search for "Scrum", most of the web articles you get would discuss Agile and Scrum as if both are one and the same. This is mainly because Scrum is the most popular framework of Agile. There are other Agile frameworks such as Extreme Programming, Test Driven Development, etc., You can read more about other Agile frameworks in Wikipedia.

Scrum is popular because of its simplicity and flexibility. Scrum allows us to focus on delivering the highest business value in the shortest time. The business partners set the priorities. Development teams self-organize to determine the best way to deliver the highest priority features. This "self-organization" is the key to succeeding in Scrum. I will discuss more about this in a separate post.

Another beauty of Scrum is that it allows us to rapidly and repeatedly inspect actual working software, every two weeks. If there are any issues in the product we are developing, we will discover it much earlier in the process rather than discovering it two days before the launch. 

What is Agile

Agile is one of the project management methodologies. Agile means "able to move quickly and easily" in plain English. When we follow Agile in project management, we move quickly to any changes and we adapt to the changes instead of resisting. This approach is very different from traditional project management also known as "Waterfall".

Waterfall approach worked ok for many decades. I have used Waterfall when I worked in Bank of America, Wells Fargo and other banking institutions. There is nothing wrong with Waterfall approach. It just doesn't work as effectively as Agile when it comes to software development projects. Software project requirements are always changing due to marketplace conditions and dynamics in the competition landscape.  It's better to adapt to these changes to reduce the time to market. Agile also provides us the capability to release our product in increments. Agile also helps us to reduce software development costs and to increase productivity. This is why all tech companies got Agile fever!