dot.coaching erklärt -  Die Krux mit der technischen Exzellenz

Tobias Ellenberger
28. April 2020

Damit eine agile Transformation gelingen kann, braucht es neben geeigneten Methoden, positiven Rahmenbedingungen und fähigen Menschen vor allem eines: eine solide Basis. Warum technische Exzellenz eine fundamentale, wenn nicht gar essenzielle Voraussetzung ist, und wie diese erreicht werden kann, beschreibt dieser Beitrag.

Meine These ist ziemlich einfach

«Wenn du das, was du machst, nicht exzellent machst, dann bringt es nichts, wenn du versuchst, es schneller zu machen».

Ich weiss, agil heisst nicht schneller. Ich weiss, durch Transparenz, Inspektion und Adaption (wie im Scrum Guide beschrieben) und möglicherweise einen kontinuierlichen, iterativen Ansatz ist es langfristig möglich, dieses Ziel zu erreichen. Langfristig.

Es gibt Situationen, da kann man leider nichts schönreden. Vielleicht habt ihr Ansätze von methodischen Konzepten, die in sich gar nicht schlecht sind. Möglicherweise gibt es Prozessbilder, die auch durchaus gepflegt werden. Vielleicht gibt es ein Vorgehensmodell für Projekte und entsprechende Schulungen. Möglicherweise gibt es eine breite Palette von Weiterbildungsangeboten für die Mitarbeitenden. Alles gut, könnte man meinen. Das Problem, meiner Meinung nach, liegt aber im Detail. Wenn diese einzelnen Lösungsansätze fragmentiert über eine ganze Organisation verteilt sind. Wenn überall lokal optimiert wird. Wenn weder ein übergreifendes Konzept noch irgendeine Form von Governance vorhanden sind. Dann können diese Lösungsansätze ihre Wirkung nicht entfalten und blockieren sich mitunter sogar gegenseitig. 

Das wirkt sich selbstverständlich auf die methodische und auch auf die technische Exzellenz aus. Wenn es kein übergreifendes Konzept gibt, dann bewirken auch die grössten Cracks auf Dauer keine Wirkung, weil sie stets lokal arbeiten. Lokal optimieren. Selbst wenn alle Mitarbeitenden in ihrem Themengebiet Cracks wären: So lange diese Themen nicht alle auf ein gemeinsames Ziel hinarbeiten, erzeugt das eher Chaos als Qualität.

Wenn also eher Chaos statt Qualität und Stringenz vorherrschen, dann fehlt meiner Meinung nach ein wichtiges Element, wenn nicht gar DAS Fundament für eine agile Transformation: methodische und technische Exzellenz. 

Überlegungen zur technischen Exzellenz

Technische Exzellenz bildet die Basis aller erfolgreichen Vorhaben. Wer schon mal ein Messer selbst geschliffen und sein Resultat mit dem Resultat eines Profis verglichen hat, weiss genau was ich meine. Es gibt immer verschiedene Wege, wie man etwas tun kann. Das nennt sich übrigens Effektivität, dazu mal ein anderer Beitrag. Es gibt aber eindeutig Wege und vor allem Resultate, bei denen sofort erkennbar ist, dass da Profis am Werk waren. Das wäre dann Effizienz.

«Geiler Scheiss» ist mein Lieblingszitat (von mir selbst) in einem solchen Fall. Rausgerutscht ist es mir, als ich die Demo eines Suchvorgangs in einer Webapplikation auf einen umfassenden Datensatz gesehen habe. Die Daten wurden nahezu in real Time aktualisiert. Der Zugriff auf das Bestandssystem über die Cloud war sogar so schnell, dass in der Webanwendung künstliche Verzögerungen eingebaut werden mussten, damit das Auge aufgrund der hohen Refresh-Rate nicht den Eindruck bekam, dass eine Störung vorliegen würde.

Technische Exzellenz kann, gemäss LeSS, in folgende Dimensionen unterteilt werden:

Es fällt sicherlich auf, dass die Disziplin Testing enorm stark vertreten ist. Man könnte interpretieren, dass technische Exzellenz das Ziel hat, nachhaltig hohe Qualität zu erreichen und sicherzustellen. Und das ist definitiv ein Ziel hinter dem Buzz Word «technical excellence».

Ein zweiter Schwerpunkt liegt im Bereich der Kontinuität. Wer in der Lage ist, kontinuierlich neue oder veränderte Funktionalität in das produktive System zu integrieren und damit gleichzeitig auch kontinuierlich neuen Wert erzeugt, hat eindeutig gute Karten im Rennen um eine hohe Kundenzentrierung. Time to market nennt sich das dann mitunter. Ein weiteres Ziel der technischen Exzellenz. 

Ein anderes, grosses Themenfeld liegt in den Bereichen «Specification by Example» und «Architecture & Design». Hier tummeln sich neben den offensichtlichen Disziplinen vor allem die Themen Requirements Engineering und wiederum Testing. Persönlich sehe ich noch Optimierungspotential im Bereich der nachhaltigen Dokumentation und damit der Unterscheidung zwischen Projekt- und Produkt-Dokumentation. Aber grundsätzlich wird klar, wie wichtig gute Anforderungen sind. Nahezu das gesamte Konstrukt der technischen Exzellenz hat seine Wurzeln in guten Anforderungen.

Die Korrektur von Fehlern in Anforderungen ist durchschnittlich Faktor 90 günstiger, wie die Korrektur von Fehlern in Produkten. 
SQS Analyse im Jahr 2007

Nun kann, ja soll vielleicht sogar, jede Organisation ihre eigene Sicht auf die Dimensionen der technischen Exzellenz haben. Je nach Branche, Produkt oder Organisation können sich diese Dimensionen völlig anders gestalten. Was aber klar sein sollte – und oft leider nicht ist – ist, dass hinter jeder Dimension der technischen Exzellenz ein methodisches Fundament steht. Technische Exzellenz mag da und dort evolutionär entstehen. Stimmt, aber nur wenn absolute Top Cracks zusammenarbeiten. Sobald das nicht der Fall ist und vielleicht sogar noch externe Mitarbeitende eigene Ideen oder jene ihrer Organisation in das System eingiessen, entsteht eher Chaos.

Ob implizit oder explizit. Technische Exzellenz bedingt ein stabiles methodisches Fundament.

Das methodische Fundament als Basis

Nun habe ich also definiert, dass technische Exzellenz die Basis erfolgreicher Vorhaben bildet und deshalb im wahrsten Sinne des Wortes essenziell ist. Doch wie erwähnt, gibt es unterschiedliche Sichten auf die jeweiligen Dimensionen. Relevant ist, dass technische Exzellenz nur auf der Basis eines gemeinsamen methodischen Frameworks entstehen kann.

Folgende Risiken existieren, wenn das methodische Framework nicht übergreifend gepflegt wird:

  • Redundanz durch mehrfach gepflegte Methoden
  • Unsicherheit durch freie Wahl der Methoden
  • Unklarheit durch nicht definierte Hoheiten in grundlegenden Elementen wie Business Data Modelling oder einem Glossar

Es reicht allerdings nicht, bloss das Business Data Modell zu pflegen. Gerade wenn man «Specification by Example» und gleichzeitig «Test Automation» pflegen möchte, kommt eine Organisation nicht umhin, die entsprechenden Methoden - wie die diversen Teststufen, das Schreiben von Akzeptanzkriterien (zum Beispiel nach dem Konzept aus Acceptance test-driven Development) - sauber zu definieren. Ohne Klarheit werden die beiden Dimensionen nicht ineinandergreifen und somit eher Waste erzeugen.

Die gleiche Herausforderung stellt sich beim Thema «Continuous Delivery» und «Continuous Integration». Wenn ich nicht in der Lage bin, meine Vorhaben in kleinere Einheiten zu schneiden, sodass diese eigenständig Wert erzeugen, durchgängig sind und gleichzeitig nicht nur Bestehendes erweitern, sondern auch selbst erweitert werden können, ja dann profitiere ich nicht wirklich von dem ganzen Apparat, den ich für diese zwei Dimensionen bereitstellen muss.

Wir sehen also sehr schnell, dass es ein übergreifendes Konzept ein methodisches Fundament braucht. Auch hier hilft lokale Optimierung eben nur lokal.

Die Frage ist nun, wie kann ich eine Organisation und deren Mitarbeitende auf das notwendige Niveau bringen und das notwendige Rüstzeug vermitteln?

Lösungsansätze für deine Organisation

Eines ist sicher: Es ist nicht alleine damit getan, die Mitarbeitenden in diverse Schulungen zu schicken. Schon gar nicht reichen die aktuell gehypten agilen Schulungen, da diese nahezu immer auf einer minimalen Basis, einem Grundverständnis über Themen wie beispielsweise Lean Production, Team Dynamiken oder Systemtheorie aufbauen. Das sagen sie dir nicht, weil sonst potenzielle Kunden abgeschreckt würden, aber es ist so. Schulungen alleine, zumal im klassischen Frontalunterricht, reichen nicht.

Die Basis einer nachhaltigen Lernreise bildet die saubere Analyse der vorhandenen Fähigkeiten. Ein Framework wie SFIA kann helfen, eine sehr übergreifende Sicht auf die vorhandenen Skills zu erfassen. Es empfiehlt sich aber, die methodischen Domänen einzeln und vertieft zu analysieren. Hierbei ergibt es Sinn, die Skills nicht nach irgendeinem generischen Lehrbuch zu ermitteln, sondern spezifisch nach dem eigenen methodischen Framework. Wie ein solches methodisches Framework erarbeitet werden kann, diskutieren wir in einem weiteren Beitrag. Im Weiteren gehen wir nun davon aus, dass solch ein methodisches Framework vorhanden ist und gelebt wird.

Ist diese Basis, also die bereits vorhandenen Fähigkeiten, ermittelt, kann für die Organisation, das Team und das Individuum eine geeignete Lernreise entwickelt werden. Unsere Learning & Development Experten arbeiten minimal mit einem dreistufigen Modell, s.g. Blended-Learning-Designs. 

In einer PRE-Phase werden auf der Basis der Differenz zwischen ermittelten Skills und den Vorgaben des methodischen Frameworks die Wissenselemente definiert, die als Basiswissen gelten. Da in der Regel eine mehr oder weniger grosse Heterogenität bei den Skills und beim Vorwissen der Mitarbeitenden vorzufinden ist, bietet es sich an, Basiswissen in Form von digitalen Lernhäppchen, s.g. Learning Nuggets, zu vermitteln. Diese können die Mitarbeitenden individuell, je nach Bedarf und zeit- und ortsunabhängig bearbeiten. (Solche Learning Nuggets können, wenn intelligent definiert, als Resultat Elemente des bestehenden methodischen Frameworks verbessern oder dieses sogar erweitern.) 

In der Präsenz-Phase liegt der Fokus auf der Vertiefung des Basiswissens, dem Transfer in konkrete Praxissituationen sowie dem intensiven Austausch zwischen Teilnehmenden untereinander wie auch zwischen Teilnehmenden und Trainern. Anhand typischer Anwendungsfälle (zum Beispiel aktuelle Vision in Iterationen schneiden, neue Architekturrichtlinien umsetzen, Überarbeitung der Prozesse) werden die methodischen Grundsätze gemeinsam eingesetzt. Auch hier gilt die Prämisse, dass während der Lernreise keine Luftschlösser, sondern durch das Lernen der Mitarbeitenden konkret Werte in laufenden Vorhaben erzeugt werden. Je nach Thema lässt sich diese Phase mit marktrelevanten Zertifikaten bestätigen. Beispielsweise kann sich ein Team, das gemeinsam die Aufgaben und Herausforderungen eines PO erlernt hat, diesen Teil der Lernreise mit einem entsprechenden Scrum Product Owner Zertifikat bestätigen lassen.

Die dritte, die POST-Phase, ist jene, die viele Organisationen sträflich ignorieren oder nur sehr kurzfristig leben. Die Mitarbeitenden haben nun also auf ihrer individuellen Lernreise persönliche Wissenslücken füllen und das Erlernte gemeinsam mit dem Team in der Praxis erproben können. Was nun folgt ist das kontinuierliche besser werden hin zur gewünschten Exzellenz. Wichtig ist dabei, dass die Lernreise eben nicht beendet ist, sondern kontinuierlich weiter geht. Folglich ergibt es Sinn, die Kompetenzentwicklung weiter aktiv mit transferförderlichen Elementen (z. B. Team- oder individuellem Coaching, regelmässige Reflexion, teamübergreifender Austausch, weiterführenden Learning Nuggets oder Workshops) zu gestalten sowie Fortschritte sichtbar zu machen.

Wie weiter?

Möchtest du die Themen Lerndesign, Lernreise, kontinuierliches Lernen oder gar lernende Organisation mit uns besprechen, oder weitere Informationen zu den Themen technische Exzellenz, methodische Kompetenz erhalten oder hast du spezifische Fragen zu Methoden, dann melde dich bei unseren Experten. 

Wir freuen uns über deine Kontaktanfrage!

dot kontaktieren

Keine Kommentare bis jetzt

Lass uns wissen, was du darüber denkst.

Vielleicht gefallen dir auch

diese Artikel Reinventing Leadership

Newsletter Anmeldung