Handling Scrum-based software development in distributed teams isn’t easy. In fact, no matter what kind of distributed team, some of the mandatory Scrum ceremonies can be difficult to handle if you are not sharing the same office. To give you an inside about how we work, it is important to understand our setup.
We have two teams: one team is mainly responsible for development (of mainly Java-based web applications). The other team is gathering requirements from the customer, provides feature definitions on a detailed level, writes user stories, defines acceptance criteria and assures the development quality (that’s us, located in Berlin). We’re also responsible for development operations, for example the provisioning of servers.
Maybe this situation is a bit unusual within the outsourcing context but it has its advantages. The dev team is supported by a team for architecture, QA and DevOps. We make sure the responsibility for implementation details stay where they belong: in the dev team. Whenever one team is specifying a feature, it will also be responsible for the QA part. This gives a direct feedback on how well you defined your user stories because the result will end up as code on your desk again. Once the implementation of a feature is done, our team has to assure that the functionality we defined is satisfying the customer.
The biggest challenge within such a setting is that both teams need to have the same understanding on how, why and when deliverable artifacts are completed. Both teams operate in two different companies, which adds to the complexity of the setup. Generally, at least nowadays, waterfall is mainly used in such a setup. We decided to use Scrum instead. The question is: how to handle Scrum ceremonies efficiently without visiting the dev team too often?
First - the daily standup: with a bit of practice, it can easily done via Skype or similar voice chats. We use TeamSpeak for quite a while because of its low network bandwidth requirements which becomes handy if some of the teammates working at home. On top of this, it reduces background noise if Push-to-talk option is enabled.
Second - sprint retrospectives: let’s differentiate between internal and external retrospectives here. Usually it’s a good idea to have a retrospective inside each team first before starting the big challenge. This helps the team to focus on problems and find solutions on the operational level. Coping with the daily little differences inside a team (yes such things exist in the real world as humans tend to insist on their opinion and the professional experience level differs among the team) is eased that way. Additionally, we do cross-team-retrospectives where all team member participate (in our setup this means approximately 8 people joining it). To minimize the traveling cost, a communication channel like Skype is necessary and at least a tool to visualize the input of the team during the meeting.
Searching the web for such a tool, we ended up with Linoit. Personally, I think it is doing the job, but there is room for improvement as it isn’t designed for Scrum retrospectives. There are multiple ways on how a retrospective can be done. You may have a look here and here.
Third - Sprint planning: let’s assume for simplicity we already have a filled Scrum backlog. However, there is one thing missing: estimating the effort of every particular user story. We spent hours at the very beginning of the project in estimation sessions. We recognized that estimating in that way doesn’t lead to success. To be more concrete: the hours developers estimated weren’t accurate. Moreover, it turned out to be difficult to find a general tendency across all the issues being estimated. The estimations told us nothing. In fact, we committed a common Scrum fallacy: estimating in hours. Story points give you the impression to be very mysterious. One main advantage is that the number of choices per issue are limited (there are different story point scales to be used - we stick to Fibonacci as the bible suggests). We experienced that developers get a much better feeling for relative complexity than for absolute
If the author of a user story sits far away from the development team, how do you do that in practice? You know the answer already: use a tool. There are a few that may fit your environment like Agile Poker for JIRA which is quite expensive. Online tools like planningpoker.com or hat.jit.su are for free.
Hat.jit.su is the best bet as it is easy to use in combination with an active voice channel. The JIRA Rapidboard is our tool to organize the sprints and this is the point that was annoying us: the missing JIRA connector to push back the story points estimated. Wouldn’t it be great to have it? Just connect to a site without providing any credentials, and see the task to be estimated by the team one by one. Once the team agrees on an estimation, the Scrum Master just commits the story points to the issues organized in JIRA? Let’s see what we can do.