This evening agile42 organised another successful Scrumtisch: Usually we either meet for timeboxed discussions on Scrum and agile development questions or a speaker is invited to present his favourite Scrum or Lean or Agile topic.

Today Markus Frick gave a presentation of how Scrum was introduced at SAP, a German software company. They started implementing Scrum in a “small” team of about 60 people, organised in about six to seven teams. The idea was to get people together who are already sort of familiar with agile technologies and let them evaluate what works in the companies context at what doesn’t. The conversion started with trainings, teams were organised by features as opposed to components. The main goal was to get people to learn Scrum and then spread the idea across the whole company.

Soon upper management were fascinated by the methodology – not shortly after that the goal was reset to converting 2500 employees working at four different locations (Bangalore, Berlin, Waldorf and Sofia/France) on diverse topics ranging from developers to managers to agile methods. The question thus turned from scaling Scrum to quickly scaling the conversion process: Where do we get enough trainers? Where does Scrum expertise come from? How should communication be organised? How do we adapt our sales and governance processes?

The way to do this chosen back then was to use Scrum itself for the conversion process. That is to introduce teams for training and conversion and let them work according to a backlog. Also managers were set up to participate by organising work according to a backlog containing management tasks. This first led to quite some confusion: Conversion does take time and working according to sprint backlogs makes it pretty much obvious how much time it actually takes and how much time people really spent on these tasks. On the other hand, the whole process was made very transparent for everyone – and open for participation.

The process started about two years ago – it has not finished to date and processes continue to evolve, get improved and refined as people go along. A very rough estimation was that it might take another three years to get to a stable, clean state. However most – if not all – problems were not caused by Scrum. They were made visible and trackable by Scrum.

The main take-home messages were that Scrum does bring improvement:

• It makes goals transparent and communicates clearly the current state.
• You get a short feedback cycle so people actually see where problems are.
• It inherently allows for reflection and analysis of problems.
• As introduced here it also made the work of management people transparent by making backlog and velocity of managers accessible by everyone.
• Internal training helped to get feedback from teams who are already practicing what is introduced.

Among the people who were very skeptical there usually were quite a few people from middle management. Uncertain about how future development should work they usually feared a loss in influence. Most positive feedback came from developers themselves: After explaining what Scrum is all about, which includes shore release cycles and fast feedback, most developers that were in the teams already for quite some time reacted by stating that this basically resembled development “in the good old days” with a bit of development process added on top.

If you are interested in hearing more stories on how Scrum is or was introduced in companies of various sizes, I would like to recommend visiting the German Scrum Day in Düsseldorf. The talk by Thilo Fromm gives a nice overview of how a transition from traditional Waterfall to Scrum can look like. And agile42 Andrea Tomasini will talk about the Scrum implementation in distributed teams at be2 ltd.