Ein zentrales Problem, das man in Softwareprojekten immer wieder antrifft, ist das Fehlen regelmäßiger Feedbackschleifen sowohl innerhalb des Projektteams als auch zwischen Projektteam und Kunde. Dabei kann eine systematische Rückmeldung maßgeblich dazu beitragen, technische Missstände und zwischenmenschliche Probleme im Entwicklungsteam rechtzeitig zu bemerken. Eingebettet in einen iterativen Entwicklungsprozess, ermöglicht regelmäßiges Feedback von Kundenseite zudem eine kundennähere, flexiblere Vorgehensweise in der Softwareentwicklung, durch die auf wechselnde Anforderungen und neue Kundenwünsche dynamisch reagiert werden kann.

Iterative Softwareprozesse

In zahlreichen Unternehmen wird Software heutzutage mit Hilfe eines iterativen Prozesses entwickelt. Im Gegensatz zu traditionellen Vorgehensweisen wird bei der iterativen Entwicklung die Abfolge von Anforderungsanalyse, Design, Implementierung, Integration und Tests nicht einmalig sequenziell durchlaufen, sondern mehrmals zyklisch wiederholt. Ein iterativer Prozess erlaubt es damit, Anforderungsänderungen vergleichsweise flexibel noch während der Entwicklung zu berücksichtigen, während Unzulänglichkeiten im Design sowie eventuelle Probleme in der Integrations- oder Testphase bei einer nicht iterativen Herangehensweise oft erst sehr spät erkannt werden. So geschieht es nicht selten, dass wenige Wochen vor dem geplanten Releasedatum völlig neue Schwierigkeiten den ursprünglichen Zeit- und Budgetplan zunichte machen, da erst gegen Projektende sehr viel Programmcode integriert und getestet wird. Bei iterativen Entwicklungsverfahren kann diese Gefahr durch laufende Integration und Tests stark reduziert werden.

Generell lassen sich die Vorteile iterativer Entwicklung jedoch nur dann umfassend nutzen, wenn gut etablierte Feedbackschleifen für einen reibungslosen Informationsfluss sorgen. Bei den meisten iterativen Verfahren wird mit Iterationen von wenigen Wochen Länge gearbeitet, die ihrerseits wiederum häufig in Projektabschnitte von mehreren Monaten Dauer eingebettet sind. Wir haben gute Erfahrungen damit gemacht, nach jeder Iteration sowie gesondert davon nach jedem Projektabschnitt Retrospektiven durchzuführen.

In den meisten Softwareprojekten existieren zwei wesentliche Kommunikationspfade, die die Basis für Feedbackschleifen bilden:

• Kommunikation innerhalb des Projektteams
• Kommunikation zwischen Projektteam und Kunde

Feedbackschleifen innerhalb des Projektteams

Innerhalb eines Entwicklungsteams arbeiten Personen zusammen, die mit unterschiedlichen Aspekten des Gesamtprojekts unterschiedlich gut vertraut sind. Berücksichtigt man zusätzlich noch die individuell verschiedenen Erfahrungs- und Wissenshintergründe sowie die unterschiedlichen Persönlichkeiten der einzelnen Teammitglieder, so liegt es auf der Hand, dass jeder das Projekt aus einem sehr spezifischen Blickwinkel und auf der Grundlage unterschiedlicher Informationen und Schlussfolgerungen betrachtet. Daraus wiederum können sich Probleme wie beispielsweise die folgenden ergeben:

• Entwickler, die sich nicht zumindest einen groben Überblick über die Zielrichtung der Software und die Vorstellungen des Kunden verschafft haben, sind kaum in der Lage, bei Design und Programmierung vorausschauend zu arbeiten. Eine zwar von der Projektleitung eingeplante, aber den Entwicklern nicht kommunizierte spätere Erweiterung der Software lässt sich deswegen womöglich nur mit großem Aufwand vornehmen.
• Erfährt der Projektleiter nicht oder zu spät von eventuellen Unzulänglichkeiten einzelner bereits umgesetzter Softwarekomponenten, können einzelne Klassen- oder Programmmodule, die im Laufe der Zeit gewachsen und daher nur noch schwer wart- und erweiterbar sind, zum Problem werden. Wenn es keine regelmäßigen Teambesprechungen gibt, bemerkt der Projektleiter diese problematischen Komponenten bisweilen erst dadurch, dass der Implementierungsaufwand für bestimmte Aufgaben drastisch steigt und die Stabilität der Software sinkt.

Feedback-Meetings in einem größeren Kreis sind oft auch ein unverzichtbares Mittel, um einen Eindruck von allgemeinen Stimmungen und Konflikten innerhalb des Projektteams zu bekommen und entsprechend darauf reagieren zu können. Dazu gehören auch die allgemeinen Arbeitsbedingungen und Arbeitsmittel sowie soziale Aspekte der Zusammenarbeit im Team. Sollten mehrere Projektbeteiligte regelmäßige Meetings als Zeitverschwendung ansehen, ist dies vom Projektleiter unbedingt zu überprüfen. Vielleicht können tatsächlich sinnlose Aktivitäten gestrichen werden, vielleicht muss den Mitarbeitern aber auch Sinn und Zweck des Meetings besser kommuniziert werden.

Teambesprechungen: Wer sollte dabei sein?

Sofern die Teamgröße einigermaßen überschaubar ist und die Zahl der Mitarbeiter 15 nicht übersteigt, ist es nach unserer Erfahrung empfehlenswert, alle Mitglieder zu Teambesprechungen einzuladen. Zwar dauert eine Besprechung mit so vielen Teilnehmern zwangsläufig länger als ein Treffen im kleinen Kreis, doch wiegt die direkte Weitergabe von Informationen (persönlich statt über einen Mittelsmann) sowie die Förderung des Zusammengehörigkeitsgefühls diesen Nachteil auf. Bei deutlich größeren Teams stellt sich in der Softwareentwicklung ohnehin die Frage, ob eine Aufteilung in mehrere Unterteams nicht effizienter ist.

Feedback-Meetings mit dem gesamten Softwareteam sind ein idealer Zeitpunkt, um allgemeine Informationen über den Stand des Projekts oder die Zufriedenheit des Kunden weiterzugeben. Überdies schadet es nicht, bei passender Gelegenheit Lob an das Team als Ganzes zu verteilen oder allgemeine organisatorische Informationen weiterzuleiten.