One Hundred Sprints - How Did Scrum Perform?

Don't misunderstand there are many good reasons for agile software methods; but there's also a lot of bad reasons. My impression is that agility is firmly part of the project liturgy and is not critically questioned whether it is necessarily needed or not. How much agility does the development of a standard software with fixed release cycles and a fixed release plan need? I'll answer this question with the experience of 7 years of Scrum process in our development team Publishing Server.

Seven year ago, we replaced our Chief Developer method with the implementation of the Scrum method, which is known as a widely used agile development method. In the Chief Developer method, the most experienced developer leads the team both professionally and disciplinarily. New requirements were established and implemented quickly and efficiently. So why did we introduce Scrum in the first place? It wasn't because the old process had no agility, but it was because we couldn't scale it in terms of resources, because everything went over the "chief developer's" desk. The team needed to be more autonomous and still work in an agile way, and new team members needed to be able to follow a familiar method.

The first attempt to introduce the Scrum method in our Publishing Server team failed. We tried to combine the advantages of the previous process with those of the Scrum method, (freely according to the slogan, "Wash me but don't get me wet!"). We quickly recognized this was a mistake and then oriented ourselves very closely to the Scrum methodology. The second attempt to implement the new method was successful, but had both benefits and pitfalls.

The Scrum method starts from a different premise: every developer can do everything. This premise of the Scrum method, was and is still not the case today within our company today. Not every team member can, for example, design a software architecture or implement a user interface with the frameworks used. Therefore, it makes no sense, as suggested by Scrum, to sort the backlog exclusively by business value. Available resources with the right skills are also relevant criteria for the order of user stories in the backlog.

A second assumption, and from our point of view not a practical one, is that the deployed software architecture is resistant to architectural changes. In other words, you can change everything without risking too much side effect. This is not the case with long-standing standard software, which sometimes contains code that is 10 years old. Architectural changes are another criterion that strongly influences the order in the backlog. We start with user stories for a new release, which include architecture changes.

A third assumption is that team size affects team efficiency. The Scrub method recommends a maximum of 9 developers. Our team size is slightly above this critical level, therefore, we tried having two teams working on the same product. The Scrum method looks at the process of a single team and does not provide answers to how teams work together. After much back and forth on this, we've converted back to working with one large team.

Many of the assumptions of the Scrum method are proving not to be completely true in our day-to-day business. The method was already designed in the ivory tower and is just now being straightened out in practice.

As a manufacturer of the standard software priint:suite, we follow a release schedule. Nevertheless, we are in a constant communication exchange with customers and partners. We have to react quickly to critical bugs, as well as any new great ideas from the market should also be implemented quickly, if applicable. Therefore, we have a significant amount of agile requirements that are not defined at the beginning of a release. That is why we simply cannot avoid an agile methodology.

We consider team responsibility to be essential for long-term success. Decisions that are made in the team and are supported by all team members are more sustainable. The Scrum method helps us to strengthen teamwork and to permanently improve our work through retroperspectives.

After 7 years we are not enthusiastic about the Scrum method, but we consider Scrum as the best alternative for us at the moment, although we question it regularly.

In closing, I'm looking forward to the next 25 sprints working with our great Publishing Server team.