Case Study of Mobile Team at Projectplace


I am currently working as a Scrum Master for multiple teams at Projectplace in Stockholm, Sweden. One of those teams is the Mobile Team. They are developing Action Boards for both iOS (iPad) and Android platforms. These Action Boards are also available in the Customer Preview of the Projectplace web service. Both Web Team and Mobile Team share the same API’s. The iPad app is planned to be released in 2-3 Sprints from now.
This case study can be written from many perspectives, but in this article I am going to focus on how we are working with the challenges of having a distributed Scrum team.

Stockholm & Bangalore

Projectplace is currently in process of starting their own office in Bangalore, India and have already engaged a number of very talented developers and testers there.

The Mobile Team is “under construction” and has a mix of consultants and employees, distributed geographically in Stockholm and Bangalore. Working in and with a distributed team comes with some challenges.

Challenges of working with a distributed Scrum team

At Projectplace, we’ve identified the following challenges of working with a distributed Scrum team:

  • Hard to get a personal connection with people far away and in a different culture.
  • All meetings require the use of some technology to be efficent.
  • Participants need to speak fairly good english.
  • Working in different time zones gives us fewer hours of the day when we can collaborate.
  • Simple Post-it notes for visualizing progress and tracking tasks doesn’t work so good.
  • Some impediments can be difficult for a Scrum Master to handle from a distance.

How we tackled the challenges of working with a distributed Scrum team

  • When the team was created, the Indian part of the team came to Stockholm to work together as a big team for an extended period of time. A big team room was arranged and all team members worked together on user storys for a couple of Sprints. We focused on getting to know eachother and Pair Programming between swedes and indians was strongly encouraged, tracked and visualized. (So noone could hide. ;-)) A special “team startup” retrospective was held with focus to improve collaboration between team members.
  • We use Polycom video conferencing or Skype for our Sprint Planning, Daily Scrum, Demos and Retrospectives. Usually “Polly” for longer meetings and Skype for Daily Stand-ups.
  • All team members at Projectplace are proficient in english, but we still have technical discussions in our native tongue when needed.
  • We have discussed pushing the standard working hours in order to get more hours together, but no action has been taken on this yet.
  • The white board and sticky notes for issue tracking has been replaced with a Jira + Greenhopper combo. The choice was simple because other parts of Projectplace were already using Jira.
  • We are going to employ a local SM in Bangalore.


All the efforts above are all good and well, but I still believe that a team should sit together. So, in the long term, we will try to split the Mobile team into two teams, one in Bangalore and one in Stockholm. This will have the following advantages:

  • Meetings will be shorter
  • Everyone can speak their native tongue
  • When a team member wants to talk to another team member, he can just stand up and say “Hey you, Stinky” (or the indian/swedish equivalent) instead of having to wait until Stockholm/Bangalore working hours and then fire up a Skype call only to be interrupted by a shaky Internet connection or any other technical troubles.
  • Team members can collaborate on simple white boards instead of having to resort to other inferior tools.

The idea is that both teams will work on the same products, in the same code base. They will have seperate Sprint Backlogs, but will take them from the same Product Backlog.

But before we can do this we need to make sure the team wants¬†to split. They need to feel the pain. They need to trigger the change because they want to, not because some consultant Scrum Master got a silly idea. ūüėČ

And before a split can be successful, we also need to make sure both teams have all the roles needed to complete user storys on their own. Otherwise we’re just building a mini-waterfall process of inter-team dependencies. Another word for this is “cross-functional teams”. So, some people will probably need to be hired. If you want to join this great team – look out for Projectplace job postings in Bangalore and Stockholm!

3 responses on “Case Study of Mobile Team at Projectplace

  1. Hi Max
    This is an interesting post and I am sure you are in the right direction.
    I really like the approach on “need to make sure the team wants to split” and you are truely making a self organizing team.

    All the best

    Cipson, CSM, PSM – I

  2. Very good sum up Max!

    One interesting point that I got from the Bangalore team is that they do not think the time zones matters. They told me that they are very used to work with abroad projects. So the Bangalore team are more adopted to work in conditions that the Sthlm Team (sometimes) faced as problems…? Or at least the Sthlm Team could say it out loud when they thought it was a problem in order to solve it. And the Bangalore team could not say it in the same way because of cultural difference..? These are just some thoughts I was thinking of when reading your post.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.