Agile / Projektmanagement / Software-Entwicklung

Einstieg in die Agilität 1/5

Die Reise zur bimodalen IT – Station 1: „Big bang doesn’t work!“, so Christoph Haas, IT Director bei bwin.party bei seiner Keynote beim ANECON Expertenfrühstück. Wenn die Einführung von Scrum nicht richtig vorbereitet wird, dann kann sie leicht schief gehen. Ziel soll es sein, eine Basis für eine erfolgreiche und vor allem langfristige Umsetzung zu legen. Einige Voraussetzungen für diese erfolgreiche Einführung sind notwendig, die ich in diesem Artikel beschreiben werde.

 

Bimodale IT_Einführung von Scrum_Rugby Team 2

 

Projekt

Eine der ersten Fragen ist, ob ein geeignetes Projekt für die Scrum Einführung ausgewählt wurde. Das Projekt sollte so wenig Abhängigkeiten wie möglich zu anderen Projekten oder Systemen haben – sonst besteht die Gefahr, dass externe Faktoren das Scrum Team ständig bremsen und die gewünschte Flexibilität und Geschwindigkeit nie zu Stande kommt. Sprich Mode 2 kommt nie ins Laufen, da Abhängigkeiten an Mode 1 Teams oder Systeme das Projekt lahm legen. Die beiden Modis hat Alexander Hartl im Prolog zu dieser Blogreihe dargestellt.

Team Aufstellung

Die nächste Frage betrifft das Team selbst. Wird es einen Scrum Master geben – oder macht das der Senior Developer? Gibt es einen Product Owner oder wird der Projektleiter sowohl Product Owner also auch Scrum Master spielen? Steht das Team 100% zur Verfügung oder hat es andere Projekte, die es auch bedienen muss? Sind Tester Teil des Teams – oder kommt Testen nach dem Sprint? Wenn das gesamte Scrum Team nicht dediziert zur Verfügung steht, dann ist die Einführung von vornherein zum Scheitern verurteilt.

Management Unterstützung

Ein Scrum Projekt passiert nicht in einem Vakuum. Es gibt natürlich eine Organisation rund um das Team – und irgendwann wird das Team an Grenzen stoßen. Wenn das Management nicht die Scrum Einführung unterstützt und sich bemüht Steine aus dem Weg zu räumen, wird es über kurz oder lang große Probleme geben. Insbesondere sollte das Management das neue Vorgehensmodell in den Bereichen IT-Operations, in den Fachabteilungen und im Marketing ankündigen und diesen Mitarbeitern den klaren Mehrwert kommunizieren. Vor allem aber auch die Erwartungshaltung an diese Abteilungen, was die Mitwirkungspflichten betrifft.

Training

Es ist wichtig, dass alle Beteiligte das gleiche Verständnis von den Scrum Konzepten und Begriffen haben. Um das zu schaffen, veranstalten wir ein gemeinsames Training mit Product Owner, Scrum Master, dem Team und am besten mit dem Management. Die Kernkonzepte von Scrum werden mittels Spielen sehr eindrucksvoll übermittelt. Das Training erklärt die Rollen in Scrum, die Meetings, die Abläufe und behandelt auch die typischen Probleme, die bei der Einführung von Scrum aufkommen.

Product Backlog

Der Product Owner hat die Verantwortung, das Produkt zu liefern, das seine Stakeholder und Kunden haben wollen. Wenn er mit seinen Anforderungen daneben liegt, kann das Team super effizient sein, aber es bringt alles nichts, weil das falsche Produkt geliefert wird. Deshalb ist es ganz wichtig, dass der Product Owner ein geeignetes Backlog erstellt und kontinuierlich pflegt.

User Stories

User Stories (samt Features und Epics) sind die Basis des Backlogs. Die meisten Product Owner sind es nicht gewohnt, kleine User Stories zu schreiben. Die Funktionalität muss überschaubar sein und man sollte Tests und Akzeptanzkriterien festlegen. Der Scrum Master sollte den Product Owner coachen, um die Qualität der User Stories zu erhöhen.

Estimation

Das Team muss die User Stories im Backlog schätzen. Am Anfang von einem Projekt gibt es sehr viele Stories – zu viele, dass man sie mit Poker Cards alle schätzen könnte. Deshalb verwenden wir meistens Magic Estimation – dabei werden alle User Stories relativ zu einander dargestellt und erst später werden Story Points ausgegeben. Dies hilft ein Backlog schnell auf die Beine zu stellen. Sobald das Team dann einen höheren Reifegrad in ihrer Zusammenarbeit erreicht und das Produkt besser versteht, wird es vorkommen, dass Schätzungen sich ändern – Scrum hat hier kein Problem, dies zu beachten („Welcome change!“), das Management aber durchaus! D.h. hier muss die Erwartungshaltung von vorneherein klar kommuniziert werden.

Priorisierung

Der Product Owner muss die User Stories priorisieren. Die Priorisierung ist eine Gratwanderung zwischen dem Business Value (sprich Geschäftswert für den Kunden) und der technologische Aufwand (User Story Points). Am Beginn eines Projekts, muss viel mehr Rücksicht auf technologische Aspekte genommen werden. Man will ein „Walking Skeleton“ schaffen und sehr oft heißt das, dass die ersten Stories nur einen dünnen Durchstich durch das System schaffen.

 

Bimodale IT_Einführung von Scrum_Scrum Development Team

 

DIE ERSTEN SPRINTS

 

Scrum Master Rolle vorleben

Der Scrum Master ist quasi der Agilitätsprediger – er glaubt, dass Scrum gute und brauchbare Ergebnisse liefert, trotz dem Misstrauen von einigen Teammitgliedern. Bis die ersten Sprints durch sind, sollte das Team auf Scrum richtig eingeschworen sein. Wenn kein erfahrener Scrum Master vorhanden ist, übernimmt ANECON am Anfang die Rolle des Scrum Masters. Der Scrum Master hat zu Beginn viel zu tun, er muss das gesamte Team coachen und sowohl intern als auch extern Begeisterung für das Vorgehensmodell schaffen.

Meetings

Scrum verlangt viel Kommunikation und sämtliche Besprechungen. Als Scrum Master, moderieren wir in den ersten Sprints die folgenden Besprechungen:

  • Daily Stand-ups – täglicher Status, Identifizierung von Blocker und Impediments
  • Sprint Planning 1 – die gemeinsame Entscheidung, welche User Stories in den Sprint Backlog hereinkommen
  • Sprint Planning 2 – die Definition der genauen Aufgaben, die notwendig sind, um die User Stories umzusetzen
  • Review – die Vorstellung der fertigen User Stories für den Product Owner und interessierte Stakeholder
  • Retrospective – das Team geht in sich und sucht nach den Prozess betreffenden Verbesserungen
  • Backlog Refinement – die laufende Pflege des Backlogs – User Stories genauer beschreiben, neue Prioritäten setzen, technische Abhängigkeiten klären

Ich habe schon oft gehört, dass Kunden bei der Einführung von Scrum von vielen Meetings sprechen – mehr als gewohnt. Hier trügt der Schein! Der Inhalt all der in Scrum vorgesehenen Meetings wurde auch im traditionellen Umfeld besprochen, allerdings wurde ein Großteil ad-hoc erledigt und es gab keinen offiziellen, strukturellen Rahmen dafür. Der Aufwand ist der gleiche, eher sogar geringer, weil eben strukturierter gehandelt wird.

Coaching

In den ersten Sprints verbringt der Scrum Master viel Zeit mit coachen. Auf der einen Seite muss er aufpassen, dass der Product Owner umsetzbare User Stories regelmäßig liefert und verfeinert. Auf der anderen Seite, muss er das Team wirklich zu einem Team zusammen schweißen. Zusätzlich muss er oft nach außen – Richtung Management und Kunden – die Vorteile des Prozesses erklären, verkaufen und verteidigen.

Probleme Identifizieren

Während der ersten Sprints zeigt der Scrum Prozess viele kleine Probleme auf. Diese Probleme können nicht alle gleichzeitig behandelt werden, sie werden in einer Liste verwaltet und priorisiert. Dann muss man in den Retrospektiven Lösungen für die Probleme suchen – manchmal kann das Team selber was unternehmen – manchmal muss der Scrum Master oder Product Owner versuchen in der Organisation kleinere oder größere Änderungen zu schaffen.

Weiterreichen

Nach einigen Sprints, kann der externe Scrum Master die „Fackel“ an den internen Scrum Master weiterreichen. Wie viele Sprints man braucht, hängt davon ab, wie schnell das Team die Kernbotschaften von Scrum verinnerlicht hat.

Feedback

In den folgenden Sprints, ist der externe Scrum Master noch bei den wichtigen Meetings dabei. Er überlässt die Moderation dem neuen Scrum Master und gibt ihm Feedback nach Besprechungen. Er schaut auch wie die Dynamik im Team ist und ob die wichtigsten Elemente des Vorgehensmodells eingehalten werden oder nicht.

Agile Praktiken

Auf die Qualität des Produkts wird ebenso geachtet. Agilität ist keine Ausrede für Schlampigkeit oder Planlosigkeit – im Gegensatz es verlangt viel Disziplin und setzt hohe Maßstäbe für Qualität und Professionalität voraus. Aber das ist das Thema des nächsten Blogbeitrags.

 

Bimodal_IT_Station_1_Einstieg-in-die-Agilität

 Conclusio

Eine erfolgreiche Scrum Einführung verlangt Vorbereitung, Unterstützung und Hartnäckigkeit. Aber unserer Erfahrung nach, wenn diese Kriterien erfüllt werden, sprechen die Ergebnisse für sich und sie können zufrieden auf die erste Station der Reise zur bimodalen IT zurückblicken.

 

 

Blogreihe „Die Reise zur bimodalen IT“:

 

Passende Artikel

Kommentare gesperrt.