Bevor wir mit der Beschreibung von Scrum starten, möchten wir Ihnen die Vorteile agilen Arbeitens an einem kleinen Beispiel erklären. Stellen Sie sich vor, Sie fangen mit einem großen Projekt an. Sagen wir, Sie möchten ein Haus bauen. Das braucht seine Zeit. Außerdem müssen Sie eine Menge Leute koordinieren. Manche Aufgaben lassen sich außerdem nur erledigen, wenn andere vorher gemacht wurden: Es macht wenig Sinn, eine Mauer hochzuziehen, bevor ein Fundament gelegt wurde.
Klarer Fall: Sie brauchen einen Projektplan! Klassischerweise würden Sie jetzt im Vorfeld überlegen, in welche Arbeitspakete man einen Hausbau einteilen kann, wie sie voneinander abhängig sind, und daraus ein detailliertes Pflichtenheft erstellen. Jetzt tauchen aber plötzlich zwei Komplikationen auf:
- Sie wollen schon vor Fertigstellung in das Haus einziehen. Damit Sie nicht auf einer Baustelle wohnen müssen, verschieben sich Prioritäten. Sie müssen also die Dinge, die Sie im Alltag brauchen, so schnell wie möglich finalisieren.
- Sie bauen nur einmal im Leben ein Haus, deswegen haben Sie beschlossen, das Gebäude Ihren Bedürfnissen anzupassen – nichts mit Fertighaus! Zum Glück haben Sie kompetente Bauunternehmer, die sich damit auskennen. Das ändert nichts daran: Ein individueller Baustil bringt individuelle Anforderungen mit, die zu Beginn nicht zu überblicken sind.
Sie schauen zuerst in Ihr Pflichtenheft und dann auf Ihre Baustelle, und stellen fest, dass beide Dinge nicht mehr so recht zusammenpassen. Ihre Planungen wurden von der Realität überholt.
Bei der Einrichtung eines ERP-Systems laufen Sie Gefahr, in die gleiche Falle zu geraten: Sie haben es hier mit einem komplexen System zu tun, das möglichst schnell produktiv werden soll, aber auch laufend auf Ihr Unternehmen angepasst wird.
Die klassische Projektplanung stößt bei diesen Anforderungen schnell an ihre Grenzen. Deswegen arbeiten wir bei der K&K Software AG agil.
Das doppelte „i“
Agil arbeiten bedeutet zunächst einmal, dass man inkrementell und iterativ arbeitet. Aber was bedeuten diese beiden Termini?
Inkrementell: Bei einem inkrementellen Vorgehen stellt man nach und nach Teile eines größeren Ganzen fertig und integriert sie nach und nach in das Projekt. Im Falle des Hausbaus hieße das beispielsweise, dass man gemeinsam beschließt, zunächst das Wohnzimmer zu bauen, ehe man andere Räume im Haus anlegt.
Natürlich schaut man trotzdem, dass das Haus Fundament und Mauern hat, ehe man mit der Einrichtung beginnt. Beim agilen Entwickeln nennen wir das das Erreichen des Minimum Viable Product (MVP). Das MVP ist ein Produkt, in das der Besitzer schon „einziehen“ kann, weil das Notwendigste zur Verfügung steht. Bei ERPNext ist das MVP schnell erreicht, immerhin fangen wir ja nicht bei null an.
Iterativ: Sie sind in Ihr Wohnzimmer eingezogen, das auf dem Papier super ausgesehen hat. Leider steht die Heizung zu nah am Sofa. Überhaupt: Sie bauen gerade das Esszimmer, und dort haben Sie eine Möglichkeit gefunden, warme Luft viel effektiver zirkulieren zu können. Sie sagen jetzt nicht, dass Sie eben Pech gehabt haben. Stattdessen bauen Sie gemeinsam mit Ihren Bauarbeitern Ihr Wohnzimmer nochmal ein kleines bisschen um. Sie haben soeben eine neue Iteration geschaffen.
Das iterative Arbeiten in der Software hat aber einen entscheidenden Vorteil gegenüber unserem Beispiel: Sie bekommen von dem Umbau gar nichts mit! Ihr Prozess bleibt in der alten Version auf Ihrem System erhalten, bis wir Ihnen eine neue Iteration ausliefern können.
Sie sehen schon: agiles Arbeiten hat seine Vorteile. Aber gerade diese flexible Struktur verlangt es, dass man den Prozess und die Rollen im Vorfeld genau festlegen muss. Ansonsten hat man keinen agilen Prozess, sondern planloses Chaos.
Rollenverteilung in Scrum
Es ist wichtig, dass jeder seine Rolle im größeren Projekt kennt, um Chaos zu vermeiden. Deswegen verteilt das Scrum-Handbuch, nach dem wir in leicht abgewandelter Form arbeiten, auch feste Rollen mit eigenen Namen, um die verschiedenen Funktionen innerhalb des agilen Arbeitsprozesses festzulegen.
Eine Übersicht über die wichtigsten Begriffe:
Product Owner (PO): Der Product-Owner bündelt Kundenwünsche und -probleme, und formuliert daraus die nächsten Arbeitsschritte, z.B. welche Module gebaut werden müssen und wie sie aussehen sollen. Er nimmt außerdem fertige Module ab und kommuniziert Feedback. Der PO ist in der Regel ein Mitarbeiter – oft eine Führungsperson – in der Firma des Kunden und stellt die Schnittstelle zwischen K&K und dem Kundenunternehmen dar.
Scrum-Master: Der Scrum-Master ist Teil von K&K Software und ist dafür verantwortlich, dass das Scrum-Prinzip während der Entwicklung auch wirklich umgesetzt wird. Er koordiniert die am Projekt beteiligten, plant Meetings und sorgt für die Einhaltung der Scrum-Standards.
Consultant: Der Consultant ist kein Teil der üblichen Scrum-Methode, hat sich bei uns aber als enorm produktiv erwiesen. Unsere Consultants beraten den Product Owner bei der Formulierung von Arbeitsschritten, beantworten Fragen zur Scrum-Methodik und bieten ein umfassendes Weiterbildungsangebot an.
Developer: Der Developer (dts. Entwickler) ist für den Code und die Erstellung der nächsten Module im Sprint zuständig. Developer sind sozusagen die Bauarbeiter des agilen Arbeitens und in der Regel Teil von K&K Software.
Stakeholder: Die Stakeholder sind diejenigen, die Stakes (dts. Einsätze, hier Interessen) bezüglich des Produktes haben. Darunter fallen vor allem zwei größere Gruppen: Zum einen das beteiligte Scrum-Team inklusive Product Owner, zum anderen diejenigen, die das Programm am Ende nutzen, z.B. das Unternehmen, für das das ERPNext-System erstellt wird, oder – bei entsprechenden Modulen – auch deren Kunden.
An dieser Stelle ist es noch wichtig zu erwähnen, dass keine der Rollen hierarchisch über einer anderen steht. Beim Scrum ziehen alle an einem Strang; der Product Owner ist also nicht der „Chef“ des Scrum-Teams, stattdessen gibt er gesammelte Anforderungen an die Developer weiter. Die wiederum haben, zum Beispiel während Meetings, die Möglichkeit, Input bezüglich Machbarkeit oder Vorgehen zu geben.
Backlogs und User-Stories in Scrum
Das Rückgrat der Arbeit mit Scrum sind die sogenannten Backlogs. Die kann man am ehesten mit einem Lastenheft vergleichen. In einem Backlog sammelt das Scrum-Team Arbeitsschritte, die dann Stück für Stück in sogenannten Sprints – das sind zwei Wochen intensiver Arbeit – umgesetzt werden. Scrum unterscheidet dabei die folgenden Begriffe:
User-Story: Eine User-Story ist ein ausformulierter geplanter Arbeitsschritt im Backlog. Sie ist dabei in Form einer Story bzw. Geschichte gehalten: Der Autor, in der Regel ist das bei uns der Product Owner, beschreibt dabei kurz und knapp, was er gerne im System hätte. Dieser Wunsch ist die Grundlage für die späteren Ausarbeitungs- und Entwicklungsschritte.
Product Backlog: Der Product-Backlog ist eine Mischung aus Projektplan und To-Do-Liste. Das Team sammelt in diesem Backlog die verschiedenen User-Stories. Diese Stories können unterschiedlich weit ausgebaut sein; damit das Projekt nicht zu einem Halt kommt, ist es aber wichtig, immer einige ausgebaute User-Stories zu Beginn eines Sprints im Product Backlog zu haben, damit man sie dem Sprint Backlog hinzufügen kann.
Sprint Backlog: Das Team entnimmt dem Product Backlog bereits gut ausgearbeitete User-Stories und fügt sie dem Sprint Backlog hinzu. Der Sprint Backlog beinhaltet die User Stories, die im aktuellen Sprint umgesetzt werden sollen.
Im Grunde haben wir jetzt alles, was wir für das agile Arbeiten brauchen. Wir haben klar verteilte Rollen und Anforderungen gesetzt, gelistet und ausgearbeitet. Aber wie sieht jetzt die Umsetzung aus? Und wie kommt man zu neuen User-Stories? Auch diese Schritte sind in Scrum genau ausgearbeitet.
Sprints
Wie eingangs beschrieben, funktioniert agiles Arbeiten inkrementell. Das heißt, dass das Ende von jeder Kette an Arbeitschritten der Anfang der nächsten Kette ist, sodass wir das Programm Stück für Stück entwickeln können. Innerhalb der Kette achten wir außerdem darauf, dass es die Möglichkeit gibt, bereits umgesetzte User-Stories mit neuen Erfahrungen iterativ zu überarbeiten.
Damit das nicht zu einem Chaos ausartet, sind die verschiedenen Schritte genau geplant und aufeinander abgestimmt. Ehe wir in die Details gehen, ist es wichtig zu verstehen, dass wir die Entwicklung um sogenannte Sprints herum aufbauen.
Sprints sind zweiwöchige Inkremente, in denen die Developer intensiv die User-Stories aus dem jeweiligen Sprint-Backlog umsetzen. In diesen Sprints findet die praktische Entwicklung des ERP-Systems statt. Alle anderen Schritte, wie die Planungs- und Abnahmemeetings, sind im Grunde eine Vor- und Nachbereitung der jeweiligen Sprintphase.
Das heißt aber keineswegs, dass diese Meetings unwichtig sind! Für den Erfolg einer Sprintphase, und damit auch für den Erfolg des jeweiligen Projektes, ist es sehr wichtig, dass der Sprint gut vor- und nachbereitet wird. Beim agilen Arbeiten nach Scrum wird der Kunde praktisch in die Entwicklung miteinbezogen – dieser Vorteil kommt auch mit einer bestimmten Verantwortung einher.
Unser Scrum-Prozess Schritt für Schritt
Auf dieser Illustration sehen Sie die verschiedenen Meetings, die zu einer Scrum-Iteration gehören. Um zu beschreiben, wie dieser Prozess in der Praxis abläuft, gehen wir diesen Schritt Stück für Stück anhand eines praktischen Beispiels gemeinsam durch.
Gehen wir davon aus, dass bereits ein wenig an und mit ERPNext gearbeitet wurde. Der PO hat zusammen mit unserem Consultant ein Product Backlog erstellt, in dem einige wichtigere User-Stories schon gut ausgearbeitet sind. Zwei Sachen stehen gerade ganz besonders dringend an: Zum einen möchten Sie, dass ERPNext automatisch Rechnungen erstellt, außerdem vergessen Sie dauernd die Geburtstage Ihrer Mitarbeiter, Sie wünschen sich also eine automatisierte Erinnerung.
Refinement: Im Refinement-Meeting setzen sich unser Consultant und der PO zusammen, um die anstehenden Anforderungen zu klar umrissenen User-Stories auszuformulieren.
In unserem Fallbeispiel würde die User-Story zum automatischen Schreiben von Rechnungen mehr Zeit in Anspruch nehmen. Wir klären also erstmal wichtige Fragen, z.B. was für Rechnungen das sein sollen, wie sie mit den Unternehmensprozessen verknüpft sind.
Planning 1: Im ersten Planning-Meeting stellt der PO seine ausgearbeiteten User-Stories für den nächsten Sprint den Developern vor. Die Developer können in diesem Schritt auch Rückfragen an den PO stellen.
Da die beiden User-Stories bereits durch ein ausführliches Refinement gelaufen sind, läuft dieses Meeting reibungslos. Nachdem er alle Stories vorgestellt hat, macht der PO klar, dass die frisch verfeinerten Stories für die Rechnungserstellung und die Geburtstage besondere Priorität haben.
Planning 2: Im zweiten Planning-Meeting schauen sich die Developer nochmal alle User-Stories an und überlegen sich, welche sie in den zwei Wochen Sprint leisten können. Dabei erstellen sie den Sprint Backlog.
Die Entwickler verteilen in unserem Fallbeispiel die Aufgaben unter sich; die automatische Rechnungserstellung und die Geburtstagserinnerung werden zusammen mit einigen anderen kurzen User-Stories in den Sprint aufgenommen.
~ Zwei Wochen Sprint ~
Daily Meetings: Unsere Entwickler treffen sich während des Sprints täglich miteinander, um Fortschritte auszutauschen und sich gegenseitig auf dem Laufenden zu halten. Diese Meetings sind für uns ungemein wichtig und produktiv! ERPNext ist ein miteinander verzahntes System; gemeinsam Arbeiten heißt schneller und effizienter arbeiten.
~ Jetzt findet auch das nächste Refinement-Meeting statt ~
Review Meeting: Am Ende des Sprints nimmt der PO die entwickelten Stories ab. Die Entwickler übergeben die fertiggestellten User-Stories an den PO, der beurteilt, ob die gestellten Anforderungen erfüllt wurden.
In unserem Fall war das kein Problem; die Geburtstagserinnerungen funktionieren zuverlässig und auch die Rechnungen werden zufriedenstellend erstellt. Der PO nimmt die User-Stories ab und die Entwickler können sich auf die nächsten Anforderungen einstellen, denn…
Planning 1: …jedes Review-Meeting ist gleichzeitig das nächste Planning Meeting 1 (daher auch das Refinement-Meeting während des Sprints) und der Kreislauf startet erneut.
Zusätzlich zu diesem Turnus setzt sich das ganze Team alle zwei Sprints – also alle vier Wochen – zu einer Retrospektive zusammen. Hier wird gemeinsam besprochen, was bei den letzten Sprints nicht so gut lief. Das Team teilt und diskutieren außerdem Wünsche, Probleme und Anregungen. Zuletzt bespricht es den Zeitplan und passt ihn gegebenenfalls an.
Scrum nochmal zusammengefasst
Uns ist bewusst, dass das sehr viele Informationen für Sie waren und versprechen: Sie kommen schnell in eine Routine. Im Grunde müssen Sie sich folgende Dinge merken:
-
- Agiles Arbeiten funktioniert, indem man Anforderungen Schritt für Schritt plant und umsetzt; auf diese Art kann man Prioritäten agil setzen und schon im Projekt von Erfahrungen profitieren.
- Dabei gibt es fest verteilte Rollen & Begriffe: Die Backlogs entsprechen am ehesten To-Do-Listen und der PO dem Projektleiter auf Seiten des Kunden.
- Anforderungen werden in zweiwöchigen Sprints umgesetzt; bei K&K Software folgen diese Sprints direkt aufeinander.
- Die Umsetzung erfolgt nach der Reihenfolge: Refinement > Planning 1 > Planning 2 > Sprint (mit Daily und Refinement) > Review & Planning 1 > …
- Alle zwei Sprints ist eine Retrospektive angesetzt, in der das Projekt, der Zeitplan und die jüngsten Erfahrungen besprochen werden.
Team K&K Software AG
Wir bei K&K arbeiten in einem interdisziplinären Team zusammen. Das ist wunderbar, da so viele unterschiedliche Denkansätze ins Unternehmen kommen. Unsere Erfahrungsberichte, Branchennews, Anleitungen und Sonstiges stellen wir regelmäßig in diesem Blog online.
