{"id":9723,"date":"2017-08-02T08:00:49","date_gmt":"2017-08-02T06:00:49","guid":{"rendered":"http:\/\/ikm-hslu.ch\/omm-blog\/?p=8464"},"modified":"2026-02-02T21:26:58","modified_gmt":"2026-02-02T20:26:58","slug":"3-stolpersteine-der-agilen-projektmanagement-methode-scrum","status":"publish","type":"post","link":"https:\/\/hub.hslu.ch\/ikm\/2017\/08\/02\/3-stolpersteine-der-agilen-projektmanagement-methode-scrum\/","title":{"rendered":"3 Stolpersteine der agilen Projektmanagement-Methode Scrum"},"content":{"rendered":"\n

<\/p>\n\n\n\n\n\n\n\n

*Quelle: http:\/\/ikm-hslu.ch\/omm-blog<\/a>, 30. April 2017.<\/i><\/p>\n\n\n\n

Agile Projektmanagement-Methoden setzen auf Flexibilit\u00e4t und Adaption. Sie unterscheiden sich in zwei wesentlichen Punkten von klassischen Ans\u00e4tzen wie beispielsweise dem Wasserfallmodell. Erstens ist das Vorgehen ein anderes. Am Anfang eines Projekts steht nicht wie bei klassischen Modellen eine umfangreiche und ausf\u00fchrliche Planung sondern die Planung verl\u00e4uft agil mit kurzfristigen Absprachen im Team. Zweitens sind die definierten Rollen der Beteiligten und die Zusammensetzung des Teams ein wesentlicher Unterschied zur klassischen Projektplanung. Das Team ist nicht hierarchisch sondern interdisziplin\u00e4r zusammengesetzt und organisiert sich weitgehend selbst.<\/p>\n\n\n\n

\"scrum_erklaerung\"<\/a> Von der Vision zum Produkt: der Scrum-Prozess schematisch dargestellt.<\/p>\n\n\n\n

Scrum kurz erkl\u00e4rt<\/h2>\n\n\n\n

Der Begriff Scrum (zu deutsch \u00abGedr\u00e4nge\u00bb) stammt aus dem Rugby. Er beschreibt einen dichten Haufen von Spielern welche um den Ball k\u00e4mpfen. \u00dcbertragen auf das Projektmanagement beschreibt Scrum worum es bei dieser agilen Projektmanagement-Methode haupts\u00e4chlich geht: Dynamik, Flexibilit\u00e4t und kurze, t\u00e4gliche Meetings (Daily Scrums) in welchen sich die Teammitglieder abstimmen. Im Scrum-Modell werden Projekte nicht starr anhand eines langfristig angelegten Plans durchgef\u00fchrt. Die Planung erfolgt anhand sogenannter Sprints (ein- bis vierw\u00f6chige Bearbeitungszyklen) in denen die vorab definierten Teilaufgaben bearbeitet, getestet und finalisiert werden. In einem Backlog werden die Tasks gesammelt, beschrieben und priorisiert. Das Backlog dient als Massnahmenplan f\u00fcr die einzelnen Sprints.<\/p>\n\n\n\n

Das Team<\/h3>\n\n\n\n

Ein Team besteht aus zirka vier bis zehn Personen und wird fach\u00fcbergreifend, beispielsweise aus Gestaltern, Entwicklern, Testern und Redakteuren zusammengestellt. F\u00fcr das selbstst\u00e4ndig agierende Team werden folgende drei Rollen definiert: Ein Product Owner, ein Scrum Master und das Projektteam.<\/p>\n\n\n\n

Der Product Owner<\/strong> vertritt die Stakeholder des Projektes, hat die Budgetverantwortung und pflegt das Product Backlog. Er sortiert und priorisiert die Aufgaben im Product Backlog und stellt sicher, dass das Projektteam die Aufgaben versteht.<\/p>\n\n\n\n

Der Scrum Master<\/strong> ist Unterst\u00fctzer f\u00fcr das Projektteam. Er ist verantwortlich f\u00fcr den Scrum-Prozess und stellt sicher dass dieser korrekt abl\u00e4uft und alle Beteiligten ihre Rollen einhalten. Weiter sch\u00fctzt er das Projektteam vor Eingriffen und sorgt daf\u00fcr dass Hindernisse beseitigt werden. Er hat das komplette Projekt im Blick und moderiert er die Daily Scrums.<\/p>\n\n\n\n

Das Projektteam<\/strong> verantwortet die Umsetzung und die Qualit\u00e4t des Produkts. Im Team gibt es keine Hierarchie. Jeder hat dieselben Rechte und Pflichten. Das Projektteam organisiert alle Aufgaben selbst und definiert welches Mitglied welche Aufgabe umsetzt.<\/p>\n\n\n\n

Quelle: YouTube Video \u00ad\u00ad\u2013 mITSM GmbH.<\/p>\n\n\n\n

Stolperstein 1 \u2013 Wenn Scrum top-down eingef\u00fchrt wird<\/h2>\n\n\n\n

Eine agile Methode wie Scrum erfolgreich einzuf\u00fchren bedeutet eine komplette Ver\u00e4nderung der Firmenkultur. Das Verlangen nach starren Strukturen und linearen Prozessen muss, in den K\u00f6pfen aller Beteiligten, aufgel\u00f6st werden. Wenn Scrum als Idee des Managements oder der Gesch\u00e4ftsf\u00fchrung eingef\u00fchrt wird, sind Konflikte vorprogrammiert. Vor allem dann, wenn Scrum mit der Absicht \u00abwir m\u00fcssen mal eben agil werden und frischen Wind in die Firma bringen\u00bb oder \u00e4hnlichen Motiven initiiert wird, ist der Einsatz von Scrum zum Scheitern verurteilt. Die notwendige Kultur f\u00fcr Scrum muss zuerst aufw\u00e4ndig geschaffen werden. Wenn die Mitarbeitenden nicht rechtzeitig eingebunden werden, entwickeln sie eine Abwehrhaltung oder kommen schlichtweg nicht mit den Ver\u00e4nderungen klar. Es ist ratsam, Scrum begleitet von Schulungen einzuf\u00fchren um alle Beteiligten langsam an die Methode zu gew\u00f6hnen.<\/p>\n\n\n\n

Scrum ist nicht f\u00fcr jede Firma in jedem Fall ein Allheilmittel. Es ist ratsam, bei Problemen nach der Ursache zu forschen, bestehende Prozesse zu analysieren und rechtzeitig in den Dialog mit allen Beteiligten zu treten. Scrum als wunderwirkende Hauruck-Aktion einzuf\u00fchren, empfiehlt sich nicht.<\/p>\n\n\n\n

Stolperstein 2 \u2013 Wenn Agilit\u00e4t falsch interpretiert wird<\/h2>\n\n\n\n

Agiles Projektmanagement bedeutet nicht, dass dauernd spontane Einf\u00e4lle eingeflochten werden. Gerade innerhalb eines Sprints gilt es die Regeln zu beachten. Die pro Sprint definierten Anforderungen sollen nicht ver\u00e4ndert, erg\u00e4nzt, gel\u00f6scht oder in ihrer Priorit\u00e4t ver\u00e4ndert werden. Es besteht die Gefahr, dass spontane Einf\u00e4lle mit Bemerkungen wie \u00abdeshalb arbeiten wir doch agil\u00bb berechtigt werden und in laufende Sprints eingegriffen wird. Wenn neue Anforderungen vom Management kommen, ist es f\u00fcr den Product Owner besonders schwierig sich ans Backlog und die Tasks im aktuellen Sprint zu halten.<\/p>\n\n\n\n

Vertrauensvolle Zusammenarbeit auf Augenh\u00f6he ist im Scrum zentral. Das gilt auch f\u00fcrs Management. Diese Kultur muss jedoch, wie im ersten Stolperstein beschrieben, vorab erfolgreich geschaffen werden. Wenn die Regeln innerhalb eines Sprints nicht befolgt werden besteht die Gefahr, dass das Team nie zu einem zufriedenstellenden Resultat kommt. Das Backlog soll durch neue, kreative Ideen anwachsen. Diese m\u00fcssen aber stets priorisiert werden. Nur eine vorab definierte Anzahl der Tasks wird pro Sprint bearbeitet. \u00dcbertriebene Agilit\u00e4t f\u00fchrt schlussendlich bei allen Beteiligten zur Frustration.<\/p>\n\n\n\n

Stolperstein 3 \u00ad\u2013 Wenn die Rollen nicht umgesetzt werden<\/h2>\n\n\n\n

Das Modell Scrum sieht drei spezielle Rollen vor: der Product Owner, der Scrum Master und das Projektteam. Die Rolle des Chefs oder des klassischen Projektleiters ist nicht dabei, obwohl zwei Rollen auf den ersten Blick \u00e4hnlich zu sein scheinen. Erstens hat der Product Owner wohl die Budgetverantwortung und treibt das Projekt im Sinne der Stakeholder voran, ist aber nicht der Chef eines Teams. Zweitens verantwortet der Scrum Master zwar den Scrum-Prozess und agiert als Dienstleister f\u00fcr das Projektteam, \u00fcbernimmt aber nicht die Rolle eines Projektleiters. Die komplette Projektkommunikation ist direkt und transparent. Allen im Team ist die Gesamtheit eines Projekts jederzeit bekannt.<\/p>\n\n\n\n

In hierarchisch gef\u00fchrten Teams k\u00f6nnen die Rollenverteilung sowie die offene Kommunikation, bei der Einf\u00fchrung von Scrum, zu Verunsicherungen f\u00fchren. Denn weder der Product Owner noch der Scrum Master definieren, welches Projektteammitglied welche Aufgabe wie zu erledigen hat noch verlangen sie einen Rapport. Es ist im Scrum wichtig, dass das Team sich selbst organisiert, alle ihre Aufgaben selbstst\u00e4ndig planen und direkt miteinander absprechen. Allerdings gilt es zu bedenken, dass nicht jeder Mitarbeitende bereit oder f\u00e4hig dazu ist, diese Rolle ohne weitere Unterst\u00fctzung, zeitnah einzunehmen.<\/p>\n\n\n\n

Fazit<\/h2>\n\n\n\n

F\u00fcr Scrum muss in erster Linie die Denkweise der kompletten Firma ver\u00e4ndert werden und das geschieht nicht \u00fcber Nacht. Um den agilen Wasserfall, die Vermischung einer traditionellen Projektmanagement-Methode mit einer agilen Methode zu verhindern, muss gen\u00fcgend Zeit in die Einf\u00fchrung investiert werden. Scrum funktioniert weder als Befehl vom Management noch kann die Methode nebenbei eingef\u00fchrt werden. Sinn und Zweck von Scrum m\u00fcssen allen Beteiligten klar sein. \u00dcberschnelle Ver\u00e4nderungen f\u00fchren zu Unsicherheiten und Frustrationen bei den Mitarbeitenden.<\/p>\n\n\n\n

Agiles Projektmanagement bedeutet nicht, dass un\u00fcberlegt vorgegangen wird. Die Pflege und Abarbeitung des Backlogs ist eine Schl\u00fcsselaufgabe im Scrum. Ans Backlog und die Laufzeit der Sprints m\u00fcssen sich alle Beteiligten halten, auch das Management. Grenzenlose Agilit\u00e4t f\u00fchrt einerseits dazu dass ein Projekt nie abgeschlossen werden kann, andererseits zum Verlust der Motivation im Team.<\/p>\n\n\n\n

Die drei speziellen Rollen (Product Owner, Scrum Master, Projektteam) m\u00fcssen verstanden und umgesetzt werden, nur so kann Scrum Freude bereiten. Die agile Methode bedingt eine nicht hierarchische, vertrauensvolle Zusammenarbeit aller Beteiligten. Von oben braucht es daf\u00fcr kontinuierlich Unterst\u00fctzung sowie Ermutigung und von unten Selbstverantwortung und -motivation.<\/p>\n\n\n\n

Und ihr?<\/h3>\n\n\n\n

Habt ihr Erfahrung mit agilen Projektmanagement-Methoden? Wenn ja, wie habt ihr diese implementiert so dass sich alle im Team in ihrer neuen Rolle wohl f\u00fchlen und die Projekte erfolgreich abgewickelt werden k\u00f6nnen?<\/p>\n\n\n\n

\n\n\n\n

Weiterf\u00fchrende Informationen:<\/h2>\n\n\n\n

Buchempfehlung:<\/strong><\/h3>\n\n\n\n