TNG Technology Consulting: Agile Entwicklung: "Das IT-Team entscheidet, wie viel es schaffen kann"

Wieso muss man plötzlich "agil" entwickeln, anstatt so weiterzumachen wie bisher?

Weil die IT-Branche sich gewandelt hat - der Fokus liegt nicht mehr auf Dokumentation und Projektplanung. Stattdessen steht bei der agilen Entwicklung im Vordergrund, dass man schnell lauffähige Software vorweisen kann. Die Entwickler verfolgen nicht mehr Projektpläne, die vor zwei Jahren gemacht wurden, sondern reagieren schnell auf Veränderungen. Wenn der Kunde heute eine Einbindung eines Social Networks auf seiner Website möchte, dann müssen wir das schnell umsetzen können - vielleicht existiert das Netzwerk ja in zwei Jahren schon nicht mehr.

Wie funktioniert agile Entwicklung konkret?

"Scrum" und "Kanban" sind die prominentesten Beispiele für agile Entwicklung. Bei Scrum gibt es klare Vorgaben für einen Prozess. Jedes Projekt besteht aus Sprints, also Arbeitsabschnitten, die üblicherweise zwei Wochen dauern. Jeder Sprint beginnt mit der Planung, in der man für den kommenden Sprint die einzelnen Anforderungen, sogenannte "User Storys", festlegt. Das Team entscheidet, wie viele User Storys es schaffen kann. Dieses "Pull-Prinzip" stellt die Vorgehensweise vom klassischen Projektmanagement auf den Kopf, in dem noch der Team-Leiter die Aufgaben an die Team-Mitglieder verteilt. Wenn die Team-Mitglieder selbst Verantwortung übernehmen, bringt das natürlich auch einen Motivationsschub mit sich.

Wie läuft ein Sprint ab?

Während des Sprints, also zwei Wochen lang, sind die User Storys, an denen gearbeitet wird, nicht mehr änderbar. So können die Entwickler in Ruhe arbeiten. Und trotzdem hat der Kunde eine große Flexibilität, weil er die Anforderungen alle zwei Wochen ändern kann - und nicht nur alle paar Monate wie in klassischen Projekten. Das Team trifft sich einmal am Tag, um die anstehenden Aufgaben untereinander zu verteilen. Das sind die sogenannten "Daily Scrums".

Was ist das Ziel von einem Sprint?

Das Ergebnis - das "Release" - soll lauffähige Software sein, die dem Kunden vorgeführt werden kann. Der Kunde gibt dann Feedback, damit die Entwickler noch besser verstehen, was der Kunde mit der Software tun will. Die kurzen Zeitabstände zwischen den Releases minimieren natürlich das Risiko: Man sieht sofort, in welche Richtung sich das Produkt entwickelt.

Und wie funktioniert Kanban?

Kanban macht nur ganz wenige Vorgaben. Die wichtigste ist: Die Anzahl der offenen Arbeit soll begrenzt werden. Also stark vereinfacht: Erstmal ein paar User Storys abschließen, bevor man neue anfängt. Außerdem rät Kanban: Visualisiere die Arbeitsflüsse. So kann man besser erkennen, wo sich zu viel Arbeit anstaut und durch gezielte Limitierungen an einzelnen Stellen den Gesamtfluss beschleunigen, wie bei einem Verkehrsleitsystem. Kanban und Scrum kann man auch kombinieren.

Wie behalten Sie das große Ganze im Blick?

Bei Scrum ist die Vorgabe, dass man zu Beginn eine Vision entwickelt. In meinem aktuellen Projekt entwickeln wir eine Internet-Plattform fürs Marketing eines großen Automobil-Konzerns. In diesem Projekt ist die Vision richtig toll umgesetzt: Es gibt einen Film, der zeigt, wie die Benutzung der Software später funktionieren soll. Diesen Film haben wir jedem Projektmitglied gezeigt. So kann sich jeder das Produkt vorstellen, das am Ende stehen soll. Aber so etwas ist natürlich nicht immer möglich. Es ist die Aufgabe des sogenannten "Product Owners", den Überblick über das Gesamtprojekt zu behalten. Er ist deswegen ganz zentral für das Projekt, weil er diese schwierige Aufgabe leistet. Was außerdem noch hilft: Nicht alles von Anfang an ganz genau spezifizieren, sondern erst dann ins Detail gehen, wenn die User Story in absehbarer Zeit umgesetzt werden soll - ein Beispiel für das "Just-in-time-Prinzip".

Welche Aufgaben hat der Product Owner außerdem?

Der Product Owner ist für den Inhalt des Projekts verantwortlich. Er muss die User Storys schreiben und den Überblick behalten. Er macht auch die Release-Planung und beeinflusst damit, wann welche Features in Produktion gehen. Der Product Owner muss nicht programmieren können, er sollte aber so viel Technik-Verständnis haben, dass er die Entwickler versteht. Wichtig ist, dass er gut planen und gut mit Menschen umgehen kann. Letztlich ist die Aufgabe des Product Owners, den Kunden glücklich zu machen.

Und dann gibt es ja noch den Scrum Master - was macht der?

Der achtet darauf, dass die Scrum-Spielregeln eingehalten werden. Er muss für optimale Rahmenbedingungen sorgen, damit das Entwickler-Team selbstorganisiert arbeiten kann. Zum Beispiel muss die Ausstattung mit Rechnern passen, das Team darf nicht bei der Arbeit gestört werden - in solchen Fällen muss der Scrum Master alles daran setzen, dass diese Hindernisse aus dem Weg geräumt werden. Kurz gesagt: Der Scrum Master muss das Team leistungsfähig machen.

Programmiert der Scrum Master auch selbst mit?

Normalerweise nicht. In dem vorher genannten Großprojekt arbeiten 13 Scrum Master für 18 Teams. Das ist für mich sehr interessant; ein so großes Projekt habe ich noch nicht erlebt. Wir verbringen viel Zeit im Scrum-Master-Team, um das Projekt zu organisieren. In anderen Projekten kam es auch schon vor, dass der Scrum Master nach der Start-Phase nicht mehr so stark mit der Organisation beschäftigt war und mitentwickelt hat.

Was ist spannend an der Aufgabe als Scrum Master?

In meinem aktuellen Projekt bin ich auch Scrum Master. Ich finde vor allem spannend, dass man sich sehr intensiv mit Leuten auseinandersetzen muss und sehr viel miteinander redet. Bei einem großen Teil meiner Arbeit geht es darum, dass ich mich um alle Teammitglieder und das Arbeitsumfeld kümmere. Ich will bei den Leuten das herausfinden, was sie beschäftigt oder auch behindert und damit erreichen, dass wir besser vorwärts kommen.

Wie steuern Sie die Entwicklerteams, um zu verhindern, dass manche zu leichte oder zu schwere Aufgaben übernehmen?

Das macht das Team selbst - denn eines der agilen Prinzipien ist die selbstständige Organisation des Teams. Wenn sich ein Entwickler eine zu schwere Aufgabe herausgesucht hat, dann sieht man das in der täglichen Besprechung sofort daran, dass er mit seiner Aufgabe nicht fertig geworden ist. Idealerweise fragt dann einer aus dem Team, ob er ihm helfen kann. Wenn das nicht kommt, dann kann der Scrum Master diese Frage stellen. Auch der andere Fall löst sich eigentlich von selbst: Das Team arbeitet so eng zusammen, dass jeder sofort die Fortschritte sieht. Da will niemand als derjenige dastehen, der nur leichte Aufgaben übernommen oder nur wenig gemacht hat.