SCRUM Overview — Chancen und Risiken mit der agilen Projektmanagement Methode

SCRUM — ein Begriff, dem man heutzutage immer regelmäßiger sowohl in kleinen, als auch in großen Unternehmen begegnet. Agilität, Sprints und Review sind hier die Schlagwörter, mit denen die Mitarbeiter:innen auf einmal konfrontiert werden. Doch was ist Scrum eigentlich und was hat es damit auf sich? Wir liefern in diesem Beitrag einen kleinen Overview über die agile Projektmanagementmethode und wie wir sie derzeit nutzen. Da das Thema aber tatsächlich eine ellenlange Serie werden könnte, reißen wir nur einen kleinen Teil davon an und berichten über eigene Erfahrungen, Chancen und Risiken.

<lets start/>

In den frühen 90ern entwickelten Jeff Sutherland und Ken Schwaber die agile Projektmanagementmethode ‘SCRUM’. Back in time wurde sie hauptsächlich in der Softwareentwicklung und im Tech-Bereich angewandt, um agiler und flexibler in iterativen Prozessen passende Systeme entwickeln zu können. Mittlerweile, fast 20 Jahre später, erreicht Scrum seinen Durchbruch auf dem deutschen Arbeitsmarkt. Es gibt einen regelrechten Boom der agilen Projektmanagementmethode; strenge hierarchische Strukturen und Prozesse werden immer seltener und von Agilität regelrecht verdrängt.

<Definition/>

Laut des von Sutherland und Schwaber entwickelten Scrum Guide wird die agile Projektmanagementmethode als “lightweight framework” definiert, das Teams, Organisationen und Menschen dabei helfen soll, adaptive Lösungen für komplexe Probleme zu kreieren und anzuwenden. Es basiert auf einem schlanken Projektmanagementmodell, welches sich rein auf Fakten und wesentliche Gedanken konzentriert.

Scrum verwendet einen inkrementellen und iterativen Ansatz, um die bestmögliche Kontrolle und Vorhersagbarkeit eines Risikos zu haben und diesen zu kontrollieren. Dabei wird ein Team aus Mitarbeiter:innen zusammengestellt, welche alle Kenntnisse und Fähigkeiten mitbringen und bündeln, die für die Fertigstellung des Produkts notwendig sind. Sie arbeiten in sogenannten Sprints, die in der Regel auf 2-4 Wochen angesetzt sind. Der Sprint ist quasi der Herzschlag der Scrum Methode, denn hier werden die einzelnen Teilprozesse in der Entstehung des Produkts festgelegt, geplant und schließlich vom Scrum Team umgesetzt.

<Scrum Werte/>

Engagement — Konzentration — Offenheit — Respekt — Mut

Wenn man ein Projekt nach der Scrum-Methode durchführt, verpflichtet man sich zum Erreichen der Ziele und unterstützt sich gegenseitig bei der Durchführung. Die Mitglieder im Scrum-Team sind engagiert und motiviert, haben das Ziel fest vor Augen, sind offen für alle anfallenden Aufgaben und Anforderungen der Stakeholder — ohne Rücksicht auf neue und unbekannte Herausforderungen.

<Rollen/>

Womit man bei Scrum recht schnell Kontakt bekommt, sind die sogenannten “Rollen”. Alle Mitarbeiter:innen haben in dem geplanten Sprint eine zugewiesene Rolle und bewegt sich auch nur in deren definierter Umgebung. Klassische Rollen wie beispielsweise “Projektleiter:in” gibt es in diesem Modell nicht.

_Scrum Master:in
sind die Organisator:innen des Scrum Teams. Sie unterstützen den Entwicklungs- & Planungsprozess, achten auf die korrekte Durchführung der Methode und planen Meetings, wie beispielsweise das Daily Scrum Meeting.

_Product Owner:in
vertreten die Interessen der Kund:innen. Diese Rolle wird entweder von den Kund:innen selbst eingenommen oder ein Mitarbeiter:in agiert in derren Namen. Das Outcome des Produkts spielt für den Product Owner:in eine essentielle Rolle. Er:Sie verwaltet den Backlog und die Reihenfolge der Abarbeitung der anfallenden Tasks.

_Scrum Team
sind multidisziplinär zusammengestellt, sodass alle Bereiche und die Notwendigkeit der perfekten Gestaltung und Ausarbeitung des Produkts gegeben ist. Sie sind für die Produktion, Programmierung und Erstellung eines Produkts nach Kund:innenvorstellung verantwortlich.

<Sprint/>

Die Arbeitsweise von Scrum definiert sich in einem sogenannten Sprint. Dabei handelt es sich um eine Art “Arbeitspaket”, welches auf die Dauer von 2 bis maximal 4 Wochen angesetzt ist. Verschiedene Arbeitsschritte werden im Vorhinein, in der sogenannten Sprint-Planung, festgelegt und fix eingeplant für diesen Zeitraum. Man geht das Commitment ein, die Aufgaben bis Ende des Sprints umgesetzt zu haben.
Um den aktuellen Fortschritt und Workload zu tracken, finden täglich kurze Daily Scrums statt. Innerhalb von maximal 15 Minuten berichten alle über den aktuellen Stand der Aufgaben. Sowohl, was am Tag zuvor geschafft wurde, als auch was aktuell geplant ist. Moderiert und strukturiert vom Scrum-Master:in, geht das Team jeden Workload durch. Werden hier Engpässe, Probleme oder Risiken erkannt, kann flexibel umdisponiert werden.
Ist der Sprint beendet, findet die Retrospektive statt. Hier wird reflektiert und analysiert und die Ergebnisse bilden die Basis eines neuen Sprints.

<Chancen & Risiken/>

Scrum klingt innovativ, modern und cool. Doch tatsächlich ist diese Methode nicht für jedes Team und jede Firma das Richtige. Der Planungsaufwand ist relativ hoch und man sollte in der Lage sein, seine Aufgaben für die Sprintepisode (also für die kommenden 2–4 Wochen) fest einzuplanen. Spontane Aufgaben und Unvorhergesehenes müssen nach Scrum-Manier hinten an gestellt werden.

Trotzdem neigen viele große und alteingesessene Firmen zur “Überbürokratisierung” von Projekten. Jeder noch so kleine Teilprozess wird akribisch und hierarchisch festgelegt.
Es finden zudem nur sporadisch Follow-ups statt, die es schwierig machen, Schritte oder Probleme direkt anzugehen. Hier wäre die Scrum Methode vielleicht eine mögliche Alternative.
Agilität ist nämlich der Main-Vibe von Scrum. Gestützt auf Empirie und Lean Thinking verlässt sich die Scrum Methode auf Erfahrungen und Wissen aus vergangenen Projekten. — Lean Thinking trägt zur Konzentration auf das Wesentliche bei und steigert damit die Effizienz.

Wird in einem Sprint festgestellt, dass ein Prozess, eine Aufgabe oder der Fortschritt nicht effizient ist und das Sprintziel in Gefahr gerät, wird für die kommende Sprintphase umgeplant. Aufgaben werden anders verteilt, anders angegangen oder ganz abgeschafft. So hält man sich nicht mit der unermüdlichen Weiterverfolgung von Dingen auf, die eventuell sogar toxisch für die Erreichung des Projektziels sein können.

<Unsere Erfahrungen/>

In unserem Status als kleine und agile Datenfabrik haben wir eine Projektmanagementmethode gesucht, die es uns ermöglicht, Transparenz und Struktur zu schaffen. Unterschiedliche Teams arbeiten mit unterschiedlichen Methoden, Themen und Teilbereichen und auch in unterschiedlich iterativen Prozessen. Wie schafft man es nun, verschiedene Bereiche zu vereinen, sodass die Hauptprojekte immer klar im Fokus stehen und wir gemeinsam an der Zielerreichung arbeiten können?

Ob man will — oder nicht, begegnet man als IT-Firma zwangsweise den agilen Projektmanagementmethoden, denn hauptsächlich arbeiten Teams der Softwareentwicklung damit.
Also wir befinden uns noch ganz am Anfang — genau genommen in Sprint Nr. 2. Man könnte meinen, dass eine ausführliche Berichterstattung plus einhergehende Chancen- und Risikenabwägung noch deutlich zu früh wäre. Doch wir konnten dennoch erste Eindrücke gewinnen.

Viele Teilbereiche kommen bei uns zusammen:
Softwareentwicklung, IT-Consulting, Programmierung, Design, Visualisierung, Marketing, Vertrieb, Content, Projektmanagement
und und und.
Jeder Bereich verhält sich anders, arbeitet in anderem Tempo und mit unterschiedlichen Prozessen.
Wir haben gemerkt, dass die IT-Bereiche, wie Softwareentwicklung, Consulting und Programmierung sehr einfach auf den Scrum-Zug aufspringen konnten. Währenddessen haben sich die “kreativeren” Teams etwas schwerer getan. Einfach, weil gerade die Zusammenarbeit mit Kund:innen, Marketing und Vertrieb deutlich schnelllebiger ist, man Unvorhergesehenes schneller bearbeiten und finalisieren muss. Die Beantwortung einer Kund:innenanfrage oder die kleine Änderung einer Vorlage eines Designprojekts könnte und sollte nicht 2–4 Wochen warten müssen. Das wäre schlichtweg geschäftsschädigend. Hier kommen viele ad hoc Themen auf, die schnell abgeschlossen werden müssen, um die positiven Kund:innenbeziehungen aufrecht zu halten.
Auch in der Softwareentwicklung und IT passieren unvorhergesehene Incidents, die an Kund:innen gekoppelt sind, welche wir natürlich ungern warten lassen. Teilweise sind die Lösungsansätze jedoch andere und man kann sich schneller unterstützen oder vertreten.
Die Kunst ist es mit Scrum den goldenen Weg zu finden. Sowohl schnell auf spontane Themen zu reagieren, als auch für eine gewisse Periode zu planen und diesen Weg zu verfolgen.

In unserer gemeinsamen Sprint Retrospektive kamen wir zu einem ähnlichen Feedback. Wir suchen nach wie vor nach der perfekten Lösung Transparenz und Kommunikationswege zu schaffen, ohne uns gegenseitig mit einer Überplanung und Überbürokratisierung im Weg zu stehen.
Für große Projekte, die über einen längeren Zeitraum gehen, macht aus unserer Sicht die Planung mittels der Scrum Methode sicherlich Sinn.
Um den Daily Workload abzubilden, würden wir von Scrum eher wegrücken und nach entsprechendem Best Practice jeder Abteilung fortfahren bzw. ein Mittel finden, wie wir über einen zentralen Kommunikationsweg die notwendige Transparenz schaffen.
Ob Scrum im klassischen Sinne für uns das richtige Modell ist, werden wir weiter beobachten und testen. Da es aber auch nicht gerade unüblich ist, beispielsweise klassische Projektmanagementansätze mit agilen Methoden zu kombinieren, werden wir vielleicht diesen Weg einschlagen oder unsere ganz eigene Methode entwickeln, die perfekt auf unsere Arbeitsprozesse zugeschnitten ist.