Agile Patterns – Teil 4/4: Tipps für den sanften Umstieg zu agiler Softwareentwicklung

Ist Softwareentwicklung ohne agiles Vorgehen überhaupt noch denkbar? Muss ich denn, genauso wie viele andere Unternehmen, mit diesem Trend mitgehen? Ist Softwareentwicklung im klassischen Sinn nicht mehr möglich? Gibt es auch Wege und Mittel beide Welten miteinander zu vereinen?
Bei einer unserer Treffen der Community Of Practice Agile bei ANECON haben wir uns mit diesem Mittelweg befasst und wie ein sanfter Umstieg zu einer agilen Softwareentwicklung gelingen kann. Schließlich bedeutet die Anwendung agiler Methoden (meist wird hier SCRUM verwendet) oft einen Paradigmenwechsel für das gesamte Unternehmen. Dies fängt bei der Planung von Softwareprojekten an und endet bei einer veränderten Unternehmenskultur der Organisation.

Sicht des Managements

Es gibt einige Praktiken, die besonders stark im agilen Vorgehen notwendig sind, aber natürlich auch in jedem anderen Vorgehen verwendet werden können und dort ihren Nutzen stiften.

Kick-off

Jedes (Software-)Projekt sollte mit einem offiziellen Kick-Off starten. Insbesondere wenn man am Vorgehen Änderungen gemacht hat, ist es wichtig alle (idealerweise persönlich Vorort) auf das gemeinsame Projekt einzustimmen. Nur wenn es zu künftigen Änderungen die Zusage und das Engagement durch das Management gibt, kann es zum Erfolg führen.

Change-Backlog

Es ist sinnvoll, die Änderungen im Softwareentwicklungsvorgehen im Rahmen eines „Change Backlog des Managements“ zu verfolgen um ggf. rasch reagieren zu können. Nicht alles ist in Stein gemeißelt und kann bei Bedarf angepasst werden. Es hindert auch niemand daran, dass das Management in der Führung des Unternehmens genauso die Methoden und Praktiken der agilen Welt verwendet. Warum soll es nicht auch hier ein Daily Standup geben, oder ein physisches Board, wo die nächsten anstehenden Tasks für aller klar ersichtlich sind.

Klare Kommunikation & Transparenz

Wichtig ist es, dass jeder versteht, wohin die Reise gehen soll. D.h. man soll von Beginn an ein „Agile Mindset“ definieren und klar kommunizieren. Man kann dies bspw. durch ein agiles Manifest tun welches von jedem im Kick-Off unterschrieben wird. Auch das kann eine Methode sein, die Gemeinschaft zu fördern, alle ins Boot zu holen und die Mitarbeiter auf die bevorstehenden Änderungen einzuschwören.
Sollte es sich zeigen, dass der eingeschlagene Weg nicht der richtige ist oder nicht so funktioniert wie gedacht, sollte man es nicht als einen Fehlschlag sehen oder gar alles über den Haufen werfen, sondern aus den Fehlern lernen. Es ist wichtig Wege zu bieten, um Fehler kommunizieren zu können. Entscheidend ist es, Fehler möglichst bald zu erkennen („Fail fast“, am besten auf allen Ebenen) und daraus die richtigen Schlüsse ziehen.

Teamgeist

Offene Kommunikationskanäle auf und zu allen Ebenen ist ohnedies (und mit Sicherheit nicht nur in agilen Softwareentwicklungsprojekten) zwingend notwendig. Es ist wichtig, dass sich ein gewisser „Teamgeist der Mannschaft“ etabliert. Alle ziehen am gleichen Strang und die Richtung wird gemeinsam bestimmt. Dazu muss hohes Vertrauen in das gesamte Team gesteckt werden. Nur wenn ich diese Vertrauensbasis schaffe und sich das Team selbst organisieren kann, wird es auch zum Erfolg führen.

Sicht des Entwicklerteams

Nun haben wir einige wichtige Punkte erläutert, die aus Sicht des Managements zu beachten sind, wenn die Reise Richtung Agil gehen soll. Aber wie sieht es mit dem eigentlichen Entwicklungsteam und den dort vorhandenen Rollen aus?

Klare Rollenverteilung

Wenn wir bei der bereits vorhin erwähnten Methode SCRUM bleiben gibt es hier zumindest neben den Entwicklern und den SCRUM-Master auch den Product Owner. Je nach Projektsituation kann man dieses Team natürlich auch erweitern.

Wenn es sich um eine thematisch komplexe und sehr breite Angelegenheit handelt, macht es Sinn, mehrere Product Owner einzusetzen oder den Product Owner durch Business Analysten zu unterstützen. Entscheidend wird es jedenfalls sein, dass der Product Owner eine starke und (fachlich) kompetente Person ist, die genau versteht, wohin es gehen soll. Dazu benötigt man selbstverständlich eine enge Abstimmung mit sämtlichen Stakeholdern. Der Product Owner sollte daher auch wirklich mit den notwendigen Kompetenzen ausgestattet sein, um rasch Entscheidungen herbeizuführen und auch diese gegenüber allen Beteiligenden vertreten zu können. Diese Verantwortung bedeutet allerdings nicht, dass der Product Owner zu sehr in technische Details der Lösung involviert ist und sich gar dafür verantwortlich sieht. Der Product Owner soll und muss den Fokus absolut auf die fachliche Seite legen.

Natürlich schadet es nicht, wenn der Product Owner auch technisches Wissen z.B. hinsichtlich Softwaredesign oder Architektur besitzt, nur muss es klar abgegrenzt sein, dass dies nicht in der Verantwortung des Product Owners liegt.

Für das Entwicklungsteam selbst haben wir einige Best Practices identifizieren können, die nicht nur für agile Team sehr praktisch sind:

Scrum Board

Um alle von Beginn an auf das bevorstehende Projekt einzustimmen, ist es eine schöne Sache, wenn alle gemeinsam ein physisches Board gestalten. Dann kennt sich auch gleich jeder aus, wo welches Post-it hingehört bzw. wofür es steht. Hier ist es wichtig, dass es auch wirklich ein physisches Board gibt und nicht nur ein elektronisches, welches von niemanden beachtet bzw. gepflegt wird. Man kann und sollte ebenfalls ein elektronisches Board haben, insbesondere wenn es Teammitglieder gibt, die nicht immer Vorort sein können. Aber eben auch Wert auf die Pflege des physischen Boards legen. Das Board sollte an einem Ort stehen, wo alle Teammitglieder öfters und gerne mal vorbeigehen (ggf. bei der Kaffeemaschine?).

Standup

Auf tägliche Standups oder sonstige Lagebesprechungen soll man auf keinen Fall verzichten. Beim Standup Meeting soll man auch drauf achten, dass dieses wirklich nur sehr kurz dauert. Da hat es sich durchaus bewährt, eine Countdownuhr („Time Timer“) aufzustellen, wo jeder genau sieht, wieviel Zeit noch bleibt. Alternativ kann man das natürlich auch mit einer Sanduhr machen, um die Redezeit bei großen Teams pro Person knapp zu halten. Um in Details zu gehen ist das Standup-Meeting ohnehin nicht geeignet.

Verteilte Teams

Apropos: Verteilte Teams spielen heute in der Softwareentwicklung allgemein eine große Rolle. Deshalb sollte man wie erwähnt auf elektronische Boards nicht verzichten und die Teammitglieder, die außerhalb sitzen, via Video- oder Audiokonferenz zum Daily Standup hinzuziehen. Denn nur dann fühlt sich jedes Teammitglied auch als Teil des Teams. Sonst wird man im Laufe des Projektes sehr einsam und abgeschieden sein.

Tasks

Was die eigentlichen Tasks und deren Größe betrifft, so sollte jeder einzelne Task nicht zu groß bemessen sein. Gerade wenn man neu im agilen Vorgehen ist, sollte jeder Task, zumindest anfangs, innerhalb eines Arbeitstages bewältigbar sein. Sonst verliert man den Überblick und das Team ist schnell frustriert, weil die einzelnen Tasks nicht und nicht fertig werden (Start Finishing, Stop Sarting!).

Unterstützung von oben

Wie bereits bei der Management Sicht erwähnt, sollte ein agiles Vorgehen oder auch das Anwenden von Teilen, nicht von oben aufs Aug gedrückt werden. Die verschiedenen Abteilungen bzw. Hierarchien sollten bestenfalls selbst erkennen, dass es notwendig ist, Änderungen im Vorgehen herbeizuführen. Wenn dann auch noch alle Ideen selbst einbringen bzw. ausprobieren können, ist jeder eher voll bei der Sache und hat Spaß daran, mal was etwas Anderes zu machen. Und überhaupt wissen wir ja schon aus Kindergarten und Volkschulzeiten, dass es am einfachsten ist, wenn man spielerisch lernt und nicht vor der blanken Theorie verzweifelt.

Bugfixing

Ein wichtiger Punkt, der auch zu jedem Softwareentwicklungsprojekt gehört, ist ein klares Bekenntnis, wie mit Softwarebugs umgegangen werden soll. Wie auch immer man diesen Prozess definiert, wichtig ist, dass jeder ein Verständnis davon hat und dieser auch praktikabel im Projekt gelebt werden kann. Sonst sammelt man endlos Bugs und der Frust steigt. Ohnehin ist es wichtig einen ausgewogenen Mix zwischen Entwicklern und Testern zu haben. Und sollte es anfangs definiert werden, inwieweit Testautomatisierung angedacht werden soll bzw. kann.
Wir sind hier der Meinung, dass Testautomatisierung auf allen Ebenen stattfinden sollte (Unit Test, Integration Test, Schnittstellen). Da muss man zu Beginn mit Sicherheit etwas an Zeit investieren, aber je länger das Projekt dauert, desto mehr wird man es zu schätzen wissen.

Delegation Poker

Wir haben jetzt ja schon gehört, dass agiles Arbeiten auch sehr viel mit Selbstorganisation zu tun hat. Eine wichtige Frage die es hier allerdings zu klären gibt ist, wer entscheidet was? Es gilt zu verhindern, dass wichtige Entscheidungen verschleppt oder erst gar nicht getroffen werden. Um diese Frage proaktiv klären zu können, gibt es eine wunderbare spielerische Art, nämlich das Delegation Poker. In Anlehnung an das Planning Poker werden hier Entscheidungsräume für das gesamte Team vom (Projekt-) Manager, über den Entwickler bis zum Tester klar aufgezeigt. Es lohnt definitiv, sich damit zu beschäftigen.

Shu-Ha-Ri Prinzip

Zu guter Letzt, sei hier noch das Shu-Ha-Ri Prinzip erwähnt. Insbesondere wenn man sich erstmalig mit der agilen Softwareentwicklung beschäftigt. Da die Einführung agiler Methoden von allen Beteiligten viel abverlangen kann, ist es wichtig, sich zuerst exakt nach den Regeln vorzugehen (Shu – „Follow the Rule“). Erst wenn man die Regeln verstanden hat, kann man darangehen, diese anzupassen bzw. für die eigenen Bedürfnisse zu adaptieren (Ha – „Break the Rule“). Schlussendlich, wenn man zum Meister geworden ist, kann man eigene Regeln erstellen und entwickelt die agile Methode selbst weiter (Ri – „Be the rule“).

Wie auch immer man das nächste Projekt angehen möchte, es lohnt sich in jeden Fall sich mit agiler Softwareentwicklung auseinander zu setzen. Selbst wenn man nur Teile davon übernimmt, kann dies schon das Mittel zum Erfolg sein. Und wer weiß, vielleicht ist es so erfolgreich, dass man schon bald alle ins agile Boot geholt hat.

Blogreihe
Agile Patterns – Teil 1/4: Überblick Crystal Family
Agile Patterns – Teil 2/4: Prinzipien Crystal Family
Agile Patterns – Teil 3/4: Beispiele Crystal Family
Agile Patterns – Teil 4/4: Tipps für den sanften Umstieg zu agiler Softwareentwicklung

The post Agile Patterns – Teil 4/4: Tipps für den sanften Umstieg zu agiler Softwareentwicklung appeared first on ANECON Blog.