Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Why Scrum is Not Enough

Why Scrum is Not Enough

This item in japanese

When developing large complex systems and dealing with legacy code, organizations need to have systems in place to support integration and delivery. Modularization can help when agile is scaled with multiple teams that are working in parallel. It’s not the framework or method that will do the job, but how your people will make it work to solve your problems says Hans Dekkers.

The Bits&Chips Software Engineering conference which was held on June 3 in Eindhoven, the Netherlands consisted of three sessions: Scrum is not enough, boosting the delivery train and model driven software engineering in the real world. Hans Dekkers, head of the lecturer group Institute of Informatics at the University of Amsterdam and independent management consultant chaired the first session:

Scrum works very fine within small teams, adding new functionality in an incremental way. But how to transform traditional developers into a scrum way of working and how to align the multiple teams? How to maintain piles of legacy code? And how to go about solving the specific issues the high tech industry has with Agile? The session "Scrum is not enough!" will give an overview of these challenges and presents best practices to address them.

InfoQ interviewed Hans Dekkers about why Scrum is not enough, the challenges of legacy software and how to deal with them in an agile way, scaling agile and combining Scrum with other frameworks.

InfoQ: The session that you chaired is called "Scrum is not enough!". Why did you pick this title?

Dekkers: Scrum really puts the development team at the center of operation, and ensures that they have frequent delivery and feedback cycles. It leaves a lot to the teams to decide.

We know that the performance of software projects depends to a large extent on the fitness of the architecture. For many projects the number of engineers. has to be scaled up We need to achieve goals that overstep the boundaries of sprints. We have to make good trade offs between different stakeholders. There needs to be good interaction design, based on researched data from users. We need to have systems in place to support integration and delivery.

In most companies Scrum is embedded in a larger organization (process, culture and systems) that ensures good performance. In this session we explored how this is done, which options we have and what the trade offs are.

InfoQ: In stead of having individual talks, the program of this session consists of discussions on a specific topic with speakers from different organizations. Why this approach?

Dekkers: The goal is to focus on a challenge: a well defined problem or ambition. The overall streaming is that the first speaker introduces the challenge in his context. He discusses what has been done. The other speakers analyse this challenge and propose solutions. This is based on their own experiences, or comes from research or from consultancy. We want to show the different aspects of such a challenge, present different options, and engage the speakers and attendants in a stimulating discussion.

InfoQ: One discussion was about dealing with legacy software. Can you mention some of the main challenges that organizations are facing?

Dekkers: Legacy software is all around us. Most projects work in this context. In an environment with a lot of existing software, the organization has to work within these constraints. One big challenge are so called God components: all user stories, require changes in that component. Another one is how to organize your regression testing, your continuous build in a complex software environment. We see that to become more agile, it is often not just a matter of process changes, but significant changes to the software infrastructure are also required: how to organise for that?

InfoQ: Do you have examples of organizations that are using agile approaches to manage legacy software? How do they do it?

Dekkers: ASML told about how they are using a process with elements of Scrum to work in their software environment. We have seen the successful completion of the project of Port of Rotterdam to phase out their old legacy system, using a Scrum based process (more about this in the InfoQ article HaMIS: One 24/7 Product and Four Scrum Teams, Four Years Later).

Also Philips and ABN AMRO are adopting more agile methods, in an environment highly dominated with legacy code. ABN AMRO mentioned that there is no difference in how they are doing Scrum for new development and for maintenance of legacy code anymore now that, they are using DevOps teams.

I feel that investments in DevOps and software renovation, are important pre conditions for success. Scrum builds upon teams that have a clear contribution to the end goal of the customer. If the teams are organized based on components and the relation between the user story and the work that needs to be done in that component is not self evident (no clear API), then one of the core ideas of Scrum is seriously impaired. Then we need some overall coordination mechanism that typically involves planning: pre specification, and in the end integration testing. The whole concept that the team can come up with new designs during the sprint is seriously constrained. You now can only do some sub optimization, and as systems theorists has shown us, you should always try to focus on optimizing the whole.

Also the ability to learn plays a vital role in Scrum. The idea is that after the sprint the product is ready to be deployed. For this we need feedback during the sprint, about how our work integrates. If your environment does not support this, then your ability to learn and to respond is again diminished.

InfoQ: Another topic that was covered is agile scaling. Can you name some of the approaches that organizations are using to address this?

Dekkers: For scaling in the sense that multiple teams work in parallel I would say that the first and foremost strategy is modularization. Have an architecture that reduces dependencies between teams. Still there will always be coordination issues that require upfront coordination, and integration and coordination during the Sprint. An extensive framework that allows you to organize this is, is the SAFe framework. This framework provides organizations the opportunity to assure that the work in the different teams meets all kinds of regulations and requirements. At the other side of the spectrum is the Nexus framework by Here the essence is that the organizational structure facilitates developers by institutionalizing a form of Scrum of Scrums.

InfoQ: Do you have a final advice for organizations that want to combine Scrum with other frameworks or methods?

Dekkers: Always look at your own problems, and it is not the framework or method that will do the job, but how your people will make it work. Make sure you do what works for you. Be open, experiment, learn, improve. Take a critical, yet constructive approach.

Rate this Article