Erfahrungsberichte zur Scrum-Einführung

Scrum-Einführungen sind eine spannende Entdeckungsreise. Das lässt sich als Fazit aus zahlreichen Erfahrungsberichten herauslesen, die von Leuten veröffentlicht wurden, die sich mit einem Team auf diese Entdeckungsreise begeben haben.

Vielfach zeigt sich dabei ein ähnlicher Verlauf bei der Einführung von Scrum, den ich in diesem Artikel gespickt mit vielen Zitaten zusammengefasst dargestellen möchte.

Eine Scrum-Einführung stellt eine tiefgreifende Veränderung dar

Zunächst einmal sollten sich die Teams bewusst sein, dass sie sich auf eine große Veränderung einlassen, wenn sie Scrum einführen. Es ist nicht eine kurze Umstrukturierung und Umbenennung, sondern eine Veränderung des ganzen Mindsets und der Art, wie gemeinsam gearbeitet wird.

“Meine sicherlich wichtigste Erfahrung ist, dass eine sanfte Einführung von Scrum nicht möglich ist: ernenne den Projektleiter zusätzlich zum Scrum Master, erkläre den Produktmanager zum Product Owner, führe Taskboard, Sprint Planning, Review und Retrospektive ein und los geht’s.” (Katja Roth)

“Es genügt nicht, lediglich die neuen Rollen, Prozesse und Meetings einzuführen, aber ansonsten in den alten Strukturen zu verbleiben.” (Katja Roth)

Ein solches lapidares Vorgehen bei der Einführung von Scrum führt höchstens zu einem “Scrum, but”, dass bei weitem nicht die gewünschten Effekte bringt.

“Die erste Herausforderung war es, Scrum innerhalb des ganzen Unternehmens zu verstehen. Wenn Scrum als Projektmanagement-Methode oder als Vorgehensmodell wie etwa das Spiralmodell missinterpretiert wird, bleiben die meisten Vorteile ungenutzt.” (Traian Kaiser)

Dabei dürfen sich Teams auch nicht von der scheinbaren Einfachheit von Scrum blenden lassen.

“Das Regelwerk ist so unkompliziert und die Methode so einfach zu erlernen, dass man annimmt, man hat sofort alles verstanden. Erst wenn man Scrum tatsächlich einsetzt, merkt man, dass es sich um einen wirklichen Paradigmenwechsel handelt, der von allen Beteiligten ein radikales Umdenken verlangt.” (Ralf Ehrhardt)

Scrum-Einführungen erfordern Veränderungsbereitschaft und Ausdauer

Teams sollten sich auf einen langen gemeinsamen Weg einstellen, bei dem allen Beteiligten die Bereitschaft für tiefgreifende Veränderungen abverlangt wird. Eine Scrum-Einführung wirkt sich auch erheblich auf die gesamte Unternehmenskultur aus.

“Der Wille von Management und Mitarbeitern, diese Veränderungen voranzutreiben und auch mehr Verantwortung in die Teams zu geben und zu übernehmen, ist absolut notwendig. Damit dies funktioniert, bedarf es einer Unternehmenskultur, die grundsätzlich dem agilen Manifest folgen kann.” (Traian Kaiser)

Einige lieb gewonnene Angewohnheiten werden über den Haufen geworfen, um sich in der gemeinsamen Zusammenarbeit weiterzuentwickeln.

“Eine besonders große Herausforderung ist von Beginn an die Umsetzung der Maxime “Jeder macht alles” gewesen: Jedes Teammitglied hat ein Projekt, das ihm besonders am Herzen liegt, und sieht sich immer wieder versucht, sich vorwiegend um die Arbeiten an diesem Steckenpferd-Projekt zu kümmern.” (Manuel Kummerländer)

Die zunehmende Einbeziehung der Teams in viele Entscheidungen kostet dabei viel Kraft.

“Jetzt muss ich die Teams fragen, wie sie etwas lösen wollen, das ist oft anstrengend” (Oliver Zeiler)

“Die Selbstverantwortung und die vielen dadurch entstehenden Diskussionen finde ich recht auf- und anregend, manchmal auch sehr anstrengend.” (Manuel Kummerländer)

Auf einmal wird Personen Verantwortung übertragen, die dieses über einen langen Zeitraum nicht gewohnt waren.

“In den letzten 20 Jahren lief das so ab: Manager haben einen Plan erarbeitet. Wurde der umgesetzt, hieß das: Wir lösen jetzt das Kundenproblem mithilfe von Software. Die Manager wissen aber häufig nicht, wie man das macht. Deswegen schlage ich vor, dass man den Programmierern das Problem beschreibt, und sie finden dann selbst heraus, wie sie es lösen. (Ken Schwaber)

Erst nach und nach, über einen längeren Zeitraum, gewinnen alle Beteiligten eine zunehmende Sicherheit in ihren Rollen und lernen, mit der neuen Verantwortung umzugehen.

“Wir befinden uns auf einer langen Straße, die, um es noch bildlicher auszudrücken, am Anfang sehr holprig und ohne Beschilderung war und nun immerhin schon zu einer stattlichen Bundesstraße ausgebaut wurde.” (Matthias Müller)

Positive Veränderungen stellen sich nach und nach ein

Nicht umsonst entwickelte sich Scrum in den letzten Jahren zum State-of-the-Art-Vorgehensmodell in der Softwareentwicklung. Die meisten Erfahrungsberichte verweisen auf viele positive Effekte aus der Einführung von Scrum. Etwa Verbesserungen an der Qualität der Arbeitsergebnisse.

“Die Qualität unserer Software erscheint mir – insbesondere für so ein neues Team – schon sehr hoch. Wir haben viele Unit Tests mit annehmbarer Code Coverage, der Code ist fast zu 100% kommentiert, und die Software macht einen “runden” Eindruck.” (Mathias Raacke)

Aber auch Verbesserungen bei der Zusammenarbeit und der Produktivität.

“Alles in allem machen wir uns also immer besser. Es macht Spaß, zu erleben, wie man gemeinsam die Atmosphäre, in der man arbeitet, verändern, die Qualität verbessern und die Produktivität steigern kann.” (Matthias Müller)

Und erste Erfolge führen dazu, alle in ein gemeinsames Boot zu holen.

“Da haben alle anderen gesehen, dass Scrum Spaß macht und sexy ist.” (Oliver Zeiler)

Machen wir uns nichts vor: Eine Scrum-Einführung ist kein leichtes Unterfangen. Aber die positiven Effekte einer gelungenen Einführung zeigen sich auf vielen verschiedenen Ebenen. Und so lohnt sich diese Reise, auch wenn sie niemals wirklich zu Ende geht… .

Erfahrungsberichte von Scrum-Einführungen:

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

About these ads

Produktmanagement Lesetipps: Architekturvision in Scrum, Top 10 Startup-Erfolgsregeln, Kundenfeedback, Kostenplanung in agilen Projekten

Die Produktmanagement Lesetipps enthalten diesmal eine Mischung aus Beiträgen zu agiler Softwareentwicklung, Startup-Vermarktung und der Nutzung von Kunden-Feedback. Viel Spaß dabei! Falls Ihr in letzter Zeit einen spannenden Artikel aus diesem Themenbereich gefunden habt, teilt es doch über einen Kommentar mit.

Die Architekturvision in Scrum

Auch wenn ein Team nach den Leitsätzen und Prinzipien der agilen Softwareentwicklung arbeitet, ist eine initiale Architekturvorstellung wichtig, um nicht ständig alles umbauen zu müssen. Sie muss aber Raum lassen, um inkrementell von Sprint zu Sprint weiterentwickelt werden zu können.
Stefan Roock und Roman Pichler stellen in einem Artikel das Konzept der Architekturvision vor und beschreiben Kriterien und Techniken für ihre Erstellung: “Die Architekturvision in Scrum: Vorausplanung und emergentes Design balancieren”. Er kann als PDF heruntergeladen werden.

Richtig groß rauskommen

Reid Hoffman, Co-Founder und Vorsitzender von LinkedIn hat auf Greylockvc.com 10 Regeln für Gründer veröffentlicht, zu denen er beim diesjährigen South by Southwest vorgetragen hat.
t3n hat diese 10 Regeln wie man richtig groß rauskommt auf deutsch übersetzt. In seiner 10. Regel stellt Hoffman selbst klar, dass solche Regeln nicht als Naturgesetz, sondern als Richtlinie verstanden werden sollten. Wenn man den Erfolg von Hoffman bedenkt, der neben der Mit-Gründung von LinkedIn und PayPal auch in Facebook, Flickr und Zynga investiert hat, lohnt es sich, sich ein paar Minuten Zeit für seine Erkenntnisse zu nehmen.

Warum Kundenfeedback wichtig ist

Evan Hamilton, Community Manager des Kunden Engagement Tools Uservoice, stellt seine Präsentation vom Online Community Meetup in San Francisco zur Verfügung.
Darin präsentiert er, warum Kundenfeedback so wichtig ist, wie es erhalten und gesammelt werden kann. Er gibt auch einen kleinen Einblick, wie am besten mit Kundenwünschen umgegangen wird, gegen deren Umsetzung sich das Unternehmen entscheiden hat.

Kostenplanung in agilen Projekten

Bei Scrumology schreibt Kane über die Kostenplanung in agilen Projekten. Sein zentraler Punkt: Kostenplanung wird durch agile Softwareentwicklung unglaublich viel einfacher.

There are two important facts about Agile projects that I need to make clear before I continue.

  • Agile project teams are cross functional. What this means is that Agile teams are comprised of Analysts, Developers, Testers etc.
  • Agile teams are dedicated for the duration of the project. At the risk of repeating myself, this means that everyone (Analysts, Developers, Testers etc) are 100% allocated to the project for the entire duration of the project.
    • Given these two ideas, it should now be obvious how to cost an Agile project. We have static team compositions and the team is dedicated 100% of the time, so there is a fixed cost for the team per day.

Mit einer Beschätzung durch das Team und das Abschätzen der benötigten Sprints kann somit eine wesentlich bessere Schätzung abgegeben werden als in Projekten, bei denen zahlreiche Übergabepunkte mit einem Wechsel der beteiligten Personen bestehen.

Weitere Ausgaben der Produktmanagement Lesetipps:

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 1.246 Followern an

%d Bloggern gefällt das: