Zeit sich mal wieder ein wenig der Software-Entwicklung zu widmen und da ich auf Twitter in letzter Zeit diverse Linktips zur Agilen Softwareentwicklung abgegriffen habe, dachte ich mir ich bündele die mal in ein Posting – und gebe natürlich ein wenig meinen Senf dazu.
Den Anfang machte eine Mail auf unserer firmen-internen Scrum Master Mailingliste über The Decline and Fall of Agilists. Der Artikel stellt einerseits einen sehr interessanten Zusammenhang her zwischen Softwareentwicklung und Komplexitätstheorie. Vor allen Dingen geht es aber auch darum nicht nur strikt auf die Einhaltung von bestimmen agilen “Werkzeugen” zu beharren, sondern sich in seinem Projekt die Flexibilität vorzubehalten, die richtigen (=nötigen) Werkzeuge auszuwählen, auch wenn bestimmte “Agile Evangelisten” solche Projekte nicht mehr als agil ansehen würden.
These days, agilists simply claim that agile is about following practices X, Y and Z
Aus meiner eigenen Projekterfahrung denke ich, dass es durchaus legitim ist bestimmte Teile agiler Methoden nicht umzusetzen. Es ist nur absolut notwendig sich dessen auch bewusst zu sein. Es muss ganz klar sein: Dieser Teil meines Projekts ist nicht agil, weil es aus [guten Grund einsetzen] nicht passt. So gab es in einem meiner letzten Projekte zum Beispiel ein Scrum of Scrums, um eine bessere Synchronisation zwischen verschiedenen Scrum Teams zu erreichen. Doch ausser dem Namen hatte dies nichts mit Scrum gemein und es wäre besser gewesen es gleich ein Projekt-Status-Meeting zu nennen (denn nichts anderes war es). Hier kommt aber leider schnell die “Angst” auf, dass man ja agil ist (und sein will) und dann auch bitte an allen Ecken und Enden … aber ich habe meine Zweifel, dass dies gerade in grossen Firmen/Organisationen immer möglich ist … und dann ist es sicherlich besser nur einen (passenden) Ausschnitt an agilen Methoden umzusetzen. Wichtig ist sich dabei nicht in die Tasche zu lügen, denn am Ende zählt immer noch der Projekterfolg; gemessen an Termintreue, Qualität (beides zusammen dürfte die Kundenzufriedenheit massgeblich definieren) und auch Teamzufriedenheit (denn ein “verbranntes” Team hilft niemandem).
Weiter geht es mit zwei Artikeln, die sich mit dem Product Backlog befassen. Hier geht es einmal darum, wie sich Non-Functional Requirements praktisch mit Agilen Methoden managen lassen, denn diese passen normalerweise nicht sonderlich gut in irgendwelche User Stories. Die Idee ist also Non-Functional Requirements an die entsprechenden (neuen) User Stories “anzuhängen”, um sicher zu gehen, dass bei der Implementierung einer neuen User Story keine bestehenden NFR “gebrochen” werden. Ein weiterer Artikel befasst sich mit der Frage Why There Should Not Be a “Release Backlog”.
Ein wichtiger Punkt jeder Softwareentwicklung ist meiner Meinung nach ein Project-End-Review. Wie kann man sonst wissen, was gut oder schlecht gelaufen ist und wie könnte man sonst etwas verbessern. Dieses oft nicht sonderlich strukturierte und wohlmöglich sogar hauptsächlich vom Projekt-Manager getriebene Review (weil es als Punkt abgehakt werden muss) wird bei den Agilen Entwicklungsmethoden durch die Retrospektive ersetzt. Hier wird der Fokus stärker auf das Team gelegt und es findet auch nicht nur ein Review am Ende des Projekts statt, sondern dies wird zu einem kontinuierlichen das Projekt begleitenden Prozess . Der verlinkte Artikel bietet eine sehr gute Zusammenfassung was eine Retrospektive ist (und was nicht).
Retrospectives use a specific structure designed to defuse disagreements and to shift the focus to learning from the experience. The basic technique is to slow the conversation down – to properly explore different perspectives on events before jumping to conclusions.
Das ist schonmal ein ganz entscheidender Punkt, denn es geht nicht darum nur “gemütlich rum zu sitzen” und ein wenig über die letzte Iteration zu sinieren, denn dabei kommt garantiert nicht viel heraus. Daher ist es wirklich ein Muss, dass jede Retrospektive einen (guten!) Facilitator hat. Einen weiteren wichtigen Aspekt definiert die Prime Directive für Retrospektiven von Norm Kerth:
Prime Directive: Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.
Das ist ein Punkt, der mich persönlich sehr interessiert und zu dem ich auch schon viele Erfahrungen in meinem bisherigen Berufsleben sammeln durfte/konnte/musste und wird sicherlich auch nochmal Thema eines weiteren Blog-Eintrags werden.
