SCRUM ist einer von mehreren existierenden sog. agilen Prozessen für Softwareentwicklung und Projektmanagement – aber das wohl bekannteste Vorgehensmodell.

Es kennzeichnet sich aus durch die Merkmal: kurze Arbeitszyklen, häufige Feedback-Schleifen und selbstorganisierende Teams.

 

Leider werden häufig solche neuen Ansätze und Ideen gerade in alteingesessenen Familienunternehmen als neumodischer Unsinn abgetan und bekommen erst gar nicht eine realistische Chance, sich zu bewähren.

Wer SCRUM neu einführen möchte, wird daher sich oft gegen interne Widerstände behaupten und ggf. viel Überzeugungsarbeit leisten müssen. Hier kann eine vernünftige Kommunikation der Vorteile helfen, Widerstände zu überwinden.

Wie funktioniert SCRUM?

SCRUM ist eine agile Entwicklungsmethode. Die Entwicklung wird in Iterationen organisiert, die man in SCRUM „Sprints" nennt. Eine gleichmäßige Sprintlänge gibt dabei dem Team einen Rhythmus. Ein Sprint dauert maximal vier Wochen.

Dabei kennt SCRUM drei Rollen für direkt am Prozess Beteiligte:

  • den Product Owner (stellt fachliche Anforderungen und priorisiert sie),
  • den SCRUM Master (managt den Prozess und beseitigt Hindernisse) und
  • das SCRUM Team (organisiert isch selbt und entwickelt das Produkt).

Daneben gibt es als Beobachter und Ratgeber noch die Stakeholders.

Die Anforderungen (Requirements) werden in einer Liste (Product Backlog) gepflegt, erweitert und priorisiert. Die Product Blacklog ist eine Liste der Kundenanforderungen, die nach Wichtigkeit priorisiert sind. Das Product Backlog ist ständig im Fluss.

Um ein sinnvolles Arbeiten zu ermöglichen, wird monatlich vom Team in Kooperation mit dem Product Owner ein definiertes Arbeitspaket dem oberen, höher priorisierten Ende des Product Backlogs entnommen und komplett in Funktionalität umgesetzt (inkl. Test und notwendiger Dokumentation).

Dieses Arbeitspaket, das Increment, wird während der laufenden Iteration, des sog. Sprints, nicht durch Zusatzanforderungen modifiziert, um seine Fertigstellung nicht zu gefährden.

Alle anderen Teile des Product Backlogs können vom Product Owner in Vorbereitung für den nachfolgenden Sprint verändert bzw. neu priorisiert werden.

Das Arbeitspaket wird in kleinere Arbeitspakete (Tasks) heruntergebrochen und mit jeweils zuständigem Bearbeiter und täglich aktualisiertem Restaufwand in einer weiteren Liste, dem Sprint Backlog, festgehalten.  Die Sprint Backlog enthält die Aktivitäten, die durchgeführt werden müssen, um die Kundenanforderungen des Sprints umzusetzen.

Während des Sprints arbeitet das Team konzentriert und ohne Störungen von außen daran, die Tasks aus dem Sprint Backlog in ein Increment of Potentially Shippable Functionality, also einen vollständig fertigen und potentiell produktiv einsetzbaren Anwendungsteil, umzusetzen. Das Produktinkrement ist das Teilprodukt, das am Ende eines Sprints erstellt wurde (alle bisherigen Funktionalität + die neuen Funktionalitäten)

Das Team gleicht sich in einem täglichen, streng auf 15 Minuten begrenzten Informations-Meeting, dem Daily SCRUM Meeting, ab, damit jeder weiß, woran der andere zuletzt gearbeitet hat, was er als nächstes vor hat und welche Probleme es evtl. gibt.

Am Ende des Sprints präsentiert das Team dem Product Owner, den Stakeholders u. a. interessierten Teilnehmern in einem sog. Sprint Review Meeting live am System die implementierte Funktionalität. Halbfertiges oder gar Powerpoint-Folien sind während des Reviews verboten.

Das Feedback der Zuseher und die neuen Anforderungen des Product Owners für den kommenden Sprint fließen dann wieder in das nächste Sprint Planning Meeting ein, und der Prozess beginnt von neuem.

Während des gesamten SCRUM-Prozesses sorgt der SCRUM Master dafür, dass Regeln eingehalten werden und der Status aller Tasks im Sprint Backlog von den jeweils zuständigen Team-Mitgliedern täglich aktualisiert wird. Er macht den Projektfortschritt transparent durch einen geeigneten Reporting-Mechanismus: die Veröffentlichung sog. Burndown Charts, welche den Fortschritt für den aktuellen Sprint bzw. für das gesamte Projekt jeweils in Form einer Kurve visualisieren. Eingezeichnete Trendlinien erlauben es, mögliche Probleme und Verzögerungen einfach (und rechtzeitig!) zu erkennen.

Im Kern basiert SCRUM also auf einer inkrementellen Vorgehensweise, der Organisation von Entwicklungsabschnitten und Meetings in vordefinierten Zeitabschnitten (Time-Boxes) und der Erkenntnis, dass ein funktionierendes Produkt wichtiger ist als eine dreihundertseitige Spezifikation.

7 Gründe für SCRUM

Für die Einführung für SCRUM gibt es viele Gründe, die am Ende zu mehr Nutzen bei weniger Aufwand führen – und das bei einem motivierten Team.

  1. Agilität
    Die Stakeholder haben fortwährende Einflussnahme und Steuerungsmöglichkeit während des gesamten Entwicklungsprozesses. Die ist ein Argument, das sicher bei vielen die ersten Widerständen bröckeln lassen wird.
  1. Kommunikation
    Die zahlreichen SCRUM Meetings sind gerade zu Beginn ungewohnt. Diesen wird zudem meist unterstellt, dass sie Arbeitszeiten kosten und erhöhte Iterationsschleifen mit sich bringen. Aber genau das Gegenteil ist der Fall. Die genaue Abstimmung, des Leistungsumfangs, die Definition der Arbeitspakete insbesondere im Refinement- und Planungsmeeting reduzieren erheblich den sonstigen Abstimmungsbedarfe zwischen den Teammitgliedern und vermeiden, dass Umsetzungen nicht den Anforderungen entsprechen und nachträglich erneut geändert werden müssen.

 

  1. Emanzipation
    SCRUM kann nur funktioniert nur erfolgreich, wenn die richtigen Leute für die richtigen Rollen eingesetzt werden. Dieses funktionierende SCRUM Team wird Eigendynamiken entwickeln, Ideen und Innovationen hervorbringen und sich selbst organisieren. Hiervon profitiert jeder, wenn dafür der Freiraum gemäß SCRUM dem Team gegeben wird.

 

  1. Time-to-Market
    Meist ziehen mehrere Woche oder Monate ins Land, bevor der Kunde (respektive Stakeholder) sein Produkt zu sehen bekommt. Bei SCRUM kann in kurzen Zyklen livefähige Produktbestandteile (Increments) vorgestellt werden. Hier kann der Stakeholder jederzeit die Anforderungen überprüfen und ggf. den Kurs anpassen. Zudem kann der Stakeholder pro Sprint entscheiden, ob das Produkt den Reifegrad erhalten hat, Live bereitgestellt zu werden.

 

  1. Opportunitätskosten
    Gerade in Kunden-Dienstleister Beziehungen kann dies ein offensichtliches Argument sein. Insofern das SCRUM Team des Dienstleisters nach SCRUM organisiert ist, ist eine genaue Schätzung, die Angebotserstellung, -prüfung, -freigabe etc. nicht erforderlich. Es wird ein SCRUM-Team „verkauft“ für einen definierten Zeitraum mit einer definierten Anzahl an Personen. Langwierige Diskussionen über den genauen Leistungsumfang, ob eine Aufgabe nicht doch irgendwie schneller durchgeführt werden könnte etc. entfallen.
  1. Qualität
    Bei SCRUM wird kontinuierlich während des gesamten Entwicklungsprozesses das Testen als fester Kernbestandteil aufgenommen. Am Sprintende werden nur erfolgreich getestete Features dem Kunden vorgestellt (Review-Meeting), so dass fortwährend die Produktqualität gewährleistet ist.
  1. Identifikation
    Beim SCRUM Team mit den Freiheitsgraden und auch den Einflussmöglichkeiten, steigt die Identifikation der einzelnen Teammitglieder und damit auch die Arbeitsbereitschaft für ein Produkt. Denn dem Team ist die genaue Produktvision klar und es entscheidet auch selbst, welche Aufgabenmenge in einem Sprint umgesetzt werden kann.

Umsetzung in der Praxis

SCRUM in die Praxis umzusetzen, bedarf zahlreicher Schritte, ausreichend Zeit und ein gutes Maß an Überzeugungsarbeit. Folgender Ablauf und Tipps können für einen erfolgreichen Start im Unternehmen hilfreich sein:

  1. Probleme erkennen
    Herausfinden an welchen Stellen Probleme existieren und prüfen ob SCRUM für die Problemlösung Ansätze bietet.
  1. Vorreiter
    Vorreiter im Unternehmen zum Thema SCRUM finden. Ein Unternehmen braucht zwingend Pioniere, die andere dafür begeistern können.
  1. Interne Kommunikation
    Es ist eine explizite Freigabe für die Pilotphase erforderlich. Ggf. ist es auch möglich, zunächst das Thema in der Testphase nicht öffentlich zu kommunizieren, sondern erstmal an einer Abteilung zu testen. Alle Pioniere sollten zu diesem Zeitpunkt fit und mit ausreichend Argumenten ausgestattet sein, um möglichen Kritikern von SCRUM begegnen zu können.
  1. Projektauswahl
    SCRUM ist unabhängig von Organisationseinheiten aufgestellt. Das SCRUM Team richtet sich nach dem Projekt und nicht umgekehrt. Daher muss sorgfältig überlegt werden, welches Pilotprojekt sich am besten für SCRUM eignet. Ggf. bei vergleichbaren Projekten aus der Vergangenheit mit einer anderen Projektmanagementmethode kann direkt verglichen werden, ob sich durch SCRUM eine Verbesserung zugetragen hat.
  1. Meetings und Artefakte sukzessive Einführen
    Das Team sollte nicht überrannt werden. Meist verhält es sich wie mit dem Tuckman Modell. Zunächst sind alle begeistert und schreiten voran. Dann kommen die ersten Stolperfallen und womöglich auch Ernüchterungsphase. Nun gilt es aufzusetzen und zu lernen und zu performen. Daher in kleinen Schritten anfangen und nicht jede noch so kleine SCRUM Vorgabe ins Detail umsetzen. SCRUM ist ein Framework innerhalb dessen man sich bewegen kann – es gibt also Spielraum.
  1. On the job training
    Am besten ist es, SCRUM zu erleben, z. B. in einer SCRUM Schulung. Danach wird empfohlen, ein SCRUM Coaching durchzuführen – denn Theorie ist die eine Sache, die tägliche Praxis eine andere.
  1. Retrospektive
    Zurückblicken auf die Erwartungen die man an SCRUM hatte versus dem, was sich eingestellt hat und verbessert werden muss.

Vor- und Nachteile von SCRUM

Es soll trotz der vielen guten Gründe SCRUM einzuführen, auch nachfolgend die Vor- und Nachteile gegenübergestellt werden.

Vorteile

Nachteile

Hohe Transparenz und rechtzeitiges Einlenken

Geringe Planbarkeit (Kosten und Zeit nicht definierbar)

Stärkt Teamgeist und fördert die Identifikation aller Beteiligten im Projekt

Geringe Strukturierung innerhalb der Sprints

Stärkere Eigenverantwortung des Teams

Trägheit – neue Anforderungen können frühestens im nächsten Sprint umgesetzt werden

Kontinuierlicher Verbesserungsprozess bspw. durch Retrospektiven

Höhere Belastung des Teams gegen Sprintende

Wenige Regeln, leicht verständlich und leicht einführbar

Supportanfragen können nicht während des Sprints bearbeitet werden, es sei denn das Sprintziel wird gefährdet oder es wurde entsprechende Zeit vorgesehen

Zeitnahe Realisierung von Produktbestandteilen (Increments)

Zahlreiche Meetings

 

Diese Gegenüberstellung soll nur dazu dienen die Nachteile zu kennen, um diese entsprechend zu berücksichtigen.

Trotzdem der unschlagbaren Vorteile der Hinweis: SCRUM ist kein Allheilmittel, und nicht für jedes Projekt und jede Organisationseinheit anwendbar.