TopMenue

10 Grundsätze für eine erfolgreiche Implementation von Scrum

scrum.that.runs

Ein Teil dieser Seiten wurde ursprünglich für doktor-scrum.de geschrieben und ziehen nun hierher nach scrumcess.de um; leider sind sie aber inhaltlich noch nicht vollständig auf scrumcess.de umgearbeitet. Zudem ist es durchaus möglich, dass die enthaltenen Links noch ins Leere zeigen, bzw. noch auf doktor-scrum.de verweisen.
Ich bitte Sie, das zu entschuldigen.

  1. Veränderte Sichtweisen werden offen und unvoreingenommen akzeptiert  ^
    Scrum unterscheidet sich in wesentlichen Punkten von anderen Softwareentwicklungsprozessen und nimmt zum Teil gegenteilige Standpunkte gegenüber klassischen Managementmethoden ein. Aus diesem Grund sollten die beteiligten Personen offen und unvoreingenommen gegenüber veränderten Sichtweisen sein und über ein ausgeprägtes agiles Mindset verfügen oder es sich im Zuge der Implementation aneignen.
  2. Konsequent zielorientierte Handlungen unterstützen das Projekt  ^
    Für eine erfolgreiche Einführung sollten 5-9 Entwickler, jeweils ein designierter Scrum-Master und Product-Owner und eine angemessene Zeitspanne für die Implementation des Scrum-Prozesses zur Verfügung stehen. Soll die Einführung im Zuge eines Einführungs- oder Evaluationsprojektes über „Learning by Doing“ erfolgen, sollten die genannten Personen diesem Projekt in Vollzeit und dem Projekt ein angemessenes Thema zur Verfügung stehen. Darüber hinaus sollte die Einführung von einem erfahrenen, ggf. externen Scrum-Coach durchgeführt oder geleitet werden.
  3. Effizient und konsequent praktiziertes Teamwork ist essentiell  ^
    Die Mitglieder des Entwicklungsteams sollten selbstbewusste, teamfähige und kommunikative Softwareentwicklungsexperten sein, die für Veränderungen offen sind. Ihnen sollte bewusst sein, dass alle im Team vorhandenen Ressourcen und Fähigkeiten trotz vielleicht unterschiedlicher Ausprägung wertvoll sind und zum dauerhaften und nachhaltigen Erfolg des Teams beitragen. Der Erfolg von Selbstdarstellern, Einzelkämpfern und exaltierten Diven ist dagegen oftmals von eher kurzfristiger, fast ausschließlich auf sich selbst ausgerichteter, plakativ orientierter Natur und für das Team und auf das zu erreichende Ziel bezogen nur sehr selten von nachhaltigem Wert.
  4. Teams werden in ihrer freien Entfaltung konsequent unterstützt  ^
    Weder Product-Owner, noch Scrum-Master sollten weder zuvor, noch aktuell oder absehbar zukünftig weisungsberechtigte Vorgesetzte des Entwicklungsteams / ehemals Projektleiter des Projektes sein oder gewesen sein. Auch wenn eine existierende Weisungsbefugnis für die Zeit des Projektes offiziell und ausdrücklich ausgesetzt wird, wirkt sich ein solches Abhängigkeitsverhältnis — egal ob zuvor, aktuell oder erst zukünftig (aber absehbar) aktiv — nachhaltig hemmend auf die konkrete Ausprägung der Selbstbestimmung und Selbstorganisation des Entwicklungsteams aus und schränkt die ausdrücklich durch Scrum angestrebte Unabhängigkeit und produktive Zusammenarbeit auf Augenhöhe im Gesamtkontext ein, da die Entwickler zumindest potentiell Konsequenzen ihres Handelns befürchten müssen, wenn sie die Belange ihrer Rolle mit dem notwendigen Nachdruck vertreten.

    Ist es unumgänglich, ehemalige, aktuelle oder bekanntermaßen zukünftige Vorgesetzte des Entwicklungsteams oder den vorherigen Projektleiter des Teams die Rolle des Product-Owners oder des Scrum-Masters einnehmen zu lassen, müssen sich diese in besonderem Maße an Scrum adaptieren und konsequent umdenken, indem sie sich für alle Beteiligten deutlich erkennbar aus der alten kommandoorientierten Struktur lösen und sich in die professionell-partnerschaftliche Struktur von Scrum eingliedern. Zudem muss sich das Entwicklungsteam ausdrücklich auf diese für sie potentiell problematische Konstellation einlassen.

    In so einer Situation ist das Hinzuziehen eines externen Scrum-Coaches dringend zu empfehlen, um die Prägung des Verhältnisses zueinander auch in der Praxis von einem vertikalen Abhängikeitsverhältnis (oben / unten) in ein horizontales, partnerschaftliches Verhältnis auf gleicher Höhe umzustellen.

  5. Gut funktionierende Teams sind mehr als die Summe ihrer Teile  ^
    Product-Owner und Scrum-Master, das Entwicklungsteam und die Stakeholder sollten selbstbewusste, kommunikative, teamfähige und für Veränderungen offene Experten ihrer jeweiligen Fachdomäne sein, denen bewusst ist, dass man in einem gut aufgestellten Team mehr erreichen kann, als nur die Summe seiner einzelnen Aktivitäten.
  6. Nur gleichberechtigte Partner auf Augenhöhe arbeiten optimal Hand in Hand  ^
    Die jeweilige innere Sicht von Product-Owner, Scrum-Master, Entwicklungsteam und Stakeholdern einander gegenüber sollte immer und zu jeder Zeit die Sicht selbstbestimmter Partnern auf Augenhöhe und nicht die Sicht von Weisungsbefugten / Weisungsempfängern sein.
  7. Allen Beteiligten ist die Bedeutung des Vorhabens bewusst  ^
    Ein unentschlossenes, in der Sache unsicheres Management überträgt seine Unsicherheit und Unentschlossenheit auf das Team. Unabhängig davon, ob die Entscheidung für Scrum bereits gefallen ist und ein Einführungsprojekt durchgeführt wird oder ob die Eignung von Scrum für das Unternehmen zunächst im Laufe der Durchführung eines Evaluationsprojektes überprüft wird, sollte das Management dieses Projekt genauso entschlossen, konsequent und zielorientiert verfolgen, wie jedes andere produktive Projekt auch. Steht das Management nicht einhundertprozentig hinter dem Vorhaben, wird das Gleiche für das Team gelten, was zu einem nicht mehr unabhängigen Ergebnis führt.
  8. In der Einführungsphase wird der Prozess so akzeptiert, wie er ist  ^
    Greift man in die hochoptimierten Abläufe eines organisatorischen Körpers, wie Scrum ihn darstellt, ein, ohne Erfahrungen mit den dort z.T. sehr diskret und zumeist äußerst subtil ablaufenden zwischenmenschlichen Prozessen zu haben, gerät man in der Absicht, eine Veränderung des Prozesses herbeiführen zu wollen, sehr leicht in die Gefahr, mit einer solchen Veränderung das intuitive Zusammenspiel des Ganzen zu stören. Das Ergebnis ist dann, dass man den prinzipiell gut ausbalancierten Prozess aus dem Gleichgewicht bringt, ihn in seiner Leistungsfähigkeit und seinen Synergiepotenzialen einschränkt und dadurch das erwünschte Entstehen von Synergieeffekten, die den eigentlichen Ertrag des optimierten Zusammenspiels aller Komponenten darstellen, einschränkt und im schlimmsten Fall sogar gänzlich zum Erliegen bringt.

    Änderungen und Anpassungen, auch zum wohlgemeinten Zweck von Optimierungen, sollte man daher erst dann erwägen, wenn man ausreichende Erfahrungen mit den z.T. sehr subtilen Abläufen und Zusammenhängen des Prozesses verfügt, um die sich ergebenden Auswirkungen der Veränderungen auf das Zusammenspiel aller im Prozess aktiven Kräfte und damit auf die Produktivität des gesamten Teams abschätzen zu können. Dies trifft insbesondere dann zu, wenn die Veränderungen am Prozess im Laufe der Einführung von Scrum mit einem Team vorgenommen werden, dessen Mitglieder noch keine oder nur wenig Erfahrung mit Scrum haben.

  9. Scrum-Coaches sind in der Einführungsphase die führenden Teammitglieder  ^
    Der Scrum-Master als Scrum-Coach muss sehr kompetent in Scrum sein und bereits praktische Erfahrungen gesammelt haben; nur davon gehört und/oder ein Buch gelesen zu haben, ist für eine erfolgreiche Implementation i.A. nicht ausreichend. Hat er noch keine praktische Erfahrung, sollte ein externer Scrum-Coach hinzugezogen werden, der den Scrum-Master in der Einführung anleitet und unterstützt.
  10. Stakeholder sind wesentliche Mitglieder der Teams  ^
    Obwohl die Stakeholder auf die Entscheidung, ob Scrum in einem Unternehmen eingeführt wird oder nicht, zunächst einmal keinen oder nur einen geringen Einfluss haben, sind sie wichtiger Bestandteil des Prozesses und ebenfalls gleichberechtigter Partner auf Augenhöhe. Management und designiertes Scrum-Team sollten sich daher bewusst sein, dass sie, wenn sie ihre Projekte nach den Prinzipien von Scrum durchführen, jeweils innerhalb der Projekte einen Partner haben werden, der in wesentlichen Teilen von außerhalb agiert, aber trotzdem jederzeit erheblichen Einfluss auf den inneren Staus des Projektes nehmen kann.
[zurück zum Seitenanfang]


No comments yet.

Schreibe einen Kommentar

V1503130747DE