Publikationen
Der Herr der Projekte
Sind die Ressourcen knapp und sollen trotzdem mehrere Projekte zur gleichen Zeit realisiert werden? Kämpfen die Mitglieder des Entwicklungsteams mit parallelen Arbeiten und sind überlastet? Welche Vorkehrungen kann man ergreifen, damit Teams trotz genannter Einschränkungen mit ihrer Arbeit vorwärts kommen. Traditionelle Projektmanagement- methoden stoßen hier oft an ihre Grenzen. Dass mit agilen Ansätzen bessere Resultate erzielt werden können, erörtern wir am Beispiel von Scrum.
Ab jetzt sind wir ein agiles Team!
Wie viele Teamleiter und Projektleiter haben sich erhofft oder mindestens gewünscht, dass dieser Imperativ der Überschrift Wirklichkeit würde, sobald er ausgesprochen wird. Leider genügen Wunschdenken und gute Vorsätze nicht, um ein agiles Team oder gar eine agil agierende Organisation ins Leben zu rufen und am Leben zu erhalten. Welche Hindernisse uns den Weg versperren, sollen dieser und die nachfolgenden Artikel aufzeigen.
Der iterative Wasserfall
Der Mensch ist ein Gewohnheitstier. Was er einmal gelernt hat, das tut er gerne immer wieder, selbst wenn sich nach einiger Zeit herausstellt, dass das, was er tut, wenig erfolgreich oder gar kontraproduktiv ist. Gleichzeitig ist der Mensch ein Herdentier, das sich gerne an der Meinung der Gruppe orientiert. Sobald die Gruppe eine neue Mode gut findet, wird alles Handeln so eingefärbt, dass es zur neuen Mode passt. Bei dieser neuen Mode kann es sich auch um «Agilität» handeln. Wie man selbst ernannte «agile Teams» auf ihre Echtheit prüfen kann, zeigen die folgenden Abschnitte.
Der Güte-Indikator
Kontinuierliche Integration der Arbeitsergebnisse aller Entwickler (der so genannte Build), bei der alle Programmteile fehlerfrei kompilieren und alle Unit-Tests laufen müssen, hat sich in der Zwischenzeit zum Standardwerkzeug vieler Entwicklungsteams, besonders bei solchen, die unter der agilen Fahne segeln, durchgesetzt. Und gerade der tägliche – oder gar kontinuierliche – Build ist ein Indikator für die Güte eines agilen Teams. Weshalb kann man das so sagen?
Chaos oder Wunderwaffe?
In einem agilen Team wird normalerweise Selbstorganisation groß geschrieben [1]. Dem Team wird die Autorität eingeräumt, selbst bestimmen zu können, was es tut und was es lässt. Niemand ist da, der ihm Vorschriften macht, wie es vorzugehen hat. Niemand ist da, der für das Team die Verantwortung übernehmen kann. Viele Manager, die Softwareentwicklung im traditionellen Stil gewohnt sind, betrachten dieses Vorgehen als Freibrief für Chaos und Unordnung. Das Team und das Projekt scheinen nicht mehr kontrollierbar. Das Bedürfnis des Managements nach Sicherheit, Kontrolle und Überwachung ist in Frage gestellt.
Fertig oder nicht fertig, das ist hier die Frage
Es ist wohl einer der am schwersten zu fassenden Sätze in der Softwareentwicklung. Dabei liest er sich so einfach. Der Satz „Ich bin fertig“ scheint eigentlich keinen Interpretationsspielraum zu bieten. Und doch gibt es in den meisten Teams – und sogar zwischen einzelnen Gliedern dieser Teams – sehr unterschiedliche Ansichten darüber, was es wirklich bedeutet, „fertig“ zu sein. Diese Unterschiede führen bei einem agilen Team oft dazu, dass am Ende einer Iteration sehr unterschiedliche Qualität geliefert wird, was einem Projekt in hohem Maße abträglich ist. Wie kann das verhindert werden?
Schlachtbericht
Messen liegt in der Natur des Menschen. Er will vergleichen, analysieren und informiert sein. Deshalb hat der Mensch auch ein ambivalentes Verhältnis zum Messen und „Gemessenwerden“. Im Projektmanagement werden Metriken – also das Messen und Vergleichen – von Werten als zentrale Aktivität betrachtet, sozusagen als Notwendigkeit. Dies, um z.B. den Projektfortschritt belegen zu können oder um die Güte eines Teams oder von geleisteter Arbeit abschätzen zu können. Metriken werden deshalb oft vom Management gefordert. Vom Softwareentwickler hingegen werden sie oft geschmäht. Welches Lager hat Recht?
Verhinderer des Projekterfolges?
Sie sind ein Relikt aus den Tagen des Wasserfall-Prozesses. Sie wurden dort zur Beurteilung des Erreichens von Meilensteinen verwendet und sollten dem Kunden die Sicherheit geben, dass sich ein Projekt auf sicherem Weg zum Erfolg befindet. Die Rede ist von so genannten Abnahmen. Der Kunde nahm ein Zwischenergebnis – oft nach mehrmaligem Hin und Her – ab, und erst nach diesem Meilenstein konnte mit dem nächsten Schritt im Entwicklungsprozess weitergefahren werden. Kunden schätzen diese Vorgehensweise. Aber ist es mit agilem Vorgehen vereinbar?
Alle Mann in einem Boot
Agiles Vorgehen stellt verschiedene traditionelle Projektaktivitäten in Frage. Denken wir da nur an die vollständige Anforderungsspezifikationen, bevor man mit der Entwicklung beginnt. Deshalb erfordert agiles Vorgehen von allen Mitgliedern eines Projekt-Teams gehöriges Umdenken. Inwiefern ist auch der Kunde davon betroffen? Kann er mit solch einem Team in althergebrachter Manier zusammenarbeiten oder muss er ebenfalls seine Denk- und Handlungsweise anpassen?
loewenfels.ch