Teil 2: Grau ist alle Theorie …

Agile Entwicklung und DevOps in der Praxis

Dr. Veikko Krypczyk, Olena Bochkor

© Den Rise/Shutterstock.com

Im ersten Teil dieser Artikelserie haben wir gezeigt, welche Ziele mit agiler Projektdurchführung und einer DevOps-Strategie verfolgt werden. Der Erfolg in der Praxis ist jedoch zusätzlich von Erfahrung und einer konsequenten Anwendung abhängig.

Agile Arbeitsweise und DevOps sind moderne Methoden des Projektmanagements, um komplexe und umfassende IT-Entwicklungsvorhaben in den Griff zu bekommen. Ziel ist es, den Kunden die Software zeitnah und entsprechend den Anforderungen bereitzustellen. Zusammenfassend können wir also sagen, dass das Ziel einer agilen Entwicklung ist, die Lücke bei der Ermittlung der Anforderungen zwischen Kunden bzw. Nutzern und dem Entwicklungsteam zu schließen.

Artikelserie

DevOps konzentriert sich dagegen darauf, die Bereiche Entwicklung (Development, Dev) und Betrieb bzw. Bereitstellung (Operations, Ops) mit dem Ziel der Erbringung einer durchgängigen Dienstleistung zusammenzuführen. Beide Sachverhalte sind in Abbildung 1 illustriert (siehe auch die Ausführungen im ersten Teil der Serie). Soweit die Theorie – und in der Praxis? Klaffen dort vielleicht andere Lücken? Was lehrt uns die Projekterfahrung? Derartigen Fragen wollen wir in diesem Teil der Artikelserie nachgehen.

Abb. 1: Zusammenhang zwischen agiler Vorgehensweise und DevOps

Eignung des Projekts

Es genügt nicht, eine agile Arbeitsweise etablieren zu wollen, man muss sie auch in der Praxis leben. Dazu ist es notwendig, sich nochmalig den Ansatz agiler Projektdurchführung ins Bewusstsein zu rufen. Mit der Entwicklung von Software betritt man sehr häufig Neuland. Es müssen Lösungen für Probleme erarbeitet und gefunden werden, die man im Vorhinein nicht genau bestimmen kann. Mit anderen Worten: Wir suchen auch immer ein Stück weit nach Innovation. Dieser Umstand gilt, je mehr Software als Innovationsgeber im Geschäftsprozess fungiert und damit den entscheidenden Beitrag für einen möglichen Wettbewerbsvorteil liefern soll. Gerade durch diese Unsicherheit gerät jedoch die klassische Planung an ihre Grenzen. Wir kennen das Ziel nicht genau, sonst wäre es keine Innovation. Und den Weg dorthin, den kennen wir auch nur ansatzweise. Das Ausmaß dieser Unsicherheit ist natürlich von Projekt zu Projekt verschieden. Eine einfache Kundendatenbank, ohne Besonderheiten, kann in der Regel durchgängig geplant werden. Handelt es sich jedoch um ein komplexes CRM-System, bei dem viele offene Punkte zu klären sind, eine heterogene Datenlandschaft vorliegt und nicht alle gewünschten Funktionen exakt beschreibbar sind, sieht die Sache schon vollständig anders aus.

Software mit einem hohen Maß an Neuem kann man daher nur schlecht nach dem Wasserfallprinzip planen. Den Umfang (Scope) kann man im Vorfeld nur schwer exakt bestimmen. Kosten und Fertigstellungstermine auf Basis dieser Ungewissheit zu schätzen, kann sich als schwierig erweisen. Die Folge ist dann eine Überschreitung der Kosten und eine Nichteinhaltung des Termins, wie wir es aus einer Vielzahl von Projekten kennen. Wir haben schlicht und ergreifend den Umfang des Vorhabens nicht richtig eingeschätzt. Trotz guter Planung konnte uns das auch nicht gelingen, denn Ziel und Weg liegen – wie beschrieben – teilweise im Nebel. Die agile Vorgehensweise dreht diese Zusammenhänge um, Kosten und Termine werden definiert. Das basiert auf einer Vision von den Funktionen der Software. Offen bleibt zunächst der Scope, was jedoch nicht heißt, dass das Ziel der Software in keiner Weise benannt wird. Nur verabschiedet man sich von dem Versuch, jede noch so detaillierte Anforderung zu definieren oder zu planen, denn das würde in vielen Fällen nicht gelingen.

Stattdessen steigt man schnell in die Entwicklung ein. Mit Hilfe von Prototypen werden erste Lösungsversuche konzipiert, validiert und als lauffähige Produktionsversionen umgesetzt. Ein frühzeitiges Nutzer- und Kundenfeedback wird genutzt, um die Vorgehensweise sofort zu hinterfragen, wenn notwendig zu korrigieren und die nächsten Schritte in Richtung des Ziels zu planen. Das ist die Idee der agilen Arbeitsweise, die von der konkreten Methode oder dem gewählten Ansatz unabhängig ist. Diese Veränderung des Scopes ist natürlich nicht immer einfach. Genaue Planungen (Wasserfall) suggerieren einen Vorteil in Form von Kontrolle in allen Dimensionen. Der Kunde beauftragt die Entwicklung eines genau definierten Produkts zu einem festgelegten Preis (Budget) und erwartet die Lieferung pünktlich zum Termin. Da die Planung so (aus den genannten Gründen) nicht funktioniert, kommen agile Ansätze ins Spiel. Den Vorteil der Flexibilität erkauft man sich mit einem vermeintlichen Kontrollverlust. Kunde und Entwickler müssen die Vertrauensbasis haben, dass, trotz variablen Umfangs im Detail, am Erfolg des Projekts gearbeitet wird. Dass das Ziel beweglich ist, heißt ja nicht, dass es keins gibt, und auch nicht, dass es beliebig verläuft.

Trotzdem muss man hier ganz klar festhalten: Das Projekt muss grundsätzlich für eine solche Vorgehensweise geeignet sein. Das bedeutet, dass auch der Kunde bereit sein muss, diese Flexibilität mitzutragen. Handelt es sich um ein genau spezifizierbares Vorhaben, zum Beispiel um die Implementierung einer neuen Funktion, dann ist eine solche Flexibilität des Scopes nicht zu begründen. Beispielsweise müssen zu Beginn eines Jahres sehr häufig bestehende Applikationen an sich ändernde Vorgaben und Rahmenbedingungen angepasst werden. Das sollte nach Wartungsvertrag bis Ende Januar des neuen Jahres abgeschlossen sein – in klarer Termin und eine klare Vorgabe bezüglich des Umfangs (Ziels). Der zu ergänzende Funktionsumfang kann wunderbar durch eine genaue Anforderungsdefinition festgelegt werden. Hier ist das Wasserfallmodell weiterhin passend.

IT Security Camp
IT Security Camp

Interview mit Christian Schneider zum Thema „DevSecOps“.

DevSecOps ist, bezogen auf Security-Checks, die logische Fortführung der Automatisierung im DevOps-Sinne

Vertrauensbasis schaffen

Eine agile Arbeitsweise macht es notwendig, dass der Auftraggeber ein Stück weit die Kontrolle abgibt und darauf vertraut, dass der Auftragnehmer zum Termin eine funktionsfähige Softwareversion liefert. Mit der Zeit schreitet die Entwicklung voran und gemeinsam wird ein hochwertiges Produkt erstellt, das die Probleme des Kunden löst. Die Schaffung dieses Vertrauensverhältnisses basiert auf den agilen Werten. Eine gute Orientierung gibt das agile Manifest. Diese Leitlinien bilden die Basis einer erfolgreichen Zusammenarbeit zwischen Kunde und Entwicklern. Es lautet wie folgt:

„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“ Die folgenden Prinzipien bilden das agile Manifest:

  1. „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
  2. Heisse [sic!] Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
  3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
  4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
  5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.
  6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
  7. Funktionierende Software ist das wichtigste Fortschrittsmaß.
  8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
  9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
  10. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
  11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
  12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.“

Diese Prinzipien sind also Leitlinien für uns Entwickler, um den Entwicklungsprozess gemeinsam mit den Kunden zu gestalten.

Agile Missverständnisse und DevOps-Verwirrungen

Eine gewollte agile Arbeitsweise löst noch keine Probleme. Es gilt, mit Missverständnissen aufzuräumen. Man könnte diese auch als agile Antipattern bezeichnen:

Keine Planung: Agiles Arbeiten heißt Flexibilität zu beweisen und auf Änderungen vorbereitet zu sein. Das heißt ausdrücklich nicht, dass eine Planung nicht notwendig ist. Zu Beginn des Projekts ist natürlich auch bei einer agilen Vorgehensweise eine umfassendere Planung unumgänglich. Weiter in der Zukunft zu realisierende Programmfunktionen werden jedoch zunächst nur mit einer Grobplanung versehen. Mit stetigem Projektfortschritt erfolgt eine Konkretisierung. Man kann das Prinzip der rollierenden Planung (Abb. 2) anwenden Basisentscheidungen, wie zum Beispiel die Architektur des künftigen Softwaresystems, müssen auch bei agiler Planung zu Beginn erfolgen.

Rollenplanung Agile

Abb. 2: Das Prinzip der rollierenden Planung

  • Zwang nach Features: Eine agile Vorgehensweise suggeriert, dass mit jeder Iteration (Sprint) neue Funktionen in die Software zu integrieren sind und damit der Kundennutzen stetig wächst. In der Praxis sind aber auch Sprints notwendig, die an der internen Qualität des Projekts arbeiten. Gerade bei größeren Projekten sind solche Schritte – auch ohne direkten Kundennutzen – unumgänglich.
  • Keine Dokumentation: Dem agilen Manifest zufolge ist Code wichtiger als Dokumentation. Das heißt aber nicht, dass eine Dokumentation vollständig überflüssig ist. Sprechender Code, im Sinne eines konsequenten Clean-Code-Development, ist zwar wichtig, kann jedoch nicht jegliche Dokumentationen ersetzen.
  • Allzeit änderungsbereit: Die agile Entwicklung hat das Ziel, heute noch nicht erkennbare Einflüsse auch noch in späteren Projektabschnitten umzusetzen. Das hat aber natürlich auch Grenzen. Das Gesamtprojekt und auch die aktuellen Sprints brauchen Konstanz, das heißt, Änderungen müssen im Rahmen bleiben bzw. sie benötigen eine gewisse Vorlaufzeit. Ebenso gibt es immer Projektentscheidungen, die absolut bindend sind und nicht mehr angepasst werden können.
  • Maximal spontan: Agiles Arbeiten heißt nicht, dass wir jederzeit spontan das gesamte Projekt und die Vorgehensweise über Bord werfen können. Planbarkeit und Verlässlichkeit müssen für einen bestimmten Zeitraum – zum Beispiel für den laufenden Sprint – in absoluter Form garantiert werden.
  • Feedback kostet nur Zeit: Feedbackrunden sind oft nicht beliebt. Herrscht Zeitdruck, werden diese gern weggelassen. Das agile Vorgehen basiert jedoch im Wesentlichen darauf, aus gewonnenen Erkenntnissen übergreifend im Team für den nächsten Sprint zu lernen. Lässt man diesen Schritt (mehrfach) weg, fehlt ein wichtiger Baustein.
  • DevOps ist Technik: Bei der Umsetzung von DevOps kommen natürlich unterstützende Werkzeuge zum Einsatz, die machen aber keine Änderung in der Arbeitsweise aus. Die Änderungen bedürfen anderer Vorgehensweisen in der Zusammenarbeit. Man spricht von der Notwendigkeit eines umfassenden Changemanagementprozesses.
  • Unternehmenskultur ist vernachlässigbar: Agile Arbeitsweisen etabliert man nicht über Nacht. Dafür müssen umfassende Lernprozesse durchlaufen werden. Die Mitarbeiter müssen den Wechsel in der Vorgehensweise schrittweise nachvollziehen; das kann dauern.

Gerade die Schwierigkeit, neue Vorgehensweisen bei der Teamarbeit zu etablieren, wird häufig unterschätzt. Nicht alle Mitarbeiter heißen die gewollte neue Dynamik mit offenen Armen willkommen. Auch Kunden wollen überzeugt werden. Hat ein Kunde bisher lediglich nach dem Wasserfallmodell gearbeitet, muss auch er erst das agile Vorgehen kennenlernen, es verstehen und auch akzeptieren. Insbesondere muss er auch lernen, dass er über das gesamte Projekt hinweg gefragt ist und aktiv beteiligt wird. Es wird ihn zusätzliche Ressourcen (Zeit) kosten. Das Motto: „Einmal beauftragt und in zehn Monaten bekommen wir das Ergebnis“ funktioniert nicht mehr.

Ein Bericht aus der Praxis: Interview mit Tim Friedrich von ApiOmat

Aus der Praxis berichten wir hier anhand der Erfahrungen eines Dienstleisters für Digitale Transformation. Wir hatten die Gelegenheit, ein Interview mit Tim Friedrich zu führen, und haben die wesentlichen Erkenntnisse daraus zusammengestellt:

In welchen Projekten spielt DevOps eine besondere Rolle? DevOps spielt in allen Projekten, in denen wir primär als Entwickler tätig sind, eine entscheidende Rolle. Wir bieten eine umfassende IT-Dienstleistung. Die meisten Mitarbeiter unseres Unternehmens sind von Haus aus Entwickler. Dennoch wollen wir den kompletten Lifecycle unterstützen und können dabei nicht formal an einer Aufgabentrennung festhalten. Bei den Mitarbeitern handelt es sich gewissermaßen um ein autonomes Team, das sich selbst um die eigene Infrastruktur kümmert. Dadurch werden künstliche Schnittstellen und Wartezeiten vermieden.

Welche Aufgaben sind vom IT-Betrieb zum Projektteam übergesiedelt? Die Mitarbeiter des Teams übernehmen neben den Aufgaben der Entwicklung nun auch folgende Aufgaben, die man nach bisherigem Verständnis dem IT-Betrieb zugeordnet hätte: das Festlegen der Deadlines zur Bereitstellung, das eigentliche Deployment inklusive der Veröffentlichung des Projekts in den Produktionsbetrieb und Teile des Supports im Livebetrieb.

Welche Anforderungen müssen die Teammitglieder dazu erfüllen? Es genügt nicht mehr, einfach „nur“ Softwareentwickler zu sein. Um den gesamten Software-Lifecycle abzudecken, sind auch umfassende Kenntnisse in Theorie und Praxis über den IT-Betrieb inklusive Bereitstellung, Produktion und Support notwendig. Die Mitarbeiter müssen stets bereit sein, zu lernen und ihr Wissen auch in für sie bisher unbekannten Domänen zu erweitern.

Welche Vorteile ergeben sich für die Projektgestaltung und -umsetzung für Ihre Kunden aus einer solchen konzentrierten Vorgehensweise? Sehen Sie hier auch Kostenvorteile? Der Kunde braucht keine einzelne Software. Er benötigt eine umfassende digitale Lösung für sein spezielles Problem. DevOps vermeidet Schnittstellen zwischen den Zuständigkeiten und beschleunigt den gesamten Prozess erheblich. Das spart letztendlich auch Kosten, vor allem aber stellt es die Lösung zeitnah bereit und verschafft möglicherweise Wettbewerbsvorteile.

Gibt es Tools, die die Ziele von DevOps aus technischer Sicht voranbringen? Als erstes ist hier natürlich Docker zu nennen. Docker revolutioniert gewissermaßen den gesamten Prozess, von der Entwicklung bis zum Deployment. Damit sind wir in der Lage, die gesamte notwendige Infrastruktur in allen Phasen effektiv und leichtgewichtig zur Verfügung zu stellen. Andere Tools, wie zum Beispiel Jenkins als Build-Werkzeug, werden projektindividuell verwendet.

Welche Hürden gibt es nach Ihren Erfahrungen immer wieder zu meistern? DevOps geht mit agilem Arbeiten Hand in Hand. Alle Beteiligten müssen diesen Weg wollen und sich auf Veränderungen und eine ganzheitliche Zuständigkeit einlassen.

Start-up-Mentalität implementieren

Warum fällt es gerade etablierten Unternehmen schwerer, eine agile Arbeitsweise und damit die notwendige Flexibilität für Innovationen zu etablieren? Die Antwort darauf ist recht schnell gefunden und kann in den folgenden wesentlichen Punkten zusammengefasst werden:

  • Starre Strukturen: Zuständigkeiten in Form von Abteilungen und Stellen sind die Folge von Wachstum in der Vergangenheit. Die statische Organisationsstruktur ist die Antwort des Unternehmens, um komplexe Aufgaben zu bewältigen. Man antwortet gewissermaßen mit Spezialisierung. Der Nachteil besteht in einem erheblichen Verlust an Flexibilität.
  • Operatives Geschäft: Etablierte Unternehmen hängen oftmals im operativen Geschäft fest. Sie müssen die Anforderungen ihrer Stakeholder bedienen und damit Geld verdienen. Eine agile Arbeitsweise in Teilbereichen einzuführen, kann sich daher als schwierig erweisen.
  • Lange Entscheidungsprozesse: Auch sie sind die Folge einer starken Spezialisierung, einer Überlastung der Entscheidungsebenen und von zu wenig Entscheidungskompetenz auf Arbeitsebene.

Was kann dagegen getan werden? Die Antwort lautet: Bezüglich der Unternehmensstrukturen ein wenig zurück zu den Anfängen zu gehen. Mit anderen Worten: Ein Stück Start-up-Mentalität in das Unternehmen zurückzuholen. Das Ziel ist der Weg zu einer agileren Organisation. Folgende Teilschritte können dabei helfen:

  • Flachere Hierarchien: Um den Teams die notwendigen Kompetenzen zu geben, müssen die Strukturen in den Unternehmen dazu passen. Statt ausgeprägter Hierarchien sind flache Strukturen zu bevorzugen. Dabei kann man so weit gehen, dass man die Teams direkt der Geschäftsführung unterstellt. Mit der Etablierung von flachen Hierarchien treten Titel und formelle Stellenbeschreibungen in den Hintergrund, denn darüber könnten Hierarchien implizit erzeugt werden.
  • Cross-funktionale Teams: Sie zeichnen sich dadurch aus, dass sie darauf ausgerichtet sind, umfassende und komplexe Aufgaben als Ganzes zu lösen. Cross-funktionale Teams weisen unterschiedliche und vielfältige Qualifikationen auf. Neben Entwicklern können das zum Beispiel Tester, Mitarbeiter für das Qualitätsmanagement und dem DevOps-Gedanken folgend auch Personen sein, die für die Bereitstellung und den Betrieb zuständig sind. Cross-funktionale Teams sollen weitgehend autark agieren, sie übernehmen Aufgaben komplett, erarbeiten Lösungen und interagieren selbstständig mit den Kunden bzw. Auftraggebern. Mit anderen Worten: Die Teams sind für ihre Arbeiten, die übernommenen Aufträge und deren Erfolg vollständig verantwortlich. Das gilt im Erfolgsfall und beim Scheitern.
  • Feedback als Steuerungsinstrument: Dem Feedback kommt bei der agilen Projektsteuerung eine ganz besondere Bedeutung zu. Es ist die Basis für Lernprozesse. Wie eine solche als Retrospektive bezeichnete Feedbackschleife gestaltet werden kann, darüber gibt der Kasten: „Retrospektive als Lernform“ einige Hinweise.
  • Agiles Coaching: Das Wissen um agile Methoden und Vorgehensweisen kann nicht automatisch vorausgesetzt werden. Ein agiles Coaching ist dann durchaus angezeigt. Ein agiler Coach sollte als neutrale Person fungieren und nicht direkt an den betreffenden Projekten beteiligt sein. Hier kann man sich durchaus auch externe Kompetenz ins Haus holen.

Kundennutzen herausstellen: Für wen wird die Software erstellt? Wer zahlt die Rechnung? Richtig, der Kunde. Das muss unbedingt herausgestellt werden. Eine hohe Kundenzufriedenheit ist das Ziel aller Bemühungen. Agile Projektmethoden und DevOps werden nicht eingeführt, damit wir (Entwickler, Designer, Projektmanager) eine neue Spielwiese haben, sondern um die Anforderungen unserer Kunden besser in Form von Software umsetzen zu können (Kasten: „Frage an Julia Lahn-Dönmez“).

Retrospektive als Lernform[1]

Eine Retrospektive bezeichnet eine Nachbetrachtung mit dem Ziel, aus Erfolgen und Fehlern zu lernen. Idealerweise sollte man eine solche Retrospektive durch eine neutrale Person moderieren lassen. Gleich zu Beginn ist allen Beteiligten klarzumachen, dass eine Retrospektive den Fokus auf die positiven Handlungen legt und damit ein Instrument des kontinuierlichen Verbesserungsprozesses ist. Ein solches Meeting sollte regelmäßig stattfinden und einem bestimmten Abschnitt (Iteration) zugeordnet sein. Der betrachtete Zeitraum sollte nicht allzu groß gewählt werden (zum Beispiel ein Monat) um noch praxisnah arbeiten zu können.

Eine Retrospektive kann man in Phasen einteilen. Aus Theorie und Praxis werden folgende Phasen empfohlen (Abb. 3):

  1. Initiierung: Hier geht es darum, alle Beteiligten auf das folgende Meeting einzustimmen und sie aus ihren Alltagsaufgaben abzuholen. Sie sollen sich vollständig auf das Thema der Retrospektive konzentrieren. Es werden der Zeitrahmen, die Agenda und die Regeln des Meetings (keine Nutzung des Smartphones, keine Schuldzuweisungen, konstruktive Kritik) besprochen bzw. aufgefrischt.
  2. Hypothesen prüfen: Es werden die Hypothesen der letzten Retrospektive überprüft. Was wurde erreicht? Welche Maßnahmen haben schon eine Wirkung gezeigt? Mit Hilfe von Hypothesen wird das Team in die Lage versetzt, an einem Thema (Problem) so lange zu arbeiten, bis eine akzeptable Lösung herbeigeführt wurde.
  3. Fakten zusammentragen: Alle Daten zum Thema der Retrospektive für den betrachteten Zeitraum werden zusammengetragen. Achtung: Nicht alle Probleme gehören hierher. Es ist eine strikte Begrenzung auf das Thema und den betrachteten Zeitraum notwendig. Solche Daten können Erfahrungen, Messergebnisse, Kundenrückmeldungen usw. sein. Auch eine Visualisierung kann angebracht sein. Arbeiten Sie zum Beispiel interaktiv an einem Whiteboard.
  4. Einsichten gewinnen: Hier geht es darum, die Zusammenhänge, d. h. Ursachen und Wirkungen aufzuspüren. Auch gilt: Zusammenhänge sind noch keine Lösungsvorschläge. Erst muss das Problem vollständig durchdrungen sein, damit man passende Lösungen dazu erarbeiten kann.
  5. Experimente planen und Hypothesen aufstellen: Niemand kann vorhersagen, ob ein Lösungsvorschlag funktionieren wird. Man wählt einige passende Optionen aus (Selektion notwendig), dokumentiert sie kurz und versucht, sie in der kommenden Zeit umzusetzen. Derartige Maßnahmen haben den Charakter eines Experiments. Passend dazu werden konkrete und überprüfbare Hypothesen formuliert. Zum Beispiel: „Auf Grund der geänderten Testplanung (Experiment) soll die Zahl der Fehler in den betreffenden Modulen um 40 Prozent gesunken sein (Hypothese)“. Das ist konkret und überprüfbar. Die Ergebnisse dieser Phase sollten für alle Mitglieder im Team sichtbar sein, zum Beispiel auf einem Flipchart.
  6. Abschluss: Wie die Einführungsphase die Teilnehmer abholt, ist es danach ebenso wichtig, sie wieder geordnet in den Alltag zu entlassen. Man sollte nach der Festlegung der Ergebnisse nicht sofort abbrechen, sondern zum Beispiel nochmals zusammenfassen. Auch ein Feedback zur Retrospektive ist ein gutes Mittel. Wie kann man sie noch besser gestalten?

Auch Retrospektiven müssen unbedingt zeitlich begrenzt werden. Eine gute Orientierung sind 60 Minuten. Gelegentlich kennt man auch den Hinweis: „Eine Stunde und eine Seite“. Das bedeutet, das Meeting sollte die Dauer dieser Zeitspanne nicht überschreiten und die Ergebnisse sollten auf eine Seite passen. Für die Phasen kann man dann folgende Zeiten ansetzen:

  1. Initiierung: 5 Minuten
  2. Hypothesen prüfen: 5 Minuten
  3. Fakten zusammentragen: 10 Minuten
  4. Einsichten gewinnen: 20 Minuten
  5. Experimente planen und Hypothesen aufstellen: 15 Minuten
  6. Abschluss: 5 Minuten

Abb. 3: Reihenfolge einer strukturierte Retrospektive

 

Frage an Julia Lahn-Dönmez (Customer Success Manager und Scrum Master/Agile Coach bei ApiOmat)
An welcher Stelle sehen Sie die meisten Vorteile eines solchen Vorgehens?Ganz klar im Erfolg für den Kunden. Scrum und Kanban folgen einem inkrementellen Ansatz. Dadurch können erfolgsentscheidende Themen für das Projekt bzw. das Produkt sehr zeitig und dementsprechend auch kostengünstig angegangen werden. Allerdings bedarf es doch einiger Erfahrung, um genau diese Fragestellungen mit dem Kunden herauszuarbeiten, zum Beispiel:

  • „Ist es eine spannende neue Idee und ist es entscheidend, als erster auf dem Markt zu sein?“
  • „Wird eine neue Technologie benötigt und sind wir noch unsicher, ob sie schon Produktreife hat?“
  • „Soll ein Bestandssystem ersetzt werden und gibt es riskante Integrationsthemen?“
  • „Was ist die Kernfunktionalität, die der Nutzer lieben muss, damit unser Produkt zum Erfolg wird?“

Manchmal kann es sein, dass es mehrere MVPs (Minimum Viable Products) und Feedbackrunden braucht, bis man den richtigen Ansatz gefunden hat. Eine Wahrheit, die jeder, der länger in der IT arbeitet, schon am eigenen Leib kennengelernt hat, ist, dass sich Anforderungen ändern. Das gilt selbst bei den erfahrensten und besten Teams. Es liegt einfach daran, dass es in jedem Projekt Fragen gibt, die sich im Voraus einfach nicht klären oder manchmal nicht einmal erwarten lassen. Das agile Manifest lehrt uns, solche Planänderungen mit offenen Armen zu empfangen, um sie anzugehen. Konventionelle Methoden bieten hierfür einfach keine adäquaten Vorgehensalternativen.

Der Vorteil kommt aus der engen Kollaboration mit dem Kunden, der insbesondere im Scrum Framework in Form der Scrum Events eingebaut ist. Die definierte Regelmäßigkeit reduziert Komplexität für eine sonst deutlich schwerer zu steuernde Herausforderung.

Fazit

Agile Projektdurchführung und DevOps sind nicht nur theoretische Konzepte, sondern heute in der Praxis angekommen. Erfahrungen zeigen, dass es dabei darum geht, veränderte Vorgehensweisen wirklich umzusetzen und es nicht bei Worthülsen zu belassen. In diesem Fall werden Projekte erfolgreicher und der Kundennutzen steigt. Zufriedenere Kunden sind die beste Werbung und damit die Basis für Erfolg im Wettbewerb.

Verwandte Themen:

Geschrieben von
Dr. Veikko Krypczyk
Dr. Veikko Krypczyk
Dr. Veikko Krypczyk studierte und promovierte in Betriebswirtschaftslehre mit dem Schwerpunkt Wirtschaftsinformatik. Er ist Entwickler und Fachautor. Aktuell beschäftigt er sich mit der App-Programmierung für Windows Phone und Android.
Olena Bochkor
Olena Bochkor
Olena Bochkor studierte Betriebswirtschaftslehre u. a. mit dem Schwerpunkt Wirtschaftsinformatik. Weitere Informationen zu diesen und anderen Themen der IT finden Sie unter http://it-fachartikel.de.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: