Ein Angebot von

Agile Methoden

Warum eigentlich (immer) Scrum?

| Autor / Redakteur: Oliver Knittel * / Franz Graser

Bei Scrum ist sehr wichtig, dass alle Beteiligten motiviert bei der Sache sind und dem Vorhaben positiv gegenüber stehen.
Bei Scrum ist sehr wichtig, dass alle Beteiligten motiviert bei der Sache sind und dem Vorhaben positiv gegenüber stehen. (Bild: Method Park)

Scrum wird fast als Synonym für agile Vorgehensmodelle gebraucht. Es stellt aber viele Organisationen vor Probleme, da Scrum nicht schrittweise eingeführt werden kann. Eine mögliche Alternative ist Kanban.

Scrum definiert drei neue Rollen, die bei der Umsetzung von Projekten sinnvoll zu besetzen sind. Dabei orientieren sich die Rollen ScrumMaster und Team offensichtlich noch relativ nah an den bisher bekannten Rollen, wie etwa Softwareentwickler, Tester oder Prozessverantwortlicher, und sollten leicht umzusetzen sein. Die Rolle des Product Owners dürfte aber viele Unternehmen vor eine große Herausforderung stellen. Denn gerade diese Rolle mit ihren vielfältigen Aufgaben existiert bisher in den meisten Organisationen so nicht.

Dem Product Owner obliegt die eigentliche Verantwortung für das zu erstellende Produkt. Er ist derjenige, der für Problemstellungen in der Produktentwicklung über geeignete Lösungen entscheiden muss. Er fällt seine Entscheidungen anhand von Geschäftswerten und benötigt vor allem die Kompetenz, solche Entscheidungen zu treffen und vor dem Management zu vertreten. Außerdem ist er für das Entwicklungsteam der erste Ansprechpartner: Er beantwortet offene Fragen zum geplanten Produkt und den einzelnen Entwicklungsschritten.

Das Rollenbild des Product Owner – Problem und Lösung

In vielen Organisationen gibt es meist keine Person, die diese Rolle und Verantwortung übernehmen kann. Oft fällt allein das obere Management die dem Product Owner zugeordneten Geschäftsentscheidungen. Das Management kann sich aber aus diversen Gründen nicht gleichzeitig auch mit den ganz konkreten Frage- und Problemstellungen der Entwicklerteams im Projektalltag befassen. Dies ist unter anderem ein Grund dafür, warum sich große Organisationen oft schwer tun, Scrum in seiner reinen Form und ohne größere Anpassungen einzuführen.

Bei der Einführung von Scrum muss daher die Rolle des Product Owners klar definiert werden. Welche Aufgaben, die bislang ein Produktmanager oder ein Projektleiter innehatte, übernimmt nun der Product Owner? Wie stimmen sich diese Personen ab?

Weiterhin müssen die Kompetenzen desjenigen definiert werden, der die Rolle des Product Owners im Projekt einnimmt. Nur das obere Management kann diese Kompetenzen festlegen, denn es übergibt dem Product Owner Rechte und Pflichten und gibt damit auch zum Teil Entscheidungsmacht ab. Wenn die Rolle des Product Owners passend definiert ist und sich alle Beteiligten positiv auf das Abenteuer einlassen, dann ist eine der schwierigsten Hürden bei der Einführung von Scrum genommen.

Es ist sehr wichtig, dass alle Beteiligten motiviert bei der Sache sind und dem Vorhaben positiv gegenüber stehen. Allerdings können gerade Veränderungen bei vielen Beteiligten Angst, Stress und dadurch Widerstände gegen das Vorhaben auslösen.

Neben den persönlichen Ängsten ist eine weitere Komponente zu berücksichtigen: die Unternehmenskultur. Agile Ansätze sind in manchen Unternehmen nur mühsam umzusetzen. Dies liegt daran, dass jede Organisation ihre eigene Kultur ausbildet, die unter Umständen im Widerspruch zu den agilen Werten steht. So betonen die agilen Methoden u.a. die Werte Kooperation und Vertrauen. Bei vielen Organisationen stehen aber Verantwortung und Kontrolle durch das Management und der detaillierte Blick über das Unternehmen im Fokus.

Ergänzendes zum Thema
 
Interview mit Oliver Knittel: „Bei Kanban sind die eigentlichen Änderungen zunächst einmal relativ klein“

Dies beschreibt auch Schneider in dem Buch „The Reengineering Alternative“ [Sch94]. Seiner Ansicht nach lassen sich Organisationen vier Kulturen zuordnen: Collaboration-Culture, Control-Culture, Competence-Culture und Cultivation-Culture.

Der Faktor der Unternehmenskultur

Viele Firmen in der westlichen Welt dürften der Control-Culture zuzuordnen sein. Sie legt viel Wert auf den Fortschritt der Firma, auf Hierarchien und Regeln. Diese Kultur neigt auch zu einem Bürokratie-Overhead. Sahota [Sah12] ordnet die agilen Werte und Prinzipien, die Kanban-Kultur und das Manifest des „Software-Craftsmanship“ den vier Kulturen zu. Er zeigt, dass agile Prinzipien eher im Einklang mit der Collaboration- und Cultivation-Kultur stehen.

Wie lassen sich diese Widersprüche auflösen? Eine Möglichkeit besteht darin, einen Kulturwandel im Betrieb einzuleiten. Die Art zu denken und zu handeln, wird dabei maßgeblich geändert. Kotter [Kot95] nimmt an, dass für einen erfolgreichen Kulturwandel zumindest 75 Prozent der Führungskräfte von der Dringlichkeit der Veränderung überzeugt sein müssen. Dies ist nur sehr selten der Fall. Denison [Den90] geht davon aus, dass sich ein Kulturwandel über mehrere Jahre hinziehen kann, zum Teil sogar über zehn Jahre!

Eine weitere Möglichkeit, das Kulturproblem zu lösen, ist der Einsatz eines Vorgehensmodells, das im Einklang mit den Kulturwerten steht. Nach Sahota [Sah12] könnte Kanban ein Ansatz sein, mit dem man die evtl. vorhandenen Schwierigkeiten und Widerstände umgeht und elegant ein agiles Vorgehensmodell in ein Unternehmen einführt.

Warum Kanban? Anderson [And10] hat Kanban entwickelt, um u.a. einen sanften Wandel im Unternehmen vollziehen zu können. Bei der Einführung von Kanban wird deshalb empfohlen, keinen ganz neuen Prozess zu definieren, sondern ausgehend vom aktuellen Stand kleine Änderungen vorzunehmen. Die bekannten Rollen und Aktivitäten können und sollen vorerst weiter gelebt werden. Kanban gibt nur fünf Dinge vor:

  • 1. Visualisiere den Fluss der Arbeit.
  • 2. Begrenze die Menge begonnener Arbeit.
  • 3. Messe und steuere den Fluss.
  • 4. Nenne die Prozessregeln klar und deutlich.
  • 5. Verwende Modelle, um Chancen für kollaborative Verbesserungen zu erkennen.

Mit den ersten Vorgaben sind die Anfangsprobleme leicht zu ermitteln. Erfüllt man die weiteren Vorgaben, werden die Kollegen den Prozess nicht nur verstehen, sondern können auch bei der Verbesserung mitwirken.

Wie unterscheiden sich Scrum und Kanban hinsichtlich Unternehmenskultur und Kulturwandel? Scrum lehnt sich an die agilen Werte und Prinzipien an, indem es ein Vorgehensmodell und die entsprechenden Rollen für die erfolgreiche Umsetzung definiert. Diese Vorgaben sind bei der ersten Umsetzung unbedingt einzuhalten; sonst setzt sich das bekannte Vorgehen schnell wieder durch. Scrum ist nicht für die schrittweise Umsetzung ausgelegt. Oft heißt es, dass Scrum revolutionär eingeführt werden muss.

Unterschiede zwischen Scrum und Kanban

Ist in einem Unternehmen das Verständnis für agile Herangehensweisen eher gering, dürfte man mit Scrum auf erhebliche Schwierigkeiten stoßen. Die Entwicklung selbst mag sich zwar an Scrum anlehnen, aber sobald Kontakt nach Außen notwendig wird, werden schnell Probleme auftreten, die viele Vorteile von Scrum wieder relativieren.

Kanban hingegen ist ein Vorgehensmodell, in das sich bestehende Prozesse leicht einfügen lassen (evolutionär). Es lässt sich daher in jeder Kultur einführen. Aufbauend darauf kann man den Prozess verändern und so (eher langfristig) auch agile Elemente in den Prozess und das Unternehmen einführen.

Viele Firmen, die auf agile Methoden umsteigen wollen, setzen Scrum ein, weil u.a.:

  • die Industrie schon Erfahrung gesammelt hat und man die Stolpersteine kennt.
  • es viele Berater gibt, die ausgezeichnete Arbeit bei der Unterstützung leisten.
  • die Mitarbeiter motivierter sind, da sie ihre Arbeit selbst planen und nicht verplant werden.

Trotz allem sollte man sich vor der Einführung agiler Methoden genau überlegen, welchen Prozess man einführen möchte und welche Methoden wirklich geeignet sind. Ein blindes „wir nehmen Scrum, weil es alle tun“ kann mittelfristig eher Frust statt Lust auslösen.

Literaturhinweise:

[And10] David J. Anderson: Kanban, 2010[Den90] Daniel R. Denison: Corporate Culture and Organizational Effectiveness, 1990[Kot95] John Kotter: Leading Change, 1995[Sah12] Michael Sahota: An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture, 2012[Sch94] William E. Schneider: The Reengineering Alternative: A plan for making your current culture work, 1994

* Oliver Knittel ist Teamleiter Medical Information Systems bei Method Park.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 42242583 / Agilität)