Im Artikel beschreibe ich die Kernelemente von Scrum, die auf andere Projekte und tägliche Teamarbeit (auch außerhalb von IT) übertragbar sind.

Scrum ist in seinem Ursprung ein Vorgehensmodell der agilen Softwareentwicklung. Ken Schwaber und Jeff Sutherland entwickelten es Anfang der 90er-Jahre. Es entstand unter anderem aus ihrer Erfahrung, dass IT-Projekte sehr oft daran scheiterten, dass sie zu komplex für die übliche langfristig und statisch geplante Umsetzung sind. Die Rahmenbedingungen (insbesondere Anforderungen der Nutzer und Auftraggeber) änderten sich während des Projektverlaufs so stark und häufig, dass Kosten, Qualität und / oder geplante Fertigstellung häufig aus dem Ruder liefen. Es macht aus ihrer Erfahrung mehr Sinn „auf Sicht zu fahren“, also den Projektverlauf eher kurzfristig zu planen und agil den aktuellen Rahmenbedingungen anzupassen, anstatt im Voraus alles festzulegen.

Scrum liefert aus meiner Sicht interessante Elemente, die auch in Projekten und Teams außerhalb des IT-Umfelds sehr hilfreich sein können. In einigen Unternehmen übernehmen bereits andere Bereiche (beispielsweise HR) wegen der sichtbaren Erfolge Elemente von Scrum für ihre Zusammenarbeit und Projekte.

In Scrum geht es unter anderem darum, allen Beteiligten (u.a. auch dem Auftraggeber) größtmögliche Transparenz in alle prozess- und ergebnisrelevanten Belange eines Projekts zu geben. Hindernisse und Schwierigkeiten werden so frühzeitig sichtbar und können gelöst werden, bevor sie zu groß werden. Erfolge und zielführende Schritte werden genauso hervorgehoben und fördern die Motivation aller.

In verschiedenen Meeting-Formaten wird über das bisher Erreichte, Schwierigkeiten und Hindernisse berichtet. „Oh bitte, nicht noch mehr Besprechungen!“ werden Sie vielleicht denken. Ich kann Sie beruhigen: Scrum-Meetings sind sehr kurz, sehr strukturiert und liefern genau das an Feedback und Information, was benötigt wird, um wechselnde Rahmenbedingungen in die Arbeit zu integrieren, ohne das eigentliche Ziel aus den Augen zu verlieren.

Zusätzliche Transparenz schaffen diverse jederzeit aktualisierte Grafiken, welche den Fortschritt des Projekts auf sehr nachvollziehbare Weise für alle Beteiligten sichtbar machen.

Die täglichen Meetings „Daily Scrum“ dauern nur 15 Minuten und jedes Teammitglied beantwortet drei Fragen: „Was habe ich gestern getan? Was habe ich heute vor? Welche Probleme gab es?“ Was zunächst vielleicht banal erscheint, liefert wichtige Hinweise: Das Meeting wird durch den sogenannten „Scrum-Master“ moderiert. Seine Hauptaufgabe ist es, optimale Arbeitsbedingungen für das Team zu sichern, damit dieses erfolgreich arbeiten kann. Im Daily Scrum erfährt er von Hindernissen und Schwierigkeiten, z.B. fehlende Ausstattung, Störungen durch andere Organisationsbereiche usw. Es ist seine Aufgabe, diese Hindernisse möglichst aus dem Weg zu räumen, damit das Team stets konzentriert auf sein Ziel hin arbeiten kann. Gleichzeitig schafft das kurze Meeting eine hohe Transparenz für alle Teammitglieder, man arbeitet zusammen und nicht aneinander vorbei.

Viele herkömmliche Projekte kranken außerdem daran, dass versucht wird neue Ideen und Anforderungen der Auftraggeber und anderer Stakeholder ohne Zeitverzögerung sofort ins laufende Projekt zu integrieren. Projektleiter erleben sich hier in einem starken Spannungsfeld zwischen den berechtigten Interessen der Auftraggeber und dem Bedürfnis der Teammitglieder nach störungsfreier Konzentration zur Fertigstellung von wichtigen Teilaufgaben. Nicht selten werden dabei auch Projektmitarbeiter auf dem kleinen Dienstweg angesprochen und gebeten diese oder jene „Kleinigkeit“ im Projekt umzusetzen. In der Masse binden diese Zusatzaufträge einen nicht unbeträchtlichen Teil der Kapazitäten und sind dabei oft wenig zielführend. Alle Projekt-Mitglieder verlieren in dieser Phase das eigentliche Ziel aus den Augen und die Erfahrung, nichts wirklich fertig stellen zu können, führt zu Frustration und Demotivation.

Scrum schafft hier einen Rahmen, der sowohl Stabilität und Flexibilität ermöglicht:
Es gibt einerseits die Rolle des „Product Owners“, er verantwortet den wirtschaftlichen Erfolg eines Projekts und repräsentiert sämtliche Stakeholder, er ist der alleinige Ansprechpartner des Kunden. Sein sehr enger Kontakt zu Auftraggebern und Nutzern des Produkts gewährleistet, dass die ständig wechselnden Anforderungen in die permanente Aufgabenliste („product backlog“) einfließen, also die Flexibilität im Projektverlauf gewährleistet ist. Der Product Owner priorisiert außerdem die Aufgaben für die anderen Projektbeteiligten.

Allerdings hat er nicht jederzeit unbeschränkten Zugriff auf das Entwicklungsteam. Dieses arbeitet in sogenannten „Sprints“ über einen festgelegten Zeitraum (je nach Projekt eine bis vier Wochen) ungestört an den vorm Sprint gemeinsam festgelegten Teilaufgaben. In dieser Zeit ist ein Eingreifen des Product Owners oder gar des Kunden nicht erlaubt. Der Scrum Master überwacht diese Regel, greift aber selbst auch nicht in die Arbeit des selbstorganisierten Teams ein. Vor jedem Sprint legen Product Owner, Team und Scrum Master im sogenannten „Sprint Planning“ die während des Sprint zu erfüllenden Aufgaben fest, wobei der Product Owner durch seine Priorisierung festlegt, welche Aufgaben zuerst zu erledigen sind und das Team selbst entscheidet, wie viele dieser Aufgaben es schaffen kann. Durch die ungestörte Arbeit schaffen Scrum-Teams meist mehr Aufgaben in der gleichen Zeit als herkömmliche Projekt-Teams. Allerdings kann es sein, dass einige Aufgaben sich durch veränderte Rahmenbedingungen nach der Erledigung als sinnlos erweisen. Da die einzelnen Sprints recht kurz sind, ist dieses allerdings weniger gravierend als in herkömmlichen Projekten.

Die beiden Rollen „Product Owner“ und „Scrum Master“ bewirken also eine Trennung von Kunden- und Erfolgsorientierung auf der einen und Team- und Prozessorientierung auf der anderen Seite. In bisher üblichen Projekten müssen diese sich wiedersprechenden Interessen alle gleichzeitig vom Projektleiter beachtet werden. Er kann sich dann aussuchen, worauf er mehr Gewicht legt: Auf die Interessen des Kunden, zu Lasten des Budgets und der Gesundheit des Teams, oder auf die Schonung der Ressourcen zu Lasten der Kundenwünsche und des Projekterfolgs.

In „Sprint Reviews“ nach jedem Sprint präsentiert das Team Auftraggebern und Nutzern seine Ergebnisse. Durch ihr Feedback werden gegebenenfalls weitere Aufgaben ausgelöst und einzelne Themen zeitnah optimiert. Positives Feedback der Nutzer erhöht außerdem die Motivation des Teams, denn der Sinn der eigenen Arbeit wir ständig erlebbar.

Nutzer und Auftraggeber werden also durch die Sprint Reviews und den engen Kontakt zum Product Owner permanent einbezogen. Sie erkennen andererseits sehr schnell und nachvollziehbar, wie Änderungswünsche Zeiten und Budgets des Projekts beeinflussen.

• Um Scrum oder Elemente daraus erfolgreich einzuführen, bedarf es einer entsprechenden Haltung der Beteiligten:
  Der Kunde gibt die Inhalte vor, das fertige Ergebnis muss dem Auftraggeber gefallen, nicht dem Entwickler oder Projektteam. Egal ob externer, interner Kunde oder Schnittstelle: Je besser die Zusammenarbeit und Abstimmung läuft, desto besser das Ergebnis.
• Egal wie wichtig die veränderte Rahmenbedingung oder ein Sonderwunsch ist, das umsetzende Team braucht ungestörte Zeiten um sich auf das zu konzentrieren, was es am besten kann. Für das Projektteam erweisen sich das Erfolgserlebnis erledigter Aufgaben und die Möglichkeit zur Selbststeuerung als produktivitäts-, konzentrations- und gesundheitsfördernd.
• Das Menschenbild in Scrum-Projekten ist positiv. Alle Beteiligten gehen davon aus, dass die Teammitglieder ihre Erfahrung und Motivation zu Gunsten des Projekts bestmöglich einbringen.
• Das Team ist der Star! Erfolge und Misserfolge werden immer dem gesamten Team zugerechnet, nie Einzelnen. Jeder kann nur profitieren, wenn das gesamte Team erfolgreich ist. Dies fördert gegenseitige Unterstützung und Zusammenhalt und es hilft in kritischen Situationen, in denen es eng wird. Diese Sichtweise kann schwierig sein für bisherige Einzelkämpfer oder „Stars“, häufig ein kritischer Punkt in Scrum-Projekten.
• Die Rolle des Product Owners und des Scrum Masters sind beide aus verschiedenen Gründen recht herausfordernd, regelmäßige Supervision und Coaching können hier hilfreich sein.

Zum Weiterlesen:
Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. Hanser Verlag, München 2011