Continuous Improvement: Mit kleinen Schritten zu mehr Effizienz und Qualität in der Projektarbeit

cont-imp

 In der Software-Entwicklung gibt es ein Muster, das sich in fast allen Projekten wiederfindet: Zu Beginn eines neuen Projektes wird so über dessen Organisation und Struktur diskutiert, als wäre noch nie zuvor ein vergleichbares Projekt durchgeführt worden. Beispielsweise werden die Themen Branching-Modell, zu verwendende Tools, das Wann und Wie der Meetings, Code-Style Regeln oder auch Quality-Gateway Regeln besprochen.

Je nach Zusammensetzung und Erfahrung des jeweiligen Teams erhalten Sie im Ergebnis ein mehr oder weniger performantes und erfolgreiches Projekt-Setup.
Das Problem dabei: Erfahrungen aus früheren Projekten werden zumeist ignoriert und die Gründe für den Erfolg oder Misserfolg vergangener Projekte sind oftmals nicht (mehr) bekannt. Dadurch findet kein Lern- und Optimierungsprozess auf Basis von gesammelten Erkenntnissen statt.

Ein Grund dafür ist, dass möglichst alles „agil“ zu sein hat – spontan, kreativ im Stil eines modernen Start-Ups. Das Team entscheidet gleichberechtigt über Organisation und Ablauf. Der Aufwand und die Unruhe für solche „Selbstfindungsphasen“ zu Beginn eines Projektes ist nicht zu unterschätzen. Je nach Zusammensetzung des Teams stehen die Chancen auch gar nicht schlecht, dass man sich damit gleich die erste Dauerbaustelle eingetreten hat.

Aber was bedeutet eigentlich „Continous Improvement“?
Wir bezeichnen dabei einen kontinuierlichen (evolutionären) Verbesserungsprozess, eine langsame aber stetige und auf Erfahrungswerten basierte Verbesserung der Art, wie wir Software entwickeln und Projekte umsetzen.
Die Verbesserung kann dabei an beliebigen Stellen der Entwicklung ansetzen: Abläufe in der Entwicklung, Optimierung der Testautomatisierung, Deployment, etc.

continuous-improvement

Das Franchising-Modell

Das Franchising-Modell bietet einen guten Ansatz für das Continous Improvement. Beim Franchising gibt der Franchising-Geber alle wichtigen Rahmenbedingungen vor: Das Produktangebot, wie die Produkte hergestellt werden müssen, die Einrichtung der Verkaufsräume, die Kleidung der Mitarbeiter, etc.

Für den Franchise-Nehmer bleibt nicht viel Raum für Kreativität, der Kunde kann sich jedoch auf eine definierte Produktqualität oder ein definiertes Einkaufserlebnis verlassen – egal in welcher Filiale oder in welchem Land er den Laden einer Franchise-Kette betritt.

Franchising in der Projektarbeit

Dieses System kann man auch auf das Projektmanagement übertragen:

Der Franchisenehmer – das Projekt-Team – erhält ein verbindliches Set an Vorgaben bezüglich der Durchführung eines Projektes. Diese Vorgaben sind die Essenz aller positiven Erfahrungen vergangener (vergleichbarer) Projekte.
Mit dem Anwenden des „Franchising-Modells“ kann das Projekt-Team sofort mit der Arbeit beginnen und der Kunde erhält als Ergebnis eine definierte Qualität.

Ein echtes Franchising wäre im Bereich der Software-Entwicklung allerdings zu statisch. Hierbei fehlt die Optimierung der bestehenden Prozesse und Vorgehensweisen; sprich, das Lernen und die Weiterentwicklung.
Eine Organisation oder ein Team das nicht in der Lage ist aus Erfahrungen zu lernen gleicht einer Person, die aufgrund einer Krankheit oder eines Unfalls über ein eingeschränktes Langzeitgedächtnis verfügen und nicht mehr auf früheres Wissen zurückgreifen können.

Für ein Projekt-Team als lernender Organismus ist es aber wichtig, sich von dieser Art der Amnesie zu befreien.

Entwicklungsprozesse und Projekt-Templates

 Ein Ansatz, dieses Vergessen zu beenden, ist der Einsatz von Entwicklungsprozessen. Ein Entwicklungsprozess ist das Langzeitgedächtnis einer Entwicklungsabteilung oder einer Firma insgesamt.
Alle Teams bringen ihre Erfahrung ein.  Hierbei werden z. B. folgende Fragen gestellt und beantwortet (man beachte die Parallelen zu einem Retro-Meeting im Scrum):

  • Wie genau ist das letzte Projekt durchgeführt worden?
  • Was lief gut und was lief nicht gut?
  • Wie kann man das Setting des letzten Projektes verbessern?

Schon der Begriff „Prozess“ beendet spontan das Interesse vieler Entwickler, weil er an Dinge wie Bürokratie, Zentralismus und Behäbigkeit denken lässt, was insgesamt das Gegenteil von agil darstellt.

Das alles trifft natürlich voll zu – wenn man es falsch anstellt.

Es gibt in jeder Organisation Leute, die ihren Mitarbeitern mit Vorschriften und Regeln jeden Raum für Kreativität und Eigeninitiative nehmen – und damit eine wichtige Arbeitsmotivation. Diesen Weg sollte man vermeiden und stattdessen Raum für Kreativität an der richtigen Stelle einräumen.
Anstelle von „Prozess“ kann man auch „Template“ verwenden, was dasselbe meint aber – besonders in der Entwicklung – einen besseren Ruf genießt.

Kreativität für Problemlösungen einsetzen

 In Softwareprojekten sollte sich Kreativität auf die Lösung von fachlichen / technischen Problemen fokussieren, nicht auf die Ausgestaltung des Build-Prozesses oder die Wahl des Chat-Tools.

Eine Prozessdefinition stellt deshalb keine Gängelung des Teams dar – im Gegenteil: Das Team kann sofort mit der Entwicklung beginnen, ohne sich über das Projekt-Setup Gedanken zu machen. Und es beginnt seine Arbeit mit dem bisher erfolgreichsten Projekt-Setup.

Agiles Mindset und Disziplin: Die Prozessdefinition in 2 Schritten

Der Entwicklungsprozess muss möglichst schlank sein und die Idee hinter dem Prozess muss den allgemein verständlichen Regeln und Erfahrungswerten entsprechen. Zunächst wird eine sog. Prozessdefinition erstellt. Hierin wird festgehalten, wie ein Softwareprojekt strukturiert ist, welche Vorgaben es gibt – alle wichtigen Eckdaten werden zumindest stichpunktartig notiert.

Genau an dieser Stelle bewährt sich ein agiles Mindset: Man verhindert damit, dass sich diese Prozessbeschreibung zu einem Bürokratie- und Regelmonster entwickelt, das unter seiner eigenen Last zusammenbricht und jedem Mitglied des Teams die Freude an der Arbeit nimmt. Das bedarf allerdings einiger Disziplin – ein weiterer, zu Unrecht aus der Mode gekommener Begriff.

Der Entwicklungsprozess wird anhand der folgenden 2 Schritte definiert:

  1. Aufschreiben der wichtigsten Punkte (Prozessdokumentation):- eher in Form eines Kodex (nicht zu verwechseln mit einem „Code of Conduct“) und nicht als starre Verhaltensregel
  2. Prozessoptimierung: Erst jetzt kann man auf eine Stelle im Prozess zeigen und Änderungs- bzw. Optimierungsvorschläge machen. Jim Collins bezeichnet diese Art des Vorgehens in seinem Buch „Good to Great“ als Flywheel-Effekt.

Wenn man nun weiß, wie ein Projekt aufgesetzt wird, wie die Infrastruktur aussieht, die CI / CD Pipelines aufgesetzt werden, usw., hat man eine definierte Qualität und jedes Team-Mitglied, das aus anderen Projekten hinzukommt, kann sich problemlos zurechtfinden.

Der Verbesserungsprozess

Der kontinuierliche Verbesserungsprozess kann erst starten, wenn der Entwicklungsprozess definiert ist.

Hierbei ist es wichtig, sich immer nur auf eine zu ändernde Sache in einem Bereich zu konzentrieren:

Wenn man eine neue Fähigkeit erlernt und feststellt, dass etwas nicht so gut läuft, ändert man genau eine Sache und schaut, wie sich diese Änderung auf das Gesamtergebnis auswirkt. Wenn man zwei, drei oder fünf Dinge gleichzeitig ändert, kann man nicht mehr identifizieren, welche Änderungen für die Verbesserung verantwortlich ist. Daher wird immer nur ein Parameter verändert.

Besser gesagt nur ein Parameter in einem Kapitel oder Abschnitt des Entwicklungsprozesses.

Änderungen im Buildprozess haben z.B. keine Auswirkungen auf die Projektdokumentation, daher können in beiden Bereichen parallel Änderungen vorgenommen werden.

Wer darf was wann ändern?

 Jedes Team und jede Person kann beliebige Änderungen vornehmen und schauen, ob der Prozess damit besser läuft.
Allerdings müssen die geplanten Änderungen innerhalb des eigenen Teams abgestimmt werden, damit es nicht zu parallelen Änderungen an ähnlichen Themengebieten kommt.

Weiterhin muss definiert werden, welche Verbesserung man sich von den Änderungen erwartet, so eine Art „Acceptance Criteria“ für die Optimierung.

Die Übernahme von Änderungen in den Prozess

Hatte die Änderung positive Auswirkungen, wird entschieden, ob diese Änderung in den Prozess übernommen wird. Ergab sich keine Verbesserung oder gar eine Verschlechterung, so wird die Änderung zurückgenommen.

Gibt es mehre Projekte gleichzeitig, muss man bei der Übernahme der Verbesserung darauf achten, dass es nicht zu Seiteneffekten kommt: Eine Änderung kann sich in einem Projekt bewährt haben. Zusammen mit einer Änderung aus einem anderen Projekt kann dieser Effekt allerdings verpuffen – hier empfiehlt sich die Vorgehensweise wie beim Mergen unterschiedlicher Sourcecodes.

Kontinuierliche Verbesserung ist wertvoll und richtig. Sie trägt zu der effizienteren Durchführung von Projekten und zur Einhaltung von Qualitätsstandards bei. Trotzdem darf nie zum Selbstzweck werden und nie dafür benutzt werden Kreativität und Eigeninitiative mit der „Regelkeule“ zu erschlagen. Deshalb ist innerhalb des Systems des Continuous Improvement ein agiles Mindset unabdingbar.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s