ScrumTisch Berlin - November #
This evening Marion 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 than 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 let 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 trainings 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, that is 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.
Update: This blog post was re-posted at the Agile42 blog.