Agile Arbeitsweise und DevOps sind moderne Methoden des Projektmanagements, um komplexe und umfassende IT-Entwicklungsvorhaben in den Griff zu bekommen. Das Ziel ist es, die Software den Kunden zeitnah und nach dessen Anforderungen bereitzustellen. Lesen Sie in diesem Beitrag, wie agile Methoden und DevOps zusammenhängen und beide Ansätze für eine erfolgreiche Bearbeitung des Projektes genutzt werden können.

Eignung des Projektes

Es genügt nicht, eine agile Arbeitsweise etablieren zu wollen, man muss es auch in der Praxis leben. Dazu ist es notwendig sich nochmalig den Ansatz von agiler Projektdurchführung in das 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, welche man im Vorhinein nicht genau bestimmen kann. Wir kennen nicht genau das Ziel. Das Ausmaß dieser Unsicherheit ist von Projekt zu Projekt verschieden. Eine einfache Kundendatenbank, ohne Besonderheiten, kann i.d.R. durchgängig geplant werden. Handelt es sich jedoch um ein komplexes CRM-System, wo viele offene Punkte zu klären sind, eine heterogene Datenlandschaft vorliegt und nicht alle gewünschten Funktionen exakt beschreibbar sind, dann sieht die Sache schon vollständig anders aus.

Vertrauensbasis schaffen

Eine agile Arbeitsweise erfordert es, 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, welches 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.

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 Anti-Pattern 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 Projektes ist 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 stetigen Projektfortschritt erfolgt eine Konkretisierung. Man verwendet das Prinzip der rollierenden Planung. Basisentscheidungen, wie zum Beispiel die Architektur des künftigen Softwaresystems müssen auch bei agiler Planung zu Beginn erfolgen (Abbildung 1).
Das Prinzip der rollierender Planung
Abbildung 1: Das Prinzip der rollierender Planung, modifiziert [4].
  • 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, welche an der „internen“ Qualität des Projektes arbeiten. Gerade bei größeren Projekten sind solche Schritte – auch ohne direkten Kundennutzen – unumgänglich.
  • Keine Dokumentation: Gemäß dem agilen Manifest 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 sind zwar wichtig, können jedoch nicht alle Dokumentationen ersetzen.
  • Allzeit Änderungsbereit: Die agile Entwicklung hat das Ziel heute noch nicht erkennbare Einflüsse auch noch im späteren Projektabschnitten umzusetzen. Das hat aber natürlich auch Grenzen. Das Gesamtprojekt und auch die aktuellen Sprints brauchen Konstanz, d.h. auch die Änderungen müssen im Rahmen bleiben bzw. sie benötigen eine gewisse Vorlaufzeit. Ebenso gibt es immer Projektentscheidungen, welche absolut bindend sind und nicht mehr angepasst werden können.
  • Maximal spontan: Agiles Arbeiten heißt nicht, dass wir spontan das gesamte Projekt und die Vorgehensweise jederzeit über Bord werfen können. Planbarkeit und Verlässlichkeit muss 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 dieses (mehrfach) weg, dann fehlt ein wichtiger Baustein.
  • DevOps ist Technik: Bei der Umsetzung von DevOps kommen natürlich unterstützende Werkzeuge zum Einsatz, aber diese machen keine Änderung in der Arbeitsweise aus. Diese Änderungen bedürfen jedoch anderer Vorgehensweisen in der Zusammenarbeit. Man spricht von der Notwendigkeit eines umfassenden Change-Management Prozesses.
  • Unternehmenskultur ist vernachlässigbar: Agile Arbeitsweisen etabliert man nicht über Nacht. Dazu sind umfassende Lernprozesse zu durchlaufen. 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, dann muss auch er erst das agile Vorgehen kennen lernen, es verstehen und es auch akzeptieren. Insbesondere muss er auch lernen, dass er über das gesamte Projekt gefragt ist und aktiv beteiligt wird. Es wird ihn zusätzliche Ressourcen (Zeit) kosten. Das Motto: „Einmal beauftragt und in 10 Monaten bekommen wir das Ergebnis“ funktioniert nicht mehr.

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 zu folgenden wesentlichen Punkten zusammengefasst werden:

  • Starre Strukturen
  • Operatives Geschäft
  • Lange Entscheidungsprozesse

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: Es ist ein Stück Start-up-Mentalität wieder in das Unternehmen zu holen. Das Ziel ist hier der Weg zu einer agileren Organisation. Folgende Teilschritte können dabei helfen:

  • Flachere Hierarchien
  • Cross-Funktionale Teams
  • Feedback als Steuerungsinstrument
  • Agiles Coaching
  • Kundennutzen herausstellen

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 damit die Basis für Erfolg im Wettbewerb.

Links und Literatur

[1] https://agilemanifesto.org/iso/de/manifesto.html
[2] Löffler, Marc: Retrospektiven in der Praxis. Veränderungsprozesse in IT-Unternehmen effektiv begleiten, dpunkt.verlag
[3] Eeles, P: Architecture, Agile and DevOps, https://www.researchgate.net/publication/330202499_Architecture_Agile_and_DevOps
[4] http://de.wikipedia.org/wiki/Rollierende_Planung