Case Study 11-1

Information Displays at Dutch Railways (Nederlandse Spoorwegen)

Each day, over 650,000 passengers complete on average 1.2 train journeys on Dutch Railways (Ned-erlandse Spoorwegen). It is important that these passengers have the most current information about train arrivals, departures, and connections in the network. That was the reason that Dutch Railways, which prides itself on its trains mostly running on time, decided to build a system to provide travel information to its passengers in all Dutch train stations. Train departure times were stored centrally and updated with information entered manually or by sensors in the infrastructure. Dutch Railways decided to outsource the contract for building the system to an Indian company. The requirements for the new system (called PUB for publish) were handed over to the outsourcing vendor that was expected to use the waterfall method and little customer involvement. This approach didn't work and after three years, the contract was cancelled because of vendor inability to deliver a working system. Dutch Railways decided to outsource againbut this time to Xebia, a vendor that would use Scrum to build the system in close cooperation with Dutch Railway personnel. The PUB project was part of a program that involved many other related software projects to build an implement the displays in all stations across the Netherlands.i

Given the problems that Dutch Railways had previously experienced with outsourcing, Xebia decided to have a three-week kick-off with a project manager, system architect, and Scrum Master to make sure that everything was set up correctly before the sprints started. But the problem of identifying a Product Owner became immediately apparent. Ideally, the Project Owner should be someone who has the necessary time, business knowledge, and authority to prioritize requirements. Lacking such a person, two Product Owners were appointedbusiness analysts who had been involved in the earlier attempt to build PUB. Unfortunately, the Project Owners did not know how to write user stories, so the Scrum Master helped them produce the initial product backlog with user stories to get started.

One seven-person Scrum team in the Netherlands started the project by agreeing on norms for working together and providing rough estimates for how long it would take to complete the required functionsestimates that would be used to communicate progress on the release burndown chart. The project estimates were especially important because the project needed to meet program deadlines. Two Indian developers joined the Scrum team in the Netherlands on its third iteration (as soon as immigration and logistical constraints allowed them to do so) since it was known that Indian scrum teams soon would be added to the PUB project. The team in the Netherlands worked in two-week iterations called sprints. The early iterations allowed the teams to build, test, and demonstrate user stories at the core of the system, greatly pleasing the client, Dutch Railways.

After the fifth iteration, the two Indian developers returned to India and were joined by engineers to form two full Scrum teams. Eventually, there were three distributed Scrum teams, each with their own tester and with both Dutch and Indian teammates. The teams used daily Skype sessions, regularly scheduled travel, a project news gazette after every iteration, and informal updates by the Product owner to communicate with one another and share knowledge. Their tools included Scrum-Works to manage the product backlog and sprint backlog electronically, burndown graphs posted daily to a wall of the team rooms, and a computerized whiteboard. Pair programming was performed only with co-located pairs. A local Dutch Scrum team was created to deal with team barriers and perform specific customer facing compliance activities such as writing documentation in Dutch that was compliant with the waterfall documentation approach that Dutch Railways wanted to maintain and discussing requirements with technical stakeholders.

The Scrum Master had to modify the typical two-part Sprint planning meeting because the Product Owners wanted to speak Dutch. So, in the modified first part, the Product Owner clarified the user stories and set the priorities without the Indian team members being present. Then the second part was conducted in English over Skype without the Product Owners. The information from the first part was communicated to the Indian teammates in the second part and tasks to complete the user stories were identified and estimated.

Dutch Railways was pleased with PUB when it was delivered: 100,000 Lines of Code reflecting 20 man-years of effort over a period of eleven months. Unfortunately, the nation-wide deployment was hindered by other projects in the program that were not completed as planned. It is hard to say that the PUB project was delivered "on time" and "on budget" since required functionality, deadlines, and budget shifted during the project. However, during these shifts, project success factors were discussed with the client. An external audit company concluded: "The maintainability of the systems is very good; The quality of the source code is very high."

Discussion Questions

1. Compare the development methodology employed by the Xebia PUB project with the waterfall (Systems Development Life Cycle) methodology? Was the Xebia PUB project approach a good approach? Provide a rationale for your response.

2. Describe some of the possible reasons that Dutch Railways selected Xebia as the outsourcing vendor to build PUB. (See Chapter 10 on outsourcing.)

3. Describe the challenges of using distributed Scrum teams. How effective do you think were the changes made to typical Scrum practices in the PUB project in addressing these challenges?

4. Discuss how program management differs from project management. Which is more difficult? Provide a rationale for your response.

5. Assess the PUB system that Xebia developed using the four dimensions of project success. How successful do you think this project is?