Artikel:
Leicht erklärt:
Agiles Projektmanagement
– Was ist Scrum?
Wir alle wissen: Projekte und Prozesse müssen organisiert werden, um zu funktionieren. Das klassische Vorgehen dazu sieht wie folgt aus: Ziel setzen, den Weg zur Erreichung von diesem planen, sich an den Plan halten und Schritt um Schritt umsetzen. Komplexe Aufgaben zerlegen wir in kleinste Teile und planen auch diese durch, damit nichts schief gehen kann. Sollten wir andere mit diesen Aufgaben betrauen, so schaffen wir Verbindlichkeiten durch Aufwandseinschätzungen und Termin-Fristen. Daraus ergeben sich Kontrollmechanismen und schlussendlich Hierarchien – Aspekte, die große Projekte und Teams gut steuerbar machen.
AGILE EXCELLENCE MIT SCRUM!
AGILE EXCELLENCE MIT SCRUM!
Klassisches Projektmanagement für statische Ziele: Die Wasserfall-Methode
Das bis ins kleinste Detail durchgeplante Vorgehen ist gemeinhin auch als Wasserfall-Methode bekannt. Sie bringt Planbarkeit und Kalkulierbarkeit. Aufgaben und Ziele können vorab klar verteilt und regelmäßig kontrolliert werden. Die Wasserfall-Methode ist geeignet, wenn ein Projekt statisch ist, also von Anfang bis Ende gut durchgeplant werden kann. Beim Bau einer Fertigungshalle ist dies beispielsweise der Fall.
Doch wie steht es um Entwicklungsprojekte? Um Projekte, die sich nach dem Markt statt einem Plan richten? Wer heute ein Projekt mit einer Laufzeit von einem Jahr mit der Wasserfall-Methode plant, hat in einem Jahr ein Ergebnis, dass auf dem Wissens- und Technikstand von vor einem Jahr basiert. Oftmals adressiert so eine Lösung den Bedarf von vor einem Jahr, nicht jedoch den Aktuellen.
Agiles Projektmanagement verstehen – mit dem magischen Dreieck
Wer auf dynamische Anforderungen reagieren will, muss sich zuerst fragen, an welchen Stellschrauben gedreht werden kann. Hierzu bietet das sogenannte magische Dreieck eine Hilfestellung. Nach diesem gibt es drei Dimensionen bei einem Projekt: Zeit, Ressourcen und den Umfang, den das Ergebnis haben soll. Während der Wasserfall-Ansatz den Umfang als Fix definiert und Zeit / Ressourcen als variabel sieht, ist dies bei agilen Projektmanagementmethoden wie Scrum umgekehrt. Zeit und Ressourcen werden fix definiert, der Umfang an die sich daraus ergebenden Gegebenheiten angepasst.
Dieser Ansatz stammt aus der Softwareentwicklung und entspringt dem Problem, dass ein Ziel vor Projektstart noch nicht oder nur grob bekannt ist. Man nähert sich mit festgelegten Ressourcen innerhalb einer bestimmten Zeit nach und nach dem Idealzustand an und reagiert auf sich wandelnde Marktanforderungen. Die Tatsache, dass sich dieser Ansatz in der Softwareentwicklung bewährt hat und auf Produktmanagement sowie Produktentwicklung übertragen werden kann, begründet die zunehmende Verbreitung von agilen Projektmanagement-Methoden über die IT-Wirtschaft hinaus.
L26 von Trumpf – Ein Beispiel für den Erfolg von Scrum
Eine voll automatische und intelligente Maschine zur Verarbeitung von Blech – L26, ein gigantischer Kasten, der Metallplatten selbst mit Lasern zuschneidet, presst und als fertige Produkte ausspuckt, wurde vom Unternehmen Trumpf mit einem Scrum Ansatz entwickelt. Die Automatisierung der Prozesse, der Einsatz von KI und viele weitere Aspekte führten dazu, dass die Arbeit von Maschinenbauern und Programmierern immer mehr miteinander verschmolz. Folglich komplex war die Produkt-Neuentwicklung, die lediglich mit einer gemeinsamen Vision begann.
Man verfolgte diese Vision, war zeitgleich jedoch mit den sich überschlagenden Entwicklungen der Digitalisierung konfrontiert. Wie, wenn nicht mit einem agilen Ansatz, hätte Trumpf auf diese dynamischen Entwicklungen reagieren sollen? Schließlich war man Weltmarktführer und wollte diese Position verteidigen. Durch die agile Produktentwicklung und das agile Produktmanagement mit Scrum bewahrt sich Trumpf die Marktführerschaft gegenüber der internationalen Konkurrenz und schafft darüber hinaus ein Produkt von nie da gewesener Qualität. All das mit begrenzten Ressourcen und in festgelegten Zeitintervallen.1
Mehr zu den Erfahrungen von Trumpf finden Sie in einer Fallstudie in einem späteren Kapitel dieses Beitrages.
Scrum leicht erklärt: Werte
Scrum ist weniger ein Plan mehr ein Prozess, der sich beliebig oft wiederholen lässt und an dessen Ende immer ein brauchbares Ergebnis steht. Um mit Scrum zu arbeiten, braucht es ein modernes Verständnis für Projektmanagement und Projektarbeit. Klassische Hierarchien und Positionen – das Silodenken – muss aufgegeben werden. Jeder im Team soll immer all seine Ideen und Fähigkeiten einbringen. Keiner soll sich hinter einer Jobbezeichnung verstecken oder lediglich die Rolle des Testers oder Architekten einnehmen. Scrum erfordert von allen stets über den Tellerrand hinaus zu blicken und auf einer gemeinsamen Ebene zu agieren.
ERFOLGREICH SEIN MIT SCRUM!
ERFOLGREICH SEIN MIT SCRUM!
Scrum leicht erklärt: Rollen statt Positionen
Nur weil bei Scrum alle auf derselben Ebene agieren, heißt dies nicht, dass den Akteuren nicht unterschiedliche Rollen zufallen. Seitens Scrum gilt es insgesamt vier Rollen zu berücksichtigen. Die erste Rolle fällt Personen zu, die ein Interesse an dem Produkt haben. Ob nun Kunden, die Geschäftsführung oder Investoren, die gerade wegen dem Produkt in das Unternehmen investieren – sie alle werden im Rahmen von Scrum als Stakeholder bezeichnet. Obwohl Stakeholder nicht zwangsläufig am administrativen und operativen Geschehen im Unternehmen beteiligt sind, haben sie eine entscheidende Rolle. Denn sie sind es, für die das Produkt gestaltet wird. Ihr Feedback ist der wertvolle Beitrag, der dem Scrum-Team die Entwicklung am Zahn der Zeit ermöglicht.
Aufgenommen wird dieses Feedback vom Product-Owner. Er ist mit einem Produktmanager und Key-Account-Manager vergleichbar und steht mit allen Scrum-Rollen im permanenten Austausch. Er wertet das Feedback der Nutzer, beispielsweise aus Umfragen aus, ist der erste Ansprechpartner für den Einkauf des Kunden und berücksichtigt zugleich die Wünsche der Geschäftsführung. Letztendlich obliegt es ihm und ggf. seinem Team den Markt im Blick zu behalten und Anforderungen an das Scrum Team zu formulieren.
Dabei fungiert er als Schnittstelle zwischen den Stakeholdern und dem Team. Er übersetzt die Anforderungen ins Technische, formuliert also ein konkretes „Was“ nicht jedoch das „Wie.“ Dadurch werden Übersetzungsfehler, wie sie bei der Wasserfall-Methode durchaus vorkommen können, vermieden. So weiß das Scrum-Team genau, welches Problem es zu lösen gilt und entwickelt nichts am Bedarf vorbei.
Besagtes Scrum-Team setzt diese Anforderungen dann um. Oftmals handelt es sich um ein interdisziplinäres Projektteam, dass – sofern man streng nach Scrum geht – eine Zahl von neun Mitarbeitern nicht übersteigen soll. Unterstützt wird das Scrum Team vom sogenannten Scrum Master, der als Mediator und Methodenkenner alle im Unternehmen bei der Implementierung und Einhaltung von Scrum unterstützt.
Scrum leicht erklärt: Sprints statt Meilensteine
Die Wasserfall-Methode geht immer erst zum nächsten Meilenstein voran, wenn der vorherige zur vollsten Zufriedenheit erreicht ist. Meilenstein- und Anforderungsgetrieben ist dieses Verhalten. Zeit spielt keine Rolle. Hier liegt der größte Unterschied zu Scrum: Scrum ist Zeit- und Ressourcen- statt meilensteingetrieben. Es stellt sich die Frage, in welchem Zeitraum welchen Anforderungen wie entsprochen werden kann. Durch die Limitierung von Zeit und Ressourcen und den Scrum-Ansatz ist das Projektteam dazu gezwungen und zugleich befähigt, jene Lösungsansätze zur Erreichung des Ziels zu wählen, die das beste Verhältnis von Qualität und Geschwindigkeit mit sich bringen.
Während sich die Begrenzung der Ressourcen auf die Größe des Teams und deren Möglichkeiten auswirkt, kommt dem Faktor Zeit eine besondere Rolle zu. Die festen Intervalle zur Umsetzung der jeweiligen Lösungen werden bei Scrum Sprints genannt und durch eine Reihe an Werkzeugen gesteuert. Ein Sprint dauert meist zwischen zwei bis vier Wochen und muss an seinem Ende immer ein brauchbares Ergebnis bringen. Sollten manche Aufgaben, mancher Feinschliff nicht in dieser Zeit zu bewerkstelligen sein, so soll dies zum Abschluss des Sprints festgehalten und bei Bedarf im nächsten Sprint berücksichtigt werden.
Scrum leicht erklärt: Anforderungskatalog / Projektgedächtnis – Product Backlog
Informationen wie diese fließen in das Product Backlog ein. Es ist der Anforderungskatalog, den der Product Owner auf Basis seiner Kommunikation mit den Stakeholdern erstellt. Aus den Informationen, die in diesem Dokument festgehalten sind, werden Aufgaben abgeleitet. Dabei muss jede Aufgabe in ihrem Kontext die Anforderungen einer sogenannten User Story erfüllen.
Exkurs: Was ist eine User-Story?
Eine User-Story, zu Deutsch Anwendererzählung, ist meist eine Abfolge von ein bis zwei Sätzen, die eine Funktion bzw. Anforderung beschreiben und meist nach der folgenden Struktur gestaltet sind:
„Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>“
Ein Beispiel für eine User-Story:
Als Mechatroniker möchte ich nach dem Start der Fräse meine zuletzt eingegebene Konfiguration sehen, um Zeit zu sparen, falls ich dasselbe Teil nochmal fertigen möchte.
Aus dieser User-Story kann die Lösung wie folgt abgeleitet werden:
Beim Start meiner Fräse werde ich gefragt, ob die letzte Konfiguration geladen werden soll. Beim Ausschalten der Fräse werde ich gefragt, ob die letzte Konfiguration gespeichert werden soll.
Der Product Owner übersetzt diese User Story in technische Anforderungen und kommuniziert diese präzise an das Scrum-Team. So wird die gewünschte Funktion in der nächsten Produktversion verfügbar.
Gestaltet werden User-Storys nach dem Akronym „INVEST.“ Die in ihm festgehaltenen Regeln sichern Sinnhaftigkeit und Machbarkeit der jeweiligen Aufgabe. Entspricht eine Aufgabe nicht den folgenden Punkten, darf sie in Rahmen von Scrum nicht vergeben und bearbeitet werden. Auch hier unterstützt der Scrum Master.
| Independent | User Storys sollten nicht voneinander abhängen. |
| Negotiable | User Storys sollten keine Umsetzungsdetails festlegen. |
| Valuable | Ihre Umsetzung erhöht den Produkt-Gebrauchswert für den Endkunden. |
| Estimable | Der Aufwand für die Umsetzung muss abschätzbar sein. |
| Small | Der Aufwand für die Umsetzung sollte überschaubar (Tage / Wochen) sein. |
| Testable | Erfolgreiche Umsetzung sollte mit objektiven Kriterien überprüfbar sein. |
Zu Beginn eines jeden Sprints werden die Aufgaben im Anforderungskatalog der Stakeholder (Product Backlog) neu geordnet und priorisiert. Die Ziele für den kommenden Sprint werden aus ihnen abgeleitet. Dabei steht das WAS im Vordergrund, nicht jedoch das WIE. Das Scrum Team kann und soll selbst denken, autark und autonom arbeiten. Es organisiert sich selbst und nutzt u. a. den Daily Scrum, ein tägliches Meeting, um sich für den kommenden Tag abzustimmen.
Alle neu gewonnenen Erkenntnisse werden zum Ende des Sprints in das Product Inkrement – das Gedächtnis des Projektes – aufgenommen und bei weiteren Sprints berücksichtigt. Dieses zu führen, unterstützt der Scrum Master. Zudem organisiert er die teaminterne Feedback-Runde zum jeweiligen Sprint. Diese soll eine ehrliche Betrachtung des Sprints und der Arbeit des Teams ermöglichen. Denn nur wenn wunde Punkte angesprochen werden, kann das Team auf diese reagieren. Der Scrum Master wirkt hier besonders als Mediator und Impulsgeber mit.
Scrum leicht erklärt: Minimum Viable Product – das brauchbare Ergebnis am Ende des Sprints
Nach jedem Sprint muss ein funktionsfähiges Basisprodukt rauskommen. Dieses Basisprodukt wird als Minimum Viable Product (MVP) bezeichnet und ist oftmals die erste Version eines Produktes oder einer Dienstleistung, die dem Kunden zur Verfügung gestellt wird, um Feedback zu sammeln. Die Schaffung eines MVP unter Zeitdruck zwingt das Team zu einer ergebnisorientierten Selbstorganisation.
Natürlich haben Ausgangslage, verfügbarer Zeit und Ressourcen Einfluss auf das Ergebnis eines Sprints. Doch im Idealfall entsteht so bereits nach dem ersten Sprint ein brauchbarer Prototyp, aus dessen Nutzung sich Erkenntnisse für die nächsten Sprints ziehen lassen. All diese Erkenntnisse aus dem Sprint, sowie das Feedback der Stakeholder zum MVP, werden im Product Inkrement gesammelt. Im Vergleich mit dem Product Backlog dient es als Maßstab des Fortkommens je Sprint und liefert zugleich Impulse für die Kommenden.
Sollte das Product Inkrement dem Produkt / der Dienstleistung eine Marktreife bescheinigen, so wird im kommenden Sprint die Abnahme bzw. der Roll-out eingeplant. Scrum nimmt sich für diesen Prozess bewusst Zeit, denn kein Produkt soll schnell bis zur Deadline fertig werden müssen. Dieser Grundsatz eliminiert Fehlerpotenziale und trägt damit entschieden zum Erfolg bei.
Scrum leicht erklärt:
Zusammenfassung: Planen, Machen, Reflektieren, Plan anpassen – Wiederholen
Scrum ist eine Methode zur Gestaltung eines Entwicklungsprozesses. Anforderungen werden eingeholt, Aufgaben abgeleitet und priorisiert. Die Aufgaben werden von fähigen Köpfen eigenverantwortlich bearbeitet und gelöst und das Ergebnis reflektiert. Das gelernte wird beim nächsten Mal berücksichtigt – man arbeitet sich von Version zu Version. Man optimiert das Produkt, genauso aber auch die internen Prozesse – das Unternehmen und seine Mitarbeiter. Man gibt sich ein bestimmtes Zeitlimit für bestimmte, erreichbare und sinnvolle Ziele und lässt dabei Raum für kreative Lösungen. Das ist Scrum.
Wozu ist Scrum gut? Produktentwicklung!
Man merkt, dass Scrum aus der Softwareentwicklung stammt. Doch gerade im Hinblick auf Produktentwicklung bietet Scrum große Potenziale für allerlei Branchen. Denn Produkte müssen jederzeit dem Markt und seinen Akteuren gerecht werden. Und der Markt ist seit der Globalisierung und Digitalisierung dynamischer denn je.
Produktlebenszyklen beispielsweise sind kürzer geworden. Bei Smartphones finden wir mindestens einmal im Jahr ein neues Modell eines jeden Herstellers auf dem Markt. Und auch die Automobilindustrie hat ihr Tempo bei Innovationssprüngen erhöht: Die Tatsache, dass am Ende eines jeden Sprints ein potenziell brauchbares Produkt zur Verfügung steht, verringert Go-to-Market Zeiten massiv. Damit ist Ihr Produkt näher am Bedarf des Kunden, geht mit dem Trend und positioniert sich so zeitgemäß und stark im Markt. L26 von Trumpf ist genau das gelungen. Die voll automatische Blechmaschine wurde am Zahn der Zeit entwickelt und gilt als Revolution aus dem Hause eines Weltmarktführers. Sie ist ein ideales Beispiel für eine Scrum basierte Produktentwicklung.
Transformation von Klassisch zu Agil
Dabei war L26 ursprünglich gar nicht agil geplant. Die Geschäftsführung formulierte das ehrgeizige Ziel, die Maschine zu einem zeitnahen Messetermin zu präsentieren. Dieser Umstand führte dazu, dass das Projektmanagement nach Projektstart schnell zu der Erkenntnis kam, dass der ambitionierte Termin nicht zu halten war. Folglich öffnete man sich für einen Paradigmenwechsel, wandte das Konzept der begrenzten Zeit aus Scrum auf das Projekt an und transformierte es so innerhalb kürzester Zeit von einem klassischen in ein agiles Projekt.
Die Stellschrauben Zeit und Umfang waren fix, daher blieb nur die Stellschraube der Ressourcen. Da die Geschäftsführung von Trumpf den Messetermin unbedingt einhalten wollte, wies man dem Produkt die Ressourcen zu, die es brauchte. Der Termin konnte eingehalten, die Erwartungen übertroffen werden. Seitdem wird L26 agil weiterentwickelt und sichert so die Position des Unternehmen Trumpf als Weltmarktführer in seinem Segment. Wenn Sie mehr über diesen Anwendungsfall erfahren möchten, klicken Sie hier, um zur Trumpf Fallstudie zu gelangen.
Ein Werkzeug, um Zukunftsfähigkeit zu sichern
Ein weiterer Aspekt, bei dem Scrum Anwendung finden kann, ist die Erarbeitung der Unternehmensstrategie. Ob die Ausrichtung des Unternehmens auf den Markt, die internen Prozesse oder schlicht Themen wie Digitalisierung oder Lean Transformation – mit Scrum haben Sie eine Methode an der Hand, die ideal ist, um Neues zu wagen und zu entwickeln. Um in kurzer Zeit mit gezielten Investitionen gute Ergebnisse zu erzielen.
Sicherlich kommt Ihnen beim Lesen dieser Zeilen ein Projekt in den Sinn, bei dem Scrum möglicherweise zu einem völlig anderen Ergebnis geführt hätte. Gerne erörtern wir mit Ihnen, inwieweit Scrum für zukünftige Projekte sinnvoll einsetzbar und vor allem ergebnisorientiert umsetzbar ist. Schreiben Sie uns!
Lesen Sie weitere spannende Artikel:
ERP – drei typische Fehler bei der Einführung
Artikel:ERP Einführung - drei typische FehlerWer ERP im Mittelstand oder anderen Unternehmensgrößen einführt, ohne die Prozesse vorher nach Lean ausgerichtet zu haben, steht unweigerlich vor Problemen mit zum Teil verheerenden Auswirkungen für einzelne Abteilungen...
Was sind ERP-Systeme
Artikel:ERP-Systeme verstehenViele mittelständische Unternehmen wollen Prozesse effizienter gestalten und digitalisieren. Um wettbewerbsfähig zu bleiben und erfolgreich zu expandieren, benötigen Mittelständler effiziente Tools und Systeme. Dabei sehen sie sich...
Wissenstransfer und Suchzeitoptimierung im Mittelstand
Artikel:Wissenstransfer und Suchzeitoptimierung im Mittelstand Für viele Geschäftsführer gehört die folgende Situation zum Tagesgeschäft: Unbewusst werden durch die Kosten, die aufgrund von typischen Betriebsproblemen entstehen, Investmentanträge für mehrere Tausende...