Martin Künkele - Agile Coach

Agil robuster durch die Krise. Das Coaching geht auch darauf ein, wie mit dem agilen Vorgehen begonnen werden kann und wie es dann weitergeht. Das Coaching richtet sich an Führungskräfte und Mitarbeiter.

Coaching für die Organisation

Coaching für die Organisation

Was kann ich als agile Coach für die Organisation leisten?

Warum ist eine agile Vorgehensweise besser als nach Wasserfall? Was muss das Management schaffen, damit die Teams erfolgreich sein können ... und damit das gesamte Vorhaben? Welche Management-Skills sind zielführend? Was sind die größten Hürden?


Coaching für die Organisation

Agile Coaching ist auch Team Coaching

Agile Coaching ist auch Team Coaching

Was kann ich als agile Coach für lernende Teams leisten?

Wie kann aus den Ressourcen jedes Team-Mitglieds ein schlagkräftiges Team entstehen? Was sind die Ressourcen eines Teams?
Wann funktioniert ein Team richtig gut? Wie entsteht eine Team-Identität? Welche Phasen durchläuft ein Team? Wie schaffen wir es uns zu verbessern und Arbeit noch als lustvoll zu empfinden?

Das lernende Team

Kunde, Vision, Werte, Wissen ...

Kunde, Vision, Werte, Wissen ...

Was kann ich als agile Coach für den Start zu Sprinten leisten?

Wie können wir den Kunden zufriedenstellen?
Was ist unsere Vision? Welche Werte sind für uns wichtig? Wie verwalten wir unser Wissen?

Wann können wir endlich loslegen? Was benötigen wir noch? Passt Scrum oder ist Kanban besser? Wie schaffen wir die Skalierung bei unserer großen Anzahl an Teams?

Starten zu Sprinten

Kontaktieren Sie uns

Kontaktformular

Name (Muss-Feld)

Email (Muss-Feld)

Betreff

Nachricht









Einzelhandelskonzern
Bei einem großen Einzelhandelskonzern war ich beauftragt, zusammen mit einem weiteren Scrum Master den Scrum-Prozess einzuführen. Die Migration nach SAP sollte innerhalb acht Monate gelingen. Um es gleich vorweg zu nehmen: wir wurden früher fertig! In der Software-Entwicklung ein einmaliger Vorfall, der beweist, dass Scrum bestens geeignet ist, um ein SW-Entwicklungsvorhaben effizient durchzuführen.
Begonnen hatten wir mit ca. zwanzig SAP-Spezialisten, für die Scrum - überhaupt das agile Vorgehen - neu war. Aus diesem Pool von hoch-karätigen Software-Entwicklern hatten wir drei Scrum Teams gebildet, wovon ich zwei Teams führte als Scrum Master.
Mit den beiden Teams erlebte ich alles, was Team-Entwicklung ausmacht:
  • die Phasen: Forming, Stormin, Norming, Performing und sogar Adjourning, weil am Ende eines der Teams aufgelöst wurde.
  • die Überwindung einiger der fünf Dysfunktionen eines Teams, wie sie von Patrick Lencioni beschrieben werden.
Energieversorgungsunternehmen
Bei einem Energieversorgungsunternehmen arbeitete ich als Scrum Master und agile Coach. Ich arbeitete mit noch zwei weiteren Scrum Mastern zusammen. Wir setzten Scrum und Kanban ein bei der Führung mehrerer Teams. Kanban war bei einem Team deshalb sinnvoll, weil seine Aufgabe im Vergleich zu den anderen Teams anders gelagert war. Es produzierte einen kontinuierlichen Strom an Artefakten, der Input war für die anderen Teams war. Diese arbeiteten mit Scrum in Sprints von drei-wöchiger Dauer. Die Kommunikation und die Abstimmung zwischen den Teams fand während sog. PO-Meetings statt, die zweimal in der Woche stattfanden.

Uns Scrum Masters oblag komplett die Steuerung des Scrum Prozesses. Wir trafen uns regelmäßig, um neue Ideen zu entwickeln und um Vorschläge auszuarbeiten für die Umsetzung mit den Teams, mit den POs und der Projektleitung. Das war eine sehr fruchtbare Zusammenarbeit.
Finanzwirtschaft
Bei einer Bank arbeitete ich als Projekt-Manager und Scrum Master parallel. Ich konnte beide Vorgehensweisen direkt erleben und vergleichen.

Bei einer weiteren Bank habe ich Scrum eingeführt gegen sehr große Widerstände. Gemeinsam mit 'meinem' Team waren wir erfolgreich bei zwei zeitlich nacheinander erfolgten Release-Einführungen. Das war der Start der Bank in die agile Welt, weil wir beweisen konnten, dass es mit Scrum schneller und besser planbar ging.
Öffentlicher Arbeitgeber
Hier lernte ich alles, was benötigt wird für Continuous Integration (CI): Versionskontrolle, agiles Testen, automatische Tests, Unittest, statische Analyse und Bewertung der technischen Qualität von Sourcecode, Nightly Builds, Deployment Pipeline, Refactoring, automatisches Deployment.

Mit sechzig Personen war das Software-Entwicklungsteam sehr groß. Ich hatte vorgeschlagen, Scrum einzuführen.
Softwarehaus
Hier lernte ich XP (eXtreme Programming) kennen. Das Team bestand aus zehn Personen, also fünf Paarungen (Pairs), weil wir mit Pairing arbeiteten, getreu dem Vorschlag von Kent Beck, dem Erfinder von XP. Einer arbeitete mit Bildschirm und Tastatur, der andere verfolgte die Arbeit, machte Notizen und korrigierte Fehler, die er beobachtete. Nach zwei Stunden wurden die Rollen getauscht. Von Zeit zu Zeit wurden die nächsten Schritte geplant und besprochen.

Es gab immer wieder Anpassungswünsche von der Projektleiterin und vom Team Lead, d.h. es musste dann ein Refactoring durchgeführt werden. Teilweise wurde dem Test-First-Ansatz gefolgt, d.h. es wurden die Test vor dem eigentlichen Code implementiert.

Das Software-Entwicklungsvorhaben hatte zum Ziel, eine veraltete Host-Anwendung (legacy Anwendung) abzulösen. Das Vorhaben wurde aufgeteilt in die Implementierung zehn verschiedener Funktionsblöcke. Zunächst arbeitete jedes Paar einem Funktionsblock. Nach Abschluss dieser ersten Phase wurde die Pairs neu zusammengesetzt. Auch mussten z.T. Team-Mitglieder durch neue Personen ersetzt werden aus unterschiedlichen Gründen. Dadurch, dass im neu gebildeten Pair noch ein früheres Mitglied vorhanden war, konnte das neue Mitglied sehr schnell eingearbeitet werden. Pairing, unter diesem Aspekt betrachtet, bedeutet eine wesentliche Einsparung. Da es ab einer bestimmten Größe des Entwicklungsteams immer zu einer Fluktuation bei den Mitarbeitern kommt, halte ich die These aufrecht, das Pairing zu einer Stabilisierung der Qualität beiträgt ohne Erhöhung des Aufwandes.
Telekommunikationsunternehmen
Ein sehr herausforderndes Projekt, weil die vier Software-Entwicklungsteams wirklich über ganz Europa verteilt waren, von St. Petersburg bis Valencia und Sofia bis Bristol. Die Integration der Team-Mitglieder zu einem Team stellte sich als sehr schwierig heraus.

Die ‚team mates‘ hatten den innigen Wunsch, sich mehr als alle vier Wochen in Darmstadt treffen zu können. Für diesen Vorschlag kämpfte ich beim Management und bekam Unterstützung. Der ‚team spirit‘ war während des Treffens und auch noch danach ein viel besserer. Der Mensch ist ein soziales Wesen und benötigt die Begegnung. Weil dann die Möglichkeit besteht, sich wirklich persönlich besser kennenzulernen.



Agil

Agil ist in aller Munde. Was ist das, agil? Woher kommt es? Was steckt hinter Agilität? Was nicht?

Agilität geht zurück bis in die 70er Jahre des letzten Jahrhunderts. Dabei ging es um Untersuchungen in den USA, herauszufinden was exzellente Unternehmen ausmacht: schnell auf Marktveränderungen reagieren zu können. Die Unternehmen agierten flexibel, aktiv und anpassungsfähig, Eigenschaften, die im weitesten Sinne auch mit agil umschrieben werden können.

In der Software-Entwicklung bahnte sich in den 90er Jahren eine dramatische Entwicklung an, dadurch, dass mit der Erfindung des PCs Software im großen Stil nachgefragt wurde. Es gab für die Erstellung von Software noch kein Vorgehensmodell, wie effizient entwickelt werden kann. Wo wird etwas gebaut, vergleichbar mit dem ‚Bau‘ von Software? In der Bauwirtschaft und dort gibt es ein Vorgehensmodell, das Wasserfallmodell. Also wurde dies adaptiert, aber Software zu erstellen ist etwas anderes als einen Wolkenkratzer oder eine Brücke zu bauen. Es leuchtet ein, dass nichts mehr an den Plänen geändert werden darf, wenn ein Gebäude einmal im Bau ist.
Das Phasenmodell hat aber lange Zeit die Software-Entwicklung beeinflusst, zu Beginn so dramatisch, dass zwischen den Phasen keine Rückkopplung erlaubt war, also damit auch keine Reaktion auf Marktveränderungen, die während der z.T. langen Entwicklungsphase entstanden. Überhaupt waren die Zyklen für die Entwicklung von Software viel zu lang.

Namhafte Verteter aus dem Software-Entwicklungsbereich fanden sich 2001 zusammen um über das Dilemma der eigenen Branche zu sprechen. Das war die Geburtsstunde des agile Manifests.

Allerdings hatten sich in den 90er Jahren bereits Vertreter, wie Kent Beck, Ken Schwaber und Jeff Sutherland, in den Software-Entwicklungsindustrie Gedanken darüber gemacht, wie es besser gehen könnte.

Ken Schwaber und Jeff Sutherland hatten bereits Scrum entwickelt, das jetzt großen Anklang fand und heute das am weitest verbreitete Vorgehen ist.

Scrum ist ein Framework, das einen Rahmen beschreibt für das agile Vorgehen der Organisation. Das Ziel ist, die Organisation agiler zu machen im Sinne der Werte des agilen Manifests. Das Scrum Guide in seiner Version vom November 2017 weitet Agilität auf zusätzliche Bereiche über die Software-Entwicklung hinaus aus: Hardware, Embedded Software, Netzwerke von interagierenden Funktionen und autonome Fahrzeuge.
Scrum wird aber auch in Schulen, Regierungs- und Marketingprojekten genutzt, zur Verwaltung von Organisationen und der Entwicklung von fast allem, was wir in unserem täglichen Leben als Einzelpersonen und als Gesellschaften verwenden. Scrum bewährt sich täglich im Umgang mit Komplexität, da Technologie-, Markt- und Umweltkomplexitäten und deren Interaktionen rapide zugenommen haben.

Kent Beck hatte Extreme Programming entwickelt, mit ganz neuen Ideen, wie z.B. Pair Programming und Test-First-Ansatz, Vorgehen bei der Entwicklung, die das Erreichen eines sehr hohen Qualitätsstandards zum Ziel haben.

Etwas später kam dann Kanban, entwickelt von David J. Anderson. Ein Wesenselement bei Kanban ist Kaizen, ins Deutsche übersetzt ‚kontinuierliche Verbesserung‘. David beschreibt, wie er Kanban einsetzte, damit die Veränderung in der Organisation möglichst ohne allzu große Widerstände vonstatten ging.

Kontinuierliche Verbesserung ist auch bei den anderen agilen Beschreibungen zu finden. Sich darauf zu fokussieren ist oft eine Veränderung, d.h. die Einführung einer agilen Vorgehensweise in einer Organisation, einem Unternehmen, ist oft eine grundlegender ‚Change‘. Diesen so verträglich und akzeptabel wie möglich zu gestalten ist die Aufgabe des agile Coach.