Bei der Unterstützung des Aufbaus eines Berliner IT Start-Ups hatten wir den Arbeitsauftrag die agile Arbeitsmethode Scrum zu skalieren. Dieses Fallbeispiel zeigt, welch mächtiges Werkzeug eine zur Verfügungstellung von wertungsfreien Beobachtungen für die Personen in einem System ist.

Schnell stellte sich hier ein Interessenskonflikt zwischen dem Gründer und dem Geschäftsführer des IT Start-Ups heraus. Der Gründer wollte, dass möglichst schnell auf seine Wünsche bei der Implementierung reagiert wird. Scrum empfand er als lästige Methode mit zu vielen Regelterminen und starren Konstrukten (Estimations, Grooming, Dailys, Review …). Änderungen sollten jederzeit bearbeitet und umgesetzt werden können. Gleichzeitig empfand er die Umsetzungsdauer als zu groß. Der Geschäftsführer hingegen wollte möglichst viel Stabilität in den Entwicklungsteams, was Aufgrund der ständigen Anforderungswechsel selten gegeben war. Ein starres beharren auf den vom Geschäftsführer eingeführten Scrummethoden hätte in diesem Konflikt nur zu Frustration auf beiden Seiten geführt. Gleichzeitig ist es nicht möglich den Konflikt von außen als Berater zu lösen. Einzige Möglichkeit besteht darin den Konflikt zu erkennen, auszuhalten und die Parteien an einen Tisch zu bringen. Eine Reflexion der Beobachtungen brachte Verständnis (wenn auch keine Einsicht) auf beiden Seiten. Der Gründer verstand, dass ein gewisses Maß an Regeln zu schnellerer Umsetzung und höherer Qualität führt, Änderungen wurden seitdem nicht mehr während der Umsetzung eingekippt. Gleichzeitig wurden einige Artefakte des Scrums abgeändert um den Bedürfnissen des Gründers zu genügen. Man einigte sich auf die Abschaffung des Review-meetings und Einführen eines Kanbanteams um mit sprintfreier Agilität zu experimentieren und so das Bedürfnis nach mehr Flexibilität zu erfüllen. Unser Beratungsansatz hier bestand darin, die Interessenskonflikte zu erkennen und diesen allen Beteiligten wertungsfrei widerzuspiegel. Die Beschreibung einer Situation durch unbeteiligte Dritte führt dazu, dass sich das System bereits dadurch verändert und von Innen heraus versucht sich selbst zu stabilsieren. Als Resultat wurde der standardisierte  Prozess als zu starr empfunden und durch eine individuelle Scrumumsetzung ersetzt, welche für die Organisation optimal war, gleichzeitig in keinem anderen Unternehmen denkbar ist.