Welche Vorteile bietet Scrum?
Scrum setzt auf selbstorganisierte Teams, weil es Verantwortung und Handlungsfähigkeit dort hin bringt, wo die relevanten Informationen verstanden werden. Selbstorganisierte Teams treffen daher bessere Entscheidungen und finden effektivere Lösungen.
Die wichtigsten Instrumente für die Arbeit selbstgesteuerter Scrum-Teams ist Transparenz und Inspect & Adapt: über die feste Taktung von Feedbackscheifen stellt Scrum verlässliches und systemisches Lernen über alle Ebenen der Produktentwicklung her: fachlich, technisch und prozessual. Die Verantwortung dieser Reflexionsebenen wird festen Rollen (Product Owner, Enwicklungsteam, Scrum Master) und Events (Review, Daily-Scrums, Retrospektiven) übertragen. Er wird kontinuierlicher Verbesserungsprozess (KVP) genannt. Übrigens: Wir bieten sowohl Scrum-Schulungen also auch Schulungen zu „Retros“.
Was genau sind die Aufgaben des Scrum Masters?
Der Scrum Master trägt die Prozessverantwortung. Er sorgt dafür, dass Lernen auf allen Ebenen der Entwicklung stattfindet (fachlich, technisch und prozessual). Dies verfolgt er mit dem Zweck, die Effektivität des Teams im Sinne des Kunden zu steigern und erreicht dies insbesondere, indem er dem Team empathisch und verlässlich sein Verhalten spiegelt, für Transparenz der Arbeitsprozesse sorgt und das Team zur Reflexion über das eigene Verhalten anregt. Er hilft dem Team bei seiner gruppendynamischen Entwicklung und unterstützt es bei der Beseitigung von Hindernissen.
Der Scrum Master hat damit eine Führungsrolle ohne Weisungsbefugnis inne, womit er dem modernen Führungsansatz des "Führen durch Dienen" (Servant Leadership) folgt.
Was genau sind die Aufgaben des Product Owners?
Der Product-Owner ist für den wirtschaftlichen Erfolg des Produkts bzw. der Dienstleistung verantwortlich. Er sorgt für die Definition der fachlichen Anforderungen aus Kundensicht und priorisiert sie in der Reihenfolge ihres Geschäftswerts. Zu diesem Zweck hat er im Blick: das Geschäftsmodell, die Kunden, den Markt und die Technologien. Er bindet für seine Entscheidungen relevante Stakeholder so ein, dass ihre Anforderungen angemessen berücksichtigt werden und sie über den Entwicklungsfortschritt informiert bleiben.
Bei der Definition der Anforderungen arbeitet der Product-Owner in der Regel eng mit dem Entwicklungsteam zusammen, um das gemeinsame Verständnis geplanter Anforderungen zu maximieren.
Wozu brauche ich eine Zertifizierung zum Scrum Master oder Product Owner?
Eine Zertifizierung dient dem Zweck Dritter, dass die zertifizierte Person eine Ausbildung mit bekanntem Qualitätsstandard erhalten hat. Eine Zertifizierung kann daher helfen, die Kompetenzen für eine gewünschte Position gegenüber Dritten in einfacher Form glaubhaft zu machen und wirkt daher vertrauensfördernd. Das Wissen selbst kann natürlich über viele Kanäle und Medien erlangt werden wie z.B. über Scrum-Schulungen ohne Zertifizierung, Bücher und Coaching etc.
Was wird aus dem Projektleiter, wenn wir Scrum einführen?
Das lässt sich so pauschal nicht beantworten, weil es verschiedene Wege und Lösungen gibt. Häufig werden Projektleiter in der Rolle des Product Owner eingesetzt. Eine Überschneidung mit vorherigen Verantwortungsbereichen haben sie dadurch aber nur bedingt; meistens ist das die fachliche Ebene sowie die Kommunikation mit den Stakeholdern und mit dem Entwicklungsteam. War der Projektleiter zuvor eine Führungsperson, die anleitete und Entscheidungen traf, so ist der Product Owner nun Teil eines selbstorganisierten Teams mit dedizierten Rollenverantwortlichkeiten ohne Führungsauftrag.
Eine Überschneidung mit Verantwortungsbereichen des Scrum Masters können ebenfalls bestehen, sodass er dem Team hilft, sich selbst zu organisieren, den Prozess verantwortet und das Teams dabei unterstützt Hindernisse zu beseitigen. Es besteht dann aber immer die Gefahr, dass die Selbstorganisation des Teams nicht in Gang kommt, weil der Projektleiter in seine alte Führungsrolle zurückfällt und beispielsweise Entscheidungen selbst trifft, statt eine Entscheidungsfindung im Team zu moderieren. Es gibt aber auch Kontexte, in denen das Team so groß oder die Organisation so komplex ist, dass es weiterhin eines Projektleiters bedarf, der eine Außenschnittstelle des Teams neben dem Product Owner darstellt und für die Rahmenbedingungen des Teams sorgt, Ihnen dabei aber nicht hineinreden sollte.
Funktioniert Scrum auch für Festpreisprojekte?
Ja, Scrum kann auch in Festpreiskonstellationen eingesetzt werden. Allerdings schöpft man dann nicht das gesamte Potential von Scrum aus, was ja darin besteht, Abweichungen zu einem erwarteten Projektverlauf früh zu erkennen und zu adressieren. Eine komplette Vorausplanung ist aufwendig und zieht alle damit verbundenen Unsicherheiten nach sich. Dennoch bekommt man mit Scrum im Festpreisprojekt einen hilfreichen, weil realistischen Projektfortschritt, um ggf. gegensteuern zu können, falls das Projekt aus dem Ruder zu laufen droht.
Wenn es unbedingt ein Festpreis sein soll, dann lohnt es, sich über den sogenannten agilen Festpreis Gedanken zu machen. Dieser sieht vor, noch nicht erledigte Anforderungen gegen neue, unerwartete Anforderungen im Projektverlauf tauschen zu können, ohne den Preis zu verändern.
Welche Voraussetzungen braucht eine Organisation, damit Scrum funktioniert?
Zu den Grundvoraussetzung einer Scrum-Implementierung gehört die Unterstützung durch das Obere Management. Denn bevor Scrum zu positiven Effekten wie Termintreue und Effektivität führt, wird es zunächst zu Transparenz möglicher inkonsistenter Prozesse führen, deren Beseitigung auch Bereiche außehalb des Scrum-Teams betreffen können. Hierzu braucht es ein Management, das die agile Reise befürwortet und die Konsequenzen von Selbstorganisation mitträgt, damit es Alignment für das gesamte Unternehmen herstellen kann.
Zu den weiteren Erfolgsfaktoren zählen zeitlich stabile Entwicklungsteams, in denen sich Mitarbeiter:innen zugehörig und pychologisch sicher fühlen. Desweiteren ist Klarheit über die Scrum-Rollen herbeizuführen und der Product Owners sollte so besetzt sein, dass er:sie schnelle Entscheidungen fällen kann, ohne aufwändige Abstimmungsprozesse durchlaufen zu müssen.
Neben diesen recht groben Empfehlungen ist die innere Haltung aller Beteiligten kritisch. Scrum zieht einen Perspektivwechsel aller Beteiligten nach sich, denn mit Scrum sind Veränderungen verbunden, die einen klaren inneren Kompass erfordern. Dafür ist ein agiles Mindset entsprechend der agilen Werte und Prinzipien nötig.
Wie führt man Scrum am Besten ein?
Eine gute Orientierung zur Einführung von Scrum stellt das 8-stufige Modell für Veränderungsvorhaben nach Kotter dar. Das Obere Management sollte in einem ersten Schritt allen Beteiligten glaubhabt vermitteln, warum (dringlicher Grund) und wofür (erwartete Wirkung) eine Veränderung wie die Einführung von Scrum beabsichtigt wird. In der Folge sollten Förderer dieses Vorhabens in das erste Scrum-Team eingeladen werden, das als Pilotierung dient. Die Erfolge und Lernfortschritte dieses Pilotprojekts werden im folgenden kontinuierlich durch das Management innerhalb der Organisation kommuniziert. Dies sollte auch dann passieren, wenn nicht die gesamte Organisation in Zukunft agil arbeiten wird, denn in der Regel hat das Pilot-Team Abhängigkeiten zu nicht-agilen Abteilungen, wo es Fragen bezüglich der Schnittstellen geben wird.
Nach dem Pilotprojekt steht die Organisation vor der Frage, wie mit Scrum im weiteren Verlauf verfahren werden soll. War das Pilotprojekt erfolgreich, so kann Scrum schrittweise auf weitere Abteilungen ausgedehnt werden. Dazu kann es sinnvoll sein, die Mitglieder des Pilotprojektes als Multiplikatoren in den neuen Teams einzusetzen.
Was ist der nächste Schritt, wenn ich Scrum eingeführt habe?
Wenn Scrum für ein Produkt oder Service eingeführt wurde und die Scrum Rollen besetzt wurden, bedeutet das meistens, dass die Scrum-Events (Daily Scrum, Sprint Planning, Sprint Review, Retrospektive) als Regeltermine im 2-4 Wochentakt etabliert werden. Es kann sinnvoll sein, zunächst nur mit Dailys und der Retrospektive zu starten und die weiteren Meetings nach einer Einführungsphase hinzuzunehmen, um Klarheit darüber zu gewinnen, welche Meetings der vorherigen Struktur noch bzw. nicht mehr gebraucht werden In der Folge sollte das Team Klarheit darüber gewinnen, welche Wirkungen es mit Scrum erzielen will. Um darüber ein gemeinsames Bild zu gewinnen, eignet sich eine Agile Fluency Diagnostik. Sie hilft dem Team, Entwicklungsziele zu formulieren und was in der Team-Entwicklung dafür getan werden sollte. Entwicklungsziele könnten z.B. sein, die Termintreue zu erhöhen, das Forecasting zu verbessern, die Qualität zu erhöhen oder die Kundenzufriedenheit zu verbessern. Flankierend zu den Maßnahmen aus den Retrospektiven können zu diesem Zweck agile Praktiken eingeführt wie testgetriebene Entwicklung, Refactoring, Continuous Integration oder Pair-Programming.
Wenn Scrum in den Entwicklungsprojekten erfolgreich läuft, sollten die Schnittstellen zu angrenzenden Bereichen betrachtet werden. Dies kann zu der Entscheidung führen, vor- oder nachgelagerte Prozesse in den Verantwortungsbereich des Scrum-Teams zu integrieren oder die Bereiche dazu ebenfalls nach Scrum zu organisieren.
Verträgt sich Scrum mit sequenziellen Entwicklungsmethoden wie dem V-Modell oder Wasserfallmodell?
Sequenzielle Entwicklungsmethoden wie das V-Modell/Wasserfallmodell und Agile Methoden wie Scrum/Kanban liegen grundlegend unterschiedlichen Ansätzen zu Grunde: squenzielle Entwicklungsmethoden sind dokumentengetrieben, während agile Methoden wirkungsgetrieben sind. Dieser Unterschied führt zu so unterschiedlichen Organisationenstrukturen wie der Matrixorganisation im ersteren Fall und moderneren Organisationstrukturen wie dem Pfirsich-Modell einer soziokratischen Kreisorganisation im letzteren. Dies ist die Konsequenz aus dem Gesetz von Conway, das besagt, dass die äußere Struktur einer Organisation der Spiegel seiner inneren Kommunikationsstruktur ist.
Wie sollte also Arbeit an den Schnittstellen zwischen agilen und sequenziellen Teams organisiert werden? Diese Fragestellung stellt sich für die Zusammenarbeit innerhalb desselben Unternehmens genauso wie etwa zu externen Dienstleistern. Im ersteren Fall werden Schnittstellen typischerweise nach dem Grad der Abhängigkeit aufgelöst, weil große Abhängigkeiten in Normalfall mit langen Verzögerungen in der Wertschöpfungskette verbunden sind. Das Scrum-Team wird versuchen, Aufgaben selbst zu übernehmen und dadurch seine Definition of Done erweitern. Dabei beschreibt die Definition of Done die Menge nicht-fachlicher und wiederkehrender Aufgaben, die ein Scrum-Team von der Anforderung bis zur Auslieferung selbst erledigen kann.
Im Falle einer Abhängigkeit zu sequenziell arbeitenden externen Dienstleistern, die auf Festpreisverträge bestehen, eignet sich ein agiler Vertrag in Form eines agilen Festpreises. Dieser sieht vor, noch nicht erledigte Anforderungen gegen neue, unerwartete Anforderungen im Projektverlauf tauschen zu können, ohne den Preis zu verändern, mit dem Vorteil frühzeitig gegensteuern zu können, falls das Projekt aus dem Ruder zu laufen droht.
Wann sind andere Methoden besser geeignet als Scrum?
Scrum ist primär ein Managementrahmen für den Umgang mit Unsicherheit. Dabei kann Unsicherheit bedeuten, nicht genau zu wissen welche Anforderungen für Nutzer:innen den größten Mehrwert stiften oder weil Unklarheit darüber besteht, welche Technologie dafür am geeignetsten ist. Im Regelfalls fällt jede Form von Wissensarbeit in diesen Sektor, insbesondere die IT. Der Grund hierfür besteht im extrem dynamischen Nutzerverhalten einerseits und der äußerst rasanten technologischen Entwicklung andererseits. Es gibt wenige Standards, die über viele Jahre in diesem Sektor Konstanz aufwiesen.
Anforderungen werden in diesem Sektor häufig als rote Arbeit bezeichnet, während Anforderungen, die wenig Veränderungen unterworfen sind mit blauer Arbeit bezeichnet werden. Bei roter Arbeit sollte der Fokus auf Effektivität gelegt werden ("die richtigen Dinge tun"), während bei blauer Arbeit der Fokus auf Effizienz gelegt werden sollte ("die Dinge richtig tun"). Jedes Unternehmen weist immer Mischformen von roter und blauer Arbeit auf.
Während in der Fachwelt Einigkeit darüber besteht, dass Scrum für rote Arbeit ein probates Mittel darstellt, ist seine Anwendung auf blaue Arbeit nicht grundsätzlich falsch; führt aber in der Regel zu unnötigem Overhead. Deswegen kann es in Unternehmensbereichen mit vorwiegend blauer Arbeit effizienter sein mit sequenzieller Methodik vorzugehen, etwa weil unstrittige Einigkeit über die Effektivität der gewählten Umsetzung besteht. In jedem Fall sollte bei Mischformen die Abhängigkeit roter und blauer Bereiche minimiert werden, weil sie zu Wartezeiten führt.
Unternehmen, denen es gelingt, blaue und rote Entwicklungen parallel mit Erfolg laufen zu lassen gelten als ambidexter (beidhändig), z.B. wenn sie beidermaßen Technologien/Produkte/Dienstleistungen der Vergangenheit (Exploitation) als auch der Zukunft (Exploration) mit Erfolg entwickeln und vertreiben.