Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Scaling Scrum to Build a New-Technology Printer

Scaling Scrum to Build a New-Technology Printer

This item in japanese

When developing a high speed printer based on a new print technology things change often; you need an effective and flexible solution for managing a large project with many different disciplines. Océ Printing Systems decided to customize Scrum and scale it to enable collaboration and make progress transparent.

Christian Sack, software project manager at Océ Printing Systems in Munich, Germany, and John Kesseler, department manager for R&D, spoke at the Software-Centric Systems Conference about how they have scaled Scrum to build a new-technology printer with a big project team consisting of software developers, mechanical engineers, chemists, physicists and testers.

InfoQ interviewed Sack and Kesseler about the main challenges they faced in their project, how they customized and introduced Scrum, how electrical and mechanical engineers felt about working in an agile way, the benefits that Scrum has brought to the project and the R&D organization, and the challenges that they currently have and how they plan to deal with them.

InfoQ: What where the main challenges that the project at Océ had to face?

Christian Sack and John Kesseler: We had to develop a printer machine at the same time the print technology was developed. So many, many changes had to be managed during development. Also, we quickly had a very large team working on this project. A complex organizational task had to be performed. On top of that only limited test capacity was available on the printer prototypes.

InfoQ: How did you customize Scrum to suit your needs?

Sack and Kesseler: In order to decide on priorities across teams, we introduced a hierarchy of product owners. A panel of master product owners, in close contact with the overall project manager, helped out solving resource conflicts by setting priorities in requested functionality.

A good software architecture, dependencies to other non-software components and also organizational interfaces must mature in the minds of developers. We decided to adopt practices from scaled Scrum approach SAFe (Scaled Agile Framework). An newly installed software architecture team, build from product owners and software experts) to analyze the requirements well in advance and also schedule the architectural implementation.

The requirement analysis was performed in two steps. First, the requirements were discussed and the cost of implementing these epics was determined in a review. The costs were estimated in epic points. Epic points are comparable to story points and give the estimated effort relative to other epics. This created a roadmap over multiple releases. In the second step epics which should be implemented in the next release were broken down into user stories and then discussed in a separate user story review. In these reviews also the required skills were identified. This was a great help for the compilation of Scrum teams.

A mandatory checklist was created that provided help in coming to detailed descriptions of cost estimation, cross-relationships between epics, and verification with essential experts for both steps of the analysis. Only when all checklist items are OK, the Definition of Read (DoR) was given by the architect team. Only epics and User Stories that fulfilled the DoR were scheduled for the next release. This increased the quality of the backlogs and helped the Scrum teams a lot to come to predictable sprint results.

Soon it was known how many epics points in average each team could implement per release (epic velocity). The epic point estimates and the clear prioritization of epics by the master product owner, made it easy to plan a viable roadmap for about three releases covering one year. The transparency on the implementation of the requirements on epic level was highly appreciated by the overall project leader and became an important basis for decisions at main project level.

Besides these Scrum customizations as described above, there were still some other improvements, such as:

  • Introduction of a web based tool called JiraAgile, which supported Scrum-process.
  • Plenary sessions of all Scrum masters with the product owners to discuss project progress, for instance to get early resource bottlenecks on the table.
  • So-called one "Scrum free day" per week to do subjects not related to the current sprint goal, used mostly to work on technical debt or experiments.

InfoQ: Can you elaborate on the additional things you did besides the usual training and coaching to introduce Scrum?

Sack and Kesseler: We took the decision to pick technologists as product owners, since they had the best know-how of the required functionality. We trained 24 technologists to become product owner in the Scrum teams.

At the beginning, the newly trained Scrum masters lacked experience in handling issues in the Scrum teams. For instance, they found it difficult to solve conflicts in the team. We decided to give them additional training on moderation, presentation, communication and conflict management. This helped; we saw that they became more effective in their new role.

InfoQ: You mentioned having electrical and mechanical engineers in the Scrum teams. How did they feel about working in an agile way?

Sack and Kesseler: At project start there was resistance against Scrum, but that decreased swiftly after the introduction; the non-software disciplines felt that Scrum facilitated them to work in an integrated manner with the software people (and vice versa).

InfoQ: Which benefits has Scrum brought to the project? And to the R&D organization?

Sack and Kesseler: Scrum improved the co-operation and communication between the technologists, the software engineers and the colleagues of quality assurance. The Scrum teams had representatives of several disciplines. We noticed that teams felt in charge of solving problems instead of doing finger pointing.

Since each scrum team had a quality assurance member, test requirements were fed in to the team from the start. This significantly increased delivery quality and long quality test campaigns at the end of development were avoided. Even the duration of the integration or system test was shorter and it became more predictable. The release planning reliability increased a lot.

The burn down reports greatly helped in making the progress transparent. Also project bottlenecks and project plan deviations from the project plan became better visible.

InfoQ: What are your current challenges with agile and how do expect to deal with them?

Sack and Kesseler: Due to the high costs of prototypes, having only very restricted hardware is always an issue in our projects. So teams will compete for required test hardware. Again and again it happened that teams could not test their software on time. We deal with this challenge by investing further in simulation and test automation. And in some cases we allow parallel working, so teams do not affect each other. This latter strategy only works if there are no dependencies between functionality build in the same sprint.

Due to the Scaled Scrum success we will plan to implement Scrum also to other projects, depending on the size we will scale. Where needed, we will add some new specific adaptations. And we need to integrate the Scrum roles with our existing project roles to minimize overhead.

Rate this Article