Heute werde ich die Beobachtungen des Scrum Masters über das erste Lebensjahr des Teams im neuen Rahmen teilen.
Warum haben wir uns für Scrum entschieden? Die Gründe sind für viele Unternehmen alltäglich:
- die nicht so einfache Beziehung zwischen "Geschäft" und "Entwicklung";
- die Notwendigkeit, Lieferungen zu beschleunigen;
- Verständnis, dass es notwendig ist, Prozesse neu aufzubauen.
Der Umzug zu Kick-Off dauerte ungefähr sechs Monate (ab Anfang 2019): Studium, Schulung, Vorbereitung von Materialien und Sammeln der erforderlichen Informationen. Und schließlich haben
wir am 3. Juni 2019 den ersten Sprint gestartet.
Das erste Jahr im neuen Framework ist eine Herausforderung für das Team und den Scrum Master. Es ist notwendig, die Denkweise radikal zu ändern und die Dinge anders zu machen.
Woran sollte sich ein Scrum Master in dieser Zeit erinnern?
Der Scrum Master ist kein Schuh, er muss nicht bequem sein. Es ist notwendig, eine nachhaltige Fähigkeit zu entwickeln, das Team und seine einzelnen Mitglieder mit ungesunden Verhaltensmustern zu spiegeln. Es ist sehr wichtig zu lernen, wie man richtig und rechtzeitig Feedback gibt, auch wenn dadurch sowohl der Scrum Master als auch der Gegner die Komfortzone verlassen.
Denken Sie im Team, nicht im Einzelnen. Sie müssen das Team so betrachten, als wäre es ein lebender Organismus, und sich daran erinnern, dass der gesamte Organismus anfangen kann zu trampeln, wenn „einzelne Organe krank werden“. Um die Analogie fortzusetzen, ist der Scrum Master ein Therapeut. Kein Chirurg, sondern ein Therapeut, daher sind schwierige klinische Fälle für andere Spezialisten.
Scrum toleriert wie LeSS nicht die persönliche Unreife von Teammitgliedern. Wenn das Team nicht weiß, was Scrum ist, noch nie in diesem Framework gearbeitet hat und wenn es bereits in der aktuellen Komposition funktioniert hat, würde ich empfehlen, nicht sofort in LeSS zu flippen.
Es ist wahrscheinlicher, dass die Identifizierung von Freiwilligen für den Anstoß (der normalerweise drei Tage dauert) in einem Team, das zuvor noch nicht an Scrum gearbeitet hat, eine Fälschung ist. Wenn Menschen noch nie in diesem Rahmen gearbeitet haben, verstehen sie kaum wirklich, was es ist, und können wirklich über ihre Bereitschaft sprechen, auf diese Weise zu arbeiten.
Hardy ist nicht alles. Wenn es ein Problem mit der Software gibt, kann selbst ein Entwickler, der in Bezug auf die Härte sehr cool ist, zu einem großen Problem werden.
In sich selbst organisierenden Teams können Menschen mit entwickelter Reflexion, emotionaler Intelligenz und dem Wunsch nach kontinuierlicher Selbstentwicklung, Bewusstseinserweiterung und der Bereitschaft, das Paradigma zu ändern, harmonisch leben und existieren.
Es wäre naiv zu glauben, dass Sie der klügste sind. Es ist sehr wichtig, diese Botschaft jedem Mitglied des Teams zu vermitteln. Das Eindringen in diese einfachste Denkweise bringt eher viele Vor- als Nachteile mit sich: vom gegenseitigen Respekt bis zum „Gefühl der Ellbogen“.
Am schwierigsten ist es, verantwortungsbewusst zu arbeiten. Für die Menschen ist es wichtig zu verstehen, dass es bei "Freiwilligkeit" nicht nur um den Willen und die Bereitschaft geht, in Scrum zu arbeiten. Hier geht es um die Bereitschaft, sich zu entwickeln, über sich selbst zu wachsen, zu lernen, Feedback zu geben und zu empfangen, zu reflektieren und Veränderungen vorzunehmen. Hier geht es um den kontinuierlichen Prozess, nicht nur die Prozesse, sondern auch uns selbst zu verbessern.
Die Leute verstehen oft nicht, warum ein Scrum Master benötigt wird. Und hier kam ich nach vielen verschiedenen Dialogen und Workshops, Diskussionen und Gesprächen zu dem Schluss, dass dieses Missverständnis oft auf mangelnde Bereitschaft zurückzuführen ist, es zu verstehen. Der Scrum Master sollte dies berücksichtigen und weiter daran arbeiten.
Was hat uns Scrum in einem Jahr gegeben?
"Geschäft" und "Entwicklung" wurden untrennbar miteinander verbunden - das Verständnis von "wir" und "sie" hörte auf zu existieren. Geschäftsexperten arbeiten mit Entwicklern in denselben Teams zusammen. Das Verständnis dafür, was ein Unternehmen braucht, liegt nun in den Entwicklungsteams. Infolgedessen haben wir die Liefergeschwindigkeit erheblich verbessert: Jetzt erfolgt die Freigabe einmal pro Sprint. Wir leben derzeit in dreiwöchigen Sprints. Bisher betrug die tatsächliche Freisetzungsrate nicht mehr als einmal alle 1,5 Monate.
Wir haben technische Schulden legalisiert und uns im Sprint Zeit dafür genommen. Wir haben uns auf einen Anteil von 70% gegenüber 30% geeinigt, wobei 30% für die technischen Schulden bereitgestellt wurden.
In einem Jahr konnten wir alle kritischen Kompetenzen in das Team einbeziehen, Anbieter aufgeben und die Entwicklung verinnerlichen. Der Einfluss jedes einzelnen auf die Entwicklungsergebnisse und auf die implementierten Lösungen hat erheblich zugenommen. Das Eintauchen der Entwickler in das Produkt und den Kundenkontext hat erheblich zugenommen. Dementsprechend hat sich die semantische Last „Warum?“ Qualitativ geändert.
Wir haben den Discovery-Prozess gestartet - das Eintauchen in die "Haut des Kunden" wurde erheblich verbessert. Jetzt überprüfen wir alle unsere Ideen, was uns als nützlich erscheint, direkt beim Kunden. Schaffung einer experimentierbereiten Umgebung und einer Kultur der Experimentierbereitschaft.
Implementierte CI / CD.
Wir haben fast die gesamte Funktionalität der WEB-Anwendung mit Autotests abgedeckt, wodurch die Zeit- und Arbeitskosten für die manuelle Regression erheblich reduziert wurden.
Wir haben mit dem Übergang zu einer Microservice-Architektur begonnen, die den Entwicklungsteams mehr Unabhängigkeit verleihen soll.
Wir haben ein System zur Überwachung von Anwendungen und Hardware eingeführt: Jetzt ist es im Online-Modus möglich, den Status des einen und des anderen zu überwachen und manchmal Signale zu empfangen, bevor Anrufe von Kunden eingehen. Wir haben eine Reihe von Dashboards zur Überwachung von Geschäftsindikatoren erstellt, einschließlich KPIs im automatischen Modus.
Während des Jahres haben wir viel erreicht, aber unser Weg geht weiter.
PS: Ich habe bewusst nicht über die Phasen der Scrum-Implementierung geschrieben. Sie können jetzt viel darüber lesen. Bei Interesse kann ich dann einen separaten Artikel schreiben.