Da ich einen Vortrag über Agile Softwareentwicklung halten werde, dachte ich mir, ich könnte das Thema auch mal hier thematisieren. Also beginnen wir mit Artefakten, Plannings, Storypoints, der „Definition of Done“… oder wir reden über etwas ganz Anderes.

Seht, über all diese Dinge gibt es Hunderte von Artikeln. Die sind ausserdem mit hübschen Bildern ausgestattet. Oder Videos. Oder Katzen. Da kann ich nicht mithalten (speziell nicht bei den Katzen).

Also informiert euch via Wikipedia oder Google (Ich werde ein paar weiterführende Links unten einfügen) über die Grundlagen und lasst uns gleich zu einem anderen Thema springen.

Warum geht es so oft schief?

Nur damit wir uns verstehen: Ich liebe die Agile Softwareentwicklung! Die Möglichkeit zusammen mit dem Business die Richtung in einem Projekt immer wieder ändern zu können, zu lernen, Fehler zu machen, ist einfach grossartig. Daneben erscheint mir die normale Projektarbeit mit ihren Vorstudien, Detailstudien, Kontrollinstanzen, etc. sehr starr, fast wie eine Fabrik, in der ich nur am Band stehe und Code im Akkord fertige.

Aber trotzdem gibt es Dinge, die nicht gut funktionieren und die müssen wir ansprechen, vielleicht können wir sie dann besser machen.

Agile Softwareentwicklung ist nur ein Aufkleber

In manchen Firmen ist Agile Softwareentwicklung mehr sowas wie die ISO 9001-Plaketten, die am Empfang an der Wand hängen und verstauben. Man hat irgendwann drei Entwickler in einen Scrum-Kurs geschickt, eine weisse Wand mit ein paar Strichen bemalt und seitdem erwähnt man in Offerten, dass die Entwicklung „agil“ sein wird.

Würde man den Verkäufer oder Marketingleiter dazu auffordern „Agile Softwareentwicklung“ zu definieren, gäbe es nur ein hilfloses Schulterzucken zu sehen. Das ist schliesslich etwas „Was unsere Techies tun“ und das nichts mit dem Management zu tun hat

Falsch.

Agilität muss durchgezogen werden bis oben, damit es sein volles Potenzial entfalten kann. Was bringt es uns, wenn zwar die Entwickler alle zwei Wochen in neue Richtungen entwickeln können, aber das Management nur einmal im Jahr eine Roadmap festlegt.

Lösungsvorschläge

Also was können wir tun, damit Agilität auch bis nach oben durchkommt? Hier einige typische Fragen des Business und mögliche Antworten darauf:
„Ein Projekt braucht einen Projektantrag und in dem müssen Start, Ende sowie möglichst schon alle Anforderungen eingetragen werden. Ich kann nicht einfach mal anfangen.“

Das verlangt auch keiner! Natürlich brauchen wir einen Startpunkt. Auch einen Endpunkt können wir definieren und wir werden zu dem Zeitpunkt ein lauffähiges Produkt liefern. Nur was in dem Produkt enthalten ist, darüber können wir im Augenblick noch wenig sagen.

Aber seid mal ehrlich: Wie viele Projekte wurden in der Vergangenheit zum definierten Endpunkt fertig und hatten alle im Projektantrag genannten Eigenschaften? Ich habe einige Zahlen darüber gelesen und stelle deshalb einfach mal 20% in den Raum. Höchstens.

Eigentlich muss sich nicht viel ändern. Definiert Startpunkt, Endpunkt sowie die Anforderungen wie gewohnt. Anschliessend legt ihr für die Anforderungen eine Rangliste fest. Die erste Anforderung werden wir zuerst umsetzten und können diese releasen, weit vor dem Projektende, wenn gewünscht. Anschliessend gehen wir in der Rangfolge weiter, bis das definierte Enddatum erreicht ist.

Möglicherweise werden wir nicht alle Anforderungen umsetzen, aber das dürften auch die Punkte sein, deren Einfluss klein ist (Schliesslich gab es einen Grund, weshalb diese in der Rangfolge später kommen).

„Ohne genauen Projektablauf weiss ich ja nicht, was das kostet. Ich muss aber Budget beantragen!“

Wenn das Team noch keine agilen Softwareprojekte gemacht hat, ist das in der Tat ein Problem. Nimm in so einem Fall die Tage zwischen Startdatum und Enddatum, rechne diese mal die Anzahl Entwickler mal deren Durchschnittslohn und du hast die maximalen Kosten. Stark vereinfacht natürlich.

Wenn es schon agile Projekte mit dem Entwicklerteam gab, lass dir die Velocity dieses Teams geben (Also die Anzahl an Storypoints, die es pro Sprint fertigstellen kann). Anschliessend erfasst du Storys zu allen deinen gewünschten Anforderungen, das Team schätzt deren Komplexität und voila, du hast die benötigte Anzahl Sprints. Das noch mal Entwickler und mal Durchschnittslohn, und du hast den ungefähren Betrag.

Am besten verteilst du aber die Kosten erst nach Projektabschluss und man sieht das Entwicklungsteam als Ressource, die Projekte nach Wichtigkeit verarbeitet.

Abschluss

So, dass waren erst zwei, aber der Artikel wird jetzt schon etwas lange. Ich werde nächstens weitere Vorschläge posten, wenn Fragen an mich gestellt werden oder mir selber was in den Sinn kommt.