InfoQ: Case study: Distributed Scrum Project for Dutch Railways - The Diigo Meta page

• 12 Mar 11
  

  Sergio Yazyi

  virtualteams distributed development management scrum

• 30 May 10
  

  kkarank_2012

  Case Study in using SCRUM in a delivery scenario-Dutch Railways

• 16 Sep 08
  

  Alexandre Marcondes

  projectmanagement_agilecases

• 20 Aug 08
  

  Mairon Croes

  From site: "In this article, we describe how we successfully executed a large (20 man-years, 100.000+ lines of code) Scrum project, one which had already been scrapped once under a traditional approach, and which included developers in both India and the Netherlands."

  netherlands scrum management articles guide casestudy development planning carreer work tdd architecture tipsntricks

  • We applied automated testing during the project to allow us to deliver tested software at the end of each Sprint, without regression bugs. Even as the system grew we managed to do this with only one tester per eight-person Scrum team while maintaining high quality: the external testing team found less than 1 defect per KLOC.

      

    We automated tests on two levels: unit tests and acceptance tests. For the former, we used JUnit and measured code coverage using Clover, using a target for server-side code of 80% coverage. Acceptance tests were automated using FitNesse. For every implemented user story, a set of acceptance tests was written in FitNesse. Having an extensive test suite, regression bugs were usually found and fixed during the Sprint. Another advantage of this approach is that the testers can be effective from the start of the Sprint, creating test cases before the user story is implemented.

     

    There was one area where we struggled with automated testing. Part of the system was an application with a complicated rich user interface. Automating tests for this proved to be harder than automating server-side tests. Therefore we largely depend on manual testing for user interface-specific functionality. As the system grew, regression testing took more and more time. Even worse, external testers found regression bugs only in this part of the system. Having automated tests could have prevented this. The lesson learned is that, even though automating tests may sometimes be hard, it will pay off when it counts, late in the project.
  • Thanks for sharing your success story. I have a doubt about scrum approach. When a sprint is completed and at the end still there are some bugs which could not be fixed during sprint period, these bugs will be items in one of next sprints based on priority; what happens to the output from previous sprint? Is it deployed with accepted bugs or it is held back till the next workable output? I understand that low priority bugs might not prevent feature release but what approach is taken for feature release which has still some critical/major bugs pending resolution?
     Which techniques did you use for estimation?
     If there is considerable difference in high level estimation done at the time of story writing (product backlog) and planning poker during sprint planning, what approach would you suggest? Thanks in advance. I ma learning to use Scrum :)
  • > happens to the output from previous sprint?
    
    Good question! In a Sprint demo, bugs should be revealed and the customer or product owner should be asked: do you accept this story/feature as done? They are the ones who get to say whether this code should be released or not.
    
    Of course, it would be better to have this discussion during the sprint, so the team could respond - by rolling back that work, or getting approval from the customer to keep it in as it is.
    
  • By the way, Ranjeev: you might find that the ScrumDevelopment or LeanAgileScrum yahoo groups are helpful places to get answers to your questions and have discussions with experts, as you continue to experiment and learn.
  • Hi Milan. Our technology platform is Java, Spring, Hibernate, WebLogic, Oracle, Swing (UI) and Flex (for the displays). Our continuous integration tool is Bamboo.

  3 more annotations...

• 17 Aug 08
  

  ken .

  Nice write up of a Dutch agile/scrum project - traditional requirements/waterfall cancelled after three years - bringing in scrum master, team building (comm'n, coop'n) - simple social technology (skype/wiki) - estimating user stories, testing (and ups fo

  agile communication cooperation development holland india management process project scrum software story teamwork technology testing wikis

Would you like to comment?

Join Diigo for a free account, or sign in if you are already a member.