Dutch Railways had a problem building a travel information system for 1.2 million passengers daily. Let’s look at a case study and how scrum helped resolve the issue.
Introduction:
Teams and organizations newly introduced to the Scrum framework may have questions such as
-
Is it better to outsource the project or execute it internally?
-
How are requirements managed in Scrum?
-
What will be the structure of the team?
-
Are multiple locations possible for the team?
This case study helps answer many of these questions.
Problem:
Dutch Railways is one of the busiest transport providers in the Netherlands. 1.2 million passengers use its services every day. This case study provides an overview of how the Dutch Railway automated its manual travel information system with Scrum. The project was originally scheduled to be undertaken by an IT vendor using a waterfall approach. Following three years of failed attempts, Dutch Railway hired another vendor that implemented Agile methodologies using Scrum. This company successfully built the automated PUB system. On the PUB system, travelers could view real-time information on a display screen and hear audio broadcasts at all stations. They explained how they organized a distributed team (India / Netherlands), identified the right product owner, kept effective communication, and documented the project using scrum.
Planning and Estimation:
The project started with 7 members of the scrum team working together in a 2-week sprint. As a first step, they created a working agreement and shared it on the Wiki. This is essential to form a coherent and productive team. The second thing they did was to bring in 2 of the developers located in India to work on-site for 6 weeks. The onboarding team and developers with the scope of work and clarity helped the scrum team to build, test, and demonstrate at the end of the first sprint. Additionally, release burndown charts were used for estimation.
Value of a good product manager:
Due to the project manager’s busy schedule, Dutch Railways had some difficulty setting up sprint planning meetings. As a result of his absence, they experienced delays in setting up priorities and scope. From this, they learned 2 things. First how critical it is to have a person who has the final say to be present at the sprint planning meeting. Second, the essence of a capable product owner for the scrum team. They hired 2 product owners and made 2 scrum teams with 5 developers and 2 testers. Although, the product owners hired did not have any experience creating a product backlog. However, they were able to create one with their prior knowledge of the PUB system and with the help of the Scrum Master.
Organizing Teams:
Managing a multi-location team
The key to success was to have team members spread across multiple geographical locations with different time zones working together. Their communication tools included Skype, a webcam, a headset, a microphone, and a large screen. Pair programming was encouraged, but only if the developers were at the same location. Team members used ScumWorks as a whiteboard tool to track sprint progress.
Separate Team to Focus on Non– Functional Requirements.
In order to complete the project, the scheduling system application (PUB) had to work on the existing Dutch Railway IT infrastructure. Rather than assigning the logistics to the scrum team, they formed a separate architectural team to do so. The Scrum team focused on making the PUB system work and let this new team take care of the architectural part namely security, logging, performance, availability, etc.
Documentation and Testing:
Documentation:
The product owner hired previously worked as a business analyst for the previous failed attempt to automate the system. Although they had knowledge and detailed requirements documentation available. Dutch Railway required all documentation to be MIL standards and written in the Dutch language. They hired technical writers for this rather than burdening developers and testers with translating everything into Dutch. Although they had some communication challenges between the scrum team and the technical writer, it turned out to be a valuable asset for developers, especially testers.
Testing:
Each 8-member scrum team was assigned one tester. They found automating the user interface was much more tedious than automating server-side tests like unit tests and acceptance tests. For unit tests, they used JUnit and measured code coverage using Clover. For acceptance tests, they used FitNesse. Initially, they tested the user interface manually, but as the system grew, they realized manual testing was time-consuming especially when it came to regression testing. They also found regression bugs when they did manual testing. It is challenging and tedious to automate tests, but the benefits outweigh the challenges. Additionally, an external testing team found fewer than one defect per KLOC in the system.
Outcomes:
The software was built as part of a much larger program that involved multiple software systems and the installation of display monitor at multiple stations. Scrum helped them orchestrate this multidisciplinary effort. In small iterations, the team kept track of the project’s progress and stayed on budget through regular communication with the client about every success factor.
Sometimes it is very difficult to find the right product owner. In Dutch Railways case, the product owners were business analysts with prior knowledge of the requirements. Nonetheless the Scrum Master helped the Product Owners to refine the product backlog.
A working agreement shared by the entire team helped build a strong team. In Retrospective they updated the agreement based on the feedback. Making use of free communication and collaboration tools also helped them share ideas and kept the cost down.
Source Link: https://www.infoq.com/articles/dutch-railway-scrum/
Additional resources:
What is the difference between a Product Manager and a Product Owner
Staying on track during a remote Daily Scrum when communication is challenging.
Scrum, Product Management, and DevOps: Simplifying the jargon
The internet and social media are full of Agile, Scrum, Product Management, and DevOps jargon, including incorrect and misunderstood concepts. This could be problematic for a learner seeking knowledge. Without a course with Scrum Alliance, Scrum.org, or DevOps Institute, this knowledge is difficult to achieve.
