Jai’s Weblog – Tech, Security & Fun…

Tech, Security & Fun…

  • Jaibeer Malik

    Jaibeer Malik
  • View Jaibeer Malik's profile on LinkedIn
  • Subscribe

  • Feedburner

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 32 other followers

  • Archives

  • Categories

  • Stats

    • 412,782
  • Live Traffic

  • Advertisements

Sprint in Action : Typical vs Distributed team

Posted by Jai on March 30, 2009

These days Scrum is well known and successful Agile methodology. Things start getting a bit rough and messy when the complexity increases. All seems to work fine if the whole team is collocated at one place But the real challenges start in case of distributed teams. Day by day so many questions arise that will it work or not?, asking for trouble and many more. Certainly the challenges are more but how the team at both the sides can make it work and still work as one team. Lets try to go deep in a typical sprint in case of distributed teams and what all things the team can adopt to make it work.

The typical Scrum Meetings are:

  • Sprint Planning
  • Daily Stand Up meetings
  • Sprint Retrospective
  • Sprint Review.

Both collocated and distributed teams plan and execute these meeting in different ways, lets have a look.

Collocated Teams

The job of communicating and collaborating with in the team is easier. Being at once place helps more in planning and execution and reduces the waste in waiting and risk of mis-communication. Executing typical sprint in here is earlier than distributed teams.

Distributed Teams

As I said earlier, the risk is more but how the team makes it work is the charm and here we will discuss how by adopting few practices and evolving over time, you can make it success. Time difference between geographically separated teams is a big factor here. We will try to cover scenarios where teams are separated with some overlapping time difference and with no overlapping time.

  • Teams with some overlapping time difference (eg. IN & Europe):
  • Teams with no overlapping time difference (eg. IN & US):

Lets have a look how the distributed team sprint goes in both the cases.

Teams with some overlapping time difference (eg. IN & Europe)

Sprint Planning:

The Time difference here adds many hurdles to run it smoothly. The day at one place has just started where as on the other side it is about to be over. But good news is you still have some overlapping time period and the challenge is how you can maximize the use of it. Well and good if the product owner is ready for the distributed planning meeting and there is no language problem, may be that client is more comfortable in local language.

First part of planning meeting: Lets say the on-site team has the access to the client and comes up with the prioritized user stories after planning meeting with the client. By the time one team does the first part of the planning meeting, the other team can concentrate on any quality issues, documentation of previously finished user stories, technical debt improvements or any other project issues.

Second part of planning meeting: The whole team sit down together to break the prioritized user stories into tasks. The product owner is not part of this. The problem here may be that the time left to complete the meeting is very less on that day. Usually how much time is required for a two iteration sprint, couple of hours works fine. And another issue may be that other than daily stand up this is the only time when whole of the team is together, so it makes sense to do at least some basic design discussion here itself. So an idea is to break this meeting itself into two parts.

  • First part of second planning meeting: Estimate just enough user stories for both the teams to get started on that left over day and for half of the next day. Flexibility in planning which user story to pick and clarity etc. is all up to the team to decide.
  • Second part of second planning meeting: Do the rest of the planning meeting next day with a fresh mind and coffee. You can update the user story description for the basic design discussion but it should not store huge information like implementation details.

It looks a lot of meeting but do whatever makes sense and fits best to the whole team.

Knowledge Transfer: The on-site team working closely with the client usually have more exposure about what is happening. The challenge is how to get the other team up to the speed on the same. You can keep a track of all this information may be in tracking tool like scrum works. Update the user story description for the related information so that it is available to both the teams.

Team Composition/Scaling: Team composition and scaling is very important aspect of getting the things kick started and for the smooth run over of the project. Plan the team composition so that you have team members on both the sides having knowledge and active participation in all the modules, functionality and technologies in the project. Scale up the team in a uniform way and the responsibility lies with the team members to get the new members up to the speed in case of the team scaling.

Team Scaling

Daily Stand Up meetings:

Local stand up: To get the kick start, start the day with the local stand up. Do discuss the progress and any impediments with the team and if any local team member can help to resolve it. If there are multiple teams, you can plan for combined local stand up to resolve dependent user stories etc. but do keep in mind to keep the whole meeting short.

Distributed stand up: The distributed stand up is very necessary and it should happen during the overlapping time period, sometime in the afternoon in IN and start of day in Europe. Teams from both the sides join in here for the meeting. Use some video chat tool like Skype because face to face talk is better than voice chat or text chat. All the team members should be aware what the other team is working on and if there is any dependency. Do keep it short and if necessary you can have design discussion etc. separately with concerned team members only.

Distributed Standup

Status mails: To overcome the time difference and dependent user stories challenges, plan something which gives you somewhat clear picture that where the other left over the development, user story, query etc. so that the other team is well aware of it. Dropping a mail at the end of day is good choice or update the information somewhere on Wiki depending on what suits best to the team. Using project mailing list is a good choice.

Query or Impediment Resolution: Both distance and the time difference add to waste in case of query or any impediments if not looked at proactively to minimize it. Before wrapping the day have a look at the work left, what you can pick tomorrow or if there are any queries on what you will be working on tomorrow, drop a mail or let the scrum master know about it in advance so that by the time you start the next day you have the answers to those or at least the assumptions.

Separate offline discussions: Do keep the team meeting short so that you don’t waste or eat up others time. Every team member should be accessible to other team member by one or other way. Use some chat tool like skype where all team members are online all the time.

Separate design discussions: For design discussions etc. plan separate offline discussions and can ask the interested team members to join other than the required ones. And later you can share the information with other team members so that every one is on the same page.

Live cams: To make a feel of one team you can use live cams on both the sides with big screens displaying the other side team area view. It gives you different feel, give it a try.

Quality Check: Do keep check on the quality of the code regularly before it is out of hand. Assign a particular role to team members on rotation basis for the quality check. The person responsible will spend some time each iteration looking into the quality issues and technical debt in the project and if possible that person itself will fix it or will create an issue which can be picked up by other team members, may be while working on that piece of code or separately in coming iteration as a task. You can use bug tracking tool like jira to keep track of these quality issues also.

Knowledge Sharing: Collective code ownership is nice but what if not all the team members are on the same page for a particular technology or may be some functional area of the project. Knowledge sharing is very import pillar here. You can plan some knowledge sharing for this in each iteration and it will empower the whole team.

Sprint Retrospective:

Retrospectives are vital in any Agile project and are an integral part of the scrum process.

Do it regularly, don’t miss: The first principle is do it regularly, do not miss it. There may be that not all the team members having any point to speak about but still there may be some or once you start it people will start sharing or will come out with something interesting.

Get everyone involved: Sometimes the meeting revolves around few people only, few people speak a lot and few don’t speak at all. Plan the meeting in a way that everyone gets the chance to speak.

Try different flavors: To make the retrospective a bit interesting try out different flavors.

  • Good points, deltas and action items: Ask every team member to participate in it and ask for few good points that how did the last iteration go, what could have been improved. Start with good points to give the feeling that we are doing good.
  • Template: Multiple choice questions, how we are doing: Sometime some kind of template may work out asking for inputs that how we are doing, what do you think about the health of the project etc.
  • Free flow retrospective: You can try free flow meeting also like everyone putting their points which they want to discuss, works well if number of people is less.

Share MOM: Keep the retrospective information on common place which is accessible to both the teams, may be Wiki. The information may be any action item for a particular person or the whole team or points raised etc. It may be useful for the person who missed the meeting and goofed up something in the last iteration.

Voting System: Well, it is a bit hard to include all the points in the discussion otherwise it will go on and on. Collect all the points from both the sides, update Wiki and do the voting that only top three or four points to be discussed.

You need to be extra careful here that you try to resolve the distributed challenges here very well. The major issues come due to lack of communication, mis-communication, unclear things etc. It is the team responsibility to resolve these issues in best possible way which work well for both the sides.

Sprint Review:

Fare enough if both teams are there in the demo over some video conference etc. If not, the other team should get the update on the outcome, feedback or nice pics of demo.
Demo update: At the end of the demo the team present at the demo should send report about the demo. You can use any of the formats like dropping a mail or some kind of news letter. You can add few pics, last iteration updates or coming iteration updates etc. to add more spice to it.

Teams with no overlapping time difference (eg. IN & US):

The biggest challenge here is that there is no overlapping time period. To make it work either one side change the work timings, the team stays on both sides or only single person keep updates of the status etc. This causes less of the communication, more focused on single person perspective and later on mis-communication etc.

Sprint Planning:

You have no overlapping time here. A bit of proper planning is required to overcome the challenges.

First part of planning meeting: The team on client side does the first part of the planning meeting an does the prioritization of user stories with the product owner. To save the time one thing you can do is to take the pro active approach and start this in the last days of iteration itself for the next iteration. Share the information and let the teams internally discuss it first, will save the time later. Teams can post the queries in advance if there are any.

Second part of planning meeting: You need both the teams for this. Both the teams take part in the estimation process.

Task Breakup: Important point to take care here is to break up the user story into smaller independent user stories or into smaller independent tasks to reduce the dependency between two sides.

Integration/Regression Tests: To have integration and regression tests will help both sides. There may come the situation where one side of the team has not worked on one part which might affect the changes on other. It is valid in local teams also but the waste in resolving such issues in distributed should be minimized.

Code Freeze/ Branching: Plan the code freeze properly so that both the teams have enough time for the bug fixing. One option is to create a separate branch for the testing and bug fixes can go on on this branch which can be merged later in the trunk.

If required, do have some broad design discussions here as whole team is available at this moment.

Daily Stand Up meetings:

Local stand up: With no overlapping time both the teams start do their own local stand up to get the day kick started.

Distributed stand up: Well this is a bit tricky part in this case. It is very hard to get whole of the team daily available on both the sides, unless one team working in different shifts. The whole idea is to share the pain, sometimes the team on one side comes first and other team stays a bit late and other way. So, the usual solution that works is that one person may be scrum master on one side do the daily distributed stand up with the whole team on other side. The problem with single person for status update and query resolution is that he should be able to handle both technical and functional queries.

Full team meeting: Plan at least one full team meeting every week to handle whole team status updates, design discussions and any impediments. It is also important to keep up the one team spirit for people to know each other more.

Status update: Updating the other side of the team is very important here because of no online discussions between team members. Drop a mail or use Wiki for the status updates which is accessible to both the sides at all times.

Offline discussion: No offline discussions within team members based on different locations is the major drawback in this case. The wait period in this case is a big waste. You can use mails or Wiki for the offline discussion so that it is available for discussion later on during stand up if whole team is not there.

Design discussions: Drop a mail or update Wiki with your thoughts about a design to allow other team members enough time for a more effective session. The next day you can have a discussion about the same in the stand up or drop a reply for the same.

Build Breaks: Build breaks are a common thing and it is hard if the team on the other side who made the changes is not available. The approach should be to fix it if possible otherwise revert the failing code and let the other side to know about the changes. With collective code ownership and a healthly spread of knowledge and tasks across team members at all locations should not pose a major problem.

Knowledge Sharing: It is hard to have long knowledge sharing session here. But Wiki is good idea to share the information and to have short follow up sessions.

Sprint Retrospective:

No excuse but the whole team should be available here. The team need to figure out some common timings which works for both. Feedback to the single person of retrospective won’t fit much.

The fundamentals are same: Do it regularly, don’t miss ,Get everyone involved, Try different flavors, Share MOM and Voting System.

The single biggest problem that arise is to overcome the impediments like the communication gaps and it is more up to team that decide how to fill this gap.

Sprint Review:

Not possible to keep both teams are present in the demo. The option left is same to share the demo feedback and few other updates.


It is true that you do not need special skills to fail a project irrespective to location and process. Even the project implemented with co-located team can go wrong due to many reasons But in case of distributed teams it is more likely until and unless you face the challenges and find out the solutions which fits best for all.

Few things you need to take care of while implementing distributed teams is:

Easy and continuous access to all the development, testing, deployment etc. resources for both the teams all the times.

  • Source Code Repository
  • Continuous Integration Server
  • Staging Servers
  • Bug tracking tool like Jira
  • Confluence
  • Project Management tool e.g. Tracker/ScrumWorks

Set-up to enable team members communicate with each other on a regular basis for all major discussion events, video conference is preferred, like:

  • Sprint Planning meeting
  • Daily stand up
  • Design discussion
  • Retrospective and Demo etc.

Strongly preferred collocated teams during the project startup phase due to following reasons:

  • Faster and better understanding of Project context
  • Better overview of Application Architecture
  • Development and Deployment Procedures
  • Better personal understanding between Team members, bridging cultural differences and overall Team Dynamics


Well, these are the basic things that are backbone of the distributed development. And the things can go wrong at any stage and in any way. If the communication with in the teams is not strong, lot more problems will arise and blame games will start. If not handled properly the pressure to get it done will be more which in return will impact quality and will increase technical debt in the project. If there is no feeling of working as one team, things will start getting apart. If you do not have access to servers then it would impact your planning and would increase the waste and later on would say things are not working fine. So, start with these things and evolve the process over the period of time. The best part is that it is up to the team to decide how to make it work.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: