07-07-2012, 01:01 PM
Case study: Distributed Scrum Project for Dutch Railways
Case study.docx (Size: 313.29 KB / Downloads: 33)
Background
The Dutch railways are among the most heavily used in the world, providing transport for 1.2 million passengers daily. Dutch Railways built a new information system to provide travelers with more accurate travel information, requiring less manual intervention. As part of this program, we built the PUB (publish) system that centrally controls information displays and audio broadcast systems in all stations.
Setting the stage
We started the project with a project kick-off to set up everything that is needed before the first sprint starts. This 3-week kick-off was done by a project manager, an architect and a Scrum Master.
The selection of a Product Owner proved to be a challenge. We could not find a single person that had the time, domain knowledge and the mandate to prioritize requirements. We nominated two business analysts to fill the product owner role. They could be made available and because of their involvement in the earlier attempt to build PUB, they had built up a lot of business knowledge to be good proxy Product Owners to several groups of customer stakeholders. High level decisions about priorities and scope were made by a project manager mandated by the customer, but who had limited availability and less detailed knowledge about requirements. In general this model worked well, but on some occasions the project manager changed the priorities that had just been set during the planning meeting (ini his absence) and the meeting had to be redone. Ideally, the person with the final say about priorities should always be present at the sprint planning meetings.
Scaling up to distributed teams
After the kick-off, the project started off with one 7-person team working in two-week iterations. From the start of the project, it was planned to scale up using people located in India. For this reason, two Indian developers joined the project from the first sprint onwards. They worked on-site at the customer site for 6 weeks to become familiar with the application domain, key customer representatives and the rest of the development team.
One of the first steps towards becoming a team is to agree on how to work together. To facilitate this we held a norming and chartering session [3] with all team members, including our colleagues from India. In this session we decided on practices like how to do pair programming, use of tools, quality targets, core hours etc. and recorded them on a Wiki page. Having agreements which are shared by the whole team proved very useful to us. When changes are made to these agreements, for instance during a retrospective, the practices should be updated so they are up-to-date when new members join the team.
In the first iterations, the team proved to be able to build, test and demonstrate user stories that formed the heart of the system. This pleased the customer, especially because - compared to the previous attempt - progress was demonstrated much sooner and the customer had more control over the course of the project.