Der erste Sprint, das erste Produkt und die Retrospektive

Ist der Sprint beendet, folgt die sogenannte Retrospektive. In diesem Meeting können alle über die vergangene Entwicklungsperiode sprechen, Verbesserungsvorschläge für die nächste machen und ihre persönliche Empfindung zum Ausdruck bringen.

Im Fall der Mitarbeiter- und Freelancer-Datenbank ist das Resümee des ersten Sprints in der ersten Retrospektive positiv. Es wird zum Beispiel angemerkt, dass die Aufgaben für einen ersten Sprint schon ganz gut durchdacht und definiert gewesen seien und dieses Niveau gehalten und weiter verbessert werden solle. Kritisch gesehen werden die schon genannten Einwürfe von außen, denn das Entwicklungsteam wird sehr oft auf dem Flur oder per Telefon von Angestellten des Kunden befragt, da dieser im gleichen Haus sitzt.

Als konkrete Maßnahme überlegen wir uns, an alle eine Meldung zu versenden, dass das Entwicklungsteam während des aktiven Sprints "on air" sei und daher keine direkten Nachfragen gestattet seien, sondern über den Scrum Master oder Product Owner laufen müssen. Eine Retrospektive sollte nie ohne konkrete Arbeitsschritte etwa zur Verbesserung der Atmosphäre, der Produktivität oder des Sprint-Umfangs verlassen werden.

Nach dem ersten Sprint ist der erste Klickdummy bereit, also ein benutzbares, wenn auch rudimentäres Produkt, mit sehr wenigen Funktionen, das der Kunde aber immerhin schon verwenden kann. Es ist ein einfaches Online-Verzeichnis, in dem man Karten von Personen anlegen und die ersten Informationen, wie Telefonnummer und E-Mail-Adresse, bereits erfassen kann. Die Anwendung wird in diesem Schritt aus Sicherheitsgründen noch lokal betrieben, gibt aber schon ein erstes Gefühl für die Bedienbarkeit. Die Rückmeldung vom Kunden ist positiv. Vor allem, dass es nach so kurzer Zeit bereits etwas zum Ausprobieren gibt, überzeugt. Der nächste Sprint kann geplant werden.

Sprinten bis zum Ziel

Bei unserem Beispielprojekt werden insgesamt acht Sprints durchgeführt, an deren Ende eine funktionierende Mitarbeiter- und Freelancer-Datenbank in einem ansprechenden Design steht. Nach jedem Sprint wird der Zwischenstand dem Kunden präsentiert, der sein Projekt stetig wachsen sehen kann.

Während der Arbeit fällt einem Entwickler auf, dass man das Netzwerk Xing mit einer API-Schnittstelle anbinden könnte, um öffentliche Informationen von Profilen der Plattform direkt in die Datenbank zu übertragen. Dem Kunden wird diese Möglichkeit vorgestellt und es wird sogar noch etwas mehr Budget zur Verfügung gestellt, um dies zu realisieren. Durch die agile Arbeitsweise kann die neue Anforderung während der Entwicklung aufgenommen, definiert und in einem Sprint umgesetzt werden.

Dieses Beispiel zeigt besonders gut die Vorteile von agiler Entwicklung. An erster Stelle steht die Kundenzufriedenheit. Denn durch die aktive Einbindung des Kunden, indem er nach jedem Sprint eine funktionsfähige Vorabversion sehen und testen, Feedback geben und Wünsche äußern kann, fühlt er sich bestätigt und verstanden.

Als zweiter Punkt ist die selbstständige Arbeitsweise der Teams zu nennen, die ihre Arbeitspakete in den Sprints selbst schnüren und umsetzen können. So ist es unter anderem möglich, sich auf Änderungen und Anpassungen wie die Xing-API einzustellen und diese umzusetzen, um damit eine maximale Flexibilität trotz des festgesetzten Projektrahmens zu erhalten.

Neben allen positiven Punkten muss aber auch gesagt werden, dass einige agile Projekte in einem derartigen Unwissen gestartet werden, dass finanzielle Mittel während des Projekts ausgehen können oder eine Software so lange weiter wächst, dass der Prozess der Entwicklung nie abgeschlossen werden kann ("und diese Funktion noch… und diese Funktion noch…"). Es gibt also auch Risiken. Die Arbeit ist zudem herausfordernd, denn tägliche Meetings und Besprechungen, wie man den Arbeitsablauf verbessern und optimieren könnte, sagen nicht jedem zu.

Das ständige Überprüfen der eigenen Arbeit und der verfügbaren Zeit im Hinblick auf die Ziele (Sprintziele, generelle Ziele, finanzielle Ziele) kann auch anstrengend sein. Aus diesem Grund braucht es neben Entwicklern auch Scrum Master, Product Owner und finanziell Verantwortliche, die den agilen Prinzipien folgen. Funktioniert dieses Team und werden Probleme und Hindernisse offen kommuniziert, ist die agile Arbeitsweise für alle Beteiligten und vor allem für die Kunden ein Zugewinn, die in agilen Projekten nachweislich zufriedener sind.

Die Datenbank für Mitarbeiter und Freelancer ist schon vor einiger Zeit entwickelt worden und bis heute im Einsatz. Immer wieder werden Erweiterungspakete vereinbart, um die Entwicklung in kleineren Schritten voranzubringen, das Design zeitgemäß anzupassen oder neue Funktionen einzubauen - für mich ist das ein Paradebeispiel für agile Softwareentwicklung.