Agile Softwareentwicklung
Agile Methoden in verteilten Teams:
Was hat sich bewährt, was nicht?
Literatur zu agilen Vorgehensmodellen gibt es reichlich. Agilität nach Scrum-Art ist mittlerweile der Platzhirsch insbesondere in der Softwareentwicklung. Doch was, wenn die Bedingungen der Lehrbücher nicht einzuhalten sind?
Es tauchen immer wieder spannende Fragen auf, wie: Welche Sprintlänge sollen wir nehmen? Wie gehen wir mit Backlog Items um, die nicht fertig geworden sind? Wie können wir täglich ein Stand-up-Meeting durchführen, wenn wir verteilt arbeiten? Sind wir überhaupt ein Team, wenn wir an verschiedenen Projekten arbeiten? Wie können wir uns an agilen Modellen wie Scrum orientieren, wenn wir nicht das klassische Softwareteam sind?
Im Artikel wird aus der Praxis verteilter Teams berichtet. Dabei wird darauf eingegangen, welche Stolpersteine überwunden werden mussten und was sich besonders bewährt hat.
Szenario
Wir haben uns in vielen Projekten, sei es intern in der Selbstverwaltung, in Entwicklungsprojekten mit unseren Kunden oder auch als agile Transition bei unseren Kunden mit den genannten Fragen auseinandergesetzt.
Die Essenz daraus soll dieser Artikel vermitteln. Die praktischen Erfahrung stammen aus verschiedenen Projekten, meist in verteilten Teams, die agile Ansätze verfolgen.
Der Artikel ist nicht als Pauschalrezept zu verstehen. Vielmehr geht es darum zu vermitteln, was in den Projekten mehr oder weniger gut funktioniert hat. Er soll Ideengeber sein und zum Experimentieren mit der eigenen Methodik anregen.
Ein durchgängiges Beispiel veranschaulicht das Szenario. Dabei handelt es sich um ein deutschlandweit verteiltes Team (siehe Abbildung 1). Near-Shore-Partner in Osteuropa werden als Entwicklungsdienstleister herangezogen, sind jedoch nicht Teil des agilen Teams.
Die Zentrale ist in Stuttgart und die anderen Standorte sind meist Home-Office-Umgebungen einzelner Teammitglieder. Teilweise ist dies auch so organisiert, dass sich Teammitglieder in einem Ballungszentrum gemeinsam in einer Co-Working-Area treffen und von dort aus gemeinsam arbeiten.
Das Vorgehensmodell sieht die Arbeit in Iterationen vor. Nachfolgend wird eine Iteration in die drei Schritte Planung, Ausführung und Rückblick (siehe Abbildung 2) unterteilt, welche anschließend einzeln beleuchtet werden.
Der zeitliche Aufwand dieser drei Schritte ist sehr unterschiedlich und der Schwerpunkt liegt auf dem Build-Anteil, also der tatsächlichen Teamarbeit an einzelnen Aufgaben und Arbeitspaketen. Dennoch sind eine gründliche Planung sowie ein Rückblick auf Erreichtes von elementarer Bedeutung, weshalb sie hier einzeln herausgestellt und betrachtet werden.
Das Team
Der Begriff Team ist allgegenwärtig. Da das Team bei agilen Methoden einen enormen Stellenwert hat, soll der Begriff hier kurz beleuchtet werden. Eine ganz allgemeine Definition bietet der Duden: „Gruppe von Personen, die gemeinsam an einer Aufgabe arbeiten“ [Dud].
Aufgabe lässt sich dabei natürlich auch durch Projekt ersetzen. Hierbei ist es wichtig, dass Personen regelmäßig in Vollzeit zur Verfügung stehen, wobei Ausnahmen akzeptiert sind. Ein Team sollte aus 3 bis 10 Personen bestehen [AgAl-e] und liefert mit jeder Iteration Produktinkremente (vgl.[Sch16], S. 5).
Doch muss das Team unbedingt komplett am gleichen Produkt arbeiten? Die spannende Frage ist hier wohl die Definition eines Produkts. Um diese Diskussion nicht akademisch zu führen, nur so viel an dieser Stelle: Ein wesentlicher Aspekt ist, dass das Team an gemeinsamen Themen arbeitet und sich somit gegenseitig helfen kann. Die im Scrum Guide [Sch16] erwähnte Cross-Funktionalität ist ein wesentliches Merkmal, welches Teams überhaupt erst in die Lage versetzt, sich selbst zu organisieren und eigenständig zu sein. Hierbei sind das Miteinander im Team und die gegenseitige Hilfestellung unabdingbar.
Iterationen
Die Arbeit in Iterationen hat den Vorteil, dass man eine fest definierte und allen bekannte Taktung hat, in der sich die Schritte Planung, Ausführung und Rückblick wiederholen.
Im Scrum Guide wird von Sprints gesprochen (vgl. [Sch16], S. 16), Agile Alliance hingegen arbeitet mit Iterationen [AgAl-d]. Die beiden Begriffe werden häufig synonym verwendet und beiden Beschreibungen ist gemeinsam und wichtig, dass es sich um eine Timebox handelt, die vier Wochen nicht überschreiten sollte.
Die Länge derart zu begrenzen, hat auch den Zweck, eine entsprechend granulare Planung zu ermöglichen. Innerhalb einer Iteration werden Aufgaben relativ kleinteilig definiert. Nur so kann eine verlässliche Aussage zum verbleibenden Aufwand zustande kommen, denn eine hohe Genauigkeit bei seiner Schätzung kann man nur bis zu einem
bestimmten Umfang sicherstellen. Hier wird meist von 1 oder 2 Tagen, also 16 Arbeitsstunden, gesprochen. Dies hat Joel Spolsky in ganz anderem Kontext bereits 2004 kundgegeben (vgl. [Spo04], S. 80 f.).
Im hier vorliegenden Beispiel sind zwei Wochen als Iterationslänge festgelegt. Es wurde auch mit drei Wochen experimentiert, jedoch hat sich zwei Wochen als zuverlässiger planbar erwiesen. Gegen einwöchige
Iterationen hat die Teamverteilung gesprochen.
Für die Effizienz bestimmter Termine ist das persönliche Treffen ein großer Pluspunkt. Dies ist jede zweite Woche einfacher möglich, als wöchentlich.
Planning
Unter Planning verstehen wir hier die gemeinsame Planung der kommenden Iteration, welche sehr gut dem im Scrum Guide beschriebenen Sprint Planning (vgl. [Sch16], S. 9) entspricht. Es geht bei diesem Ereignis darum, dass das Team festlegt, was es in der kommenden Iteration erreichen will.
Für das Planning kommt das verteilte Team aus dem Beispiel an einem Ort zusammen. Dort gibt es einen entsprechend ausgestatteten Teamraum. Verschiedene Experimente, das Planning-Ereignis virtuell, also verteilt über Skype & Co., zu machen, hat sich zwar als möglich, aber schwierig erwiesen. Es ist sehr hilfreich, bei der Planung einzelner Arbeitspakete, User Stories oder Product Backlog Items (PBIs) alle Kommunikationskanäle nutzen zu können. So kann man an einem Tisch sitzend durchaus Fragen oder Zweifel in der Mimik erkennen, was über Skype viel schwerer ist.
Lässt sich das persönliche Treffen überhaupt nicht einrichten, so ist ein Remote-Planning unter bestimmten Voraussetzungenmachbar. Man braucht an allen Standorten eine gute Internetverbindung, gutes Screensharing und vor allem hochwertige Mikrofone und Lautsprecher. Eine Webcam ist unabdingbar. Darüber hinaus ist sehr hohe Disziplin bei allen Beteiligten gefordert.
Des Weiteren spielt die Anzahl der Teammitglieder je Standort eine Rolle. Arbeiten beispielsweise sechs Teammitglieder in der Unternehmenszentrale zusammen und drei Personen vereinzelt remote, so konkurrieren hier zwei Aspekte des Teamgefüges. Während es auf der einen Seite für die sechs Personen optimal ist, gemeinsam an einem Standort zu arbeiten, kann es für die anderen Teammitglieder schnell zur Ausgrenzung kommen.
Um diesen Effekt etwas einzudämmen, sollte man…