Die aus dem Code Factoring bekannte "Rule of Three" ist nicht nur dort nützlich -- diese Regel ist auch eine gute Faustregel für Prozessveränderungen in Teams und Unternehmen.
Teams stoßen auf Fehler, wenn Prozesse und Abläufe im Unternehmen nicht klar sind oder wenn zum Beispiel zu viele beteiligte Parteien mit Vor-Erwartungen gearbeitet haben.
In der nachfolgenden Retrospektive bekommt das Team mehr Prozessklarheit und vereinbart Maßnahmen zur Optimierung des Prozesses.
In den wenigsten Fällen wird das Team sofort einen vollkommen anderen Lösungsweg wählen. Davor scheuen viele Teams zurück. Die zu erwartende Unruhe im Unternehmen oder im Team versuchen viele zu vermeiden.
Gleichzeitig kann es dazu kommen, dass Teams den Zeitpunkt verpassen, zu dem sie eine grundlegende Veränderung des Prozesses vereinbaren.
Für das Refactoring von Software hat Martin Fowler die "Rule of Three" vorgeschlagen. Diese Regel lässt sich auf Organisationn übertragen:
Rule of three is a code refactoring rule of thumb to decide when a replicated piece of code should be replaced by a new procedure. It states that the code can be copied once, but that when the same code is used three times, it should be extracted into a new procedure.
[zitiert nach Wikipedia] Übertragt man die "Rules auf Three" auf Teams und Organisationen, ergibt sich folgender Ablauf:
Wenn Serienfehler in Euren Prozessen auftreten, zählt einfach die Wiederholungen. Explizieren, Klarheit schaffen: das sind die Maßnahmen beim ersten Auftreten.Ein Vorgehen direkt beim ersten Auftreten vollständig zu verändern, könnte mehr Verwirrung stiften als notwendig. Vielen Beteiligten wird auch noch nicht klar sein, dass die "große" Änderung wirklich notwendig ist.
Wenn sich Fehler dann mehrfach wiederholen, stellt sich die Frage ein, ob nicht eine größere, grundlegendere Veränderung notwendig ist.
Wenn sich ein Phänomen in der Organisation zum dritten Mal ähnlich abspielt, ist es sinnvoll, eine Veränderung der zugrunde liegenden Prozesse herbeizuführen.
Mit dieser Faustregel schafft Ihr es auch, eine gute, nachvollziehbare und für das Team realisierbare Änderungsgeschwindigkeit zu erzeugen.
Natürlich wird es immer mal Ereignisse geben, die sofortige große Änderungen erzwingen. Die Abwägung, welcher Fall vorliegt, wird dem Team sicher in der entsprechenden Retrospektive oder Post-Mortem-Analyse gelingen.
Kommentar schreiben