Bei unserem letzten Treffen des Agile Monday Rhein-Neckar in Mannheim haben wir uns erneut mit IT-Kanban auseinandergesetzt: Die Alternative zu Scrum weckt immer wieder Interesse, Kunden bitten mich häufig sowohl zu IT-Kanban als auch Scrum zu beraten, um eine Wahl treffen zu können, für den im Firmenkontext am Besten geeigneten Weg zu mehr Agilität.
Doch was brauche ich nun, um solch eine Entscheidung treffen zu können?
Sicherlich etliche Fakten, die dahinterliegende Theorie und einige Modelle, Prinzipien und Praktiken. Dann etwas, dass mir hilft, die Konsequenzen meiner Entscheidung abzusehen. Doch halt – da fehlt noch etwas Wichtiges! Wie sieht es mit Erfahrung aus?
Wissen ist nicht Erfahrung, Kennen nicht Können.
Wenn wir etwas am eigenen Leib erfahren, wandelt sich theoretisches Wissen in etwas Erspürbares, Konkretes. Man bekommt ein Gespür für das Thema.
Simulationen helfen, unser Kennen zum Können zu verwandeln. Eine dieser Simulationen, die wir beim Agile Monday erlebt haben, ist das Kanban Pizza Game von Agile42.
In gut eineinhalb Stunden findet unser Team von Pizzabäckern vom intuitiven Weg, Pizza zu produzieren zu einem effizienteren Prozess – mit Spaß und durch gute Zusammenarbeit. Wollen wir das nicht auch im Berufsleben? Das Team hat sich deutlich gesteigert im erwirtschafteten Gewinn, auch durch Einsparung von Verschwendung, neue Produkte ins Portfolio aufgenommen und an kontinuierlicher Verbesserung gearbeitet.
Sie möchten das Kanban Pizza Game gerne auch ausprobieren? Den genauen Ablauf dieser Simulation können Sie hier nachlesen.
Uns hat es beim Agile Monday viel Spaß gemacht, so IT-Kanban zu erleben.
Da die Simulation völlig technologiefrei ist, eignet sie sich übrigens auch für alle anderen Teams, die ihre Teamarbeit mit IT-Kanban verbessern möchten. Längst sind agile Methoden ja außerhalb der Softwareindustrie im Einsatz.
Wann backt Ihr Vertriebsteam die erste Pizza Hawaii?
Agiles Management ist ein häufig übersehener Teil agilen Vorgehens. Es gibt viele verfügbaren Informationen über agile Softwareentwicklung, agiles Testen und agiles Projektmanagement, aber wenig konkrete Praktiken für Entwicklungs- und Teamleiter. Unabhängig davon müssen auf dem Weg zum agilen Unternehmen aber nicht nur Entwickler, Tester und Projektmanager neue Praktiken lernen. Auch Entwicklungs- und Teamleiter müssen eine solche neue Herangehensweise zur Führung und Steuerung agiler Organisationen lernen.
Mehrere Studien identifizieren, dass das traditionelle Management das grösste Hindernis bei der Einführung agiler Softwareentwicklung ist. Entwicklungsleiter und Teamleader dürfen also neu erfahren, was ihre Rolle in der agilen Organisation ist.
Jürgen Appelo hat sich seit einigen Jahren mit genau diesem Thema in seinem bekannten Blog auseinandergesetzt, im Buch „Management 3.0“ sowie den gleichlautenden Kursen seine Erkenntnisse aus seiner eigenen Zeit als Manager einer großen agilen Firma in den Niederlanden veröffentlicht.
Zweimal hatte ich im vergangenen Jahr die Gelegenheit, Jurgen in seinen Kursen zu besuchen und bin zu der Überzeugung gekommen, dass die Denkweisen und Werkzeuge, die er entwickelt hat, vielen Führungskräften im 21. Jahrhundert helfen können, professionell und erfolgreich in komplexen Umgebungen zu arbeiten. Daher biete ich in Kooperation mit Jurgen als offizieller Trainer in diesem und den kommenden Jahren offene Management 3.0 Kurse in Deutschland an.
Wenn auch Sie sich diesem Thema intensiver widmen möchten, finden Sie vieles dazu in Jurgen Appelos Buch und in meinen Kursen.
Wenn Projektteams zusammenfinden, treffen unterschiedliche Meinungen, Erfahrungen und Weltanschauungen aufeinander. Dies betrifft sowohl technische Aspekte als auch Organisatorisches.
Wer dies nicht hinreichend berücksichtigt, läuft Gefahr, schwelende und immer wieder neu auflodernde Konflikte zu erleben und mögliche Synergien unter Kollegen zu verhindern. Eine Teamcharta ermöglicht es, Klarheit zu schaffen, bevor Konflikte entstehen.
Um sich auf gemeinsame Konventionen einigen zu können, bedarf es jedoch auch einer guten Methodik. In einem kurzen Exkurs führe ich Sie in die Theorie der Verhandlungsführung bei gegensätzlichen Positionen ein, damit Sie auch in festgefahrenen Situationen einen Konsens finden. Ein Praxisbeispiel vertieft die Theorie des Vortrags.
Ich freue mich über die Einladung der Scrum User Group Bodensee und auf viele Freunde agiler Methoden. Die Teilnahme ist kostenfrei. Kommen Sie doch auch vorbei! Mehr Infos finden Sie hier.
Wer mit agilen Teams oder Methoden in Kontakt kommt, hört manchmal die Aussage, dass Manager nicht mehr benötigt werden, da sich die Teams selbst organisieren sollen. Das ist ein völlig falsches Verständnis von Selbstorganisation.
Der ScrumMaster hat im Scrum Prozess eine laterale Führungsrolle. Das bedeutet, dass er keine disziplinarische Macht hat, jedoch ganz klar eine Führungsaufgabe hat, was auch durch den Begriff des „Servant Leaders“ deutlich wird.
Wieso braucht man diese Rolle? Sind ein Team von Experten nicht von alleine in der Lage durch Selbstorganisation möglichst efffizient Software zu produzieren? Der Haken an selbstorganisierten Systemen ist, dass ohne vorgegebene Rahmenbedingungen absolut beliebige Systemzustände entstehen. Das bedeutet nicht zwangsläufig Chaos, aber auch nicht, dass ein System alleine zu positiver Entwicklung neigt.
Ein System könnte zum Beispiel zu einer lokalen Optimierung neigen. Sagen wir mal, ein Team ist damit beauftragt, intensive Lasttests auf eine im Internet platzierte Serverfarm durchzuführen. Dieses Team wird sich bemühen, die Arbeitsumstände so optimal wie möglich für ihr Vorhaben zu gestalten und im schlechtesten Fall die Netzwerkbandbreite der gesamten Firma konsumieren.
Und auch Manager setzen Rahmenbedingungen für Teams: Sie müssen Menschen zum Beispiel vor Mobbing schützen, gemeinsame Ressourcen wie Platz im Büro, Netzwerkbandbreite, usw. vor zu hoher Inanpruchnahme durch einzelne Teams und Individuen.
Ein „Rahmengeber“ ist also ein elementarer und wichtiger Bestandteil eines selbstorganisierten Teams. Innerhalb dieser Grenzen kann eine positive und sinnvolle Entwicklung eines Teams stattfinden. Hier ist neben dem ScrumMaster auch das Linienmanagement gefragt, diesen Rahmen zu definieren.
Jurgen Appelo, den ich dieses Jahr persönlich bei seinem Management 3.0 Seminar in Hamburg kennenlernen durfte, hat eine für mich sehr stimmige Aussage getroffen:
Alle Modelle sind falsch, aber manche sind nützlich.
Ein Modell, dass ich für nützlich halte, ist das Shu Ha Ri – Modell, welches aus dem fernöstlichen Kampfsport stammt und von Lyssa Adkins in ihrem Buch „Coaching Agile Teams“ ausführlich dargestellt wird.
Gerade in einer solch komplexen Domäne, wie der Softwareentwicklung, sind solche Abstraktionen hilfreich, um effektiv mit Gruppen arbeiten zu können und bei Teamentwicklungsprozessen bei der Selbstreflektion zu helfen.
Das Shu Ha Ri – Modell besteht aus drei Stufen:
Shu: Jemand, der sich in dieser Ebene bewegt, benötigt klaren Regeln. Ihm fehlt die Erfahrung, Zusammenhänge und Hintergründe bewerten zu können und er folgt den Regeln erstmal in Vertrauen auf seinen Lehrmeister.
Ha: Der Lernende beherrscht die grundlegenden Praktiken und Prinzipien. Jetzt entsteht Raum, das Handeln zu reflektieren und ein tieferes Verständnis zu entwickeln, warum das gelernte funktioniert oder was es im Kern ausmacht. Diese Einsichten ermöglichen es, die Regeln zu brechen und neu zu definieren, ohne die dahinterliegenden Wirkprinzipien zu verletzen.
Ri: Man selbst ist die Regel. In tiefer Kenntnis der Notwendigkeiten und Mechaniken des Handelns können eigene Regeln erstellt werden, die nichts mehr mit den ursprünglichen Regeln zu tun haben und diese in ihrer Wirksamkeit in Bezug auf die eigene Situation deutlich übertrumpfen.
Man kann dieses Modell auf verschiedene Bereiche eines Teams anwenden, wie auch auf die persönliche Entwicklung in Bezug auf ein Thema.
In welchem Bereich Deines Lebens oder Jobs bist Du Shu, wo Ha und wo Ri?