Swiss Postal Services has used scaled Scrum with seven teams to replace a legacy system. Ralph Jocham talked about their experiences with scaling Scrum at the Agile Greece Summit 2015 in his presentation on 10 Months, 7 Teams, 18 Apps - Scaled Scrum at Swiss Postal Services.
InfoQ interviewed Jocham about how they scaled Scrum and dealt with legacy issues, using a definition of done, how they managed to deliver their system three months earlier than planned, and the main learnings from the project.
InfoQ: Can you describe how you scaled Scrum to work with multiple teams?
Jocham: Scaled Scrum should still be Scrum at it’s very core, based on empiricism and self-organisation. Scaling is all about managing dependencies, to make sure that the right information is at the right location at the right time. For this Scrum needs to be augmented with additional exchanges between the various teams. As a minimum you need to address architectural concerns, crosscutting features, and quality. Most importantly you have to make sure that at any given moment during a Sprint you have a releasable increment - only then your are "Done" with no work remaining. For this to be possible you need to work towards continuous delivery as continuous integration doesn’t cut it anymore.
At Scrum.org we’ve developed the NEXUS framework (see Scaled Professional Scrum and NEXUS), which exactly addresses these points. With scaling there is not one single answer, don’t relapse into the method trap as many scaling approaches do. Even at scale you still need to be empirical, and build on self-organisation. Let the right approach emerge.
InfoQ: Scrum was used to replace a legacy product. Did this pose additional challenges for the teams?
Jocham: The existing system was getting really old. The software was a WindowsCE application, the hardware was not supported anymore. Even though the system was still functioning it had to be replaced.
Did it pose additional challenges? Well, we had to make sure that the new product covered all required functionality and that it would be happily absorbed by the current user base of over 22000 people. Over the years quirks became features. So we had to watch out for usability. However this wasn’t a challenge in itself as we engaged with the end-users, and asked them for their input from a very early stage. They were engaged from the initial creation of the Product Backlog items. Through continuous refinement the items were made ready. This included UI wire-frames and clear acceptance criteria as a minimum. The empirical feedback loop was closed through bi-weekly Sprint Reviews.
Personally, I don’t treat the replacement of legacy systems different from new product development. In the end it is all about maximizing value (outcome versus output) and happy clients or end-users.
InfoQ: Did you tailor Scrum to handle the legacy issues?
Jocham: In the Scrum Guide the refinement process is described as the following: "Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items."
Since we invited final end-users -- postmen -- into the refinement, we did change Scrum. But this was on a very detailed level. Doing this our end-users quickly saw the benefit of Scrum with its empirical feedback cycles and embraced it. I guess the short answer would be "No, we didn’t tailor Scrum" as the refinement is not an official Scrum event.
However we augmented it with additional exchanges (workshops based on CDE - Container Difference Exchanges, influencing self-organisation as described in Facilitating Organization Change: Lessons from Complexity Science by Glenda H. Eoyang, 2001) between the Development Teams. Those exchanges were put in place for dependencies of features, architecture and testing. Since Scrum is a framework, adding practices and elements is perfectly fine and actually intended.
InfoQ: Can you describe your Definition of "Done"?
Jocham: The Definition of "Done" is mostly about quality, maintainability and enhance-ability. This was a large project with at its peak around 100 people involved. From the beginning we made sure that, as soon as the devices would be rolled out and the product would go into maintenance mode, the teams after us would inherit a self-testing system for both aspects of quality: validation and verification.
We had a 90% test-coverage on all business logic functionality and for each business scenario an UI-test based on Selenium in the browser and Appium on the Android device. It is true that high test coverage does not guarantee quality, however, high quality is often obtained with a high test coverage. All this together allowed us to know for sure whether our product was "Done" or not.
Apart from the mentioned quality aspects we also had the usual coding standard compliance checks, up-to-date documentation of the realised requirements, test-cases, software architecture, and interfaces.
Last we made sure that the product was internationalised as in Switzerland it had to be in three languages: German, French and Italian.
InfoQ: You managed to deliver three months earlier. Can you elaborate what was the success factor that made this possible?
Jocham:They were three things:
1. Requirements: We were agile with our requirements. The one legacy program was broken down into many smaller apps. This allowed us to focus on one thing at a time, work in parallel with seven Development Teams, and mitigate feature risks. The number of apps changed from 20 to 33, down again to 18 to finish at 22. The exchanges for features we added on this project led to the creation of many reusable components.
2. Quality: It was a top priority from the start and not an afterthought. Quality was enforced through test automation based on a powerful build pipeline, and a continuous integration of all developed functionalities. In my opinion, if testing happens after development or even later, it is not about quality anymore but about stability.
3. Transparency: It was ensured through honest hard work with (close to) no politics. We continuously assessed our situation on all important aspects and had a fast acting risk mitigation approach. Every two weeks we took action based on the data we could inspect. Trust is key for this to be possible.
InfoQ: Can you share the main learnings from this project?
Jocham: Nothing is "Done" until it is really done and this goes all the way from the UI to the last corner of the back-end systems. Don’t ever expect that something promised will work. Demand that all functionality is integrated from the early beginning. Be "Done" from the first Sprint, don’t postpone it until later as it will haunt you.
InfoQ: If you had to repeat the project once more, what would you do differently?
Jocham: We did have some assumptions about the back-end systems, how we would connect them and how they would work and perform. In many cases these assumptions were wrong and turned out to be tripping wires for us. Luckily we had our automated tests, which saved us a couple of times. In future projects, I would insist that "Done" also includes the back-end systems. I would go as far as putting back-end developers in each Development team.