Die Geräuschkulisse ist extrem hoch. Dabei befinden wir uns gerade nicht in der Ausstellung der DOAG 2013 Development Konferenz während der Mittagspause, sondern in der Keynote von Jutta Eckstein, die zum Thema Agilität in Großprojekten referiert. Auf der Leinwand im Saals Schumann sind die zwölf Prinzipien zu sehen, die das Manifest für agile Softwareentwicklung untermauern. Die Keynote-Speakerin bittet die Teilnehmer darum, sich kurz „nur eine, zwei Minuten“ zum Thema auszutauschen. Es wird auf einmal erheblich lauter. Als sie das Wort übernimmt, folgen Einwürfe des Plenums wie: „Business people und developers working together“ oder„Einfachheit in komplexen Organisationen“. Diese bindet Eckstein dann gekonnt in ihren Vortrag ein.
„Wer hat das Manifest schon mal gesehen – nicht gelesen, sondern einfach nur wahrgenommen?“ Ein paar Hände heben sich hoch. Die Mehrheit der Teilnehmer der DOAG 2013 Development Konferenz sind offensichtlich nur bedingt mit dem Thema Agilität vertraut. Sie werden zwar sicherlich mit keinen Staatsgeheimnissen, aber vielleicht doch mit der einen oder anderen Erkenntnis den Saal wieder verlassen.
Dass sie mit den Themen, die sie anspricht, das Rad nicht neuerfindet, ist ihr vollkommen klar: „Sehr häufig, wenn ich über das Thema spreche, höre ich: Ja, es ist ganz cool, aber nichts Neues.“ Mit einem gesunden Menschenverstand käme man zu den gleichen Schlussfolgerungen, ergänzt sie. Und sie stimmt dem auch zu. Die Fundamente der Agilität zu verstehen, ist in der Tat keine Kunst. Auf die Umsetzung kommt es an. Und da kann sie aufgrund ihrer Erfahrung mit Agilität in Großprojekten ansetzen und Best Practices vorstellen.
Es gibt verschiedene Möglichkeiten, die Größe eines Projektes festzulegen. Eckstein macht sie an der Anzahl der Mitarbeiter fest. „Je nachdem, wieviele Mitarbeiter ich im Projekt habe, skalieren die anderen Messkriterien auch mit“. Ihr Spezialgebiet ist die agile Softwareentwicklung in Teams zwischen 30 und 300 Mitarbeitern.
„Bei 100 Personen ist es fraglich, ob sie noch alle im selben Raum sitzen können.“ Und selbst wenn – dann sei die Gefahr relativ groß, dass sie nicht mitbekommen, was am anderen Ende des Raums gesagt wird.“ Bei 1000 Projektmitarbeitern wird es noch kritischer: „Da kennt man die anderen Projektbeteiligten nicht mehr“.
Agilität ist vielmehr eine Kultur oder eine Haltung, die man einnimmt, als eine Technik. Deswegen stehen bei der agilen Software Entwicklung die Menschen im Vordergrund und nicht die Prozesse, die Dokumentation oder die Verträge. Natürlich werden trotzdem Verträge geschnürt, Dokumentationen verfasst und Prozesse aufgesetzt. Diese werden weiterhin gebraucht. Aber sie sind nur Mittel zum Zweck und kein Selbstzweck.
In Großprojekten gibt es außerdem nicht „den Kunden“, sondern „eine Menge von Kunden“, meint Eckstein. „Und derjenige, der am lautesten schreit, bekommt, was er will“, fügt sie hinzu. Aber letztendlich kann man folgendes Motto festhalten: „Ein Projekt ist erfolgreich, wenn der Kunde erfolgreich ist“. Ändert der besagte Kunde zwischendurch seine Meinung, dann nütze es wenig zu lamentieren.
Deswegen gibt es im Projektteam einen „Product Owner“. Er vertritt die Interessen des Kunden gegenüber dem Team. Seine Rolle ist nicht einfach: „Er sitzt zwischen den Stühlen – zwischen Kunden und Team“. Und wenn es mehrere Teams gibt, gibt es dementsprechend viele Project Owners, die sich auch in einem eigenen Meeting austauschen.
Wer bereits auf dem DOAG 2013 IMC Summit die Keynote von Matthias Marschall erlebt hat, dürfte mit dem Thema der Silo-Denke vertraut sein. Das fasst Eckstein mit folgenden Worten zusammen: „Fast jeder hat es schon erlebt: Wenn alle an einem Strand ziehen, dann findet man immer einen Weg zum Erfolg. Wenn aber Misstrauen herrscht, dann wird es schwierig“.
Vertrauen durch Kommunikation erzeugen – das ist eine der größten Herausforderungen überhaupt. Eine ehrliche und offene Kommunikation habe wiederum auch einen sehr starken Einfluss auf die Qualität, meint Eckstein. Für sie ist Face-to-Face-Komunikation ein Muss – auch in Großprojekten. Da wird es zwar schwieriger, aber es ist nicht unmöglich. Sie setzt auf tägliche Besprechungen und betont, dass diese Frequenz durchaus vorteilhaft ist: Wer sich täglich austauscht, kann so viel nicht zu sagen haben. Die Statusberichte in Teams dauerten demnach zirka 10 Minuten. Eine weitere, teamübergreifende Besprechung sorgt dann für die Aufrechterhaltung der Kommunikation zwischen den Teams: Jedes Team entsendet einen Repräsentanten. Das geht auch in zehn Minuten.“
Eckstein stellt Ihre Projektteams cross-funktional auf. So besäßen die Mitglieder eines Teams alle Rollen und Skills, die gebraucht werden, um einen Geschäftswert liefern zu können. Als Basis gilt eben die Arbeit in selbstorganisierten Teams. Hinzu kommt eine oder mehrere Architektur-Teams, die sich als Dienstleister verstehen und nach den Anforderungen der Feature-Teams arbeiten.
