Case Studies

Posts

Offshore Partners should have Distributed Agile in their DNA – We Do

/0 Comments/in , /by

 

Agile emphasizes that all team members should be in one location for daily meetings, requirement discussions, designing, coding, testing, etc. Along with the trend toward agile becoming the predominant development methodology for software development, it’s more and more common to find project members located in different cities or even different countries.

When team members are in different locations, the primary challenge is the lack of face-to-face communication. Time-zone issues can also arise when team members are in different countries, and cultural differences can also add to the challenge.

One example we can discuss is a team that has used agile methodology to work for a Fortune 500 e-commerce website for over four years. Located in Shanghai China, our team works with a US team (California) and an India team (Bangalore) on software new feature development, production issue fixing and production support. Team sizes are roughly similar in each location and this is the case for more than 10 module teams. We have frequent engagement and collaboration with the other module teams, and under this model, we face all three challenges of location, time zone and culture.

Overcoming the challenge

To manage these challenges, we adopted the following practices:

  • Over-communication

    You can never over-emphasize the importance of communication when your team is distributed across locations. We have daily standup meetings with the US and India teams. Everyone talks about what he or she has completed yesterday, what he/she is going to do next and the impediments blocking our progress in the daily meeting.

    We’d always rather over-communicate than have a lack of communication. [tweetthis]When it comes to distributed agile, it’s always better to OVER communicate than UNDER communicate[/tweetthis]

    At the end of each day, everyone sends a daily status summary to the Scrum Master. This enables the Scrum Master to understand the work progress status of employees in the same time zone or opposite time zones (and not available at that time). This allows him/her to lead working associates to adapt immediately to changing circumstances and requirements.

    Bleum teams use both audio conference calls and screen sharing meetings such as GoToMeeting™ or video conferencing to facilitate communication. We have found it’s very useful for us to smoothly perform sprint planning meetings and review meetings.

  • Flexible Timing

    As teams are located in different time zones, it’s critical to identify a suitable meeting time for every time zone. It’s impossible to find a time that everyone feels happy about, however, a time should be identified that everyone can accept.

    Team members must be flexible.

    California is 15 hours behind Shanghai and Bangalore 2.5 hours behind, we chose to hold meeting at 11:30am Shanghai (8:30pm California and 9am Bangalore). The US team has to sacrifice every evening and the Shanghai team sometimes has to postpone lunch, but this is the time everyone has accepted.

  • Hybrid Model

    From time-to-time, a few engineers from the Shanghai team travel to California where the Product Manager and Scrum Master are located. These engineers spend half-day on California working time and the second half on Shanghai time communicating with the team there.

    Occasional on-site visits, targeted at specific critical project phases, offer a ‘best-of-both-worlds’ solutions

    This is a hybrid model and it is very effective and useful to get correct and detailed requirements through and allows for product managers to either confirm or give comments on requirement completion.

  • Dedicated Person for Production Support

    Teams not only work on new feature development but also take responsibility for production support, especially during Black Friday and Cyber Monday.

    We have found it is most effective to assign 1-2 dedicated engineers to provide support service.

    They join new feature development when no support tickets are assigned, and are the only resources to work on support if support tickets come in. This approach enables their peers to focus on new feature development and support resources to accumulate support knowledge and practice.

  • Continuous Integration

    Continuous integration plays an important role in guarding code quality especially under a distributed team model.

    Bleum has a dedicated team whose main responsibility is to checkout code from SVN, compile code and run automated test cases every day.

    If an issue occurs, they will identify who caused the issue. Everyone, no matter their location, has the responsibility to fix their own code and get it to pass compile and auto test as soon as possible once they receive a phone call from the support team. As teams are located in three locations, this becomes a very important part of the process to guard code quality.

  • Knowledge Base

    Team knowledge placed into the knowledge base system includes: requirements, release plans, design documents, domain knowledge, test cases, testing accounts, API documentation and more.

    The best practice is for all teams to maintain all knowledge in one system. [tweetthis]The secret to KM with global teams? For ALL teams to maintain ALL knowledge in ONE system[/tweetthis]

    It’s accessible not only to the US teams, China teams and India teams but also to the peer function teams. It ensures that everyone has the same understanding about the system and it also shortens the learning curve for new team members.

Consistent over time

The team has adopted these approaches in agile projects for more than four years, and successfully managed the challenges of distributed teams. The US team, India team and China team have collaborated with each other well and delivered many important functions, during which time the site revenue doubled. The biggest impact has been on delivery speed.

Before the team adopted agile, it performed a release every two months. After adopting agile and the above practices, the team now performs a release at the end of each sprint. This means that delivery speed has improved by four times while keeping the same quality level.

Over to you

How do your teams navigate the sometimes complex issues of multiple teams in different time zones and cultures?  Do you have any additional thoughts on this topic?  If you are just scratching your head as to how to improve your team’s performance, reach out to us through the form to the right. We will help.