Software Maintenance - Alles rund um die Wartung, Instandhaltung, Produktpflege, Maintenance von Software

Man mag sich fragen, was jetzt Kanban und agil mit Software Maintenance zu tun haben. Das einfachste wäre jetzt wohl darauf zu verweisen, daß ich den Zusammenhang in naher Zukunft in diesem Blog darlegen möchte. Das stimmt auch, aber als Erklärung reicht es zum jetzigen Zeitpunkt noch nicht. Also hier die minimal ausführlichere Begründung: Erstens arbeitet das Team, in dem ich momentan beschäftigt bin, erfolgreich mit einem Kanban-System. Zweitens wird Kanban oft, evtl. sogar zu oft, im Zusammenhang mit Scrum und generell mit agilen Methoden genannt, obwohl das keine Selbstverständlichkeit ist. Drittens war heute Abend das monatliche Treffen der Limited WIP Society München, und als einigermaßen regelmäßiger Teilnehmer an diesen Treffen habe ich in den heutigen Open Space die Frage mitgebracht, ob Kanban denn selbst agil sei?

Die Diskussion war lebhafter, als ich erwartet hätte. Mein Ausgangspunkt war, Kanban mit dem Agilen Manifest abzugleichen. Und der erste Beitrag war, daß Kanban ja per se nicht agil ist. Guter Anfang. Hier nochmal die Gegenüberstellung des Agilen Manifests und Kanban:

1. Individuen und Interaktionen > Prozesse und Werkzeuge: Mit Kanban wenden wir ein Werkzeug an, um unseren Prozess darzustellen, also im ersten Moment scheint es wie das Gegenteil eines agilen Vorgehens. Schaut man aber genauer hin, fördert Kanban die Kommunikation im Team, mindestens durch ein Daily Standup, so wie in meinem aktuellen Team gelebt wird. Das Werkzeug erleichert in dem Moment nur, daß wir trotzdem unserem Prozess folgen.
2. Funktionierende Software > Umfassende Dokumentation: Kein direkter Punkt für Kanban, jedoch sehe ich persönlich in der Konzentration auf den Flow eine eindeutige Ausrichtung auf die Software, und nicht auf Dokumentation.
3. Zusammenarbeit mit dem Kunden > Vertragsverhandlung: Ein Kanban-Team setzt voraus, daß man mit dem Kunden zusammenarbeitet, denn der Kunde ist in meinen Augen Teil des Teams.
4. Reagieren auf Veränderungen > Befolgen eines Plans: Heimspiel, würd‘ ich sagen. Das ist definitiv eine der Stärken von Kanban. Die Art der Priorisierung schreibt Kanban ja nichtmal vor. Aber wir können jederzeit neu priorisieren, und das genau ist ja notwendig beim vielzitierten „moving target“.

Bis jetzt sieht’s ganz gut aus. Kanban erfüllt zwar das agile Manifest nicht in allen Punkten, widerspricht aber auch keinem. Gehen wir auf die Prinzipien hinter dem agilen Manifest ein:

1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen:Der Flow zielt genau darauf ab, ein Feature schnell fertig zu kriegen und möglichst früh produktiv zu bekommen, denn erst dann bringt es Geld.
2. Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden: Siehe Punkt 4 im Manifest selbst. Heimspiel.
3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne: Regelmäßig, kurze Zeitspanne, klingt im Idealfall nach Continuous Integration, ebenfalls ein Idealbild bei Kanban.
4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten: Das ist das Ziel des Daily Standup. Dabei entstehen die notwendigen Diskussionen, die danach im kleinen Kreis fortgeführt werden.
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: Den Punkt haben wir heute länglich diskutiert. Erstens sind wir über die „Projekte“ gestolpert. Produktpflege oder Maintenance haben eigentlich eine andere Ausrichtung als ein Projekt, und die Projekt-Exklusivität der agilen Vorgehen kann ich nicht unterschreiben. Das ist aber eher Kritik am Manifest als an Kanban. Zweitens die motivierten Individuen: Beim letzten Treffen der Limited WIP Society München haben wir Voraussetzungen für eine Kanban-Einführung diskutiert. Am meisten hat mich dabei überrascht, daß sich die Diskussion nur um die beteiligten Menschen gedreht hat. Die beiden technischen Punkte, die ich als Vorbereitung auf die Session mitgebracht hatte, waren nur optional. Motivierte Individuen sind tatsächlich unerläßlich für ein funktionierendes Kanban-System. Und der zweite Satz des Prinzips heißt für mich „selbstorganisierendes Team“, ebenfalls in Kanban vorgsehen.
6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht: Daily Standup, wie auch im Punkt 4. Wir sollten aufpassen, daß wir das Daily Standup nicht mit diesen Prinzipien überladen…
7. Funktionierende Software ist das wichtigste Fortschrittsmaß: Ein CFD (Cumulative Flow Diagram) zeigt das sehr gut. Auch wenn es nicht zwingend vorgeschrieben ist, bin ich starker Befürworter dieses Charts. Das war übrigens das Thema einer anderen Session heute Abend.
8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können: Hm. Da Kanban an sich kein agiler Prozess ist, wird’s hier ein bißchen eng. Mir fehlt zumindest der Ansatzpunkt. Vielleicht liegt’s daran, daß mein momentanes Team so gut wie keine Schätzungen mehr vornimmt. Damit ist der Zwang zu selbstdestruktiven Überstunden wegen selbstüberschätzender Aufwandsangabe nicht vorhanden, und es besteht keine Notwendigkeit die Gleichmäßigkeit zu betonen.
9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität: Das klingt mehr wie Agilität als Selbstzweck. Warum sollte ein Kunde denn hohe Qualität wollen, wenn er nur ein funktionierendes Proukt will. Ups. Wir sind ja hier auf softwaremaintenance.de. Passen Maintenance und Agilität wirklich so gut zusammen? Ich finde schon.
10. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell: Na perfekt, oder? Kleine Karten, am besten das „Minimal Marketable Feature“, gehören zu Kanban ebenso, wie die hohe Priorisierung der wirklich wichtigen Dinge.
11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams: Selbstorganisierende Teams haben wir in Prinzip 5 schon gesehen. Daß dadurch Anforderungen und Technik ebenfalls einen Vorteil haben, spielt Kanban nur in die Hände. Und wir haben schon wieder das Thema Qualität, das uns in diesem Blog immer wieder tangieren wird.
12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an: Ein Kanban-System ohne regelmäßige Retrospektiven (oder auch „Operations Reviews“) ist unvollständig. Kaizen ist unabdingbar.

Alles in allem mag Kanban an sich zwar nicht agil sein, aber es widerspricht zumindest nicht dem Agilen Mainfest, sondern unterstützt es gar in vielen Punkten. Ich glaube, daß Kanban zu Recht im agilen Umfeld angesiedelt ist, auch wenn zu meiner Überraschung auf vielen Konferenzen ein Streit zwischen Scrum- und Kanban-Anhängern entsteht. Für mich war das ziemlich unverständlich, als ich es das erste Mal mitbekommen hatte. Wenn man aus einem Unternehmen kommt, in dem der Wasserfall immer noch das höchste Paradigma darstellt, und das Wort „agil“ die Freikarte zum Scheiterhaufen ist, empfindet man die Diskussion um Kanban vs. Scrum als Luxusproblem.