DOAG Online: Ab wann spricht man eigentlich von Großprojekten?
Jutta Eckstein: Ab zwei Teams verändert sich bereits ganz viel. Denn das Projekt muss in diesem Fall über die Teams hinweg geplant und ausgesteuert werden. Eine andere Definition von Großprojekten wäre ab 30 Personen aufwärts. Da stößt man schon an gewisse Grenzen: Es wird dann mühsam, Projekt-Meetings noch effektiv zu gestalten. Beispielsweise ist es schwierig, ein Stand-Up-Meeting mit allen Beteiligten in 15 Minuten durchzuführen oder bei einer Retrospektive sicherzustellen, dass wirklich alle Beteiligten zu Wort kommen. Die Kommunikation ist nicht mehr selbstverständlich und muss sozusagen institutionalisiert werden.
DOAG Online: Welche Voraussetzungen müssen denn gegeben sein, um agile Softwareentwicklung bei Großprojekten einsetzen zu können?
Jutta Eckstein: Absolut unerlässlich in Großprojekten ist die Teamstruktur. Anfangen würde ich im ersten Schritt mit einem einzigen Team, das die Basis schafft und sich um die Core-Architektur kümmert und diese auch direkt durch die Umsetzung von zwei bis drei Key-Features (oder User Stories) verifiziert. In einem zweiten Schritt werden weitere Teams eingeführt, die weder nach Abteilungen noch Aktivitäten gegliedert sind, sondern nach Features. Das heißt: Diese Teams sind auf den Geschäftswert ausgerichtet und können über Features einen Geschäftswert umsetzen, ohne auf die Zuarbeit von anderen Teams angewiesen zu sein.
Da es bei Projekten nicht nur auf den Geschäftswert ankommt, sondern auch um den architektonischen Unterbau, muss auch für diesen Unterbau gesorgt werden. Dies kann zum Beispiel über ein Architektur-Team erfolgen. Dabei ist meiner Meinung nach ein Aspekt besonders wichtig: Das Architektur-Team sollte sich als Service-Team, als Dienstleister verstehen. Also anders, als in nicht-agilen Projekten, wo sich oft die Architekten ein tolles Konzept ausdenken und die Entwickler dann damit leben müssen. In einem agilen Kontext tragen die technischen Feature-Teams ihre Anforderungen an das Service-Team heran. Das heißt, das Architektur-Team wird von den Feature-Teams ausgesteuert und implementiert die technischen Anforderungen, die die Feature-Teams bei der Umsetzung der Geschäftsfunktionalitäten unterstützen. Es ist ein Schlüsselelement für die gute Durchführung des Projekts.
Es gibt auch eine andere Herangehensweise: Man kann die Weiterentwicklung der Architektur auch dadurch sicherstellen, dass in jedem Features-Team die Rolle des Architekten besetzt wird . Diese Architekten tauschen sich dann regelmäßig aus, um die konzeptionelle Integrität über das Gesamtprojekt zu gewährleisten.
Die Entscheidung, ob mit einem Architektur-Team oder mit der Besetzung der Rolle des Architekten in den jeweiligen Feature-Teams gearbeitet werden soll, sollte an der Komplexität des Projekts festgemacht werden. Das heißt, es kommt beispielsweise darauf an, wie neuartig die Technologie ist und wie die Teammitglieder mit dieser Technologie umgehen. Je komplexer ein Projekt ist, desto größer ist die Notwendigkeit, ein technisches Service-Team zu haben.
DOAG Online: Nach welchen Kriterien werden die Teams gebildet?
Jutta Eckstein: Was die Teamstruktur angeht, gilt allgemein die sogenannte Miller-Regel: sieben Team-Mitglieder (+/-2). Ich leite die Aufteilung der Teams meistens von der Größe der jeweiligen Fachbereiche und Features ab. Aber man kann auch ganz anders vorgehen: Einmal haben wir die Fachbereiche ausgehängt. Die Projektbeteiligten konnten sich je nach Interessen und Schwerpunkten selber einem Fachbereich zuordnen. Das ist eine gute Voraussetzung für die Motivation der Entwickler und für die Selbst-Organisation der Teams. Man kann natürlich auch schauen, wie sie miteinander umgehen und sich daran orientieren. Aber meistens stellt man fest: Wenn Menschen sich nicht mögen, liegt es oftmals daran, dass sie sich nicht gut genug kennen.
DOAG Online: Stoßen Sie im Rahmen Ihrer Tätigkeit auf Widerstand gegenüber agilen Vorgehensweisen?
Jutta Eckstein: Ich würde es nicht auf die agile Entwicklung beziehen. Es gilt allgemein für jede Art von Veränderungen. Sie werden immer Personen haben, die gut oder eben weniger gut damit zurechtkommen. Dabei geht es – wie immer – um das Verständnis für die Notwendigkeit der Veränderung: Ist man nicht davon überzeugt, dass eine Veränderung notwendig ist, so klammert man sich an dem, was früher war. Das ist eine normale Reaktion. Ist man sich der Notwendigkeit der Veränderung bewusst, dann unterstützt man diese.
Allgemein, durchläuft jeder Mensch unterschiedliche Phasen bei Veränderungen. Die Zeit für das Durchlaufen der Phasen dauert allerdings je nach Projektteilnehmer unterschiedlich lange. Aber wie gesagt: Das hat mit Veränderungen im Allgemeinen und nicht unbedingt mit Agilität an sich zu tun. Man sollte immer versuchen herauszufinden, was es für die einzelnen Projektmitarbeiter einfacher macht, eine Veränderung anzunehmen. Dies funktioniert am besten im Zweiergespräch. Zum Beispiel könnte es sein, dass die Meetings zu einer Urzeit stattfinden, die einem Entwickler nicht passen. Auf Anhieb ist es nichts Dramatisches. Doch der Entwickler selbst empfindet es als dramatisch – weil die Kinder um die Uhrzeit in den Kindergarten gebracht werden müssen, zum Beispiel. Ist diese Information bekannt, so kann man dann damit arbeiten und diesen Aspekt bewusst einbinden.
DOAG Online: Heißt es, dass die Emotionen raus müssen?
Jutta Eckstein: Nein! Die Emotionen möchte ich drin haben. Leidenschaft ist bei Veränderungen wichtig. Aber die Projektbeteiligten brauchen eine Möglichkeit, sich im Prozess wiederzufinden. Dafür brauchen sie eine Mitgestaltungsmöglichkeit. Damit sie sich einbringen, müssen sie spüren, dass sie ernstgenommen werden. Das ist ein wesentlicher Aspekt. Basis dafür ist eine funktionierende Kommunikation – was bestimmt der wichtigste Schlüsselfaktor für eine erfolgreiche Einführung von agilen Methoden und jede andere Art von Veränderung ist.
DOAG Online: Kann jeder Entwickler mit agilen Vorgehensweisen umgehen?
Jutta Eckstein: Grundsätzlich ist es für jeden möglich. Agile Softwareentwicklung verlangt gleichzeitig mehr Eigen- und Teamverantwortung. Durch diesen Fokus fühlt man sich möglicherweise mehr unter Druck gesetzt. Man ist nicht fremdgesteuert, sondern selbstgesteuert. Das heißt, dass Entwickler besser einschätzen müssen, was sie in einem gewissen Zeitraum schaffen. Aber andererseits haben alle Projektbeteiligten ein gemeinsames Ziel und das bedeutet wiederum, dass sie sich gegenseitig unterstützen müssen. Dafür ist es essentiell abzuklären: Wer macht was? Und wie? Das Team muss lernen, mit Selbstbestimmung umzugehen. Das ist eine Herausforderung.
DOAG Online: Wie kann man sich darauf einstellen?
Jutta Eckstein: Es geht letztendlich um die Frage: Was ist eigentlich in dem vorgegebenen Zeitrahmen überhaupt machbar? Das ist immer schwer einzuschätzen. Meistens nimmt man sich zu viel vor – man glaubt nicht, wie schnell zwei Wochen vorbeigehen. Also sollte auch Unerwartetes und Arbeiten, die nicht direkt mit dem Projekt zu tun haben (wie zum Beispiel E-Mails beantworten oder Kollegen bei Alt-Projekten unterstützen) mitberechnet werden.
Aber die Geschwindigkeit, mit welcher in einer Iteration Features entwickelt werden, kann man messen und sich dann daran orientieren. Für die nächsten Iterationen kann man dann herausfinden, was den Fortschritt unterstützt beziehungsweise hindert und dann entsprechend optimieren. Die Zahlen sollte man jedenfalls ernst nehmen.
