Der Scrum Prozess

Ich möchte gerne den Scrum Prozess aus meiner Erfahrung heraus beschreiben, mit der ich 2013 bei BMW in Berührung gekommen bin.

Es ist eine Arbeitsweise, an die ich mich zuerst gewöhnen musste. Zum Glück mussten wir in/mit diesem Prozess arbeiten, denn freiwillig hätte ich es nicht gemacht. Denn die Informationen, die wir zu Scrum bekommen hatten, waren nicht positiv: Man wird stärker kontrolliert, man hat keine Freiheiten mehr, jeden Tag ein Meeting usw..

Auf die „Freiwilligkeit“ komme ich später noch einmal zu sprechen.

 

So, was ist nun Scrum?

Es ist eine Arbeitsweise, weg von der Chef-Mitarbeiter-Befehlsempfänger-Philosophie, hin zu eigenverantwortlichen Entscheidungen.

 

Ich kenne noch folgende „alte“ Struktur:

  • Chef/Projektleiter
  • Mitarbeiter (z.B. Entwickler)

Der Chef sagt und der Mitarbeiter macht. In dieser Struktur erkennt man leicht, in welchen Abhängigkeiten jeder steckt.

In einem Scrum Team gibt es 3 Rollen:

  1. Product Owner – der sogenannte Auftraggeber.
  2. Scrum Master – der sogenannte Projektleiter.
  3. Team – ca. 7 Personen, die selbstorganisiert arbeiten.

 

Der Product Owner ist für das Endprodukt verantwortlich. Er ist nicht der Vorgesetzte des Teams und vergibt keine Arbeitsanweisungen.

Der Scrum Master sorgt für die korrekte Einhaltung des Prozesses. Versucht alle Hindernisse, die dem Team im Wege stehen, zu beseitigen. Er ist auch nicht der Chef des Teams. Er vergibt auch keine Arbeitspakete an die einzelnen Teammitglieder.

Das Team sollte aus ca. 7 Personen bestehen. Es arbeitet selbstorganisiert, d.h. es hat keinen vorgesetzten Teamleiter, sondern die Mitglieder entscheiden selbst über ihre Aufgaben und deren Verteilung.

Und genau hier ist der Unterschied zur herkömmlichen Arbeitsweise! Die Verhaltensmuster der Teammitglieder ändern sich. Die Selbstverantwortung für jeden im Team steigt, ohne direkten äußeren Einfluss – einfach aus der Gruppendynamik heraus. Sicherlich wird das „gleichgestellt sein“ einiges an Übung und Eingewöhnungszeit in Anspruch nehmen, aber das gehört zum Lernprozess dazu.

 

Die Arbeitsweise in diesem Prozess wird in 5 Aktivitäten aufgeteilt:

  1. Product Baklog Refinement
  2. Sprint Planning
  3. Daily Scrum
  4. Sprint Review
  5. Sprint Retrospective

 

Als Grundlage aller weiteren Schritte dient der Product Backlog. In diesem werden nämlich durch den Product Owner die Anforderungen an das Produkt (oder die Dienstleistung) beschrieben. Zudem werden diese Anforderungen nach ihrer Wichtigkeit für das Endergebnis priorisiert.

Aus diesem Grund ist es wichtig regelmäßig das sogenannte Product Backlog Refinement durchzuführen. Dabei wird der bisher bestehende Product Backlog weiterentwickelt und verfeinert. Beim Product Backlog Refinement handelt es sich um einen fortlaufenden Prozess, den der Product Owner (gemeinsam mit dem Entwicklung-Team) durchläuft und der immer gegen Ende eines jeden Sprints, aber auch zu Beginn des Projektes – also vor dem ersten Sprint – eingeplant werden sollte.

Im nächsten Schritt, dem sogenannten Sprint Planning, werden die umzusetzenden Anforderungen für den kommenden Sprint ausgewählt. Der Ablauf ist wie folgt:

  • Der Product Owner stellt dem Team das an erster Stelle stehende Product Backlog Item – also die aktuell wichtigste Anforderung an das Produkt (oder die Dienstleistung) vor.
  • Falls noch nicht (im Product Backlog Refinement) geschehen, muss nun der zur Umsetzung dieser Anforderung nötige Aufwand geschätzt werden. Zudem muss die sogenannte “Definition of Done” geklärt werden, d.h. was muss erreicht sein, dass die Anforderung als erfolgreich umgesetzt gilt. Es ist also wichtig, dass ein gemeinsames Verständnis über die Anforderung erreicht wird.
  • Im nächsten Schritt entscheidet das Team (und nur das Team!) darüber, ob es für den anstehenden Sprint noch einen weiteres Product Backlog Item bearbeiten kann. Falls ja, werden die oben genannten Schritte wiederholt.

Dieser Prozess wiederholt sich solange, bis das Team entscheidet, dass für den anstehenden Sprint keine weiteren Aufgaben mehr aufgenommen werden können. Wichtig ist hier darauf hinzuweisen, dass der Product Owner alleine die Reihenfolge der umzusetzenden Anforderungen bestimmt und das Team alleine darüber entscheidet, wie viele Anforderungen im anstehenden Sprint umgesetzt werden können!

Daily Scrum: Wie der Name schon sagt, treffen sich die Teammitglieder (meist auch der Scrum Master und oft der Product Owner) jeden Morgen zu einem “Gedränge”. Dieses maximal 15 minütige Kurztreffen dient dem Informationsaustausch, nicht aber einer möglichen Problemlösung (denn diese wird separat gehandhabt).

Während des Daily Scrums teilen die Teammitglieder reihum mit:

  • was sie/er seit dem letzten Daily Scrum erledigt hat,
  • was sie/er bis zum nächsten Daily Scrum erledigen will sowie
  • was sie/ihn auf diesem Weg behindert.

Fragen bzw. Probleme, die während des 15 minütigen Daily Scrum Zeitfensters nicht geklärt werden können, werden an den Scrum Master zur Klärung gegeben, oder in einer separaten Besprechung geklärt.

Sprint Review: Hierbei präsentiert das Team seine Ergebnisse des aktuellen Sprints. Der Product Owner überprüft dann, ob bzw. inwieweit das Team die “Definition of Done” – also die Anforderungen – der einzelnen Product Backlog Items, die in diesem Sprint bearbeitet werden sollten, auch wirklich erfüllt hat. Anschließend werden die anwesenden Stakeholder um ihre Kommentare gebeten.

Wichtig ist hier darauf hinzuweisen, dass an einem Sprint Review Meeting alle interessierten Stakeholder teilnehmen dürfen (bzw. auch sollen), denn durch die Rückmeldungen können sich u.a. neue Product Backlog Items ergeben und zudem wird recht schnell klar, ob die entwickelten Lösungen auch die Bedürfnisse der Nutzer /Zielgruppe treffen.

Sprint Retrospective: Hierbei blickt das Team (zusammen mit dem Scrum Master) auf die bisherigen Sprints zurück und sucht nach Möglichkeiten die bisherige Zusammenarbeit zu verbessern. Da bei diesem Prozess offene und ehrliche Kritik unter den Teammitgliedern eine der Grundvoraussetzungen ist, sollten – anders als beim Sprint Review – keine Stakeholder anwesend sein. Falls es in bestimmten Situationen Sinn macht doch den einen oder anderen Stakeholder mit einzubeziehen, dann sollte dieser ausdrücklich zu dieser Retrospektive eingeladen werden.

Um die Arbeitsweise auch in einen zeitlichen Rahmen zu fassen, wird ein sogenannter Sprint festgelegt, der ca. 10 Arbeitstage umfasst. Bei 10 Arbeitstagen würde es dann so ablaufen:

  1. Tag: Arbeiten, 11 Uhr Daily (5 – 10 Minuten)
  2. Tag: Arbeiten, 11 Uhr Daily (5 – 10 Minuten)
  3. Tag: Arbeiten, 11 Uhr Daily (5 – 10 Minuten)
  4. Tag: Arbeiten, 11 Uhr Daily (5 – 10 Minuten)
  5. Tag: Product Backlog Refinement, Daily, arbeiten
  6. Tag: Arbeiten, 11 Uhr Daily (5 – 10 Minuten)
  7. Tag: Arbeiten, 11 Uhr Daily (5 – 10 Minuten)
  8. Tag: Arbeiten, 11 Uhr Daily (5 – 10 Minuten)
  9. Tag: Arbeiten, 11 Uhr Daily (5 – 10 Minuten)
  10. Tag: Sprint Review, Sprint Retrospective, Sprint Planning.

Ein weiterer wichtiger Aspekt, der sich in diesem Prozess entwickelt, ist das Prinzip von „lessons learned“. Hieraus entstehen ganz „automatisch“ Vorgehensweisen und Regeln, die das Team entwickelt und als sogenannte Checklisten festhält. Diese werden dann immer wieder abgearbeitet, wie es z.B. auch die Piloten vor einem Start machen. Dieses Checklisten-Prinzip ist überall einsetzbar, für immer wiederkehrende Aktionen.

Hört sich doch alles GUT an, oder?

Leider gibt es auch hier einige Herausforderungen, die in der Planung manchmal nicht bedacht werden bzw. nicht bedacht werden können. Scrum ist eben ein offener Prozess, der „gelebt“ werden muss! Hier einige Beispiele, die ich erlebt hatte:

  1. Die größte Herausforderung ist wie immer der Mensch selber! Wir alle sind durch unser Leben geprägt mit Emotionen und Erfahrungen, die uns permanent „begleiten“ und sich weiterentwickeln. Wäre ich nicht in diesen Prozess „gesteckt“ worden, hätte ich ihn wohl nicht freiwillig mitgemacht. Ich musste durch alle Phasen und hatte dadurch einen sehr guten Einblick bekommen.
  2. Ist man in einem Umfeld, wie BMW, AUDI und Mercedes (Auftraggeber) uva. auch, kann es passieren, dass das Team gemischt ist: Auftraggeber + Dienstleister. Hinzu kommt, dass die Rollenvergabe vom Auftraggeber festgelegt wurde: Product Owner – Auftraggeber, natürlich notwendig. Scrum Muster – Auftraggeber, sollte nicht so sein und Team – Dienstleister. Betrachtet man jetzt die Leistung des Dienstleisters, die bezahlt werden sollte, entsteht hier ein Konflikt mit dem Prozess. Das Team entscheidet die Wertigkeit der Leistung über Story Points. Diese sind wie folgt definiert: Story Point ∈ [0, z], z ∈ N.  Auf der anderen Seite hatte aber der Einkauf vom Dienstleiter schon mit der Finanzabteilung des Auftraggebers, während der Projektverhandlungen geklärt, welche Summe er bekommt. Wie viele Euros sind dann wie viele Story Points? Leider weiß das Team nichts von den Vereinbarungen. Und im Endeffekt wird der Druck dann automatisch von beiden Seiten auf das Team nach und nach erhöht, weil es immer eine Differenz zwischen der festgelegten Summe und den erreichten Story Points geben wird.
  3. Ein weiteres Problem für den Dienstleister ist, dass das ganze Wissen immer in den Softwaresystemen des Auftraggebers festgehalten wird. Alles, was in den Sprints dokumentiert wurde, geht dem Dienstleiter „verloren“. Klar, solange der Mitarbeiter greifbar ist, hat man das Wissen. Was ist, wenn er weg ist und man keinen Zugriff mehr hat auf die Dokumentations-Tools des Auftraggebers? Als ein „Software-Haus“ sollte man alles dokumentieren! Egal, ob es nun Software-Code, Arbeitsstunden oder ein Brief an den Kunden ist.
  4. Ist der Scrum Prozess von der Chefetage nicht vorgegeben, wird es schwer den Prozess zu „leben“. Alte Strukturen und Denkmuster sind nicht leicht zu durchbrechen. Der Chef/Projektleiter sagt was und wie etwas gemacht werden soll, und der Mitarbeiter erledigt die Aufgaben. Wer einmal den Scrum Prozess kennengelernt hat, wird es schwer haben, wieder nur Befehlsempfänger zu sein. Als Befehlsempfänger überlässt man es dem Projektleiter, Entscheidungen zu treffen.

 

So, dies war ein kleiner Einblick in den Scrum Prozess.

Aufrufe: 330

WP2Social Auto Publish Powered By : XYZScripts.com