Scrum
Bei subshell organisieren wir unsere Entwicklungsarbeit nach dem agilen Vorgehensmodell Scrum. Dieses Modell hilft unserem Entwicklerteam dabei, sich selbst zu organisieren. Durch Scrum gliedert sich das Arbeitsleben bei uns in zweiwöchige Sprints, die mit einer Sprintplanung beginnen und mit einer Review (Vorführung der Sprintergebnisse) und einer Retrospektive (rückblickende Betrachtung und Bewertung des Sprints) enden.
Sprintplanung
Die Sprintplanung beginnt montags um 10:00 Uhr und dauert bis etwa 13:00 Uhr (maximal bis 17:00 Uhr). Ein mehrstündiges Meeting mit 10 bis 15 Personen ist naturgemäß kein Zuckerschlecken. Wir machen daher nach jeder Stunde eine 15minütige Pause und mittags eine lange Pause von 12:00 bis 14:00 Uhr.
Zu Beginn der Sprintplanung, ermitteln wir die Zahl der Personentage, die uns für den Sprint zur Verfügung stehen, wie viel wir also tatsächlich schaffen können. Dafür addieren wir die Anzahl der Tage, die jeder einzelne zur Verfügung steht, und multiplizieren die Summe mit unserem Fokusfaktor, der momentan bei 50% liegt. Über den Fokusfaktor geht in diese Berechung ein, wie fokussiert bzw. konzentriert wir arbeiten. Er ist die Geschwindigkeit mit der wir arbeiten. Der relativ niedrige Fokusfaktor erklärt sich dadurch, dass wir unseren Support nicht explizit in den Sprint einplanen, sondern ihn wie ungeplante Aufgaben behandeln.
Für die Sprintplanung verwenden wir eine so genanntes Backlog in Form einer einfachen Excel-Tabelle, in der alle Aufgaben absteigend nach Priorität geordnet sind. Wir gehen die Aufgaben der Reihe nach durch und schätzen ihre Dauer ab, bis wir so viele Aufgaben zusammen haben, wie in den Sprint passen.
Zunächst wird jede Aufgabe vom „Product Owner“ oder einem Entwickler vorgestellt. Sofern es dazu Fragen aus dem Team gibt, werden diese diskutiert, bis alle in der Lage sind, eine Aufwandsabschätzung abzugeben. Dabei wird die Aufgabe - wenn nötig - gleich in Teilaufgaben zerlegt. Für die Abschätzung der Umsetzungsdauer spielen wir „Planning Poker“. Planning Poker ist eine Technik zum gemeinschaftlichen Abschätzen der Umsetzungsdauer von Aufgaben, die sicherstellen soll, dass niemand z.B. durch seine starke Persönlichkeit Schätzungen dominiert. Wir spielen Planning Poker mit einem speziellen Kartensatz, der folgende Karten enthält: ?, 0, ¼, ½, 1, 2, 3. Stellt sich bei der Abschätzung heraus, dass eine Aufgabe mehr als drei Tage beansprucht, zerlegen wir sie in mindestens zwei kleinere Teilaufgaben und schätzen diese erneut ab.
Sehr wichtig ist uns, dass jeder Sprint ein Ziel hat. Ein Ziel ist wie ein Magnet, der alle Tätigkeiten ausrichtet und dabei den Weg vorzeichnet, der gegangen werden muss, um das Ziel zu erreichen.
Sprintbacklog
Das Ergebnis der Sprintplanung ist das Sprintbacklog. Im Anschluss an die Sprintplanung wird als erstes sichergestellt, dass es zu jedem Eintrag im Sprintbacklog ein Ticket in unserem Projektmanagement-Tool JIRA gibt. Danach visualisieren wir den Sprint auf einer großen Glastafel. Dafür drucken wir jede Aufgabe aus dem Sprintbacklog auf eine DIN A5 Karteikarte.
Unsere Glastafel hat die Bereiche aufgaben, termine, in arbeit, review, test, abnahme, merge und done. Am Anfang des Sprints hängen alle Karten in der Spalte aufgaben. Im Verlauf des Sprints wandern sie in die Spalte done. Die dazu gehörenden Status haben wir natürlich auch in JIRA abgebildet.
Als wir mit Scrum anfingen, hatte unser Board übrigens nur die Spalten aufgaben, in arbeit und done. Die Bereiche review, test, abnahme und merge haben wir erst nach und nach eingeführt; angefangen mit review. Ein Grund dafür war die mangelnde Akzeptanz von Pairprogramming in unserem Team. Es bestand aber Einigkeit darüber, dass neben dem Autor mindestens ein weiterer Entwickler jeden neuen oder veränderten Programmcode gesehen und verstanden haben sollte. Nebenbei haben die Reviews auch eine deutliche Verbesserung des Qualität bewirkt.
Doch das genügte unseren eigenen Ansprüchen an die Qualität noch nicht. So haben wir den Bereich test eingeführt und mit eigenem Personal unterfüttert, das sich nur mit dem Testen unserer Software beschäftigt. Die Abnahme dient schließlich zum finalen Check einer Aufgabe und zur Klärung der Frage, in welche Releases das betroffene Ticket gemerged werden muss. Ist ein Merge erforderlich, wird die Karte im Anschluss wieder auf review gehängt.
Burndown-Chart
Zusätzlich befindet sich auf der Glaswand noch das Burndown-Chart, das über den aktuellen Zustand des Sprints Auskunft gibt. Auf diese Weise ist für alle leicht erkennbar, in welchem Zustand sich ein Sprint befindet. Es ist gut sichtbar, was das Team bereits geschafft hat.
Standup
Jeder normale Arbeitstag im Sprint beginnt für alle spätestens um 10:00 Uhr mit dem Standup.
Wer zuletzt zum Standup kommt, fängt an zu berichten, was er am Vortag gemacht hat, was er dabei für Probleme hatte und welche Aufgabe er heute angehen will. Im Anschluss daran beginnt jeder mit seiner ersten Tagesaufgabe oder sucht sich einen Partner, mit dem er zusammen arbeiten möchte.
Welche Probleme hatten wir bei der Einführung von Scrum?
Eine Herausforderung bei der Sprintplanung ist nach unserer Erfahrung der Umgang mit funktional unzureichend spezifizierten Aufgaben oder Aufgaben, deren Umsetzungsweg unklar ist. Bei diesen Aufgaben besteht die Gefahr, dass die Diskussion ausufert und dennoch nicht die nötige Klarheit erreicht wird, die für eine vernünftige Abschätzung erforderlich ist. Wir sind daher dazu übergegangen, für derartige Punkte nur die Konzeption in den Sprint einzuplanen und die Umsetzung in den nächsten Sprint zu verlagern.
Dieses Vorgehen birgt insbesondere für den "Product Owner" ein Problem, da auch für hoch priorisierte Punkte nicht garantiert ist, dass sie im aktuellen Sprint umgesetzt werden. Mittlerweile haben aber alle Beteiligten verstanden, dass dieses Vorgehen sinnvoll ist, und gelernt, damit umzugehen. Der "Product Owner" plant wichtige, aber potenziell unklare Punkte frühzeitig ein oder versucht, im Vorfeld alle Unklarheiten zu beseitigen. In besonderen Situationen besteht außerdem immer die Möglichkeit, im laufenden Sprint die Umsetzung einer wichtigen, nicht eingeplanten Funktion gegen andere Aufgaben aus dem Sprint einzutauschen.
