Agile Softwareentwicklung in kleinen Projekten

Die Grundlagen der agilen Softwareentwicklung sind im Agilen Manifest festgehalten und den meisten vermutlich bereits bekannt:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

So weit, so nachvollziehbar.

Das Problem für Software-Teams besteht nun darin, wie diese Prinzipien in eine erfolgreiche Projektpraxis umzusetzen sind. Eine direkte Folgerung aus dem Manifest ist, dass es keinen Standardprozess im Sinne eines Kochrezeptes geben kann, da dieser den individuellen Voraussetzungen des Teams und des Projektes nicht gerecht werden würde (Cockburn 2007, S. 261).

Für die webfactory haben wir inzwischen eine ganze Reihe an Prozessbausteinen und Methoden gefunden, die sich für unsere Projekte regelmäßig sehr bewähren.

Unter welchen Rahmenbedingungen muss agile Softwareentwicklung bei uns funktionieren?

webfactory entwickelt komplexe Websites und Webanwendungen als Individualsoftware im Kundenauftrag. Wir haben ein insgesamt 10-köpfiges Entwicklungsteam aus Designern, Frontend-Entwicklern und Backend-Entwicklern sowie Serverspezialisten.

Unsere Projekte sind – verglichen mit den in der einschlägigen Literatur beschriebenen – sehr klein. Typische Entwicklungsbudgets liegen bei uns zwischen 10 und 100 Personentagen. Der größte Teil der Literatur sieht hingegen Teamgrößen zwischen 5 und 10 Personen und Laufzeiten von mehreren Monaten für ein einziges Projekt vor, also die 10-fache Größe.

Dementsprechend müssen bei uns regelmäßig mehrere Projekte parallel durchgeführt werden und es gibt keine feste, längerfristige Zuordnung von Entwicklern zu einem bestimmten Projekt. Bei einem gemeinsamen Workshop vor einigen Jahren haben wir Alistair Cockburn gefragt, wie wir die agilen Methoden am besten auf mehrere parallele Projekte anwenden können. Seine kurze Antwort: "don't do multiple projects". Damit konnten wir uns allerdings nicht abfinden.

Da wir im Kundenauftrag arbeiten, müssen meistens vorab konkrete Projektbudgets auf der Basis von Aufwandsschätzungen vereinbart werden. Einfach ohne Schätzung zu starten – wie gute Kanban-Teams das inzwischen häufig tun – und anschließend nach Stunden abzurechnen ist für uns in der Regel nicht möglich.

Nicht alles ist bei uns anders

Viele andere Erkenntnisse, die zum Entstehen der agilen Softwareentwicklung geführt haben, treffen bei webfactory hingegen lehrbuchmäßig zu:

• Im Laufe des Projektes lernt der Auftraggeber mehr über seine wahren Anforderungen, häufig aufgrund der ersten Umsetzungsergebnisse
• Während des Projektes ändern sich Umweltparameter durch Aktivitäten von Konkurrenten, Gesetzesänderungen, neue Trends o. ä.
• Dementsprechend ist es unsinnig, Details der zu entwickelnden Lösung frühzeitig zu spezifizieren und festzuschreiben
• Je schneller die Entwicklungsergebnisse gelauncht werden, desto früher können sie den erwarteten Nutzen generieren und desto weniger Kosten entstehen durch halbfertige Arbeiten
• Ein erfolgreiches Produkt stellt ein globales Optimum aller Teilfunktionen dar (Konzeption, Design, Programmierung, Betrieb). Die lokale Optimierung einzelner Funktionen (z. B. Design) führt nicht zum optimalen Gesamtergebnis. Hierfür ist eine ganzheitliche Herangehensweise unter Einbeziehung des Auftraggebers erforderlich.

Interdisziplinäres Team, Arbeitsplätze in Hörweite

Das webfactory-Team umfasst Designer ebenso wie Softwareentwickler und Betriebswirte. Die meisten Arbeitsplätze befinden sich in Hörweite voneinander und Türen sind in der Regel offen. Hierdurch bekommen auch Entwickler, die gerade an einem anderen Projekt arbeiten, mit, wenn im Nachbarraum ein Thema besprochen wird, zu dem sie einen wichtigen Beitrag leisten können. Für Themen, mit denen man niemanden ablenken möchte, werden die Türen geschlossen. Auf feste Arbeitsplätze haben wir bei der Gestaltung unserer Büroräume verzichtet – zugunsten einer flexiblen Nutzung abhängig von der Projektsituation. Cockburn hat die Bedeutung dieser Art von Kommunikation im Kapitel "Convection Currents of Information (Cockburn 2007, S. 107ff) sehr eingänglich beschrieben.

Das interdisziplinäre Team hat sich bei der webfactory seit 2006 sehr bewährt. Vorher bestand das Team ausschließlich aus Softwareentwicklern; Gestaltungsentwürfe wurden von externen Agenturen erstellt. Eine Zusammenarbeit zwischen Gestaltern – insbesondere User Experience-Designern – und Softwareentwicklern über Unternehmensgrenzen hinweg verschärft allerdings das Problem der lokalen Optimierung: Jedes Unternehmen ist versucht, auf ein für sich optimales Projektergebnis zu optimieren anstelle eines optimalen Gesamtergebnisses. Mary und Tom Poppendieck beschreiben dies in Lean Software Development (Poppendieck 2003, S. XXVII).

Featureorientierte Vorgehensweise und Kanban-Workflow

Jedes Entwicklungsvorhaben wird bei uns in möglichst kleine, individuell launchfähige Features zerlegt. Ein Feature hat dabei meistens einen Umfang zwischen einigen Personenstunden und einigen Personentagen. Die erste Zerlegung in Features erfolgt bei uns oft direkt im Kundenworkshop und wird auf einem Trello-Board dokumentiert. Dieses Board dient dann auch direkt zur Visualisierung des Projektfortschritts und damit zur Teamsteuerung. 

Die Anzahl der gleichzeitig in Entwicklung befindlichen Features wird auf ein sinnvolles Minimum (abhängig von der Teamgröße, der Erreichbarkeit des Auftraggebers für Rückfragen und anderen Projektparametern) begrenzt, wodurch sichergestellt wird, dass jedes Feature so schnell wie möglich gelauncht wird. Nach unserer Erfahrung hat dies nicht nur den Vorteil, dass der Nutzen früher entsteht, sondern reduziert auch die Häufigkeit von Fehlern im Betrieb, den Aufwand für Fehleranalyse und Probleme beim Zusammenführen (Merge) des Features mit dem Livesystem. Sobald ein Feature online gegangen ist, kann der Auftraggeber über das nächste zu entwickelnde Feature entscheiden, wie wir es kürzlich im Beitrag Große Projekte Schritt für Schritt realisieren beschrieben haben.

Zum Thema Kanban in der Softwareentwicklung ist das Buch Kanban von David Anderson (2007) sehr empfehlenswert.

Effiziente Aufwandsschätzungen

Aufwandsschätzungen und Angebotserstellung waren lange Zeit ein großes Problem in unseren Projekten.

• Die zuverlässige Voraussage von Entwicklungsaufwand ist meistens mit sehr hohem Schätzaufwand verbunden – im Extremfall kann für die Schätzung eine fast vollständige experimentelle Entwickung erforderlich sein
• Der Schätzaufwand mag teilweise den späteren Entwicklungsaufwand reduzieren, ist aber überwiegend verschwendet (Muda)
• Schätzaufwand für Features, die aufgrund des prognostizierten Entwicklungsaufwandes später nicht beauftragt werden, ist vollständig verschwendet
• Zwischen Schätzung und Implementierung liegen häufig mehrere Wochen oder Monate. Das führt zu doppeltem Einarbeitungs-/Konzeptionsaufwand, da Entwickler das Problem einmal für die Schätzung durchdringen müssen und später noch einmal für die Umsetzung. Nur ein kleiner Teil des Einarbeitungsaufwandes kann durch entsprechende Dokumentation über diese Wartezeit gerettet werden – es sei denn, man treibt für die Dokumentation ihrerseits einen hohen Aufwand.

Auf der anderen Seite muss der Auftraggeber natürlich eine zuverlässige Basis für eine Entscheidung über die zu entwickelnden Features haben - ein Feature, das für 1000 € lohnend ist, wird für 10.000 € vielleicht verworfen.

Zu diesem Zweck haben wir das von Steve McConnell beschriebene T-Shirt-Sizing-Verfahren (McConnell 2006, S. 145) für unsere Projekte angepasst und optimiert. Dieses Verfahren setzen wir nun seit mehreren Jahren erfolgreich ein. Es ermöglicht uns schnelle Schätzungen und dem Auftraggeber damit eine gute und günstige Entscheidungsgrundlage.

Zum T-Shirt-Sizing planen wir in den nächsten Wochen einen eigenen Beitrag.

Shared Project Ownership und Shared Code Ownership

Für den Quellcode ist bei uns das gesamte Team gemeinsam verantwortlich, es gibt keine "Königreiche" einzelner Entwickler. Auf diese Weise kann jeder seine Fähigkeiten am besten einbringen und auch Urlaube sind keine Risiken für den Projektfortschritt.

Für den Erfolg des Projektes setzen wir auf gemeinsame, geteilte Verantwortung (Ownership) zwischen uns und unseren Auftraggebern - ganz im Sinne der Declaration of Interdependence. Dazu gehört auch, dass der Auftraggeber jederzeit und sehr eng in den Entwicklungsprozess eingebunden wird, sodass alle auftretenden Fragen schnell beantwortet werden und im Falle von Missverständnissen oder neuen Erkenntnissen schnell umgesteuert werden kann.

Kostentransparenz und Feedback

Für die langfristige Projektsteuerung auch Seitens des Auftraggebers haben die tatsächlichen Kosten eine weitaus höhere Bedeutung als die ursprünglichen Aufwandsschätzungen. Traditionell kennt der Auftraggeber allerdings nur die Angebotspreise für Features und nicht den tatsächlich entstandenen Aufwand. 

Wurde ein Feature zum Festpreis von einem Personentag angeboten und abgerechnet, muss der Auftraggeber davon ausgehen, dass ein ähnliches Feature beim nächsten Mal auch wieder einen Personentag kostet. Ohne ein Feedback über den tatsächlich entstandenen Stundenaufwand entsteht eine Informationsasymmetrie, die optimale Entscheidungen verhindert:

• Wenn der tatsächliche Aufwand nur einen halben Tag betrug, könnte der Auftragnehmer versucht sein, bei der nächsten Anfrage dennoch wieder einen ganzen Tag berechnen, denn mit diesem Preis wird der Auftraggeber rechnen. Der Auftraggeber zahlt in diesem Szenario dauerhaft zu viel, ohne es zu merken.
• Wenn der tatsächliche Aufwand höher als der angebotene war, ohne dass der Auftraggeber dies erfährt, wird er umgekehrt bei Überlegungen zu zukünftigen, vergleichbaren Features erneut einen Preis von einem Personentag budgetieren. Nehmen wir an, der tatsächliche Aufwand für das erste Feature betrug zwei Personentage. Der Auftragnehmer wird dementsprechend das nächste, vergleichbare Feature mit zwei Personentagen anbieten. Dies lässt nicht nur den Auftragnehmer wegen der Preissteigerung in einem schlechten Licht erscheinen, sondern es kann überdies dazu führen, dass das vom Auftraggeber eingeplante Budget nicht für die geplanten Features reicht.

Aus diesem Grunde führen wir eine minutengenaue Zeiterfassung in unserem Issue Tracker FogBugz durch. Auf dieser Basis können wir jederzeit aktuell über die verbrauchten Projektstunden informieren. Für die Zukunft planen wir einen direkten Kundenzugang zu den Aufwandsdaten über eine geschützte Website, sodass für die Auskunft nicht einmal mehr ein Anruf nötig ist.

Teamkultur

Über unsere Teamkultur haben wir im Inside-Blog schon mehrfach geschrieben und wir halten sie auch für einen zentralen Baustein erfolgreicher Projekte.

Besonders wichtig ist ein offener, konstruktiver Umgang mit Fehlern. Niemand wird für Fehler zurechtgewiesen oder bestraft, sodass es gefahrlos möglich ist, Probleme anzusprechen und eigene Fehler zuzugeben, um gemeinsam nach besseren Lösungen für die Zukunft zu suchen.

Dies entspricht "Personal Safety", einem der wichtigsten Ziele für ein agiles Projekt gemäß der Methodik Crystal Clear (Cockburn 2005, S. 29): Probleme können nur angesprochen und gelöst werden, wenn derjenige, der sie anspricht, dafür nicht mit Angriffen rechnen muss.

Sehr lesenswert zum Thema ist auch die brand eins mit dem Schwerpunkt "Fehler".

Kontinuierliche Verbesserung

Die offene Teamkultur ist auch die Basis für kontinuierliche Verbesserung und gemeinsames Lernen. Unser Entwicklungsprozess und die verwendeten Softwaretools haben sich über Jahre sehr schnell weiterentwickelt: Bei jedem Projekt haben wir überprüft, welche Werkzeuge sich bewährt haben und ob wir noch Probleme hatten, die man durch Modifikationen im Prozess oder neue Tools lösen kann.

Inzwischen kristallisiert sich ein bewährtes Toolset heraus:

• Trello für die visuelle Projektsteuerung (das gesamte Team und der Auftraggeber haben Zugriff auf das Projektboard)
• FogBugz für E-Mail-Kommunikation, Bugreports, Arbeitszeiterfassung und die automatische Erfassung der Codeänderungen, die mit einem Feature verbunden sind
• Confluence für die langfristige Dokumentation und für die Spezifikation und Abstimmung umfangreicherer Features

Für die schnelle und effiziente Budgetauswertung anhand der in FogBugz erfassten Arbeitszeit haben wir eigene Tools wie den Case-Tagger und eine Projekt-Controlling-Datenbank entwickelt – aber dazu demnächst mehr.

Die Suche geht weiter

Auf Projektebene funktionieren die beschriebenen Tools für uns sehr gut. Insbesondere im projektübergreifenden Bereich sind wir allerdings weiter auf der Suche nach Lösungen für folgende Probleme:

• Wenn ein Entwickler an mehreren Projekten mit jeweils eigenen Kanban-Boards beteiligt ist, wie behält er am besten den Überblick? Wie entscheidet er, was er als nächstes tun soll, wenn man nicht eine feste Tageseinteilung vornehmen möchte – also Montag und Dienstag Projekt A, Mittwoch Projekt B, ...?
• Verschärft wird das "Was soll ich tun?"-Problem dadurch, dass manche Aufgaben nur als FogBugz-Cases entstehen (z. B. Bugreports) und zu klein für eigene Kanban-Karten sind bzw. den Überblick im Projekt stören würden. Hier denken wir über ein Dashboard nach, das in Form eines Mashups alle FogBugz-Cases und Trello-Karten des jeweiligen Mitarbeiters übersichtlich präsentiert.
• Auch die Ressourcenzuteilung im Team (wie viele Personen arbeiten in einer bestimmten Woche an Projekt A), die kundenübergreifende Priorisierung von Projekten sowie die Vorhersage der Auslastung sind Aufgaben, für die wir bisher keine regelbasierte Lösung gefunden haben sondern uns auf die langjährige Erfahrung in der Projektsteuerung verlassen.