improuv

Wie effektive Führung über Vertrauen besser gelingt

hedi.buchner — Thu, 11 Apr 2019 07:00:00 +0000

Es hat den Anschein, als würde sich 'Vertrauen' mit drei Begriffsgruppen hinreichend trennscharf beschreiben lassen. Das lässt eine psychometrische Studie vermuten, die hoch korrelierende, verhaltensbeschreibende Begriffe über eine Faktorenanalyse prüfte.

Die Untersuchung wollte erhellen, welches Verhalten Vertrauen bewirkt und speziell, mit welchem Führungsverhalten Vertrauen evoziert werden kann. Oder anders: Wie kann ich als Führungskraft erreichen, dass meine Mitarbeiter mir 'trauen'?

Diese zusammengefassten und geprüften drei Begriffsgruppen sind gleichsam auch die Handlungssmaximen für tragfähige Beziehungen ausserhalb von Hierarchien:

positive Beziehungen pflegen
Erfahrung und gute Einschätzungen teilen
Konsistenz im Sagen und Handeln

Wie werde ich vertrauenswürdig?

Wer vertrauenswürdig wirken möchte, sollte also …

positive Beziehungen pflegen
- in Kontakt stehen mit den Problemen und Bedenken anderer
- Zusammenarbeit zwischen anderen stiften
- (ihre) Konflikte mit anderen lösen
- ehrliche Rückmeldung in hilfreicher Form geben
Erfahrung und gute Einschätzungen zeigen
- so dass andere ihren Ideen vertrauen und ihre Meinungen suchen
- ihr Wissen und Erfahrung als ein wesentlicher Beitrag zur Erzielung von Ergebnisse sehen
- Probleme erahnen und schnell reagieren
Authentisch sein: Tun, was man sagt
- als Vorbild handeln
- Mitarbeit wertschätzen und Versprechen halten
- Mehr als das Notwendige beitragen

Vertrauen ist binär.

Es scheint so zu sein, dass Verhaltensausprägungen in diesen drei Begriffsgruppen, wenn sie nur leicht überhalb des Mittels lagen, einen nachhaltig positiven Einfluss auf das wahrgenommene Vertrauen haben. Lagen die Werte nur knapp unterhalb des Mittelwertes, wurde zugeschriebenes Vertrauen vernichtet, also komplett abgesprochen. Das erscheint als binäre Mechanik: ganz oder gar nicht vertrauen — ein 'bisschen trauen' scheint nach diesen Daten nicht möglich.

Vertrauen und Führungseffektivität hängen zusammen.

Das Vertrauensniveau in dieser Untersuchung korreliert statistisch mit der wahrgenommenen Führungseffektivität und hat damit den stärksten Einfluss auf die direkt berichtenden Mitarbeiter und die peers auf gleichem hierarchischem Niveau.

Experimentell geprüft wurde auch die Frage, ob Führungsrollen diese drei Elemente gleichermassen erfüllen müssten, um als vertrauenswürdig wahrgenommen zu werden. Aus den Daten zeigte sich, dass die Pflege positiver Beziehungen den wichtigsten Einfluss hat: ist eine Beziehung beschädigt oder wurde nie etabliert, wird das Geben wie Nehmen von Vertrauen schwierig.

Perfekt sein ist nicht nötig. Dauerhaft besser als der Durchschnitt schon.

Um überdurchschnittlich gut führen zu können müsse man nicht unbedingt perfekt sein, heisst es oft. Für das gerichtete Vertrauen in Führungsrollen hingegen müssen alle drei Elemente deutlich über dem Durchschnitt liegen, kann aus den Daten der Studie geschlossen werden.

Führungskräfte sollen also in der Hierarchie positive Beziehungen aktiv pflegen, ihre Erfahrung und Einschätzungen mit anderen teilen und vorbildlich auch das tun, was sie sagen und von anderen erwarten.

Ganz einfach also und nicht weit weg vom servant leader, jenem damals neuen Typus Führungskraft, den Robert Greenleaf 1970 zum ersten Mal so benannte. Greenleaf verstand “going beyond one’s self-interest”, “über Eigeninteressen hinaus gehen” als zentrale Charakteristik eines dienenden Vorgesetzten, der als 'primus inter pares', als 'Erster unter Gleichen' nicht seine Macht nutzt um Ziele zu erreichen, sondern Mitarbeiter zu überzeugen sucht.

Vertrauen und Verantwortung bedingen einander.

Das passt zu einem Schaubild, das hier ins Deutsche adaptiert ist. Es stammt aus einem lesenswerten Buch, das sich befasst mit dem Zusammenhang von Vertrauen und Verantwortung und kommt zum selben Ergebnis: Führung mit und über wechselseitiges Vertrauen geht einher mit empfundener Verantwortung im Team oder individuell. Der grüne Quadrant agiler Methoden fusioniert diesen sweet spot. Vertrauen und Verantwortung bedingen einander. Was sich anhört wie ein dünner Aphorismus ist tatsächlich, worum agile Methoden drehen.

Der servant leader ist die Rennleitung auf der VUCA-Strecke

Eine dienende Führungskraft ist also eher eine Rennleitung auf der VUCA-Strecke: wir vertrauen Führung, aufrichtig und authentisch das Richtige zu tun und Behinderungen unterwegs auszuräumen. Als vertrauende Mitarbeiter übernehmen wir in einem agilen Umfeld Verantwortung und handeln so gut und richtig, wie es uns möglich ist.

Ja dann: Weitermachen!

Referenzen

Greenleaf, R. K. 1977. Servant leadership: A journey into the nature of legitimate power and greatness. New York: Paulist Press.
Reinke, S. J. 2003. Does the form really matter? Leadership, trust, and acceptance of the performance appraisal process. Review of Public Personnel Administration, 23: 23-37.
Dierendonck, Dirk van. 2011. ‘Servant Leadership: A Review and Synthesis’. Journal of Management 37 (4): 1228–61. https://doi.org/10.1177/0149206310380462.
»Trust/Ownership-Model« adapted from Pixton, Pollyanna, Paul Gibson and Niel Nickolaisen. The Agile Culture - Leading through Trust and Ownership. Addison-Wesley, 2014. p41ff
Zenger, Jack, and Joseph Folkman. 2019. ‘The 3 Elements of Trust’. Harvard Business Review, 5.2.2019. https://hbr.org/2019/02/the-3-elements-of-trust.

Working Out Loud — Des Königs neue Kleider?

hedi.buchner — Tue, 09 Apr 2019 10:45:00 +0000

In einem früheren Blog mit dem clickbait-Titel Was Tigidalisierung mit Asterix und Fischstäbchen zu tun hat: eine lose Serie über Patentrezepte nahmen wir uns eine lose Serie über Wandel und Patentrezepte vor. Mit 'New Work' — eine Auslotung geschah der Einstieg in das glitzernde Feld 'neuer Arbeit'.
Viel blieb leider nicht übrig.

Hier versuchen wir, einen Henkel zu kriegen an 'WOL — working out loud' — ein peer-coaching, das seit mindestens drei Jahren wenigstens in der agilen Szene Wellen schlägt.

Was ist dran an #wol?

Sie kennen vielleicht die kleine Parabel des eitlen Königs, der nicht genug neue, unerhört eindrucksvolle Kleider haben kann um noch viel schöner zu sein als sein Hofstaat. Ein schlauer Schlawiner nutzt seine Geltungssucht und verkauft ihm unsichtbaren Stoff, er schreitet nackend unters Volk. Allein ein Kind benennt, was es sieht »der ist ja nackig!«.

'Working out Loud', WOL könnte eines dieser Kleider sein. Doch vielleicht tut man mit diesem Vergleich auch Unrecht.
Sehen wir uns an, was dahinter steckt.

WOL wurde bekannter durch John Stepper, der ein gleichnamiges Buch geschrieben hat. Die griffige Abkürzung stammt von Bryce Williams, der 2010 so die Gewohnheit bezeichnete, "die Prozesse der eigenen Arbeit transparent zu machen, um die eigene Expertise darzustellen und gleichzeitig Kollegen zur Zusammenarbeit einzuladen."

'Vernetze dich und sag', was du machst!'

Die Botschaft ist in aller Schlichtheit: 'vernetze dich, mache bekannt, was du tust und alles weitere wird sich finden'. Das Buch müsste man nicht eimal kaufen, es steht ohnehin alles auf Steppers Website.

Stepper selbst gibt bei, dass er vorhandene Methoden zu einem peer-coaching zusammenfügt. Der Nutzen sei, dass mit WOL 'wertvolle Kontakte aufgebaut', 'ein Ziel erreicht' oder ein 'Projekt umgesetzt' werden — besser als ohne WOL.

Das Seltsame daran: WOL scheint in größeren Organisationen und Konzernen zu funktionieren. Andere Methoden vielleicht auch — doch WOL scheint so nebenbei und leichtfüssig, dass man sich fragen darf, weshalb man sich Training und Tort mit Scrum und Kanban antut, wenn andere es mit weniger Aufwand und gleichem Ergebnis schaffen.

Wie WOLt man ...?

Der Kern bei WOL ist ein 'circle' aus Menschen, die sich sich wechselseitig helfen und drei Leitfragen stellen:

Was möchte ich erreichen?
Wer sonst hat mit meinem Ziel zu tun?
Und was habe ich diesen Personen anzubieten?

Stakeholder- und Erwartungsmanagement heisst das anderswo.

Und es gibt fünf WOL-Prinzipien:

Beziehungen pflegen (Relationships): Wir lernen im Austausch mit anderen.
Visible Work — Die eigene Arbeit sichtbar machen.
Generosity — Kleinigkeiten großzügig teilen und persönliche Vernetzung starten
Purposeful Discovery — das eigene Ziel kennen
Growth Mindset — wachsen wollen und dabei auch gelegentlich die Komfortzone verlassen

Hübscher ist das in einem Sketchnote dargestellt.

Bei WOL treffen sich vier bis fünf Circle-Teilnehmer zwölf Wochen lang jeweils eine Stunde und folgen einem Leitfaden zum Aufbau eines persönlichen Netzwerkes. Die einfache WOL-Wahrheit: Was kann ich meinem Gegenüber anbieten? Gib’, bevor du nach Gegenleistung fragst, baue persönliche Beziehungen auf zu Menschen, die dir weiterhelfen können. Das wird in weiteren Circle-Treffen gemeinsam gemacht. Kleinigkeiten anstossen, sich ins Gespräch bringen.

Zieht man das 12 Wochen durch, dann sollte man am Ende mehr Kontakte haben als zu Beginn.

Wertvolle Beziehungen aufbauen

Die zu erlernende soziale Kompetenz ist damit, Beziehungen aufzubauen, sie stabiler und wertvoller zu machen.

Bei IBM, DEKRA, DATEV, BMW, Daimler oder Bosch ist WOL in Teilbereichen im Einsatz und wurde bei manchen gar zu einem Bestandteil des HR-Instrumentariums. »Ver-WOLle dich, wenn du hier anfängst.« Verrückt, nicht wahr? Wie kann etwas so Naheliegendes wie das Erlernen proaktiver Sozialkompetenz in konventionell strukturierten Unternehmen wirksam sein — oder: was machten die da alle ohne Sozialkompetenz und bevor die Steppersche Weltformel in der Welt war? Welches Problem löst WOL für wen?

Ein Antwortversuch

WOL ist eine ToDo-Liste um quer über Hierarchie und Fachlichkeit Kontakte aufzubauen, das eigene Silo zu verlassen und auszuschwärmen. Sehen und Gesehen werden. Die Taktung auf 12 Wochen und die Gruppierung mit anderen helfen, neues Verhalten zu festigen. Danach ist alles besser als zuvor, du wirst wahrgenommen, deine Arbeit erfährt Wertschätzung und es geht aufwärts mit dir. Aufwärts in der Hierarchie. Oder seitwärts — irgendwie weiter und anders auf jeden Fall. Bei WOL geht es damit darum, die eigene Karriere zu bedienen.

Was hielt nur all jene, die 12 Wochen in WOL-circle gehen davon ab, das auch ohne Anleitung zu tun?

In einem Interview (Bußmann. 2018) wird Stepper in der Einleitung zitiert als:

Statt sich zu vernetzen, um etwas zu bekommen, ist dabei Großzügigkeit das leitende Prinzip: Man tritt in Vorleistung, indem man zunächst in den Aufbau von persönlichen Beziehungen investiert, und zwar zielgerichtet in solche Kontakte, die einem in einem zweiten Schritt Zugang zu anderen interessanten Menschen, Möglichkeiten oder zu neuem Wissen bieten können.

... Kritik

Das ist Reframing. 'man tritt in Vorleistung' und 'Großzügigkeit als leitendes Prinzip' verschleiert, dass das Kontakte machen und anderen kleine Hinweise geben zum Ziel hat, das eigene Fortkommen zu erleichtern und zu beschleunigen. Am 'System Unternehmen' geschieht nichts, es bleibt, wie es war.

Mit 'Agilität' hat WOL damit ebenso wenig zu tun wie mit 'Digitalisierung', wie Sylvia Lipowski in einem Artikel 'WOL bei BOSCH' nahe zu legen versucht. Bei WOL geht es um das Erlernen von Sozialkompetenz mit dem Ziel, das eigene Fortkommen zu erleichtern — oder wie John Stepper formuliert:

WOL ist nur das konventionelle Wissen darüber, wie gute Beziehungen funktionieren, kombiniert mit der Macht und der Reichweite digitaler Netzwerke. Oder: Dale Carnegie plus Internet.

Vielleicht ist WOL auch ein Papierballon, einer dieser strahlenden, die mit einem Teelicht befeuert im Nachthimmel aufsteigen und magisch leuchten. Gibt es längsschnittliche Daten dazu, wie WOL über Monate, Jahre wirkt? Was bleibt übrig nach zwölf Wochen und kann man das messen? Gesucht und nichts gefunden.

Working Out Loud beispielsweise wird in der Regel als Graswurzelbewegung begonnen, die Teilnahme basiert auf Freiwilligkeit. Und die Vorteile dafür liegen auf der Hand: Wer sich mit der Methode identifizieren kann, ist auch bereit, Mehrleistung zu erbringen, die formal nicht angeordnet werden könnte – zum Beispiel, weil notwendige Übungen außerhalb der Arbeitszeit zu erledigen sind. Wird diese Freiwilligkeit zugunsten von Steuerungsimpulsen aus der Hierarchie jedoch aufgegeben, erzeugt das zwangsläufig Enttäuschung bei denen, die sich bisher über den Graswurzelcharakter der Methode identifiziert haben. Das heißt: Will die Organisation Working Out Loud als Pflichtprogramm etablieren, riskiert sie, dass mindestens bei einem Teil der bisher motivierten Unterstützer das persönliche Engagement einbricht. Das erhoffte „brauchbar illegale“ Verhalten wird damit eher unwahrscheinlich.
— Muster, Judith und Bull, Finn-Rasmus. Konzerne go agile? managerSeminare, Heft 251, Februar 2019, S. 36f

Polemik

WOL scheint damit ein wenig wie das Programm der Weightwatchers™ zur Gewichtskontrolle. Dort schlankt es sich gemeinsam schöner, bei WOL networkelt es sich mit Gruppendynamik und Checkliste geschmeidiger als jeder für sich. Wer nicht dran bleibt, wird wieder fett — wer sich nicht tummelt, bleibt das selbe Kostenstellenmäuschen wie zuvor.

Damit des Königs neue Kleider einen Abschluss finden: ja — WOL trifft wohl einen Bedarf in grösseren Unternehmen, etwas Neues ist es nicht. Und ob gemeinsames WOLlen auch ein unternehmerisches Können und Verhaltensänderungen zur Folge hat ... kann man WOL erst beantworten, wenn die Initiativen ein paar Monate laufen und jemand sich die Mühe macht und die Effekte prüft.

Referenzen:

Bußmann, Nicole, und Sylvia Lipowski. 2018. „John Stepper im Interview ‚Sagt den Leuten nicht, was sie tun sollen‘“. managerSeminare, Nr. 248 (November): 38–46.
Sebastian Hollmann. 07:32:07 UTC. „WOL @ CeBIT“. Business. https://www.slideshare.net/SebastianHollmann/wol-cebit.
Lipkowski, Sylvia. 2018. „Working Out Loud bei Bosch Köpfe vernetzen“. managerSeminare, Januar 2018.
Stepper, John. 2015. Working out Loud: For a Better Career and Life. New York: Ikigai Press. www.workingoutloud.com/.de

Nächste Folge dieser Serie ist alsbald ein Ritt durch Beta-Codex, OpenSpace Beta, Komplexithoden, VFOT und dann Intrinsify.

Hic sunt Dracones — mit Wardley Maps das Unbekannte greifen

hedi.buchner — Mon, 01 Apr 2019 07:20:00 +0000

Wechselbeziehungen in einer unbekannten Zukunft

Die meisten, aus dem Methodenköfferchen der Betriebswirtschaftslehre bekannten Methoden zur Strategieentwicklung erscheinen gegen Wardley Mapping wie die Weltsicht von "Die Erde ist eine Scheibe" gegen ein LIDAR-Modell. Diese Präzision kommt aber zu einem Preis.

Wardley Maps sind nicht gerade einfach konsumierbar: Simon Wardley geht es nicht um einfache Wahrheiten sondern um dynamische Wechselbeziehungen vieler Variablen in einer unbekannten Zukunft.

Abb: "Figure 246 — Combination Plays", eine schon etwas kompliziertere Wardley Map. Quelle: Medium

Damit verwundert nicht, dass Wardley Maps nicht als 'the next big thing' durch alle Kanäle geistern. Man muss sich reinfuchsen, auseinandersetzen damit, Notation, Codes und Konstrukte verstanden, nachvollzogen und selbst geübt haben — bevor man selbst in der Lage ist, ein eigenes Mapping zu bauen.

Eine Notation für veränderliche Wertschöpfung

Anders als bei Zielbildern ('da will ich hin'), findet Simon Wardley eine Notation um sich verändernde Wertschöpfungsketten über die Zeit und in wahrscheinliche Zukünfte abzubilden. Der Schlüssel dazu ist, alle bremsenden, riskanten und unscharfen Einflüsse mitsamt ihrer Annahmen abzubilden, also Glaubenssätze und Vermutungen offen zu legen und sie rückhaltlos in einer Expertengruppe zu debattieren.

Das gelingt, indem auf einer Wardley Map der veränderliche Pfad von Produktlebenszyklen, Geschäftsmodellen, Branchen, Industrien mit zunehmend vielen Wenns und Abers modelliert wird. Aus einer groben Karte wird mit mehr Informationen, Randbedingungen und Wechselwirkungen ein Modell. Legt man mehrere davon nebeneinander, kann man Muster erkennen, Regelhaftigkeiten erahnen — oder grandios daneben liegen.

Viele Produkte und Geschäftsmodelle starten mit einer Erfindung, einer Entdeckung oder der kostbaren Handarbeit eines Meisters. Die meisterhafte Fähigkeit eines Einzelnen etwas zu bauen, was so gut nur er oder sie selbst kann, nicht jeder. Ein Wettbewerbsvorteil so lange, bis andere imitieren und besser werden.

Jemand stellt also von Hand etwas her und optimiert, macht es besser, passender, gefälliger. Bis es 'good enough' ist. Wenn mehr Menschen dieses Etwas haben wollen, wird einfach mehr hergestellt, mit Maschinen, mehr Händen, Kopien oder am Fliessband mit Robotern. Mit Geschirr ist das so. Wir speisen von Industrieporzellan und töpfern Tassen und Teller nicht mehr selbst.

Wir wüssten nicht einmal, wie das geht.

Vom Unikat zur commodity

Viele — nicht alle — Innovationen münden mit ihrer Industrialisierung in einer Allerwelts-commodity. Das haben wir in einer halben Generation mehr als einmal erlebt. Wo das erste Mobiltelefon mit Fotofunktion noch teure Sensation war, ist der Grenznutzen praktisch ausgeschöpft: mit Bauformen und Formfaktoren ist nicht viel mehr heraus zu holen aus den Optiken.

Was bei den ersten Geräten ein entscheidendes Feature war, hat heute jeder Grundschüler in der Schultasche. Mehr Speicher braucht auch niemand. Wo vor nicht zu vielen Jahren eine handvoll eigener Server in einem Rechenzentrum unerhört waren, ist die Cloud und Rechenkapazität um Centbeträge eine commodity, ein ’eh’-da’ wie Luft, Strom und Wasser.

Karten abstrahieren die Realität

Wie alle Karten sind auch Wardleys Karten notwendigerweise Abstraktionen einer Realität. Das kennen wir von Wanderkarten, die trotz eines Maßstabes von 1:40.000 als Vereinfachung der Natur eben nicht jeden Steinbrocken zeigen. Eine Karte im 25-fach größeren Maßstab 1:1.000.000 muss noch drastischer abstrahieren, mehr weglassen und zusammenfassen weil aus Flughöhe eines Verkehrsflugzeuges noch viel weniger Details relevant und erkennbar sind als am Boden.

Je nach use case sind andere Details relevant.

Wer sich beim Wandern erfolgreich verlaufen hat, kennt das: eine Karte ist nur nützlich, wenn man die eigene Position und Ausrichtung kennt. Uns hilft dabei GPS. Auch das ist kein besonderes Feature mehr und kein Militärgeheimnis sondern commodity in jedem 100€-Smartphone.

Wo bin ich — und wo soll es hingehen?

Für Wardley Mapping ist allerdings das schon die erste Einstiegshürde: wo stehe ich, mein Produkt, meine Idee, 'die Branche' jetzt wirklich? Was ist der präzise Standort und was die gerade noch akzeptable Unschärfe? Wie sehr kann ich in meiner Verortung daneben liegen, so dass die Karte noch einen Weg weisen kann?

Die Analogie kartografischer Karten mit Wardley Maps geht noch weiter: so wie die Übersichtskarte in 1:1Mio nützlich ist für die ersten 250km, wird es die Wanderkarte für die letzten Kilo- und hunderte Meter.

In der Nahorientierung helfen nur mehr die eigenen Sinne. Das 'hier und jetzt' sperrt sich einer Kartierung, für die Vergangenheit ist es einfach und für mögliche Zukünfte … schwierig.

Weil alles eine Vergangenheit und Zukunft hat, bewegen sich alle Komponenten auf Wardley Maps von links nach rechts. Jede Aktion (was wir tun) in der Art, wie wir es tun und jedes mental model, das den sinnhaften Zusammenhang abbildet. Zum Einstieg reicht es zu wissen, dass Bewegung und Weiterentwicklung von der Manufaktur zur commodity über Wettbewerb geschieht.

Selbermachen mit peers und Annahmen offenlegen

Die erste Übung im Wardley Mapping ist, die eigenen Annahmen offen zu legen und darauf die immer wieder unangenehme Frage zu stellen »Ist das wirklich so?«. Schwer genug. Funktionieren kann das nur in einer Gruppe, in der sich die Erfahrungen überlappen, in einem Unternehmen oder wenigstens einer peer-group. Das kann man nicht outsourcen an Berater oder Experten. Wir selbst sind die Experten für das, was wir tun.

Das wiederum erklärt hinreichend, weshalb einschlägige Berater und Auskenner nicht im Handumdrehen zu Wardley-Jüngern werden: man muss sein Geschäft verstehen, nicht das eines anderen.

Mapping ist damit ein Gruppenprozess unter Fachexperten, ein gruppendynamischer Vorgang. Die wiederkehrenden Fragen nach den eigenen Annahmen sind allesamt token for communication, Gesprächsanlässe wie eine user story. Wardley mapping steht damit in einer großen, wenn auch fast unsichtbaren Tradition von Vorgehensmodellen, die 'the wisdom of the many' nutzen, die Weiheit der vielen ... wenn sie sich in einer Sache gut auskennen. In den nächsten Folgen sehen wir uns genauer an, mit welchen Regeln und Mechaniken ein Wardley Map entsteht. Bleiben Sie uns gewogen!

Im Unbekannten lauern die Ungeheuer: Hic sunt Dracones

Ach ja — damit hier kein cliff hanger entsteht: »Hic sunt dracones« stammt von den ersten Karten und Globen im sechzehnten Jahrhundert. Auf dem Hunt–Lenox Globe (ca. 1510) hat der Kupferstecher am Rande des aus europäischer Perspektive gerade noch bekannten Erdenrunds neben Seeungeheuern dieses »Hier sind Drachen« vermerkt. Wenn man schon nicht wusste, was da war, gefährlich sollte sc

Hat keiner kommen sehen.

hedi.buchner — Mon, 23 Mar 2020 08:48:00 +0000

Ich lese schon länger an einem eher dicken Buch. Es ist überaus lohnenswert: „Never saw it coming“ handelt unter anderem von einer kognitiven Fehlleistung. Sie besteht darin, dass wir die guten Zukünfte überhöhen und für die schlechten keine Vorstellung pflegen.

Diese Asymetrie ist durchgängig und kulturabhängig, zutiefst menschlich also, ubiquitär und demokratisch.

Wie dieses dumme Virus.

Das Virus ist basisdemokratisch: niemand kann aus nur weil er größer, grüner, reicher oder von wo anders ist. Ebenso gleich verteilt ist die kognitive Asymetrie, sich die Dinge schön zu flunkern.

Wer will das schon kommen sehen?

In uns allen ist diese Fehlleistung fest verdrahtet: wir malen uns aus, wie toll und wunderbar etwas werden wird und sind blank für das Gegenteil. Davon handelt das Buch. Die Flut in New Orleans, eine Gummidichtung am Space Shuttle oder ein Flugschüler, der lernen will eine Boeing in ein Hochhaus zu zielen ... und keinem fällt es auf. Hunderte weitere beschämende Beispiele. Es ist ja nicht so, dass die WHO und Epidemiologen nicht seit Jahren warnen, dass rein statistisch eine Pandemie überfällig ist. Wen juckt die Statistik, wir wollen es nicht hören. Nun ist es da.

Einige wenige Spezialisten im Zivilschutz oder beim Militär können ihre rosa Brille ablegen. Sie müssen das hart üben und dem kognitiven Sog‚ ’es wird schon alles nicht so schlimm werden’ widerstehen lernen. Doch auch die sind auf dem privaten Auge blind wie wir alle. Verlieben sich, heiraten, gehen mit allem in Beziehungen um dann irgendwann und vielleicht zu sehen, dass es doch nichts fürs ganze Leben war. Wer überlegt schon die Trennung, wenn das Zusammenkommen ganz wunderbar ist. Niemand macht das, durchdrehen würden wir.

Emergenz und Komplexität

Was nun geschieht, vielmehr ... dabei ist zu geschehen, ist Emergenz und Komplexität: aus einer unbekannten Anzahl Randbedingungen entwickeln sich Situationen, für die es keine good practice gibt, keinen Masterplan und niemanden, der einem aus Erfahrung raten könnte, was das beste Vorgehen und die wirksamsten Massnahmen sind. Weil noch niemand so etwas erlebt hat. Keine noch so spezielle Unternehmensberatung, kein Think Tank und kein Guru. Vor dem Virus, das dargestellt wird, wie eine Unterwassermine sind wir alle gleich.

Die sonst so mauerblümchenhaften und possierlichen Mathematiker sind nun die Stars. Recht und richtig so. Deren Modelle müssen vereinfachen um berechenbar zu sein, Parameter stark vereinfachen und kategorische Annahmen treffen. Daher kann es kein Modell geben, das die unbekannte Anzahl Randbedingungen für eine ganze Gesellschaft abbildet. Oder für mehrere Nachbargesellschaften oder gleich die ganze Welt.

Wir blicken über die richtig geschlossenen Grenzen — überlastete Krankenhäuser in Italien, um Luft ringende Patienten auf spanischen Hospitalfluren — und wollen gar nicht daran denken, was geschieht, wenn das Virus sich ebenso rasend über Afrika ausbreiten wird.

Was dann geschieht, wenn Menschen nicht nur vor Krieg und Not weg sondern zu medizinischer Hilfe hinfliehen. Zu uns, die wir diese Kompetenzen haben könnten aber sie kaputtgespart haben, die wir zwar Hüften und Knie im Dutzend sanieren aber auf asymmetrische Katastrophen nicht vorbereitet sind.

Wenn alles vorbei sein wird (tm)

Wenn alles vorbei sein wird (tm), dann werden Ärzte, Pfleger, Altenbetreuer, Lehrer und Erzieher fairen Lohn erhalten. Dann wird — nein — weit zuvor wird einer kollektiv bedrohten Gesellschaft hoffentlich auffallen, dass das konzertierte Spekulieren von Finanzverbrechern auf einen Zusammenbruch nicht systemkritisch ist sondern kriminell. Weshalb nicht den Börsenhandel aussetzen? Weshalb nicht asoziale Trader blockieren? Ich bin kein Ökonom, ich weiss es nicht.

Es werden nun liminale Zustände entstehen, die wir uns nicht weiter vorstellen können werden, für die wir keine Methode und Vorstellungskraft haben um allein diesen einen Zustand, geschweige denn seine Auswirkungen auf unsere rosa Zukünfte zu imaginieren.

Im Begriff der Vorstellung steckt schon viel: da stellt sich etwas vor die Wahrnehmung. Noch sind wir im Rosa-Modus, ‘so schlimm wird es nicht werden‘ — doch wer weiss das schon? Wir sitzen wieder der Asymetrie-Falle auf, schnapp und gefangen.

Was gerade geschieht, ist also ein Flug auf Sicht in tief liegender Wolkendecke. Das hat kein Politiker je erlebt, kein Kommentator, kein Experte für irgendetwas. Könnt ihr also bitte allesamt aufhören zu spekulieren?

Sich führen lassen

Also ist das Einzige, das rational geschehen kann: Beobachten, orientieren, entscheiden und handeln. Schnelle Experimente und Prüfschleifen. Die, die wir gewählt haben uns zu führen, müssen im Nebel eine Richtung finden. Und die, die das machen müssen, sind genau die Richtigen.

Was es bei aller Unsicherheit ganz sicher geben wird, ist ein Innovationsschub, Wenn alles vorbei sein wird (tm): Fernlernen, VPNs und working-from-home als default. Adieu Stechuhr — weil es noch nie Sinn machte und es jetzt jeder auch gemerkt haben wird. Selbstorganisation von Menschen, die vom umgebenden System keine oder keine hilfreiche Unterstützung und Handlungsfreiheiten erhalten um einfach nur ihren Job zu machen.

Die englische Abkürzung B.C. stand bislang für ’before christ’, vor Christi Geburt. Auch das könnte sich ändern, wie so vieles sich ändern muss.

Möchte jemand wetten, ob im Dezember die Geburtenrate oder die Scheidungsrate höher liegen wird als die Jahre zuvor? Oder alle beide? Ich nicht.

Irgendwo war auch zu lesen, dass die Situation mehr für die Klimawende tut als alle anderen Massnahmen zusammen. Werden wir uns daran erinnern, Wenn alles vorbei sein wird (tm) und dann Gas geben mit dem Klima?

Ich wünsche uns maximal schlechtes Wetter, das macht alles leichter für die Hardcore Cocooning. Sauwetter soll es haben, sechs Wochen lang. Bitte. Und wenn es alles schwerer macht für die, die helfen — dann bitte kein schlechtes Wetter. Wir wissen es nicht.

Das Buch ist:
Cerulo, Karen A.; 2006. Never saw it coming: cultural challenges to envisioning the worst. The University of Chicago Press, Chicago. ISBN-13: 978-0-226-10033-3

Was können Agile Coaches?

hedi.buchner — Wed, 01 May 2019 11:43:00 +0000

Das war das clickbait. Dieser Beitrag handelt von etwas anderem, doch wollte ich Sie nicht verschrecken. Der ursprüngliche Titel ist 'Was zeichnet hoch effektive (Gruppen-)Therapeuten aus?'

Dabei fiel mir auf, dass Sie das niemals lesen würden — weil Therapie klingt nach 'krank' und das will niemand sein, darüber lesen auch nicht.

Ich komme darauf, weil ich gerade ein Lehrbuch angefangen habe zu lesen, eines über Familientherapien. Aus professionellem Interesse — weil ich vermute, dass die Methoden der Familientherapie vielleicht hilfreich sein können bei agilen Transformationen — was ein etwas hochtrabender Begriff ist für 'einen Laden umkrempeln' oder: einem Unternehmen helfen, morgen anders zu arbeiten als gestern. Familientherapien betreffen mich selbst natürlich überhaupt gar nicht und Sie ebenso wenig — weil ja alles immer in feinster Ordnung ist. Gell?

Auf den ersten paar Dutzend Seiten dieses Buches kommt es zu einem Abschnitt, in dem die Persönlichkeitscharakteristika und Fähigkeiten der '10 besten' Psychotherapeuten beschrieben sind. Skovholt und Jennings (2004) machten dazu eine Studie, die wissenschaftlichen Anforderungen genügt und damit als Stand des Wissens 2004 gelten darf. Heute und 15 Jahre später sollte sich wenig daran geändert haben (Hypothese). Wir Menschen ändern uns ja in eher glazialen Geschwindigkeiten, unser Betriebssystem ist ja schon mindestens 40.000 Jahre eingebrannt (Tatsache).

Was die besten Therapeuten also auszeichnet, sind diesen Dimensionen:

Der unbedingte Wille zur Meisterschaft — wissend, sie nie erreichen zu können.
Die Fähigkeit tief in die Welten Anderer einzutauchen ohne sich selbst zu verlieren
Die Fähigkeit, eine sichere emotionale Situation herzustellen und Klienten dennoch zu fordern. → Psychological Safety!
Die eigenen therapeutischen Kräfte zu nutzen und dennoch bescheiden zu bleiben.
Die Integration der eigenen und professionellen Persönlichkeit und dabei klare Grenzen zu bewahren.
Die Fähigkeit, aus dem eigenen Selbst zu geben und gleichzeitig für sich selbst zu sorgen.
Die Fähigkeit, selbst Feedback zu nehmen ohne destabilisiert zu werden.

Weitere, Ein-Wort-Beschreibungen waren:

lebendig, kongruent, hingegeben, zielgerichtet, intensiv, offen, neugierig, tolerant, vital, reflektiv, sich selbst erkennend, grosszügig, erwachsen, optimistisch, analytisch, lustig, scharfsichtig (...) (pp 133–134)

Wenn Sie bis hier her durchgehalten haben, dann kommt jetzt der intellektuelle Knaller. Bleiben Sie stark ... und dran.

Unterscheiden sich Therapeuten von 'leitenden Agilisten'?

Per se 'sind wir alle gleich', wir alle Agilisten in welchen Rollen auch immer: im Entwicklungsteam, als Scrum Master/Mistress, Produktverantwortlicher oder Trainer oder Coach. Eine Hierarchie soll es nicht geben, es arbeiten alle auf Augenhöhe. So will es das Selbstverständnis, das Agile Manifest und überhaupt das Mantra der Selbst-Organisation.

(Notiz an mich selbst: unbedingt nochmal herausarbeiten, wo genau der Unterschied sein soll zwischen Trainer und Coach ... beim Fussball jedenfalls scheint mir da keiner zu sein. Egal, ein andermal. Bin ja froh, dass Sie überhaupt noch dabei sind und nicht bei 'Therapie' schon schnell weitergesurft sind.)

Wo waren wir stehen geblieben? Ach ja - alle Menschen sind gleich und brüderlich im Agilismus vereint. Keiner oben, niemand unten, alle miteinander und auf Augenhöhe.

Doch nicht.

Realistisch lässt die immanente Dynamik in allen sich formierenden Gruppen eine soziale Rangfolge entstehen: wer 'mehr zu sagen' hat als andere, wer im dayjob den höheren Rang mehr Macht und Einfluss hat ... steht sozial an einer anderen Position als 'die externe Softwareentwicklerin im Team'. Diese immanenten sozialen Hierarchien erfassen wir in Windeseile und unterbewusst, nehmen Verschiebungen ohne kognitive Beteiligung umgehend wahr. Da können wir nicht aus, das ist tief in unserem humanen EPROM hart verdrahtet. Siehe oben, OS H aka menschliches Betriebssystem. Dazu gibt es mindestens einen Beleg aus fMRI-Studien. Wir sind in der Lage ein kohärentes Verstehen einer Hierarchie aus den Interaktionen zwischen Personen schliessen und ergänzen unbewusst und richtig die fehlenden Informationen. (Kumaran 2016) Wie wir das machen? Mit Bayesscher Inferenz, probabilistisch. Auch interessant doch 'zu akademisch', wie Kollege Krishan Mathis angenehm selten bemerkt ... führt uns jetzt aber zu weit weg vom clickbait.

Der Vergleich scheint mit allen Parallelen damit tragfähig: als Agilisten können wir aus den Erfahrungen und Methoden der Gruppentherapie vieles lernen. Vielleicht nicht alles 1:1 übernehmen ... doch die Methoden sind schon alle da und seit den 50er Jahren des letzten Jahrhunderts auch ordentlich lang und breit beschrieben.

Was geht in beginnenden Agile Coaches vor ...?

Ungefähr das, was uns allen irgendwann geschieht. Da kommt einer und sagt 'der hat's ja nicht drauf'. Siehe: des Kaisers neue Kleider.
Also ungefähr das, was auch einem Therapeuten oder Trainer/Coach begegnet:

Auftragsklärung: was erwartet das Team, PO und stakeholder von mir? (Ausser, dass ich über Wasser gehen und es zu Wein machen kann).
Wollen und werden sie mir zuhören und sich leiten lassen, auf meine Hinweise eingehen?
Geht mir der Stoff aus vor Ende des Tages?
Wir meine Unerfahrenheit als Inkompetenz stigmatisiert ... und bin ich raus?
Soll ich aktiv werden oder warten, bis das Team mich auffordert?
Soll ich die Agenda setzen oder abwarten, bis die Gruppe sich eine erarbeitet?
Welche Methoden und Praktiken soll ich in der forming-Phase einsetzen? Und was, wenn das Team nicht mitspielt?
Was mache ich mit offener oder versteckter Opposition ...?

Für den angehenden Agile Coach ist 'möglicherweise nicht zu genügen' beängstigend. Man müsste schon sehr abgebrüht und wenig emphatisch sein, berührte einen das nicht.

Glaubenssätze, innere Monologe und Biases, die fiesen

Es kann helfen, aufmerksam auf die eigenen inneren Monologe und negative Ideen zu achten. Das hat viel zu tun mit Glaubenssätzen und Biases, diesen lästigen kognitiven Denkfallen. Sanfte Befürchtungen und Lampenfieber sind durchaus förderlich, als positiver Eustress aktivieren sie persönliche Potenziale. Schwierig wird es, wenn ängstlich-negative Gedanken sich aufschaukeln und zu hemmenden Spiralen werden.

Ein Weg ist, die eigenen Ängste zu teilen — dem Team die eigenen Ängste offen zu legen. Auch das kostet Überwindung, aber dann ist es raus.

Die Kunst in der Offenbarung der eigenen Befürchtungen ist vielleicht, das Was, Wann und Wie zu dosieren — und sich sicher zu sein, dass man selbst es steuern kann.

Gefühle? Haben wir nicht.

Über die eigenen Gefühle zu sprechen mag im professionell-effizienten 'business context' verwegen sein — die Alternative es nicht zu tun ist fahrlässig: Was wir sehen und beobachten können, sind professionelle Stereotypen. Was wir nicht sehen, ist der Eisberg von Emotionen, deren Auftrieb die Glaubenssätze über dem Wasser hält. → IMG iceberg

Helfen kann der einfach gesagte, schwerer umsetzbare Viersatz von Marshall Rosenberg:

Beobachte Tatsachen ohne Bewertung.
Benenne deine Emotionen angesichts der Beobachtungen.
Formuliere deine Bedürfnisse und Werte, durch die deine Emotion entstand.
Stelle eine Bitte um dein Bedürfnis zu bedienen.

Da steckt Verletzlichkeit drin und Verletzbarkeit. Was geschehen kann, lässt man sich ein auf wertschätzende Kommunikation als Framework für Kommunikation, ist Offenheit, Lernen und Verständnis in beide Richtungen: vom Trainer/Coach zum Team und wieder retour. Bilaterale Offenheit, gemeinsames Lernen und wechselseitiges Verständnis.

Führungskräfte in neuen Rollen? Kann klappen.

Das Gleiche gilt für Führungskräfte in ungewohnt neuen Projektrollen. Noch nie gemacht und keine Erfahrung. Neue Methoden einführen weil die alten nicht mehr funktionieren, zu langsam sind, zu widerständig. Nichts liegt näher, nichts ist menschlicher als zurück zu schnappen in erlerntes, sozialisiertes Verhalten. 'Briefen' und 'einzukippen', 'aufgleisen' und Arbeitsanweisungen als kaum maskierte 'Bitte' zu re-framen. Freiwillig vortreten, wem das noch nicht passiert ist. Sitzenbleiben, wem es unendlich peinlich war.

Dem/der Agile Coach sollte das nicht passieren müssen oder nicht mehr passieren.

Sich klar werden darüber, wovor einem graut, was Angst macht oder wenigstens unsicher. 'Den andere' geht es genau so. Es rückt nur niemand raus damit weil wir allesamt konditioniert sind im stark sein, im 'Wissen was man tut'. Ohne ein Alphatierchen-Gen wird man keine Führungskraft oder bleibt es nicht lange.

Am Ende sind wir alle Menschlein und nicht so sehr verschieden voneinander, wie Alter, Erfahrung, Titel und Zertifikate uns glauben machen wollen. Zwischen den Ohren rumort das gleiche Getriebe aus Angst und Anziehung.

Andere coachen, trainieren, führen, leiten ... wird einfacher, wenn es leicht geht. Leichter geht es, wenn man lernt, seine eigenen Gefühle und Beobachtungen zu kennen.

Das können gute Agile Coaches.

'New Work' — eine Auslotung

hedi.buchner — Sun, 17 Mar 2019 16:03:00 +0000

Im letzten Beitrag am 10.3.19 'Was Tigidalisierung mit Asterix und Fischstäbchen zu tun hat: eine lose Serie über Patentrezepte' geschah die Ankündigung, ich würde mir Methoden wie New Work, WOL (working out loud), Beta-Codex, OpenSpace Beta, Komplexithoden, VFOT und Intrinsify auf den Seziertisch legen.

Und weil wenig besser wird, je länger es liegt: hier der erste ernsthaftere Teil zu 'New Work' und was dahinter steckt — vielmehr: wo 'New Work' heute noch verbaut ist.

'New Work' als Gegenmodell zur industriellen Lohnarbeit

Der Begriff 'New Work' beschreibt das Zielbild einer Wissensgesellschaft im Kontrast zu den Umständen industrieller Erwerbsarbeit Ende der 1970er Jahre. 'New Work' ist ein Ansatz des in Österreich geborenen, dann in den USA und international wirkenden Sozialphilosophen Frithjof Bergmann.

Sein Vorschlag eines Gegenmodelles sollte über Selbstständigkeit, Freiheit und Teilhabe ermöglichen, Freiräumen für Kreativität und der Entfaltung der eigenen Persönlichkeit zu schaffen.

Teilhaben in drei gleichen Anteilen

Die 'Teilhabe' besteht aus drei Anteilen, in denen der Einzelne anteilig seine Zeit aufteilen solle:

konventionelle Erwerbsarbeit, gainful employment
technisch unterstützte Selbstversorgung, smart consumption und 'High-Tech-Self-Providing' und
Arbeit die man wirklich will, ’work that you really, really want'.

Unter 'Freiheit' versteht Bergmann die individuelle und im Hegelschen Sinne verstandene Handlungsfreiheit, nicht die Entscheidungsfreiheit zwischen Alternativen.

Wirtschaftskrisen und Kapitalismuskritik

Das Konzept einer neuen Arbeit steht vor dem zeitgeschichtlichen Hintergrund der US-Automobilkrise Ende der 70er Jahre, als hohe Arbeitslosigkeit, Arbeitsplatzabbau, der Kalte Krieg und auch ökologische und esoterische Bewegungen Aufmerksamkeit hatten.

In dieser Zeitströmung wurde klar: Massenproduktion reicht nicht mehr aus, um die Arbeitslosigkeit zu beseitigen und grenzenloses Wachstum ist möglicherweise keine Lösung, sondern Teil des Problems.

Bergmann schloss, dass das mit weiterer Automatisierung von Arbeitsabläufen nach seiner Beobachtung auslaufende Modell der Lohnarbeit und damit der Wegfall der Vollbeschäftigung neue Chance böte und entwickelte das Alternativmodell der 'New Work', eine Art Gesellschaftsvertrag für eine neue Generation.

Geschichten und Anekdoten: es bleibt wenig Handfestes

Viel konkreter wird es leider nicht, weder in Bergmanns Schriften noch in aufgezeichneten Vorlesungen oder Vorträgen. Konkrete Anleitung, Methoden oder Metriken — was auch immer repliziert und implementiert werden könnte, gibt es nicht. Als Professor der Philosophie und in der Tradition von Hegel und Nietzsche wählt Bergmann das story telling, das anekdotische Erzählen als Form, gibt teils längliche sprachliche Bilder und Geschichten zur Illustration seiner Idee einer neuen Arbeit.

Ein t3n-Beitrag zuckte unlängst ebenso hilflos und konnte nichts entdecken, das von 'New Work' übrig blieb. Auch nicht bei General Motors, bei deren Werk in Flint, Bergmann mit Unterstützung von GM und Anfang der 80er Jahre Modellversuche mit sogenannten 'Zentren neuer Arbeit’ unterhielt — nach seiner ersten persönlichen Erfahrung in der Welt der Lohnarbeit am Band der Automobilfabrik. Der Ansatz dort war, an Stelle von Massenentlassungen, zeitlich begrenzte Modell- oder Auffanggesellschaften zu gründen, in denen von Arbeitslosigkeit bedrohten Arbeiter sich neu orientieren könnten.

'New Work' als Schlagwortgeber

Bei aller Unschärfe scheint Bergmann wenigstens einen Trend getroffen oder gar geboren zu haben: 'New Work' wird als Schlagwort weiter getragen. Die sozialutopischen Forderungen von Frithjof Bergmann werden auch nach mehr als 40 Jahren gerne zitiert. Allen voran beruft sich die 'Working out Loud’-Strömung mit ihren Vertretern auf Bergmann. Ohne in die Tiefen auszuloten — an denen es offensichtlich mangelt.

One Size Fits All

Oder wie Jan Weilbacher, nach dem Besuch der diesjährigen NWX19, New Work Experience, einer von XING organisierten Frontalveranstaltung in der Hamburger Elbphilharmonie zusammenfasste "New Work ist wie ein Kleid, das jedem passt, egal, wer es anzieht."

Bonmot: XING, die Kontakte- und Recruitingplattform firmierte sich im Februar 2019 um in 'New Work SE'.

Dann ist alles klar.

Was #wol ausmacht, behandeln wir in einem der nächsten Beiträge.

Referenzen:

‘An Interview with Frithjof Bergmann: Rethinking Work on a Global Scale’. 1999. Journal of the International Institute 6 (2). http://hdl.handle.net/2027/spo.4750978.0006.203.
‘Die XING SE wird zur New Work SE’. 11.2.2019. Accessed 11 March 2019. https://corporate.xing.com/de/newsroom/pressemitteilungen/meldung/die-xing-se-wird-zur-new-work-se/.
Bergmann, Frithjof. 2005. Die Freiheit leben. 1. Aufl. Freiamt im Schwarzwald: Arbor-Verl.
Gelder, Sarah van. 2011. ‘New Work, New Culture’. Context Institute. 16 September 2011. https://www.context.org/iclib/ic37/bergmann/.
Grabmeier, Stephan. 2019. ‘New Work: Die Lüge Der “Neuen Arbeit”’. Manager Magazin. Accessed 21 February 2019. http://www.manager-magazin.de/lifestyle/artikel/new-work-die-luege-der-neuen-arbeit-a-1251629.html. Grabmeier ist Chief Innovation Officer bei Kienbaum, einer Personalvermittlung.
Vollmer, Jan. n.d. ‘New-Work-Urvater Frithjof Bergmann: Der alte Mann und das Mehr’. t3n Magazin. Accessed 10 March 2019. https://t3n.de/magazin/new-work-urvater-frithjof-bergmann-alte-mann-mehr-247621/.
Weilbacher, Jan C. 2019. ‘#NWX19 – schön gemütlich’. HRpepper Management Consultants (blog). 10 March 2019. https://hrpepper.de/nwx19-schoen-gemuetlich/.
XING. NWX17 - Prof. Dr. Frithjof Bergmann auf der XING New Work Experience 2017. Accessed 11 March 2019. https://www.youtube.com/watch?v=29IoGFD86QM.

Was Tigidalisierung mit Asterix und Fischstäbchen zu tun hat: eine lose Serie über Patentrezepte

hedi.buchner — Sun, 10 Mar 2019 09:03:19 +0000

Eine der wiederkehrenden Figuren der Asterix-Serie ist dieser Fischhändler, vielleicht erinnern Sie sich — in 'Asterix in Spanien' tauchte er das erste Mal auf. In der deutschen Ausgabe heisst er 'Verleihnix' und trägt ein schwarzes Wams über dem Bauch. Er hat zwar ein Fischerboot, doch fischt er nicht selbst und frisch, sondern kauft seinen Fisch aus Lutetia. So halten manche diese Fische für zu teuer, andere für zu alt. Das ein oder andere führt gerne zu einer fulminanten Keilerei.

Die Fische in diesem Beitrag sind Rezepte des Wandels. Mal sind sie alt, mal weit her geholt, sie schmecken nicht jedem und manchmal sind sie teuer.

Eine lose Serie über Wandel und Patentrezepte

In einer losen Serie soll es hier also um 'Transitionen', change, Wandel oder Patentrezepte im Allgemeinen gehen. Das ist, was Sie als Unternehmenskapitän brauchen, wenn tradierte Methoden ins Stocken kommen. Wenn es nicht mehr weiter geht wie gewohnt, weil der dumme Markt sich ändert oder die lästigen Kunden etwas ganz anderes wollen oder diese 'Tigidalisierung' auch ihre Branche entdeckt hat.

Gerne kommen dann 'Berater', die sich auskennen mit sowas. Coaches, Trainer, Agilisten. Die legen einen Plan vor, in 16:9 und mit großen, inhaltsschweren Worten wie 'mindset change'. Nach Plan und best practice ist in kaum sechs Monaten Ihr Laden auf links gedreht, alles agil und die Umsätze strömen wieder. Berater gehen heim, Abschlussfanfare, Welt gerettet.

Die doofe Nachricht: 'agil' ist kein Patentrezept und wandeln müssen Sie sich leider selbst

Und doch haben alle einen in Powerpoint gegossenen Masterplan. Mit Zwischenüberschriften! Nur, dass das ist wie ein Fisch, der schon ein Weilchen liegt. Und Sie wissen ja, wo Fische zu riechen beginnen.

Hier soll es also darum gehen, die vielen Ansätze, Methoden und Instant-Change-Pakete auf ihre Substanz hin zu zerlegen. Oder — um Asterix noch einmal die Ehre zu geben: an die Fischtheke gehen und die Fische genau ansehen, nachsehen, was dran ist. Vielleicht werden wir dabei gemeinsam ein wenig schlauer, vielleicht klären sich ein paar Zusammenhänge und es wird klarer, aus welchen anderen Rezepten sich Strömungen bedienen.

Vielleicht wird auch alles noch viel vielleichtiger.

Rezepte sezieren

Auf der Methodentheke liegen momentan und ohne Reihenfolge:

New Work
WOL (working out loud)
Beta-Codex, OpenSpace Beta, Komplexithoden und VFOT
Intrinsify

Ja, da sind noch jede Menge andere. Die gute alte Tante Scrum und die weiter entfernt wohnende Großtante Kanban. Und wie das bei Familientreffen so ist, auch die Verwandten aus SAFEistan kommen dran.

Und wenn vorher Mut und Ideen nicht ausgehen, dann sezieren wir hier auch, was die großen Unternehmensberatungen anzubieten haben. Das wird lustig.

Ja, Sie können kommentieren.
Nur zu. Vielleicht entsteht eine Debatte, das ist schöner.

Eines noch: wissen Sie, wie unser Verleihnix in der US-Ausgabe heisst?
'Fishstix' heisst er — sehr treffend: in Fischstäbchen ist alles mögliche geschreddert und paniert ... vielleicht auch Fisch.

Mentoring im Sprint

ugurakin

//text

/bild

Start from Scratch - Agile Prinzipien

krishan — Mon, 16 Dec 2019 09:18:36 +0000

Agile Prinzipien kommen im Diskurs meist erst im fortgeschrittenem Stadium vor – nach dem viel Zeit und Gehirnschmalz auf Prozeduren und Regeln verwendet wurde.

Warum fangen wir nicht am Anfang an:

Teams arbeiten zusammen an einem Ziel

Der Rest wird sich finden.

Was ist Agilität:

Target Operating Models
Organisationsentwicklung

Kandidaten:

Teams arbeiten zusammen an einem Ziel – Radical Focus
Teams haben Werte: Modern Agile
Teams möchten sich verbessern – Agile Fluency

Target Operating Models für Hardware- und Softwareentwicklung und für Operations

Flight Levels und die Änderung des Aggregatzustands für Agilität

Wie Agile Coaches HR ins Transformations - Boot holen - Teil 3

Sabine — Tue, 12 May 2020 13:29:34 +0000

Teil 1 - Teil 2

Nach der Diskussion der Frage „Warum sollen Coaches HR mit ins Boot holen?“ (Teil 1) und Tipps zur konkreten Umsetzung zu Onboarding und Zielvereinbarungen (Teil 2), möchte ich hier konkret auf das Thema Führung eingehen.

Führungsprinzipien:

Das Thema Führung ist extrem wichtig für eine erfolgreiche Transition. Agil erfordert nicht zwangsläufig die sofortige Abschaffung aller Hierarchien: Die Vorstellung, dass Hierarchien und bestehende Führungspositionen von heute auf morgen überflüssig werden, jagt vielen Führungskräften und sicher auch unserer Lisa Angst ein. Diese Vorstellung stellt vielleicht alles in Frage, woran sie sich bisher orientiert haben. Es ist wahr, dass sich das Verständnis von Führung in einem agilen Unternehmen ändern muss. Die Zukunftsvision und der Weg dahin sind immer kontextabhängig. Ob die Personalabteilung eine eher administrativ-unterstützende Aufgabe hat oder als Sparringpartner oder Coach für Führungskräfte dient, ist ebenfalls je nach Unternehmen unterschiedlich. In den großen Unternehmen, in denen ich gearbeitet habe, war HR für die Entwicklung von Führungsprinzipien, Schulung und Weiterentwicklung von Führungskräften zuständig. Vieles davon hat einem agilen Mindset entsprochen, so dass man darauf aufbauen konnte. HR sollte eine wichtige Rolle übernehmen in der Begleitung der alten und neuen Führungskräfte bei dem (für sie zum Teil schmerzhaften) Änderungsprozess.

Mit diesem Thema könnte man Bücher füllen (und hat dies bereits getan). Ich möchte an dieser Stelle nur ein paar aus meiner Sicht besonders wichtige Prinzipien agiler Führung zusammenfassen:

Führung beginnt mit Selbst-Führung: Jede Führungskraft sollte regelmäßig ihre eigenen Glaubenssätze und ihr Verhalten reflektieren und anpassen.
Vorbild sein für agiles Mindset und Verhalten: den Mitarbeitern eine Orientierung und eine Motivation geben, welches Verhalten in einem agilen Unternehmen erwünscht ist.
Führung als Dienstleistung an den Mitarbeitern: "Die Mitarbeiter sind unser höchstes Gut" - das darf nicht nur eine Phrase sein. Mitarbeiter, nicht die Führungskräfte, erschaffen Wert für Kunden und Märkte.
Rahmenbedingungen, Prozesse und Strukturen für Selbstorganisation schaffen: Selbstorganisation entsteht nicht von allein. In traditionell aufgestellten Unternehmen müssen sowohl die Aufbau- als auch die Ablauforganisation dazu angepasst werden.
Führung abgeben und verteilen: Auch wenn Hierarchien nicht zwangsläufig abgeschafft werden, gewinnen informelle Netzwerke an Bedeutung. Führung verteilt sich auf mehrere Schultern: viele Mitarbeiter übernehmen (z.B. in ihren Rollen als Produktverantwortlicher oder Experte für ein bestimmtes Thema) situativ und temporär Führungsverantwortung.
Als Mentor Mitarbeiter fördern und weiterentwickeln: Ein häufig geäußertes Bedenken gegen Agilität im Unternehmen ist die Überforderung der Mitarbeiter. Sind sie überhaupt willens und fähig, Verantwortung zu übernehmen? Vielleicht ist ihnen Selbstorganisation durch jahrelanges Funktionieren in klassischen Mustern abhandengekommen? Dann ist es nun die Aufgabe von Führung, die Fähigkeit dazu wieder zum Leben zu erwecken.

Beispiel:

Die DB Vertrieb GmbH ist ein Beispiel dafür, dass HR nicht nur "Mitläufer" in einer agilen Transformation ist, sondern eine eigene agile Transformation starten kann. Geleitet durch ihr Zielbild KAI (Kundenzentriert, Agil, Innovativ) hat HR agile Elemente in ihren Alltag integriert, sich neu aufgestellt und damit zum agilen Vorreiter gemacht. Dabei ist die bestehende Hierarchie abgeschafft worden, aber "hierarchiefrei ist nicht führungslos". Es sind neue Rollen entstanden, die näher "am Kunden" sind (HR Partner, HR Business Partner), sowie Rollen die eher unterstützen (HR Experte).

Fazit:

HR hilft agilen Transformationen, die Neue Welt zu entdecken und zu erschließen. Unternehmen legen nicht einfach einen Schalter um, sondern befinden sich auf einer Reise, die Jahre dauern kann. Während dieser Zeit werden klassische und agile Elemente in der Organisation ko-existieren, und HR kann diesen Übergang unterstützen in seiner Schnittstellenfunktion als Führungs- und Organisationsentwickler.

Und auch HR profitiert von der Zusammenarbeit: HR muß selbst agiler werden, um relevant zu bleiben für das Business. Flexibilität in der Organisation erfordert auch Flexibilität der unterstützenden Funktionen. Nur so kann HR neben den Standardprozessen dem Business schneller individuelle Lösungen anbieten.

Agile Leadership - was ist es und wenn ja, wie viele? (Test)

hedi.buchner — Thu, 21 Oct 2021 06:40:50 +0000

Vor einigen Monaten hat Howard Sublett, Chief Product Owner und CEO der Scrum Alliance zu einem live Diskussionspanel auf youtube eingeladen, um mit einigen erfahrenen Agilist:innen und Leadership Expert:innen darüber zu sprechen, welche Facetten und Styles Agile Leadership hat. So viel schon mal vorne weg: die Ansätze werden sehr kurz und knackig vorgestellt. Ich finde es lohnt sich, das Webinar anzusehen!

Sabine hat beispielsweise 'Leadership as a Coach' vorgestellt. Coaching Techniken und vor allem ein Coaching Mindset sind eine wertvolle Basis, wenn ein Leader die große Aufgabe hat, eine innovative und adaptive Organisation aufzubauen. Wie sonst kann man seine Kolleg:innen dazu ermutigen, sich einzubringen, innovativ zu werden, Verantwortung zu übernehmen und das Unternehmen zu gestalten? Spoiler: eher nicht durch Command und Control. Sabines Leadership Ansatz ist 'Coaching with intent' - Alignment gepaart mit Empowerment (= Autonomie). Das Konzept schwirrt schon seit einiger Zeit durch die agile Szene. Angefangen mit Henrik Knibergs Arbeit bei Spotify bis hin zu der inspirierenden U-Boot Story von I. David Marquet "If you want people to think, give them INTENT, no instruction".

Brad Swanson stellt den 'Balanced Leadership' Ansatz vor. Er geht von zwei Leadership Style Polen aus: den Accomodative Leadership Style, der eher in Richtung Coaching geht. Und dem Assertive Leadership Style, der eher in Richtung durchsetzungsfähige, anpackende, experimentierfreudige, charismatische Führungskraft geht. Brad geht es darum, je nach Situation die notwendige Agilität zu besitzen, um auf einem Spektrum zwischen den beiden Stilen die Balance zu finden. Der erste Schritt um diese Balance zu finden ist das Bewusstsein zu entwickeln, welches eigentlich der eigene dominate Style ist. Der zweite Schritt wäre dann die Absicht in geeigneten Situation auch mal den anderen Stil zu üben.

Als dritte Input-Geberin stellt Judith W. Ullas noch ihren Ansatz 'Grateful Leadership - using the power of acknowledgment' vor. Sie erklärt anschaulich, welche Kraft Anerkennung und vor allem welche destruktive Auswirkung die Abwesenheit von Anerkennung haben kann. Für viele Menschen ist das Gefühl "nicht gesehen zu werden" der entscheidende Grund für die innere Kündigung, die dann oft zur tatsächlichen Kündigung führt.

Die drei Leadership Ansätze greifen tatsächlich sehr ineinander, das Mindset dahinter ist das gleiche. Was die drei Ansätze auch noch teilen, ist der erste Schritt: als Führungskraft/Leader muss ich mir erst selbst bewusst werden, wie ich handle und welche Ziele ich verfolge, wie ich kommuniziere und führe. Erst dann kann ich mich bewusst für einen Leadership Style oder besser gesagt einen Leadership Ansatz entscheiden. Und mich bewusst weiter entwickeln. Meiner Meinung nach ist der 'Balanced Leadership Ansatz' derjenige, der die anderen integriert: je breiter mein Spektrum ist umso angemessener kann ich auf unterschiedliche Situationen, Menschen und Bedürfnisse eingehen. Es geht also nicht um den einen richtigen Leadership Ansatz. Es geht darum je nach Situation und Bedürfnis, durchaus auch aus der eigenen Sicht als Leader, die richtigen Ansätze zur Verfügung zu haben.

Cross-funktionale Teams - Allheilmittel oder überschätztes Dogma? (Test)

Sabine — Thu, 21 Oct 2021 06:51:20 +0000

"Scrum Teams sind interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen." (Scrum Guide).

Historischer Rückblick

In diesem Blog-Beitrag geht es um interdisziplinäre - oder auch näher am englischen Original cross-funktionale - Teams. Bereits vor Scrum hatten sich herausgestellt, dass diese Teams besonders erfolgreich sind bei der Entwicklung von innovativen Produkten (The New New Product Development Game (hbr.org)). Mit Scrum sind sie dann so richtig populär geworden. Als Scrum in den 1990ern entstand, waren Entwicklungsabteilungen in Form von funktionalen Teams organisiert: es gab Kästchen im Organigramm für die Entwickler:innen (damals noch nicht gegendert ) und die Tester:innen, oft noch aufgeteilt in Integrations- und Systemtest. Ich erinnere mich an meine Zeit in einem großen Konzern damals, als es gerade Mode wurde, Testabteilungen in Indien aufzubauen, um Kosten zu sparen. Weiterhin gab es Spezialfunktionen wie Systemarchitekt:innen (von bösen Zungen als "Elfenbeinturm-Architekten" bezeichnet), Risk Manager, Integrationsmanager, Requirement Engineers... alle in ihren eigenen Abteilungen, und damit Diener ihrer jeweiligen Herren, den Abteilungsfürsten. Andere Teile des Unternehmens, die nicht direkt zur Entwicklung gehörten, wie z.B. Produktmanagement und Marketing, waren außen vor. Ein cross-funktionales Team dagegen vereinigte die Menschen, die mit ihren unterschiedlichen Expertisen zur Entstehung eines Produktes beitragen sollten, und schwor sie auf ein gemeinsames Ziel ein. Was für ein Fortschritt!

Die Vorteile liegen auf der Hand:

Für das Team lässt sich leicht ein gemeinsames Ziel formulieren: ein Produkt mit Wert für Kunden zu erzeugen. Entwickler:innen, Tester:innen und die anderen Funktionen ziehen an einem Strang und arbeiten eng zusammen. Das steigert die Identifikation mit dem Team, die Motivation und damit auch die Leistungsbereitschaft.
Mit ihren unterschiedlichen Skills und Sichtweisen findet das Team innovative Lösungen für komplexe Probleme.
Übergabeformalitäten, zum Beispiel in Form von Meilensteinen wie "Ready for System Test", können eingespart werden. So ist der Weg geebnet für ein iterativ-inkrementelles Vorgehen anstelle eines Wasserfallprozesses. Das Team ist in der Lage, schnell und agil zu agieren und seinen eigenen Prozess ständig weiterzuentwickeln.
Um das gemeinsame Ziel zu erreichen, werden starre Rollenbeschreibungen aufgelöst. Jedes Teammitglied trägt Verantwortung zur Erreichung des Ziels. Statt der Elfenbeinturm-Architekt:innen gibt es nun Team-Mitglieder, die sich besonders gut mit Architektur von Systemen auskannten, aber auch andere Tätigkeiten übernehmen können. Team-Mitglieder lernen voneinander und entwickeln sich weiter. Das Know-How wird verbreitert, nicht nur vertieft.
Durch die Unterschiedlichkeiten im Team entstehen Herausforderungen wie Umgang mit Konflikten und gemeinsame Entscheidungsfindung. Was auf den ersten Blick als Nachteil erscheint, ist tatsächlich ein Vorteil, wenn das Team lernt, derartige Herausforderungen gemeinsam bewältigen.

All das waren wichtige Verbesserungsschritte - die oft nur gegen den Widerstand der Abteilungsfürsten durchzusetzen waren. Allerdings waren nicht alle Probleme damit gelöst. Es existierten weiterhin Abhängigkeiten zwischen cross-funktionalen Teams, die gemeinsam an einem Produkt arbeiteten. Der Grund: Die Zuständigkeit der Teams beschränkte sich auf einzelne Komponenten des Produkts. Damit die Anteile der einzelnen Komponenten zusammenpassen, ist ein Planungsschritt notwendig, der diese Anteile identifiziert. Zur Erzeugung des Produktes müssen die Beiträge der Komponenten zusammengebaut werden. Es gibt also Analyse, Entwicklung, Integration und Test mit den entsprechenden Verantwortlichkeiten - ist das wirklich der große Fortschritt im Vergleich zum klassischen Wasserfallprozess?

Feature Teams - ein weiterer Schritt zur Business Agility

Feature Teams sind cross-funktionale Teams, die end-to-end Verantwortung für komplette kunden-orientierte Features übernehmen und so eigenständig Wert für Kunden erzeugen können. Hört sich gut an (s. Feature Teams - Large Scale Scrum (LeSS)) - in der Realität ist es ein sehr anspruchsvolles Unterfangen, Feature Teams aufzustellen. Als Voraussetzung sind hervorragende technische Fähigkeiten nötig wie kontinuierlicher Integration, Test und Auslieferung, die leider in vielen Organisationen nicht vorhanden sind. Der Schritt von Komponenten- zu Feature Teams erfordert eine Umorganisation mit vielen Reibungsverlusten. Ich habe als Coach erlebt, dass Organisationen mehrere Versuche und Experimente gebraucht haben, bevor sie genügend Erfahrung beisammen hatten, sich als Feature Teams aufzustellen (s. z.B. German Big Insurance - Large Scale Scrum (LeSS)). Und selbst wenn dies in der Software-/Produktentwicklung gelingt, besteht ein end-to-end-Prozess aus weiteren Aktivitäten, angefangen mit dem Portfolio-Management über Budgetfreigabe bis zum Marketing, die man in großen Organisationen nicht auch noch in den Feature Teams unterbringt.

Also: cross-funktionale, end-to-end Teams sind ein wichtiger Baustein für agile Unternehmen. Um wirkliche Business Agility zu erreichen und damit in der Lage zu sein, als gesamte Organisation schnell zu reagieren und zu liefern, braucht es eine Sicht auf die Abhängigkeiten und Interaktionen zwischen den Teams und die dort entstehenden Wartezeiten. Mit einem Blick auf das gesamte System und seine Wertschöpfungsketten sollte man zunächst herausfinden, wo es kritische Abhängigkeiten gibt und wirklich hakt, um dann an diesen Stellen gezielte Verbesserungen vornehmen zu können.

Einsatzmöglichkeiten für cross-funktionale Teams

Agilität ist als Denkansatz längst über die Software- bzw. Produktentwicklung hinausgewachsen - und damit auch die cross-funktionalen Teams. Ich habe solche Teams in allen möglichen Bereichen unterstützen dürfen: von einem Team, das ein IT-Sicherheitskonzept zum Schutz gegen Hackerangriffe entwickeln sollte, bis hin zu einem Team, das Governance-Richtlinien zur Sicherstellung von Nachhaltigkeitsaspekten erstellen sollte. Mitglieder in diesen Teams waren Personen aus der Unternehmenskommunikation und der Organisationsentwicklung, Jurist:innen, Change Manager, Vertreter:innen aus den einzelnen Regionen... mit den nötigen Entscheidungsbefugnissen und Entlastung von operativen Tätigkeiten ausgestattet, können solche Teams sehr effektiv arbeiten.

Inter- und extra-dependent Teams

Sind die cross-funktionalen Teams - zumindest als Grundbaustein - also ein Allheilmittel, wenn es um die effektive Lösung von komplexen Problemen geht?

Denken wir zurück an die so oft geschmähten "Silos" (dieser Begriff wird heute von den meisten Agilisten mit einem unverkennbar abwertenden Gesichtsausdruck verwendet). Die Leistung der "Silos" besteht in der Weiterentwicklung einer bestimmten Expertise, die allen Mitgliedern des "Silos" gemeinsam war. Also zum Beispiel Test-Kompetenz. Damit sorgte das "Silo" dafür, dass Fachwissen in einer Organisation entsteht und erhalten bleibt. Die Motivation dahinter ist die Erhöhung von Qualität und Effizienz - was in der agilen Welt heute als ewig gestrige Denkweise und kontraproduktiv bei der Lösung komplexer Probleme verschrien ist. Erfolgreiche Organisationen brauchen aber beides: agiles Vorgehen bei der Nutzung von neuen Chancen UND effizientes Vorgehen bei etablierten Prozessen mit wenig Unsicherheit. Durch die gemeinsame Expertise schaffen die "Silos" ein Zusammengehörigkeitsgefühl, das langfristiger sein kann als die Entwicklung eines Produktes. Wo bleibt dieser Aspekt bei den cross-funktionalen Teams? Na klar, dafür gibt es die "Communities of Practise (CoP)" - ein team-übergreifender Zusammenschluss von Personen einer bestimmten Fachrichtung wie Test oder Architektur. Im Gegensatz zu den "Silos" aber eher informell und damit im Zweifelsfall weniger wichtig als die Arbeit im "eigentlichen", cross-funktionalen Produktteam.

Dieser Zusammenhang ist mir deutlich geworden bei der Lektüre von "Extra-Dependent Teams" (David Kesby). David argumentiert, dass die gängige Team-Lehre zwischen "richtigen" Teams und "work groups" unterscheidet. Die Team-Lehre suggeriert, dass jede Gruppe sich am besten zu einem "richtigen" Team entwickeln sollte, weil sie nur dadurch "high performing" werden kann. Dazu sind - so lehrt uns die Lehre - bestimmte Attribute notwendig, wie ein gemeinsames Ziel, gemeinsame Verantwortung und Interdisziplinarität. Dabei wird verkannt, dass die "work group" ein hervorragendes Modell zum Beispiel für CoPs ist. Um zu vermeiden, dass "work groups" als bloßes Übergangsstadium zum "richtigen" Team und damit als minderwertig betrachtet werden, nennt David sie "extra-dependent" Teams - im Gegensatz zu den "inter-dependent Teams", unseren Produktteams. Die Mitglieder der extra-dependent Teams arbeiten nicht ständig zusammen, sondern hauptamtlich als Mitglieder von inter-dependent Teams. Sie erfüllen aber eine wichtige Aufgabe, indem sie gemeinsam lernen, strategisch wichtiges Wissen erzeugen und gute Praktiken, Richtlinien, Tools... für die Organisation bereitstellen. Im Gegensatz zu CoPs, die eher informell sind, sind diese extra-dependent Teams in der Regel eine Organisationseinheit mit einer gemeinsamen Führungskraft.

Ein anschauliches Beispiel für ein extra-dependent Team ist die Schwangerschaftsgruppe zur Geburtsvorbereitung. Das inter-dependent Team ist die einzelne Familie. Die Familie hat damit ein gemeinsames Ziel: ein gesundes Baby auf die Welt zu bringen. Die Geburtsvorbereitungsgruppe hat kein gemeinsames, sondern ein identisches Ziel. Übertragen auf die agile Welt sind dies Einheiten, "Silos", von Tester:innen, Designer:innen, Produkt-Manager:innen, Scrum Master:innen...

Ein weiteres Beispiel sind wir - improuv. Wir arbeiten als Coaches und Berater:innen bei unseren Kunden als Mitglieder von inter-dependent Teams. Wir bilden aber auch gemeinsam mit unseren improuv-Kolleg:innen ein extra-dependent Team: wir entwickeln neuen Ideen, führen kollegiale Fallberatungen und tauschen unsere Erfahrungen aus. Unser identisches Ziel ist es, gemeinsam zu lernen und Spaß dabei zu haben - und improuv langfristig erfolgreich zu machen.

Je größer die Organisation ist, desto eher werden bestimmte Funktionen zentral zusammengefasst: HR, Legal, Finance, Marketing, Sales, Procurement... sind Beispiele dafür. Um Kundenorientierung und damit Business Agility zu erreichen, sollte das Geschehen jedoch nicht von diesen Zentraleinheiten bestimmt werden, sondern vom Kunden, bzw. von kundenorientierten Teams. Die Aufgabe der Zentraleinheiten ist es, diese zu unterstützen. Ein Business Partner aus HR, der für einen bestimmten Bereich zuständig ist, ist "interdependent" Mitglied dieses Bereichs und gleichzeitig "extradependent" Mitglied seiner HR-Einheit.

Extra-dependent Teams sind die Realität in Organisationen. Nach Untersuchungen von David in drei Organisationen machen sie zwischen 43 un 69% aller Teams aus! Wir sollten also vermeiden, alle Teams über einen Kamm zu scheren und extra-dependent Teams in das Raster eines inter-dependent Teams zu pressen. Das führt nur zu Frustration und nicht zu der erwarteten Verbesserung der Performance.

Fazit: Cross-funktionale Teams sind super - aber bitte nicht als Dogma. Die Arbeit an Produkten ist eben nur ein Teil einer agilen Organisation. Ein Team ist mehr als die Summe seiner Mitglieder - und eine Organisation ist mehr als die Summe seiner Teams.

Agile Leadership - was ist es und wenn ja, wie viele? (Test)

christian-braun

test en

christian-braun — Tue, 07 Dec 2021 07:37:17 +0000

Elementor #40369

jens

Elementor #40558

christian-braun

Culture: Always there, but nobody can see it!

ugurakin

SAFe kuschelt mit OKRs

ugurakin

Wie erreiche ich meine Ziele

ugurakin

Grundsätzlich zwei Arten um Ziele zu setzten. Und nein, die Option genau die Ziele zu erfüllen in Zeit, (beste) Leistung, Ressourcen (kosten) sehe ich nicht als realistisch. Zumindest nicht für meine Ziele. Dafür ist mein persönlicher Anspruch immer zu hoch.

Zu hohe Ziele
Zu niedrige Ziele

Product Owner als Facilitator

ugurakin

Die Stärke des/der Product Owner:in als Facilitator:in

Warum sollte die PO Facilitator sein? Dafür hat sie doch die SM, oder?

Während meiner Ausbildung zum A-CSPO und CSP-PO habe ich viel dazu gelernt, was das Thema Facilitation angeht.

Pros:

Scrum Master wenig Erfahrung mit dem Produkt (die muss sie als Facilitator auch nicht haben)
PO hat Ahnung vom Produkt
Hat evtl. direkten Kontakt zu den Kunden/Nutzer
Wird ernst genommen von den Stakeholdern
Kann den Rahmen besser abschätzen
Besser Rückfragen stellen wie was gemeint ist
Kann auch alleine mit den Stakeholdern Termine abhalten

Cons:

Redet sehr stark mit
Leitet die Stakeholder in eine Richtung absichtlich-unabsichtlich

Wann ist das relevant:
Während der Product Discovery (also jenseits des eigentlichen Scrum-Prozesses) geht es darum, Ideen zu generieren und möglichst schnell etwas darüber zu lernen, welche Lösungen von Stakeholdern akzeptiert werden. In dieser Phase ist es sinnvoll, Workshops mit Stakeholdern abzuhalten.

Beispiel aus der Praxis:

Mit Stakeholder in einem Meeting. Unterschiedliche Bereiche. Wissen zusammen führen.
Mehrere Runden drehen. Gedanken frei machen, sammeln, Gedanken frei machen und erneut sammeln. → Bild

Technik- und Business-zentrierte Tests

krishan — Mon, 08 Nov 2010 07:11:00 +0000

Scrum beschäftigt sich in letzter Zeit stärker mit der Frage, wie die Lücke zwischen der Spezifikation und dem mit TDD entwickelten Code überbrückt werden kann. Dazu muss man Zwischenschritte zwischen der Spezifikation und der Implementierung entwickeln über:

User Stories
Akzeptanzkriterien
Definition of Done
Akzeptanztests
Akzeptanztestgetriebene Entwicklung

User Stories haben eine empfohlene Darstellungsform mit den Teilen: Wer, was warum. Das ist aber nur ein Vorschlag. Die Formulierung von Ron Jeffries kreist stärker um das Wesen:

Card: Stories werden traditionell auf Karteikarten geschrieben. Damit kann schon gar nicht die Illusion auskommen, das seine eine vollständige Spezifikation (dafür wäre ein schlicht lächerliches Format).
Conversation: vielmehr offenbaren sich die Details hinter einer Story oft erst in einem Gespräch über die Story
Confirmation: Akzeptanzkriterien und die daraus entwickelten ersten Akzeptanztests bestätigen, daß die Story korrekt umgesetzt wurde

Akzeptanztests sind also Tests auf der Ebene der Business-Funktionalität. Sie setzen zum Teil direkt Akzeptanzkriterien um. Jetzt kann ich versuchen, die Schritte der akzeptanztestgetriebene Entwicklung (ATDD) zu definieren:

Zu User Stories werden Akzeptanzkriterien entwickelt
Wo immer ich feststelle, daß ich mich wieder hole und immer die gleichen Kriterien formulieren, kann diese herausziehen: das ist der Kern einer Definition of Done (ggfls. zusammen mit externen Vorgaben)
Aus den Kriterien entwickeln wir die ersten Akzeptanztests. Damit haben wir ein wesenntlich mächtigeres Mittel zur Fomrulierung als nur die verbale Spezifikation in der Hand: eine ausführbare Spezifikation. Diese können (von Kunden, dezidierten Testern oder auch von Entwicklern) auch zuerst entwickelt werden, bevor die Implementierung des Business-Codes startet
Diese Akzeptanztests leiten dann die Implementierung mittels TDD

Dieser Zyklus kann einige Stunden bis zu einem Sprint gehen. In der Kombination mit einer Entwicklung mit TDD er stellt sicher, daß das Richtige und daß die Implementierung richtig entwickelt wurde und die Entwicklung insgesamt berechenbarer wird. Zuerst eine Abgrenzung. Wir reden von

Testautomatisierung
Kontinuierliche Integration
Test-First
Testgetrieben

Testautomatisierung ist noch relativ einfach: Test, die von Anfang bis Ende ohne manuelle Eingriffe laufen und damit wiederholbare Testergebnisse erlauben. Möglichst soll eine ganze Testsuite mit einem Knopfdruck gestartet werden. Der Nutzen dabei liegt in der Option wesentlich tiefgreifendere Änderungen in einem System einzuführen. In einer traditionellen Arbeitsteilung, in der Tester das ganze immer wieder durchklicken müßten, würden diese gar nicht mehr sinnvoll nachkommen. Kontinuierliche Integration ist die sinnvolle Fortsetzung und als Konsequenz relativ einfach: wenn es diese Tests gibt, dann sollte man auch sicherstellen, daß sie auch zeitnah ausgeführt werden. Möglichst immer dann, wenn eine Änderung im Versionsverwaltungssystem eingecheckt wird. Oft wird dann noch die Forderung erhoben, die Tests vor der Implementierung zu schreiben und dann die Implementierung (Test First). Ich bin in diesem Punkt skeptisch, ich habe oft erlebt, daß diese Diskussion sich an der Geschmacksfrage festmacht, d.h. an den persönlichen Vorlieben des einzelnen Entwicklers. Testgetriebene Entwicklung (TDD) ist da konsequenter und paradoxerweise leichter zu vertreten. Es ist ein Ansatz, mit dem sichergestellt wird, daß

Jedes Codestück durch einen (Unit-)Test motiviert ist. Der Test wird dadurch tatsächlich zu einer ausführbaren Spezifikation. Man schreibt gerade so viel Code, daß der Test nicht mehr fehlschlägt – und dann wechselt man den Hut und refakturiert – ohne neue Funktionalität zu schreiben – bis man mit dem Programm zufrieden ist.
Jedes Codestück ist dadurch auch per Definition testbar
Der gesamte Code ist auch so oft mit Refakturierung durchgeknetet worden, daß sich das System wesentlich anpaßbarer verhält. Anpaßbar heißt auch, daß initiale Entscheidungen, z.B. Architektur, stärker revidiert werden können – das ist wichtig in einer Umgebung, in der ich sowieso noch nicht alles vor dem Start der Entwicklung weiß.
Dieser TDD-Zyklus wird normalerweise in sehr kurzen Zyklen durchlaufen. Kurz heißt hier wenige Minuten und ist der ständige Rhythmus in der Arbeit eines Entwicklers oder eine Pairs.

Wenn man diese Stufen ansieht, bemerkt man, daß sie inkrementell immer tiefer Strukturen der Software hinterlassen. Man sieht es der Software an, wenn sie testgetrieben entwickelt wurde und man hat deutliche Unterschiede nicht nur in er inneren Qualität, sondern durch die bessere Änderbarkeit auch in den Kosten über den gesamten Lebenszyklus. Jetzt stimmt auch die innere Qualität der Software: jedes Codestück ist durch einen Unit-Test motiviert und es macht das richtige - der äußere Zyklus des ATDD wurde gerade dafür gemacht.

Fünf Aspekte der Firmenpolitik als Ursachen für Verschwendung

krishan — Tue, 24 Aug 2010 22:00:00 +0000

Ich lese gerade das neue Buch von Mary und Tom Poppendieck: Leading Lean Software Development und ich bin hin und weg. Da werden mit leichter Hand strategische Einsichten zusammengetragen und verständlich gemacht. Wenn wir die Scrum-Brille aufhaben, etwa als ScrumMaster, starten wir die Betrachtung beim Team, helfen dem Team effektiv zu arbeiten und eine Umgebung zu sichern, die eine solche effektive Arbeit dauerhaft sichert. Manchmal hört die Betrachtung auch da auf, und man fasst den Rest als „organisatorische Impediments“ zusammen. Die Poppendiecks fangen am anderen Ende an: sie betrachten den Prozess, wie man ihn optimiert, seine Probleme beseitigt. Sie kommen dann auch zum Team und zu optimalen agilen Arbeitstechniken, begründen diese aber oft anders. Für mich ist diese Herangehensweise deshalb so eine wertvolle Ergänzung zu meiner Scrum-Brille, weil ich dadurch oft überraschende neue Argumentationen für die Skalierung von Scrum in großem Maßstab oder überhaupt für die Einbettung in organisatorische Prozesse bekomme. In diesem Fall stellen sie die Forderung, das System als ganzes zu betrachten („systems thinking“) und identifizieren fünf Aspekte der konventionellen Lebenserfahrung, die als Prozesse oder Vorgehensweisen ein Problem geworden sind.

Komplexität
Fehlgeleitete Skalierung
Trenne der Entscheidungen von der Ausführung
Wunschdenken
Technische Schulden

Zu viel Komplexität

Viele Softwareysteme enthalten viel zu viele Features und die Komplexität der Software steigt mehr als linear damit an. Und of gibt es Bedingungen, unter denen suggeriert wird, dass der Umfang der Systeme nicht verhandelt werden kann. Irgendwann schlägt dann die Realität zu und man muss sich doch entscheiden: Termin verschieben oder Scope verkleinern. Dann ist aber das Kind schon inden sprichwörtlichen Brunnen gefallen: Zeit und Arbeit sin in Features geflossen, die noch nicht oder nie genutzt werden. Ein weiterer verstärkender Faktor sind Metriken, die ein solchen Verhalten noch unterstützen: Messen der Produktivität in Lines of Code oder Function Points suggerieren einen Erfolg auch bei der Produktion unnützer Features und starten einen verhängnisvollen Feedback-Zyklus.

Fehlgeleitete Skalierung

oder: das Denken in batch-and-queue ist uns schon so fest eingebrannt, dass wir es oft nicht einmal mehr erkennen, wenn wir es in der Suppe finden. Bei komplexen Entwicklungen geht es nicht darum, die Ressourcen (hier: Menschen) optimal auszulasten, sondern den Durchfluß zu optimieren. Das führt zu einem Prozess, der sehr schlecht auf Überraschungen reagiert, bei dem Arbeiten unterbrochen werden müssen und Multitasking und nutzloser Streß endemisch sind. Das gilt auch und gerade für die Praxis von Jahresbudgets für Entwicklungen, die man in keiner Weise seriös abschätzen kann, die aber oft achselzuckend als „so macht man es eben“ akzeptiert werden.

Trennen der Entscheidungen von der Ausführung

Es gibt immer noch den Irrglauben, dass Manager nicht verstehen müssten, was ihre Mitarbeiter tun. Solche Manage können auch keine Hilfen geben und keinen Beitrag zur Lernprozessen leisten. Auf der anderen Seite ist in solchen Kulturen oft die einzige Möglichkeit aufzusteigen, seine technische Expertise brachliegen zu lassen und Personalverantwortung zu übernehmen. Wenn das keine Verschwendung ist...

Wunschdenken

In der Entwicklung gehen wir allzu oft mit einer geadezu naiven, unwissenschaftichen Attitüde an Aufgaben heran. Wir prüfen nicht die Nützlichkeit eines neuen Werkzeugs, produzieren keine Prototypen, haben keine systematische Methode, aus unserer Arbeit Erkenntnisse zu gewinnen. So viel wußte aber sogar schon Frederick Taylor.

Technische Schulden

Wir tolerieren unfertigen Code, zwingen Entwickler zu unrealistischen Zeitplänen, sparen am Refactoring und wundern uns dann über Wartungskosten und unzureichende Qualität.

Scrum und die Verschwendung

Wenn man jetzt wieder die Lean-Sicht mit der Scrum-Brille vertauscht, wird man diese Beschreibungen alle wiedererkennen:

Zu viel Komplexität wird mit einer rigirisen Priorisierung im Product Backlog bekämpft
Einer fehlgeleiteten Saklierung setzt Scrum das selbstorganisierte Team entgegen, das am Ende jeden Sprints ein fertiges Inkrement liefert
Viele Entscheidungen und die Ausführung liegen in der Hand des selbstorgniierten Teams
Wunschdenken verhindern wir, indem wir es nach jedem Sprint in einer Retrospektive aufdecken und Konsequenzen ergreifen
Technische Schulden entstehen nur, wenn man nach dem Sprint keinen potentiell auslieferbaren Code produziert hat

Meine Konsequenz? Der Blick über den Tellerrand lohnt sich immer wieder. Manchmal ändert sich nichts an der Arbeit, aber es gibt neue Ideen und Argumentationen. Und in diesem Fall kommt noch dazu, dass es wirklich ein gutes Buch ist.

Was kann Kanban einem Scrum Team nutzen

krishan — Tue, 26 Apr 2011 22:00:00 +0000

In meiner frühen Kanban-Wahrnehmung waren Scrum und Kanban erbitterte Feinde. Das lag unter anderem daran, dass ich als erstes Kanban-Buch das Buch "Scrumban" von Corey Ladas gelesen habe. Darin ist bei mir vor allem der Satz "the time has come and gone for .. fixed length iterations" hängen geblieben - stellvertretend für eine Reihe von Relativierungen der Selbstorganisation des Teams.

Die Selbstorganisation ist für mich mit der Kern von Agil, der Sprint in Scrum ist für mich als geschützter Raum eine Möglichkeit, Fehler zu machen und kreativ zusein. Schon damit war das für mich ein frontaler Angriff auf den Geist von Agil. Seitdem habe ich mehr über Scrum und Kanban gelesen und diskutiert, insbesondere das Buch von David Anderson.

Und für mich kristallisiert sich eine Synergie heraus, die gerade aus den verschiedenen Gesichtspunkten von Scrum und Kanban entsteht. Da ist einmal das Verständnis vom Prozess. Der Scrum-Prozess versteht sich als ein Teil der Rahmenbedingungen, in denen das Team arbeitet und innerhalb derer es sich organisiert. Das ist notwendig, weil er auch ein Teil des „Vertrags“ des Teams mit seinen Auftraggebern und der übrigen Umwelt ist.

Das bedeutet, die Wurzel von Scrum liegt in der Organisation der Teamaufgaben und der Verfolgung einer erfolgreichen Entwicklung. Es wird ausdrücklich unterschieden zwischen den Aufgaben – die vom Product Owner vorgegeben werden – und dem „wie“, das vom Team selbst organisiert und bestimmt wird. Dazu gehört auch ein das Konzept des Sprint, einer Iteration fester Länge, als geschützter Bereich, innerhalb dessen das Team Freiheiten der Gestaltung garantiert hat. Das braucht man auf jeden Fall, wenn man innovative Lösungen für komplexe Probleme finden will:

Man geht Umwege und macht Fehler.
Man muss die Freiheit haben, kreative Methoden zu nutzen.

Das bedeutet immer auch einen Bereich, in dem man das Ergebnis nicht vollständig vorhersagen kann: manchmal dauert es länger, manchmal gibt es gar kein Ergebnis – das ist aber auf der anderen Seite eine unverzichtbare Quelle von Innovation. Bei Kanban gehört die Ausgestaltung des Prozesses dem Team. Wenn man das übersetzt, ist das der Teil des Prozesses, den Scrum unter Selbstorganisation beschreibt, also die innere Organisation der Teamarbeit.

Ein weiterer Unterschied besteht darin, dass bei Kanban die Stabilisierung des Prozesses im Vordergrund steht, Kanban betrachtet vorrangig wiederholbare Aufgabentypen (David Anderson beschreibt in seinem Hauptbeispiel ein reines Maintenance-Team). In diesem Licht haben Scrum und Kanban komplementäre Stärken. Wir haben erst angefangen zu lernen, wie man diese intelligent kombinieren kann, ohne dass durch den Prozessgedanken die Innovation und Kreativität unter die Räder kommt. Was bisher schon deutlich geworden ist: Kanban oder Elemente von Kanban kann man in verschiedenen Projekttypen und Formen nutzen:

Ein Team kann seine Arbeit während eines Sprints damit organisieren. In Scrum gibt es schon das Taskboard zur Visualisierung als ein zentrales Werkzeug für die Teamorganisation, mit Kanban haben wir eine lange Liste ausgefeilter Ideen, wie man diese Visualisierung für die Optimierung der Arbeit nutzbar machen kann:
Eine Sprache für die kleinteilige Organisation im Sprint
Verschiedene differenzierte Formen, wie man aus dem Taskboard einen optimierten "information radiator" machen kann:
- Taskboard mit verschiedenen Prozessstufen
- Formale work-in-progress limits
- Swimlanes: Differenzierung verschiedener Arbeitsfelder
- Farben und andere Auszeichnungen von Tasks in Bearbeitung
Wenn ein Team mit vielen externen Abhängigkeiten umgehen muss, werden Commitments für diese Items schwierig: wie kann man die Fertigstellung einer Arbeit garantieren, die von einem unzuverlässigen Lieferanten abhängig ist? Hier hilft es, die eigentlichen Entwicklungsaufgaben und die Integrationsaufgaben separat zu verfolgen und evtl. zwei Boards zu führen oder verschiedene Swimlanes anzulegen.
Für die Bearbeitung von Bugs gilt auch: Wenn man sie in einer eigenen Swimlane führt, kann man transparent machen, wie der Fortschritt ist und wie viel Kapazität darauf verwendet wird.
Reine Wartungsteams werden wenig Nutzen von abgrenzbaren Sprints spüren, da alle Aufgaben unvorhersehbar auflaufen und die Sprintplanung wenig oder keinen Nutzen bringt. Sie werden eher geneigt sein, eine Retrospektive-Kadenz einführen und ganz auf Kanban setzen.

Kanban kennt ähnlich wie Lean Software Development Rezepte einen Satz von Regeln, es sind im Kern sechs – also etwas abgespeckte - Prinzipien:

Fokussiere auf Qualität
Reduziere unfertige Arbeiten (work in progress, WIP)
Liefere oft
Gleiche Erwartungen mit dem Durchsatz ab
Priorisiere
Bekämpfe Quellen von Variabilität um die Vorhersagbarkeit zu verbessern.

Wenn man diese Prinzipien für die Arbeit des Teams im Sprint anwendet, sind sie noch keine Gegensätze zu Scrum-Prinzipien, sondern können sich gut mit Scrum-Prinzipien ergänzen. Ich finde das Scrumban-Buch immer noch zu polemisch, aber ich habe angefangen, meinen Frieden damit zu schliessen und Nutzen darin zu suchen. Ich finde die Argumentation, man hätte bei der Einführung von Kanban weniger Widerstände, immer noch gefährlich: es kann dazu führen, dass man sich um die harten (und wichtigen) Probleme herumdrückt.

Aber ich empfehle meinen Teams trotzdem, sich diesen Werkzeugkasten anzueignen. Weise angewendet, kann er viel nutzen und einem Team einige Hilfen geben, wie es seine Arbeit, seine Sprints, besser organisiert. Es kann helfen, bessere Resultate zu erzielen und daran wird das Team letztlich gemessen: verlässlich und effektiv Anforderungen in fertige Software zu konvertieren.

Wie überzeuge ich mein Management von Pair Programming

krishan — Thu, 24 Mar 2011 08:06:00 +0000

Im vorigen Post habe ich darüber geschrieben, wie man die Kollegen von Pair Programming überzeugt. Die Vorteile von Pair Programming lassen sich auch sehr deutlich in Vorteile für die Firma übersetzen.

Einarbeitungszeit reduzieren

Neue Teammitglieder werden quasi über Nacht eingearbeitet und sehr schnell produktiv. Bei der Verteilung und der Erledigung von Aufgaben ergibt sich eine Art von „osmotischem“ Informationstransfer als Nebeneffekt von Pair Programming. Neue Teammitglieder können zielgerichtet beim Programmieren fragen stellen. Das ersetzt fast immer eine zum Teil quälende und ineffektive Einarbeitungsphase, in der das neue Teammitglied „sich erst einmal einlesen“ muss.

Risiko durch Verlust von Schlüsselpersonen reduzieren

Durch den permanenten Fluss von Wissen beim gemeinsamen Bearbeiten von Aufgaben bauen sich Wissensinseln sehr schnell ab. Das heißt nicht, dass jeder in allen Bereichen Spezialist wird – dazu sind manche Bereiche zu kompliziert und vielleicht entspricht das auch gar nicht seinen Interessen – aber es kommt sehr schnell dazu, dass er Einblick in das Thema bekommt und erste Aufgaben übernehmen kann.

Das Team wird flexibler und kann zuverlässiger liefern

Dieser Einblick in ein Nachbargebiet hat auch dann Vorteile, wenn der Spezialist nicht ausfällt: nur selten sind die Lasten in einzelnen Gebieten immer gleich verteilt. In manchen Sprints gibt es Spitzen bei einem Thema, das kann im nächsten Sprint wieder ganz anders sein. Wenn mehr Teammitglieder Aufgaben aus verschiedenen Bereichen übernehmen können, steigert das Team seine Lieferzuverlässigkeit und verringert seinen WIP – und das ist ein massives wirtschaftliches Argument für Pair Programming. Gleichzeitig wird die Nacharbeit und das Restrisiko für die Produktinkremente deutlich reduziert. Dazu finden sich in [Wil2003] eine ganze Anzahl empirischer Untersuchungen.

Effektive Teams, die zufrieden sind und gut zusammenarbeiten

Pair Programming ist ein effektives Mittel, ein Team als ganzes effektiver zu machen, indem das gegenseitige Verständnis verbessert, Missverständnisse und Reibungsverluste reduziert und die Motivation verbessert werden.

zum Weiterlesen [Wil2003] Laurie Williams, Robert Kessler: Pair Programming Illuminated. Addison Wesley 2003.
Eine umfassende Einführung in Pair Programming für jeden: neben vielen Tipps zur praktischen Einführung (von denen wir hier auch zitiert haben) weisen sie auf typische Probleme im Team und deren Lösung hin. Auserdem haben sie einige empirische Ergebnisse und Fallbeispiele zusammengetragen, mit denen man zögernde Manager überzeugen kann.

Java Coding Dojo in München

krishan — Thu, 03 Feb 2011 02:02:00 +0000

oder: Kata und die Kunst sich weiter zu entwickeln

Wie wird man ein großartiger Musiker? Wenn man über Musiker liest, werden Fähigkeiten wie seine Einfühlungsgabe und seine Ausdrucksfähigkeiten hervorgehoben. Niemandem fällt aber ein zu denken, dass ihm in den Schoß gefallen wäre – jeder weiß, das dies erst durch jahrelange harte Arbeit und Üben elementarer Techniken möglich geworden ist. Erst die perfekte Beherrschung der Technik befreit ihn davon, im Konzert daran zu denken und gibt ihm die Möglichkeit, sich ganz auf seinen spezifischen Ausdruck zu konzentrieren. Und jeder weiß auch, dass die Meister weiter hart üben, um diesen Stand zu halten. Schirennfahrer müssen eine perfekte Fahrtechnik haben, erst auf dieser Basis (unter anderem natürlich) können sie überhaupt anfangen, über die Taktik in einem Rennen nachzudenken. Analog gilt wie für die Musiker: sie arbeiten hart an der elementaren Basis ihrer Fähigkeiten. Das geht so weit: Was machen Schirennfahrer im Sommer? Sie fahren auf den Gletscher und üben ihre Technik.

Entwickler haben ebenfalls eine kreative Tätigkeit, die auf einer Menge elementarer Kenntnisse und Fähigkeiten beruht. Aber wie üben sie? Viele denken, es sei genug, täglich zu programmieren. In letzter Zeit hat sich aber die Erkenntnis verbreitet, dass es ebenfalls unerlässlich ist, die elementaren Dinge zu üben – eben damit man in der täglichen Arbeit nicht ständig daran denken muss. Ob man dabei besser wird, ist damit nicht mehr dem Zufall überlassen, sondern man arbeitet gezielt an einzelnen Skills. Das ist bekannt geworden als Kata – anlog einer Kata aus dem Karate, die in etwa der Pflicht beim Eiskunstlauf entspricht.

Eine Karateschule hat einen Ablauf von Schritte, Techniken, Schlägen..., in denen möglichst viele der typischen Bewegungsabläufe vorkommen. Der Schüler übt diese regelmäßig, um sie perfekt zu beherrschen und sie in Fleisch und Blut übergehen zu lassen. Die typische Anwendung einer Programmier-Kata ist das Einüben von Techniken der testgetriebenen Entwicklung mit Refactoring. Eine Kata kann man sehr gut allein durchführen und beobachten, wie die notwendige Zeit für eine Aufgabe mit der Wiederholung kürzer wird.

Dann kann man anfangen zu beobachten, welche Hindernisse einer weiteren Verbesserung im Weg stehen und z.B. gezielt nach Tastenkombinationen für häufige Aktionen suchen oder einrichten. Neben der Verbesserung von TDD und Refactoring-Praktiken kann man Kata auch einsetzen

Zum Lernen einer neuen Programmiersprache: man kann sich ganz auf die Sprachfeatures konzentrieren, ohne vom Druck abgelenkt zu werden, dass man schnell Ergebnisse vorweisen muss
Sich in eine neue Arbeitsumgebung einzuarbeiten
Pair Programming zu üben
In Gruppen zu arbeiten und sich gegenseitig Tipps und Hilfestellungen zu geben. Das wird weiter unten im Abschnitt über Coding Dojos weiter konkretisiert.

Coding Dojo

Während eine Kata auch dann nützlich ist, wenn man sie allein durchführt, kann man aber noch mehr davon profitieren, wenn man sie in der Gruppe durchführt. So eine Übung heißt Coding Dojo, auch als Randori bekannt. Dojo ist die Übungshalle in den japanischen Kampfkünsten, Randori (wörtlich: das Chaos nehmen) ist eine der Übungsformen eine Kampfes in den Kampfkünsten. Im Gegensatz zu einem richtigen Wettkampf geht es nicht ums gewinnen, sondern darum, die erlernten Techniken fließend in einem simulierten Kampf anwenden zu können.

Java Coding Dojo in München

In München gibt es seit geraumer Zeit ein regelmäßiges offenes .NET Coding Dojo,das von Ilker Cetinkaya veranstaltet wird. Wir (das sind Daniel Zappold und ich, Christoph Mathis) wollen jetzt ein Coding Dojo für Java veranstalten. Der erste Termin findet am 22.02.2011 im Feringapark-Hotel in Unterföhring statt (sorry für die ÖPNV-feindliche Location). Wenn genug Interesse da ist, gibt es sicher weitere Veranstaltungen: also: meldet Euch bei der Xing Gruppe "Agile developer Skills" an.

PMBoK und Scrum - ein Widerspruch?

krishan — Mon, 10 Jan 2011 09:01:00 +0000

Viele Projektmanager glauben, auch wenn sie sich agil nennen, dass Scrum als agile Methode grundsätzlich im Widerspruch zum klassischen Projektmanagement Ansatz steht.

Auch ich war anfangs dieser Meinung. Nachdem ich viele Jahre versucht hatte, Projekte so lean wie möglich zu organisieren, war ich spontan von Scrum begeistert und überzeugt, dass diese geniale Methode dem administrativen Projektmanagement weit überlegen ist. Nachdem ich aber den PMBoK Guide des PMI kennengelernt habe, war ich überrascht, dass Scrum sehr wohl auf Projektmanagement Erfahrungen aufbaut und sich beide Ansätze ergänzen.

Der „Guide to the Project Management Body of Knowledge“ (PMBoK Guide) ist ein weit verbreiteter Projektmanagement-Standard der vom Project Management Institute (PMI) herausgegeben und unterhalten wird. Der PMBoK Guide ist die Basis für die Zertifizierungsprüfung zum Project Management Professional (PMP), dies war auch der Anlass für meine Auseinandersetzung damit.

Beim Studium des PMBok Guide wurde mir klar, dass Scrum mit allen PMBoK Knowlege Areas und Process Groups kompatibel ist. So wird im PMBoK kein „Wasserfall“ Vorgehen vorgeschrieben. Vielmehr wird darauf Wert gelegt, dass alle Prozesse während der Projektlaufzeit ständig neu durchlaufen werden müssen, ohne jedoch genauere Angaben zu machen, in welchen Abständen oder Zyklen dies sinnvoll geschehen sollte. Hier bietet Scrum mit Regeln und Tools erheblich mehr Praxisorientierung, wogegen der PMBoK Guide bei den Vorschlägen für die praktische Anwendung meist sehr vage bleibt.

Scrum Tools für die zentralen PMBoK Prozesse:

Planning. Integration aller Elemente der Planung ist im Scrum Prozess relativ einfach. Time, Cost und Human Resources sind fixe Parameter im Sprint. Scope wird im Sprint-Planning flexibel nach Priorität an die Parameter Time, Cost und HR angepasst. Risk Planning ensteht beim Schätzen und Sprint Planning.
Executing. Integration und Kommunikation wird durch Sprint Backlog und Daily Scrums gewährleistet. Qualität wird durch Definition of Done und Reviews erreicht. Communication und Human Resources Management wird durch Scrum Regeln und die Rolle Scrum Master unterstützt (Hindernisse).
Monitoring und Control. Daily Scrums und Burndown Charts liefern genaue und transparente Fortschrittsdaten. Risiken werden vermindert durch: Specification breakdown, regelmässige Neuschätzung, Demos und Reviews, Product Owner, der Scope Creep durch Priorisierung verhindert.

Dass Projektmanagement und Scrum kein Widerspruch sind, zeigen auch Veröffentlichungen wie „The Software Project Manager's Bridge to Agility“. Michele Sliger und Stacia Broderick vergleichen in einem überzeugenden Mapping Scrum Prozesse mit den PMBok Knowledge Areas.

Es fällt auf, dass sich beide Welten einander immer mehr annähern. Inzwischen gibt es eine große „Agile Community“ innerhalb des PMI in der auch viele Scrum Practitioner aktiv sind.

Folgende Übersicht zeigt ein beispielhaftes Mapping zwischen PMBoK und Agile (Quelle: Sliger Consulting Inc. www.sligerconsulting.com)

Business Case für Agile

anja.stiedl — Sat, 25 Dec 2010 23:00:00 +0000

Kunden erwarten bei zunehmender Komplexität immer kürzere Lieferzyklen. Für viele IT-Organisationen stellt dies eine große Herausforderung dar: es gefährdet zunehmend die Qualität der Software und der Raum für Innovationen wird kleiner. Der Versuch, Qualität durch nachgelagerte Prozesse zu verbessern, erhöht aber meist nur die Kosten und Durchlaufzeiten ohne die Kundenzufriedenheit zu verbessern.

Agile Methoden bieten hier Wettbewerbsvorteile:

Agile Methoden wie Scrum sorgen dafür, dass Software zuverlässig und mit gleichbleibender Qualität geliefert wird.
Selbstorganisation und das Pull-Prinzip reduzieren die Komplexität und stimulieren Höchstleistung und Produktivität.
Ein iteratives Vorgehen kann flexibel auf Kunden-Anforderungen reagieren und teure Fehlentwicklungen verhindern.
Transparenz als Eckpfeiler einer agilen Kultur macht Chancen und Risiken immer zum frühestmöglichen Zeitpunkt sichtbar.

Coaching is Key for Scrum Success

krishan — Wed, 15 Sep 2010 13:09:10 +0000

Ein wunderbares White Paper von der Scrum Alliance beschreibt, warum ein Coach nötig ist und was er tun kann. Ich werde das unbedingt verwenden und kann es nur empfehlen.

Auf meinen Coaching-Backlog habe ich auch schon eine Übersetzung platziert - ziemlich weit oben. Für jetzt muss ich auf den obigen Link verweisen.

Im Papier (das erste aus von zweien)

werden verbreitete Probleme beschrieben, die man hat, wenn man Scrum neu einführt
wird verraten, was meist nicht funktioniert
warum man einen Coach holen sollte, was der tun kann und woran man ihn erkennt

Im zweiten Teil wird dann verraten, warum man einen zertifizierten Coach (CSC) holen sollte. Ich bin auf die Argumente zwar gespannt, vermute aber dass es mir als CSC recht leicht fallen wird, die zu akzeptieren :-)

Sieben Leitlinien für agile Entwickler

krishan — Sun, 15 Aug 2010 13:08:00 +0000

Es ist immer problematisch, einen so komplizierten Sachverhalt auf ein paar Schlagworte zu reduzieren. Ich probiere es trotzdem einmal und hoffe, daß es ein bißchen nützen möge. Diese konkreten Punkte sind mir in meinen Softwareprojekten immer wieder untergekommen. Bei der Vorbereitung unserer Kurse zum „Certified Scrum Developer“ hatte ich endlich einen Anlaß, sie zusammenzufassen:

Entwickle das richtige System
Beweise es kontinuierlich
Liefere zielgerichtet neue Funktionalität
Liefere bei jedem Sprint
Trage zur richtigen Architektur und zum richtigen Design bei
Arbeite kooperativ
Bilde Dich weiter und hilf anderen zu lernen

Entwickle das richtige System

Ein alter Kalauer sagt, das zweitwichtigste sei, etwas richtig zu machen. Das wichtigste ist, das richtige zu machen. Das hat eine ganz reale Anwendung in der Softwareentwicklung: jeder Schritt in der Entwicklung muß von Anforderungen her motiviert sein. Viel zu oft werden spekulative Verallgemeinerungen oder gar spekulative Features realisiert, für die es letztlich gar keinen „business case“, keine geschäftliche Motivation gibt. Das ist einer weit verbreiteten Lücke in der Kette der Übergabe von Anforderungen geschuldet: Kunden spezifizieren Anforderungen in ihrer Welt, ihrer Begrifflichkeit und Granularität. Das reicht oft nicht aus, um die Realisierung hinreichend genau zu leiten. Was hilft, ist Diskussion der Anforderungen. Dabei entsteht ein gegenseitiges Verständnis und evtl. verändern sich dabei auch die Anforderungen: Arbeite mit dem Product Owner am Verständnis. Nutze User Stories als Werkzeug und achte darauf, daß das gemeinsame Verständnis durch Akzeptanztests gefestigt wird. Übrigens: technische Anforderungen können oft nur vom Entwickler-Team erkannt oder sinnvoll formuliert werden. Dann muß ich das auch tun und so dazu beitragen, daß das richtige und das beste System entwickelt wird.

Beweise es kontinuierlich

Oft gehen Akzeptanzkriterien direkt in die Formulierung von Akzeptanztests ein, die damit die Rolle einer ausführbaren Spezifikation bekommen. Das bietet eine riesige Chance, kooperativ alle Fähigkeiten im Team einzubinden. Insbesondere die Rolle der Tester verändert sich massiv, sie stehen nicht am Ende eines Mini-Wasserfalls, sondern sind mitten in der Entwicklung dabei. Manchmal übernehmen sie teilweise die Rolle eines Analysten, der Geschäftszusammenhänge für die Umsetzung in Software aufbereitet. Am besten funktioniert das mit Werkzeugen, die es erlauben, automatisch ablaufende Testskripte schon vor der dazu gehörigen Realisierung zu schreiben. Das heißt: setze Akzeptanzkriterien direkt und nachvollziehbar in Tests um.

Liefere zielgerichtet neue Funktionalität

Die Zielsetzung heißt: gemeinsam wandelt das Team effektiv und zuverlässig Anforderungen in neue Funktionalität um. Die Mittel der Wahl, die den Stand der Kunst repräsentieren, heißen Testgetriebene Entwicklung und Pair Programming. Für eine Testgetriebene Entwicklung gibt ausgezeichnete Gründe:

Jede Zeile Code ist durch einen Test, d.h. ein Stück ausführbare Spezifikation begründet. Das stellt sicher, daß keine „goldenen Wasserhähne“ eingebaut werden, die niemand braucht.
Die Software ist unendlich viel flexibler. Das wird allein schon dadurch erreicht, daß man bei der Entwicklung jedes Stück Code auf Verbesserungsmöglichkeiten abklopft: das Refactoring bei jedem Schritt
Ich hänge nicht mehr fest: durch die Aufteilung der Entwicklung in kleine, reversible Einzelschritte kann ich jederzeit einen Schritt zurückgehen und neu aufsetzen – im Gegensatz zum Fall, in dem ich mit dem Debugger eine Fehler in der Arbeit von mehreren Tagen suchen muß.

Es gibt keine Möglichkeit, Wissen und Fähigkeiten in einem Team schneller zu verbreiten als mit Pair Programming.

Neue Techniken lassen sich ohne Risiko im laufenden Projekt erarbeiten
Gefährliche Wissensmonopole werde aufgelöst oder verhindert, das Team erhöht seine Handlungsfähigkeit

Das heißt: Um zielgreichtet und zuverlässig liefern zu können, arbeite testgetrieben und mit Pair Programming.

Liefere nach jedem Sprint

Ein Sprint, nach dem keine fertige Software ausgeliefert wird, wird zum puren Ritual. Seine Funktion zum Inspizieren des Entwicklungsstands, die Gelegenheit zum Nachsteuern, die genaue Aussage über Stärken und Defizite geht verloren. Die Motivation und das Interesse gehen verloren, das Commitment wird wertlos. Das Team wird in einem negativen Feedback-Kreis gefangen: die Menge der unfertigen Arbeiten nimmt zu, man kann sich nicht auf Arbeitsergebnisse verlassen, die Entwicklungsgeschwindigkeit sinkt. Deshalb: Plane realistisch, beende angefangene Arbeiten und liefere nach jedem Sprint getestete Software.

Trage zur richtigen Architektur und zum richtigen Design bei

Zwei Aspekte einer guten Softwarelösung sind von außen nur schwer zu beurteilen:

Die innere Qualität, das heißt, die Einhaltung von Strukturierungsprinzipien
Manche nichtfunktionalen Eigenschaften der Software

Manche der nichtfunktionalen Eigenschaften kann man durch Qualitätsmetriken erfassen – das sollte man auch tun. Andere erschließen sich nicht so leicht: wenn über die Zeit viele Änderungen stattgefunden haben, stellt sich manchmal die Frage, ob die Gesamtstruktur der Software noch adäquat ist oder ob tiefgreifende Änderungen durchgeführt werden müssen, um die Entwicklung zu unterstützen – agile Architektur ist emergent, d.h. die Strukturen entwickeln sich tendenziell weiter. Um das zu erkennen und ggfls. zu thematisieren, muß man einen Blick über den Tellerrand wagen, sich mit dem Gesamtbild beschäftigen und nicht nur mit dem aktuellen Arbeitsschritt. Man muß auch einen Blick dafür entwickeln und gezielt weiterpflegen. Mit anderen Worten: arbeite daran, ein Systemarchitekt zu werden.

Arbeite kooperativ

Softwareentwicklung ist eine Teamarbeit. Wir arbeiten gemeinsam an einem Resultat und wir lernen voneinander. Von Alistair Cockburn stammt die Gleichung „Entwicklungstempo = Lerntempo“. Das funktioniert nur dann, wenn ich kooperativ im Team arbeite und wenn wir voneinander lernen. Kooperation geht aber über das Team hinaus. Ich muß mit dem Product Owner und meinen Kunden zusammenarbeiten, ich muß ihre Probleme und Ziele verstehen, um den besten Beitrag zur Lösung zu erbringen. In keinem Fall funktioniert diese Kooperation, wenn ich meinen Gegenüber nicht respektiere und versuche, ihn zu verstehen. Das heißt dann vollständig: arbeite kooperativ im Team, mit dem Product Owner und Deinen Kunden, respektiere Deine Kollegen.

Bilde Dich weiter und hilf anderen zu lernen

Bob Martin startete eine Diskussion auf der Konferenz Agile 2008 mit einem Beitrag „Software Craftsmanship over Crap“. Das bringt eine Diskussion auf den Punkt, in der deutlich wird: ich bin für die Resultate meiner Arbeit verantwortlich. Gute Software entsteht nur, wenn ich selbst dazu motiviert bin – Außenmotivation funktioniert nicht. Ich kann nur dann auf der Höhe der Zeit bleiben, wenn ich selbst die Initiative zu kontinuierlicher Weiterbildung ergreife. Und der Stand unseres Handwerks (meinetwegen: unserer Kunst) wird sich nur dann signifikant verbessern, wenn wir selbst daran arbeiten.

Was sind essentielle Team-Skills

krishan — Sun, 06 Jun 2010 04:06:00 +0000

Wenn man nicht nur technische Skills für die Mitarbeit in agilen Teams betrachtet, kommt man sehr schnell auf die Frage, welche Eigenschaften denn ein Teammitglied in einem agilen Team aufweisen oder entwickeln sollte.

Hier ein Vorschlag für eine Liste.

Aktives Zuhören

Aktives Zuhören ist eine Fähigkeit, sich auf die Kommunikation mit einer anderen Person zu fokussieren – verbal und nicht-verbal.

Man denkt nicht an die eigene Antwort, bis die andere Person zu Ende gesprochen hat. Eine einfache Art, das zu tun ist, die Aussage des anderen mit eigenen Worten wiederzugeben. Das bedeutet oft, nach Klarstellungen zu fragen und zu fragen, ob man richtig verstanden hat.

Effektives Fragen

Die Fähigkeit, gute Fragen effektiv zu formulieren hilft uns, neues Wissen in unser mentales Modell der Welt zu integrieren – oder auch, unser Modell zu verändern.

Was sind gute Fragen? Wir müssen die richtigen Worte und einen angemessenen Tonfall finden. Die Frage „warum hast Du das getan“ kann den Gegenüber in eine defensive, abwehrende Haltung bringen. Wir können das durch den Tonfall und die Körpersprache abmildern. Noch besser wäre eine Frage wie „ich verstehe Deine Gründe nicht. Könntest Du sie mir erklären“ – es ist eine freundlichere und effektivere Art, dieselbe Information zu bekommen.

Logisch Argumentieren

Beim Präsentieren einer Idee oder einer Meinung ist es wichtig, diese logisch abzuleiten, um die Essenz zu finden und abzusichern. Das beginnt damit, die eigenen Voraussetzungen und Annahmen darzustellen, auf welchen Daten man aufbaut und die logischen Schritte zur eigenen Schlußfolgerung. Das heißt auch, trügerische oder falsche logische Pfade zu erkennen und wieder aufzugeben.

Respektieren der Kollegen

Respekt heißt, einen Schritt von den eigenen Überzeugungen zurückzutreten und zuzugestehen, daß die Meinung des anderen ebenfalls legitim ist. Das heißt nicht, daß man den gegenüber mit unangemessenem Verhalten davonkommen läßt. Es heißt aber, ihn als Person anzuerkennen. Das unterstützt ihn ebenfalls dabei, respektvoll zu handeln.

Hilfe anbieten

Hilfe anbieten und dann auch zu leisten gehören zusammen. Wenn Du siehst oder vermutest, daß ein Teammitglied mit etwas kämpft, biete ihm mit Worten und Taten Hilfe an. Das kann Information, emotionale Unterstützung, Hilfe beim Lösen des Problems oder gemeinsames Handeln sein.

Teilen und Mitteilen

Teilen heißt, wir teilen unser Wissen, Kenntnisse oder wir teilen Ressourcen. Im Team ist Teilen darauf gerichtet, daß es dem Team hilft, die gemeinsamen Ziele zu erreichen. Es unterscheidet sich vom Helfen durch seinen Charakter als Transaktion im Unterschied zu einer kontinuierlichen Aktivität. Teilen ist nicht unbedingt symmetrisch, es muß nicht unbedingt eine Gegenleistung geben und man sollte dies auch nicht damit verknüpfen oder erwarten.

Partizipieren

Um im Team zu arbeiten, muß man teilnehmen. Offensichtlich, nicht wahr? Es gibt aber weniger offensichtliche Seiten dabei: wenn Du die email checkst, weil Dich eine Diskussion langweilt, nimmst Du nicht teil. Wenn Du eine Teamentscheidung nicht umsetzt, weil Du nicht einverstanden bist, nimmst Du nicht teil. Das vermindert die Effektivität der Teamarbeit und stört das Team und die Kollegen.

Quellen

Als ich angefangen habe, zu dem Thema zu recherchieren, hat mich verwundert, daß es sehr wenig im Netz gibt – zumindest im Zusammenhang mit agilen Teams.

Ich habe dann Seven essential teamwork skills gefunden und eine Rezeption in Agile Advice: Seven Essential Tamwork Skills. agileadvice.com ist übrigens eine Fundgrube für alle möglichen Fragen). Es gibt natürlich, wenn man zu den einzelnen Fragen weiter recherchiert, viel mehr Informationen, z.B viele Wikipedia-Stichworte. Aller Anfang ist eben schwer.

Product Backlog Priorisierung

krishan — Thu, 08 Apr 2010 06:04:10 +0000

Kein Projekt (oder Unternehmen) ohne Priorisierung kann erfolgreich gesteuert werden. In einem agilen Projekt kann man auf auftretende Änderungen zeitnah reagieren. Damit das auch funktioniert,

Muss der Product Owner nützliche Abstraktionen haben – sowohl um über einzelne Produktfeatures zu entscheiden als auch um den Projektfortschritt effektiv zu überwachen. Aus diesen beiden Anforderungen können durchaus verschiedene Sichtweisen entstehen.
Muss der Product Owner tiefer in der Arbeit des Teams eingebunden sein als ein traditioneller Projektmanager. Da er im Prinzip gleichzeitig mit dem Team arbeitet, hat er wesentlich bessere Möglichkeiten einzugreifen und neue Erfahrungen aufzunehmen.

Priorisierung des Product Backlog durch den Product Owner

Steuert effektiv den Produktzuschnitt und den Arbeitsfortschritt
Muss zugeschnitten sein auf die Aufgabe das Team auf die wichtigsten Arbeiten zu fokussieren,
Schützt das Team vor permanentem Entscheidungsstress

Es gibt einen Unterschied zwischen Portfolio-Planung und PBL – deshalb funktioniert es nicht, einfach die Priorisierungsmethoden der Portfolioplanung zu übernehmen.

Priorisierungen für das Portfolio

Für die Portfolioplanung gibt es verschiedene etablierte Priorisierungsverfahren: ROI, NPV, Kano, Theme screening und viele andere.

Alle diese bestimmen eine Kennzahl aus der BWL, die Gewinn oder Kosten auf einzelne Einträge herunterbricht.

Mit diesen Verfahren werden die potientiellen Features des Produkts bewertet und validiert. Dann stellt man die Features zusammen, die in die einzelnen Releases aufgenommen werden.

Dummerweise funktioniert das nicht so einfach für einen Prouct Backlog. Die Verfahren sind entweder viel zu aufwändig, um belsatbare Zahlen für die einzelnen Einträge zu bestimmen und/oder die Sinnhaftigkeit geht beim Herunterbrechen auf einzelne Einträge verloren.

Es kann sogar gefährlich sein, Kriterien zu haben, deren breite Anwendung schwierig oder nicht möglich ist, z.B.: für Einzelfälle: ein Kunde zahlt x € für ein Feature, es kostet y € und x >= y: manchmal tun wir das auch, wenn x < y ist (weil wir den Kunden mögen, weil wir das Geld brauchen, ...) oder weil es die einzigen Features sind, für die wir überhaupt Zahlen haben.

Zum Priorisieren des Product Backlog muss der Product Owner eine Gruppe von geeigneten pragmatischen Attributen entwickeln, an denen er die zu priorisierenden Einträge bewertet und sortiert

Es ist im besten Fall sehr aufwändig, den ROI einzelner Backlog-Stories festzustellen. Die meisten Stories in einem Backlog, die detailliert genug zum Realisieren (“ready”) sind, haben keinen eigenen ROI.

ROI-basierte Priorisierung ist eine Sackgasse: Wir müssen andere Attribute für eine PBL-Priorisierung finden

Ein Prozess für die Priorisierung

Wir brauchen also einen spezifischen Prozess für die Priorisierung, der das Spannungsfeld zwischen der Sicht des Gesamtprodukts und der Sicht der Abbildung in Sprints berücksichtigt.

Danach werden die Elemente des Backlog so sortiert, dass sie optimal zu den Gewinntreibern beitragen.Das umfasst die folgenden Schritte:

Identifiziere Schlüsselattribute
Gruppiere sie
Entwickle eine Gewichtung
Priorisiere den Backlog

Der Schlüssel für Priorisierung nach Gewinn ist:

Gleiche Anforderungen der Stakeholder aus
Synchronisiere mit der Unternehmensstrategie
Bediene die Gewinntreiber

Mögliche Attribute für die PBL-Priorisierung

Speziell: Attribute, die einem Team erlauben, nach Gewinn zu priorisieren

Ablauf:

Identifiziere eine Menge von Attribute, die Backlog-Items zugeordnet werden
Weise den Attributen einen Wert zu
Bestimme die Gewichtung
Sortiere die Backlog-Items

Kandidaten für Attribute

Kunden-Präferenzen, gewonnen aus den Marktuntersuchungen
Kosten-basierte finanzielle Attribute, die als Nebeneffekte der agile Schätzrunden entstehen
Bewertungen interner Stakeholder (Vertrieb, Services, Entwicklung)
Firmen-Prioritäten, z.B. die Präferenz, einen neuen Markt zu entwickeln oder die Effektivität zu erhöhen
Abhängigkeit von externen Systemen (vor allem, wenn diese nach einer Wasserfall-Methode entwickelt werden)
Verschiedene Risiko-Attribute wie technische oder Markt-Risiken
Weitere Attribute, die den Gewinn beeinflussen

Auswahl und Gewichtung der Attribute

Auswahl und Gewichtung der Attribute zur Priorisierung variieren mit dem Produkt und z.T. mit dem Release. Gleichzeitig reflektieren sie die Denkweise des Product Owners.

Ein Standard-Satz von Attributen trägt zur Übersichtlichikeit und zum effektiven Arbeiten des Product Owners bei:

Sie gelten über mehrere Releases
Ihr Wert kann einfach und kostengünstig bestimmt werden
Sie unterstützen ein effektives Produkt-Management
Sie sind konsistent mit den Firmen- und Produktzielen

Kriterien für die Attributauswahl

In aller Regel sind erfüllen die folgenden Gruppen diese Kriterien:

Stakeholder Präferenzen (Stakeholder gibt es als interne und externe Stakeholder)
Konsistenz mit den Unternehmenszielen
Treiber für den Gewinn

Es wäre schön, wenn man direkte Marktforschung zu den User Stories treiben könnte, aber auf dieser Detaillierungsebene ist das in aller Regel zu aufwändig.

Stakeholder Präferenzen

Interne Stakeholder

Vertrieb
Marketing
Kundenservice
IT und Maintenance

Sie sind wichtig für den Projekterfolg, weil sie die Funktionen der Firma repräsentieren, die für den Kunden funktionieren müssen.

IT und Maintenance müssen berücksichtigt werden, auch und gerade weil sie oft in Konflikt mit den kurzfristigen Wünschen nach Weiterentwicklung stehen. Ein wichtiger interner Stakeholder ist das „System“. Es muss gewartet werden, deshalb muss eine gute Qualität der Architektur und des Codes eingebaut werden. Manche Teams verwenden es direkt: ?„Als System will ich ... damit ...“

Externe Stakeholder

Kunden
Marketing-Partner
Distributoren
Die ganze Community, die mit dem Produkt verbunden ist

In aller Regel werden diese Stakeholder (auf der Ebene der User Stories) indirekt über Einschätzungen des Product Owners oder interner Stakeholder gehört.

Konsistenz zur Firmenstrategie

Der Product Owner muss aktiv mit dem Management arbeiten, um die Konsistenz der Kriterien und Prioritäten mit der Firmenstrategie herzustellen und kontinuierlich zu kommunizieren und zu überprüfen. Wenn er das versäumt, provoziert er geradezu Spannungen und Eingriffe bis zum Mikro-Management des Projekts / der Produktentwicklung.

Prioritize for Profit ?

Jeder Product Owner sollte (erfolgreiche PO können das fast immer) beantworten können, wie eine User Story zu profitablem Wachstum beiträgt. Achtung: diese Attribute beschreiben keine isolierten Verbesserungen des Produkts, sondern die Zuordnung zu den Profit-Treibern des Geschäfts:

Geringere Kosten
Verkäufe im Luxus-Segment ...

In der Verbindung der User Stories und den Profit-bezogenen Attributen liegt die Schlüssel-Verbindung zwischen den Rollen eines Product Owners und eines voll verantwortlichen Agilen Produkt-Managers

Driving Profit - Fragen

Was ist Ihr value-exchange-Modell
- Zeitbasierter / dauerhafter Zugriff auf Software
- Transaktionsbasiert (z.B. Kreditkarten-Formen)
Wie ist Ihre Beziehung zum Markt
Was treibt Ihren Gewinn

Zum Beispiel

Adobe: kostenloser Reader, der den Markt für weitere PDF-basierte Produkte bereitet
Kreditkartenfirmen, die ein umfassendes Netzwerk mit Standardisierung, Sicherheitsfunktionen etc. zur Verfügung stellen

Der Priorisierungsprozess

Sammle die Präferenzen der Stakeholder
Synchronisiere mit der Unternehmensstrategie
Treiber für den Gewinn
Bestimme die Daten für die Priorisierung

Sammle die Präferenzen der Stakeholder

Gewinne ihre Perspektive auf die User Stories
Beteilige sie kontinuierlich, finde Alternativen zu traditionellen Marktuntersuchungen
Benutze neue Werkzeuge um zu neuem Denken zu gelangen
Beteilige sie an Innovation Games, um Vorstellungen und Priorisierungen zu ermitteln (z.B. buy-a-feature)

Dabei kann die System-Perspektive auf der Strecke bleiben. Das muss man aktiv kompensieren, z.B. indem man „dem System“ eine eigene Stimme gibt

Synchronisiere mit der Unternehmensstrategie

Wenn die Strategie klar ist (das ist der einfache Fall)

Setze sie in Attribute zur Bewertung der User Stories um
Zeige, für welche User Stories sie zutreffen
Übernimm wenigstens einige in den Backlog

Wenn das schwierig ist - z.B. wegen einer unklaren Strategie

Folge der bestmöglichen Interpretation
Arbeite mit dem Management an Strategie und Marktforschung
Manchmal ist es richtig, die Strategie zu ändern
Demonstriere die Konflikte von User Stories
Verhandle mit dem Management

Driving Profit

Hinterfrage, ob Kunden ein Feature einfach nur erwarten oder ob es wirklich ein Gewinntreiber ist.

Ein Produkt muss letztlich profitabel sein, und es ist Verantwortung des Product Owners zu zeigen, welche User Stories den Gewinn treiben

Aus Sicht des value-exchange-Modells
In der Beziehung zum Markt

Der Konflikt bleibt zunächst: User Stories, die als Gewinntreiber identifizierbar sind, tendieren dazu, groß zu sein (Epics). User Stories, die in einen Sprint Backlog eingehen, müssen oft viel kleinteiliger sein. Das ist OK, wenn die Beziehung transparent, für das Team nachvollziehbar ist und damit der Fokus der Arbeit klar bleibt.

Test 1: Stakeholder Balance

Ein ausgeglichener Backlog hat in jedem Release mindestens eine User Story für jeden Stakeholder.

Durch unausgeglichene Releases verlieren wir am Ende Kunden, Stakeholder, Channel Partner ... oder den guten Willen interner Stakeholder

Test 2: Synchronisierung mit der Unternehmensstrategie

Ein strategisch synchronisierter Backlog hat in jedem Release mindestens eine User Story, die direkt mit den Schlüsselelementen der Unternehmensstrategie korreliert werden kann

Test 3: Profit

Ein Backlog treibt den Gewinn für einen Release, wenn mindestens eine User Story kongruent mit dem value-exchange Modell ist und den Gewinn treibt

Quellen

Brandon Carlson: Story prioritization at the Blink of an eye - blog.projectconnections.com/project_practitioners/2008/09/story-prioritiz.html

Pascal Van Cauwenberghe: Whose value is it anyway? - blog.nayima.be/2010/01/06/whose-value-is-it-anyway/

Pascal Van Cauwenberghe: How do you estimate the Business Value of User Stories? You don’t. blog.nayima.be/2009/12/30/how-do-you-estimate-the-business-value-of-user-stories/

Mike Cohn: Prioritizing your Product Backlog - Agile 2009 conference - www.mountaingoatsoftware.com/presentations/108-prioritizing-your-product-backlog

Mark Denne, Jane Cleland-Huang: Software by Numbers - Prentice Hall 2004

Luke Hohman: Why Prioritizing Your Product Backlog for ROI Doesn’t Work - http://www.enthiosys.com/insights-tools/prioritizeforprofit1of3 (and part 2 and 3)

Selbstorganisierte Teams: kann man sie beeinflussen?

krishan — Sun, 17 Jan 2010 16:01:10 +0000

Was heißt Selbstorganisation

Selbstorganisation heißt nicht, dass das Team über seine Ziele autonom entscheiden kann. Es heißt auch nicht in jedem Fall, das Team könnte über seine Zusammensetzung entscheiden.

Selbstorganisation heißt, das Team bestimmt, wie es auf seine Umgebung reagiert. Und nur wenn diese Möglichkeit hat, bildet sich eine Gruppe von Menschen zu einem Team heran.

Die Umgebung des Teams allerdings kann man als Manager / Leiter / ScrumMaster beeinflussen. Das ist nichts, was nicht transparent gemacht werden könnte und hat nichts mit unfairer Manipulation zu tun, die hier keinesfalls empfohlen werden soll.

Systemtheorie

Die Systemtheorie in der Biologie (wesentliche Namen sind Maturana und Varela) beschreibt die Selbstorganisation lebender Systeme mit den Haupt-Begriffen

Homöostase – Selbstorganisation, das Bestreben eines Systems eine innere Stabilität zu erreichen
Autopoiesis - Selbsterstellung/Selbsterzeugung, der Prozess der Entstehung und Weiterentwicklung eines Systems.

In der soziologischen Systemtheorie (der prominenteste Vertreter ist wohl Niklas Luhmann) wird dieser Ansatz weiterentwickelt und auf ein breites Spektrum von Anwendungsbereichen angewandt:

Es werden ausdifferenzierte Funktionssysteme in der Gesellschaft beschrieben
Ein wichtiger Begriff ist immer eine Leitdifferenz System / Umwelt, d.h. die Festlegung, wie sich das Innenleben und die Abläufe eines Systems von der Außenwelt unterscheiden
Die Form der inneren Abläufe, immer eine Art von Kommunikation

Ein wichtiger Aspekt betrifft noch die Steuerbarkeit eines Systems (Förster):

Beobachtung und Intervention von außen schaffen ein neues System unter Einbeziehung des Beobachters

Das klingt schon fast wie eine soziologische Art der Quantentheorie.

Und ein praktisch wichtiger Punkt kommt noch mit der Beschreibung von Schleifen (Bateson, Watzlawik):

Wer scheitert, passt zunächst seine Vorgehensweise an (Feedback)
Er kann auch zum Ergebnis kommen, dass Situation/Strategie/Ziel nicht zusammenpassen
Das kann zur Reflexion führen, dass mit dem Lernen etwas nicht stimmt
Das ist bekannt unter dem Begriff des Double Loop Learning: die Überlegung, wie das Lernen verbessert werden kann - das bricht Denkmuster auf und wirkt selbststeuernd auf ein System ein.

Komplexe adaptive Systeme

Im angelsächsischen Raum ist eine andere Beschreibungsmethode populärer: Komplexe adaptive Systeme (Complex Adaptive Systems, CAS). Diese beschreiben

Ein dynamisches Netzwerk von Akteuren, die parallel handeln und aufeinander reagieren
Kontrolle ist dezentral
Das Verhalten des Systems wird durch eine große Menge von Entscheidungen getroffen, die kontinuierlich und parallel von den Akteuren getroffen werden

Beispiele für solche komplexen Systeme sind

Autofahrer
Bienenstock
Die Zuschauer, die in ein Stadion zum Fußballspiel wollen
Ein Softwareteam

Kontrolle und Anreize

In jedem dieser Systeme gibt es Kontrollen und Anreize

Autofahrer: Fahre in Richtung Deines Ziels und bleibe auf der rechten Seite der Strasse
Bienenstock: Produziert Honig
Die Zuschauer: Kaufe eine Karte, gehe durch die Eingangskontrolle und gehe dann auf Deinen Platz
Ein Softwareteam: Ziele und Anreize können von Managern und Leitern gesetzt werden .. oder von Teammitgliedern

Praktische Modelle

Praktische Modelle beschrieben Ansätze, wie man auf Basis dieser Erkenntnisse einem Team gezielt Anstöße geben kann, sich in eine bestimmte Richtung zu entwickeln:

CDE: Containers, Differences and Exchanges von Glenda Eoyang
Sieben Hebel (Seven Levers) von Philip Anderson

In der Scrum-Community wurde diese Ansätze durch Mike Cohn in verschiedenen Vorträgen bekannt gemacht.

Das CDE-Modell

Das CDE-Modell beschreibt

Container, d.h. die Umgebung
Differences, Unterschiede und Verschiedenheit zwischen Mitgliedern eines Teams
Transforming Exchanges, d.h. die Interaktionen bzw. den Informationsaustausch zwischen den Teammitgliedern.

Das CDE-Modell kann man durch Eingriffe in diese Elemente nutzen:

Container

Teams vergrößern oder verkleinern
Grenze der Verantwortung eingrenzen oder ausweiten
Wechsle Teammitgliedschaften aus
Schaffe neue Teams

Differenzen

Verlange keine Harmonie
Kreativität braucht Spannung
Stille Ablehnung ist schlechter als intensive Diskussion, die evtl. zu einer Änderung von Verhalten führt
Stelle harte Fragen
Fordere vom Team, Antworten zu entwickeln

Transforming Exchanges

Ermutige die Kommunikation zwischen Teams
Wer schweigt, sollte aber sprechen?
Bringe Personen in den Austausch oder nimm sie heraus
Ändere Reporting-Beziehungen
Setze Personen an andere Plätze / Rollen
Ermutige Lernen

Andersons Pfad der Selbstorganisation

Anderson nutzt intensiv biologische Begriffe in der Beschreibung von Teams, er sagt, Selbstorganisation passiert nicht nur einmal

Ein Team ist niemals damit fertig
Das Team reagiert kontinuierlich auf seine Umgebung und passt sich an

Wenn man beobachtet, wie sich das Team (re-)organisiert, kann man den Weg dieser Anpassung beeinflussen - aber man kann ihn nicht kontrollieren, ohne das Team als funktionierendes System zu zerstören.

Wir können das als Evolution des Teams betrachten.

Evolution ist das Ergebnis von drei Elementen: Variation, Selektion, Beibehalten

Am Beispiel einer Giraffe heißt das

Variation: eine Mutation führt zu einem längeren Hals
Selektion: Der lange Hals führt zu einem Konkurrenzvorteil und zu einer höheren Chance auf Überleben und Fortpflanzung
Beibehalten: die Mutation wird an die Nachkommen weitergegeben

Andersons Idee ist nun, diese Konzept auf Teams anzuwenden und er identifiziert dazu sieben Hebel. Die sieben Hebel zum Beeinflussen von Team-Evolution sind

Auswahl der externen Umgebung
Definieren von Performance
Managen von Bedeutung
Auswahl von Personen
Rekonfigurieren des Netzwerks
Entwicklung zielgerichteter Selektionssysteme
Dem System Energie zuführen

1. Auswahl der externen Umgebung

Nicht nur der physischen Umgebung

In welcher Branche arbeiten wir
Der Ansatz der Firma zu Innovation
An welchen Projekten arbeiten wir und wie vielen werden in die Organisation eingeführt
Erwartungen über Multitasking und Fokussierung

2. Definieren von Performance

Die Merkmale, die uns helfen zu überleben, werden tendenziell beibehalten

Manager und Leiter senden Signale, welche Merkmale beibehalten werden sollten

Welche Signale schickt Ihre Organisation über die relative Wichtigkeit von kurz- und langfristiger Performance?

Welche Signale werden geschickt, wenn

Trainings angeboten werden
Arbeit in nachhaltiger Geschwindigkeit möglich ist
Beschäftigte haben Zeit, wilde Ideen auszuprobieren
Einhalten einer Deadline ist nicht wichtiger als unpflegbarer Code

3. Managen von Bedeutung

Individuen in einem komplexen System reagieren auf Signale

Bienen reagieren auf „Gefahr“-Signale

Leiter können Signale in das System senden

Z.B. das Team in Kontakt mit dem Kunden bringen

... oder Signale heraushalten

Bedeutung entsteht oft aus Geschichten, Ritualen und Mythen, die erzählt werden

„Wir werden dieses Jahr profitabel“
„Unser GF kontrolliert jeden morgen um 6h, welche Autos schon da sind“

4. Auswahl von Personen

Wer Mitglied eines Teams ist, beeinflusst natürlich dessen Selbstorganisation

Anpassen von Teamgröße, Arbeitsort, Hintergrund, Erfahrung, Skepsis, Entscheidungsfindung, Geschlecht, Motivation, ...
Manche Personen wirken wie Klebstoff aus den Zusammenhalt des Teams

5. Rekonfigurieren des Netzwerks

Kommunikationswege können wichtiger als die konkreten Individuen sein

Formal
Informell

Man kann neue Informationsflüssen einführen oder ausschliessen

Andere Teams, Teameinteilung
Experten
Kunden

6. Entwicklung zielgerichteter Selektionssysteme

Variation, Selektion, Beibehalten

Warten bis der Markt wirkt, dauert zu lange und ist riskant

Firmen entwickeln zielgerichtete Selektionssysteme

Vergütungssysteme
Retrospektiven
Googles 20-Prozent-Regelung

7. Energie zuführen

Wenn ein System keine zusätzliche Energie erhält, setzt die Entropie ein

Stelle sicher, daß das Team ein klares positives Ziel hat

Motivation

Team Chartering, Sichtbare Vision, Presse-Releases diskutieren, Elevator Statement

Gelegenheiten

Lernen, wichtige Rolle im Unternehmen, in noch bessere Projekten arbeiten

Information

Kundenbesuche, Training, Konferenzen

Bei der Vorbereitung auf mein Seminar "Selbstorgansierte Teams coachen" bin ich wieder auf einen Satz von Vorträgen von Mike Cohn gestossen. Daher habe ich meine Idee zur Zusammenstellung dieser Beschreibung.

XPDays Germany - Lehren über das Entwicklungsteam

krishan — Sat, 28 Nov 2009 23:00:00 +0000

Den Titel des Vortrags hatte ich auf den letzten Drücker geändert in : Das Agile Team - Skills, Arbeitsweise, Umgebung.

Vorher war er "Rechte und Pflichten des agilen Teams". Ich wollte den Fokus schärfen und habe mir zum Teil ein kontroverses Feedback eingefangen. Manche Teilnehmer dachten, dass ich das Thema geändert hätte; und was hinzukommt war, dass ich das Thema wesentlich breiter fasse als viele der Vorträge vorher. Das war wohl auch eine Überraschung und manchmal ein Schock.

Ich glaube aber, dass wir Agilisten und keinen Gefallen tun, wenn wir agil auf einen Satz technischer Tricks reduzieren. Agil braucht, um zu leben, auch eine Haltung, eine Kultur und Werte. Und daraus ergibt sich dann auch ein wesentlich breiterer Bereich von Anforderungen an die Teammitglieder als die, effizientere Codierknechte zu sein.

So weit der Rundschlag.

Was ich beibehalte: der Fokus für Developer Skills ist breiter als man initial denkt. Ich beziehe mich dabei auf die Formulierung der "7 pillars", die einen ganz guten Ausgangspunkt für die Diskussion bietet. Was ich ändern werde: ich werde nicht mehr so stark darauf vertrauen, dass das ein Konsens zwischen allen ist, die am agilen Diskurs teilnehmen und stärker diese Grundlage propagieren.

Das Agile Skills Project

krishan — Fri, 16 Oct 2009 14:10:00 +0000

Das ist der Name, den wir im "Agile Skills Developer Workshop" zusammengebraut haben. Es war ein dreitägiger Workshop in Ann Arbor, den Ron Jeffries und Chet Hendrickson veranstaltet haben und "wir" in diesem Zusammenhang sind die 14 Teilnehmer. Den Fortgang der Diskussionen konnte man schon in dem (etwas ironischen) Twitter-Tag #adswsummit verfolgen. Die Themen, die wir bearbeitet haben, sind im Wesentlichen

Eine Bestandsaufnahme (inventory) agiler Kenntnisse und Fähigkeiten. Was ist nötig, um ein "gutes" Mitglied eines agilen Teams zu sein. Als Referenz für die Strukturierung dient erstmal der Entwurf der 7 Pillars. Darauf aufbauend wird es sicher Spezialisierungen für Technologien und für Rollen geben. Wie sollte dies zur Verfügung stehen? Z.B. als Links zu Materialien, Büchern, Kursen oder Online-Materialien.
Die Problematik von Assessment und Zertifizierung. Hier gab es eine ziemlich lebhafte Diskussion, ein Teil der Teilnehmer lehnte jede Zertifizierung ab oder wollte eine solche auch aktiv bekämpfen, ein anderer Teil sah und sieht Zertifizierung als einen notwendigen Service an, den ein Teil der Industrie braucht, um sich auf den Weg zu agiler Entwicklung zu begeben. Das sah für mich zunächst wie ein echtes Problem aus, aber wir kamen zu einer, wie ich finde, ziemlich produktiven Lösung - dazu später mehr.
Daran schliesst sich direkt die Frage an, wer der Nutzniesser dieses Assessment sein soll. Es sollte auf jeden Fall die Möglichkeit offen stehen, dass das Inventory für eine Selbstbewertung nutzbar ist. In diesem Sinn ist es eine Unterstützung der agilen Community für Individuen und Teams, die sich auf diesen Weg machen.
Es sollte eine Möglichkeit geben, verschiedene Stufen von Kenntnissen zu identifizieren. Ein Vorschlag ist:
- Understood – exposed to (e.g. read a book about it)
- Attempted (could lead to self assessment)
- Did it (could lead to 3rd party assessment)
- Improved my understanding
- Improved others understanding
- Improved the state of the art
Zusammen mit den "7 Pillars" gibt das eine äußerst interessante Matrix, in der man sowohl individuellen Kenntnisstand (oder eine Beschreibung des Erfahrungsstands), ein Team, einen Kurs, ein Trainingsprogramm oder eine Zertifizierung einordnen kann.

Das halte ich für ein sehr schönes Ergebnis. Darauf aufbauend haben wir konkret diskutiert, was die nächsten Schritte sind, diese Ideen umzusetzen. Wir arbeiten an einem Vision Statement und an einer ersten Website. Das Ergebnis wird offen sein für Mitgliedschaft und die Ergebnisse werden unter einer Creative Commons-Lizenz zur Verfügung stehen. Es soll ein lebender Satz von Dokumenten werden (deshalb "project" und nicht sowas wie "Manifest"). Ich hängen mich jetzt aus dem Fenster und sage, dass diese Initiative ziemlich wichtig für die agile community werden kann, deshalb bleib dran: demnächst mehr, ich muss jetzt erstmal zum Flieger und dann zum Scrum Gathering.

Clean code and the Scrum roots

krishan — Fri, 09 Oct 2009 07:10:09 +0000

he recent discussion in the Scrum alliance about developer qualifications guided also my focus to the root goal of Scrum:

Consistently and reliably convert requirements into potentially shippable product increments.

In the last weeks I followed some of the discussions in the Scrum Alliance and elsewhere, namely in http://groups.google.com/group/agile-developer-skills and others - I will write more about this topic in the next time.

I chose deliberately not to focus on my opinion to the quarrel aspect - as you may know, Ken Schwaber founded a new firm (scrum.org) in which he plans to offer assessments and you can read a lucid and very personal comment on this of Tobias Mayer: http://agileanarchy.wordpress.com/2009/10/06/ken-and-the-scrum-alliance/ .

For me, the fascinating point is that there seems to be a growing sense of urgency in the Scrum Alliance and the Agile community to develop an integrated view of the Scrum techniques and agile engineering.

As a develper and practising coach, this in itself is not a surprise to me. In fact, I keep telling my teams that making Scrum sustainable without agile development practices is difficult at best.

While preparing my speech for the XPDays, I am brooding over the question how to help the team members to develop their skills. There are several aspect to it, but a necessary element is to make it easier and more rewarding to practice self-improvement in the team.

There is an extremely interesting approach invented by Stefan Lieser and Ralph Westphal (http://clean-code-developer.de/). It includes a few fundamental values and a set of clean-code-developer (CCD-) levels. Developers are expected to cycle through the levels, which focus on different principles and practices. The levels have each a different color and developers can make their current focus of self-improvement visible by wearing a writband in that color.

Agile Leadership - meine Leseliste zum AgileTuesday

krishan — Wed, 09 Sep 2009 07:09:09 +0000

Ich schreibe hier mal die Leseliste auf, die ich gestern auf unserem Münchner Stammtisch AgileTuesday vorgestellt habe. Wir hatte uns das Thema Agile Leadership ausgesucht.

Wenn man in die Lage kommt - und nur darüber lesen will, was Agile Leadership für jemanden bedeutet, der zum ersten Mal Leitungsfunktionen übernimmt, kann man starten mit
First Among Equals - How to manage a group of professionals
von Patrick McKenna und David H. Maister.

Die Autoren beraten "professional service" Firmen und nehmen das Wort agil nicht in den Mund. Stattdessen geben sie einen guten Einstieg darüber

Was sich für jemanden ändert, wenn er eine Leitungsfunktion bekommt
Was er für seine Rolle und seine Aufgabenbeschreibung explizit klären muss,um nicht in kürzester Zeit in Seenot zu geraten
Dass er in erster Linie mit Individuen zu tun hat und diese coachen muss
Und was darüber hinaus zu tun ist, damit ein Team entsteht, das einen gemeinsamen Fokus hat

Dann ist in letzter Zeit noch erschienen - und wird diskutiert:
Stand back and deliver - Accelerating business agility von Pollyanna Pixton et al.

Da steht zwar agil im Titel, mir hat das Buch aber weniger gegeben. Die Autoren verzetteln sich zum Teil mit der Darstellung von Allgemeinplätzen wie den verschiedenen Differenzierungsmöglichkeiten von Firmen und gehen dann mit einem Nebensatz darauf ein, dass man das auch bei der Priorisierung von Projekten verwenden könnte.

Was für mich noch immer der Hit ist:
Behind closed doors - Secrets of great management von Johanna Rothman und Esther Derby

Das Buch ist gnadenlos praktisch und gibt unvergleichlich gute Ratschläge, wenn man "plötzlich" eine Gruppe leiten muss. Die Autorinnen sind auch nicht zuletzt sehr profilierte agile Praktikerinnen. Esther Derby kennen wir alle von ihrem Buch über Retrospektiven und Johanna Rothman war jetzt bei der Agile 2009 - Konferenz in Chicago die Vorsitzende des Programmkommitees.

Wenn ich den Hut wechsle und mich als Change Agent sehe, stehen für mich neben den Rollenildern, die in den obigen Büchern vermittelt werden auch im Mittelpunkt, wie ich Impulse in eine Organisation trage.

Die Patternsammlung darüber, was funktioniert und was ziemlich wahrscheinlich in die Hose geht, findet sich in
Fearless Change - Patterns for Introducing new Ideas von Mary Lynn Manns und Linda Rising

Ein Beispiel sind die Beschreibung verschiedener prototypischer Rollen wie der "Evangelist" oder der "early Adopter" und was die

Aktionsmuster dieser Rollen sind. So ist z.B. ein Mitglied der "early Majority" nur darüber für etwas zu motivieren, dass die Kollegen es auch machen und niemals nicht darüber, dass etwas hip ist. Wenn man solche Sachen berücksichtigt, kann man eine Menge verschwendeten Atem sparen.

Was war noch - ach ja, nur fürs Protokoll:
The fifth Discipline - The art and Practice of the learning organization von Peter Senge

für den das Wort Klassiker erfunden wurde, und
Facilitating Organization Change - Lessons from complexity science von Edwin Olson und Glenda Eoyang

für jemanden, der tiefer in die Zusammenhänge einsteigen will, warum es nicht ganz so einfach ist, das Verhalten von Organisationen zu verändern.

Zerbrochene Fenster im Projekt

krishan — Mon, 20 Jun 2011 18:06:00 +0000

Kennen Sie die Theorie vom zerbrochenen Fenster, die „broken window theory“? Sie kommt ursprünglich aus den USA und versucht die Frage zu beantworten, warum man- che leer stehenden Gebäude innerhalb kürzester Zeit verwahrlosen und andere nicht. Die überraschende Erkenntnis: Oft fängt es mit einem zerbrochenen Fenster an. Wird das nicht umgehend repariert, werden die Menschen bald weitere Fenster einschlagen, Müll in dem Haus abladen und es in kurzer Zeit in eine Ruine verwandeln. Ob deshalb die „Null-Toleranz-Politik“, die auf dieser Erkenntnis fußt und schon für Bagatelldelikte heftige Strafen vorsieht, tatsächlich eine gute Idee ist, daran scheiden sich die Geister. Doch für agile Entwicklerteams steckt in dieser Theorie eine absolut berechtigte Aufforderung: Wehret den Anfängen, sonst geht in atemberaubendem Tempo die Moral den Bach hinunter! Was sind zerbrochene Fensterin einem Projekt? Zum Beispiel

Offene Bugs
Nicht abgeschlossene Stories
Nicht refakturierter, schlecht strukturierter Code
Auskommentierte Codefragmente
Nicht aufgelöste Wissensmonopole
FehlendeAnwenderdokumentation
Ausgefallene Daily Scrums
Ausgefallene Retrospektiven
Demonstrationen unfertiger Stories im Sprint Review

Lassen wir also in unseren Projekten keine „zerbrochenen Fenster“ zu.

Debugging SAFe

ugurakin

improuv zu Gast auf der Agile Tour Lux

christian-braun — Tue, 01 Aug 2023 16:00:17 +0000

Sacha Storz und Laura Deo reisen nach Luxembourg zur Agile Tour Lux und wir freuen uns schon sehr auf Networking und Austausch außerhalb unserer gewohnten regionalen Bubble.

Hier findest du mehr Infos.

Agile Tue

christian-braun

Agile Organisation: Regelmäßig liefern reicht nicht

jens — Mon, 19 May 2014 17:05:00 +0000

„Wir sind ja auch agil, wir haben ja auch ein Team, das dieses SCRUM macht! Wofür steht die Abkürzung eigentlich?...“ Wer sich auf Konferenzen und Netzwerktreffen als agiler Coach outet, kennt diesen Satz zur Genüge. Und er weiß auch, dass der Satz ein Oxymoron ist, ein Widerspruch in sich: Nur weil irgendwo in der Organisation ein Team den Mut und die Kraft gefunden hat, sich gegen etablierte Managementansätze abzukapseln und Scrum zu machen (und hoffentlich weiß, dass das keine Abkürzung ist), ist die Organisation noch lange nicht agil. Aber was macht denn nun eine agile Organisation aus?

Vorweg: Dazu gibt es keine allgemein etablierte Definition. In unserem Coaching-Alltag hat sich allerdings eine Sicht herausgebildet, die fünf Ebenen einer agilen Organisation differenziert (wir haben der Versuchung widerstanden, das „Reifegrade“ zu nennen ;-).

Die erste Ebene nennen wir „Agile Delivery“. Sie beschreibt die Fähigkeit eines Teams, wertschöpfende, qualitativ hochwertige Software in kurzen Zyklen in Produktion zu setzen und systematisch aus den Erfahrungen zu lernen. Hier spielen Ansätze wie Scrum, XP, agile Entwicklungstechniken oder Kanban eine wichtige Rolle.

Die zweite Ebene ist „Agile Scaling“, also die Fähigkeit mehrerer Teams, koordiniert wertschöpfende, qualitativ hochwertige Software in kurzen Zyklen ausliefern zu können und gemeinsam systematisch voneinander zu lernen. Je nach Anzahl der Teams kommen hier leichtgewichtige Ansätze wie Communities of Practice in Frage, aber auch „schwerere Geschütze“ wie Portfolio Kanban bis hin zu Frameworks wie SAFe.

Die nächste Ebene ist „Agile Business“, also die Fähigkeit des Unternehmens, die Agilität ihrer Entwicklungsmannschaft in Marktpotenzial umzusetzen. Auf dieser Ebene geht es plötzlich nicht mehr (nur) um „ein bisschen“ Produktivitäts- und Qualitätsgewinn, sondern um ein anderes Agieren am Markt. Hier wird die Luft an „vorgefertigten Frameworks“ langsam dünner. Die Ideen von Lean Startups und evolutionärer Produktentwicklung gehören hier sicher zum Standardrepertoire, aber auch klassische Wettbewerbslehre.

Als vierte Ebene sehen wir das „Agile Management“. Hier geht es darum, das tayloristische Erbe des „heroischen Managements“ abzuschütteln und den Manager nicht mehr als den „Macher“ zu verstehen, der dafür sorgt, dass seine schlecht qualifizierten „Untergebenen“ ihre Arbeit machen. Stattdessen versteht sich ein agiler Manager als „Katalysator“ (danke an Bill Joiner für die Metapher!), der eine hochqualifizierte Mannschaft aufbaut und ihr ermöglicht, hervorragende Leistungen zu bringen. Agile Manager fordern Retrospektiven ein und beweinen nicht die vermeintlich „unproduktive“ Zeit. Laut Joiner ist ein solcher „post-heroischer“ Managementansatz vor allem mit einer Managementtugend eng korreliert: Mit der Fähigkeit des Managers zur Selbstreflektion. Aber auch Werkzeuge wie Delegationslevel oder Real Options und systemische Modelle wie Human Systems Dynamics sind hier hilfreich.

Auf fünfter Ebene findet sich schließlich die „Agile Organisation“. In diesen Organisationen haben alle Managementebenen die Idee der lernenden Organisation verinnerlicht. Sie verstehen ihr Unternehmen als ein auf Feedback basierendes komplexes System, das sich durch Experimente und offene Kommunikationsformen weiter entwickelt und durch solides Handwerk und ergebnisorientierte Controllingwerkzeuge seinen Auftrag erfüllt. Wirklich agile Organisationen gibt es bisher nur wenige am Markt und entsprechend wenig Erfahrungen oder gar Frameworks. Zu den interessantesten Ansätzen zählt hier sicherlich die Beyond Budgeting Bewegung auf Seite des Controllings und neue Führungsansätze.

Auch wenn viele Organisationen diese Ebenen in der Regel von „unten nach oben“ ausprägen, muss sie doch vom Beginn weg an allen Ebenen gearbeitet werden. In der Regel kommen nur kleine Startups komplett ohne Scaling Ansätze aus (es muss ja nicht gleich SAFe sein). Wenn das Business in Form des Product Owners nicht versteht, was er an einem agilen Team hat, wird sich die Einführung nur schwerlich rechnen. Auch das enthusiastischste agile Team wird irgendwann entnervt aufgeben und in der Regel kündigen, wenn das Management jede Retrospektive als Verschwendung ansieht und die Organisation muss der „agilen Insel“ zumindest ausreichend Freiraum lassen, um wenigstens vom Standardvorgehen abzuweichen. Wenn Transitionen scheitern, dann oft an der fehlenden Bereitschaft des Managements, die eigenen (Vor-)Urteile und Modelle zu hinterfragen und sich aus der „Macher-Attitüde“ zu befreien.

Ein gutes Coaching setzt daher auf allen diesen Ebenen an. Nicht gleichzeitig und nicht auf allen Ebenen in gleicher Intensität, aber der Coach muss alle diese Ebenen berücksichtigen und jeweils dort ansetzen, wo sich aktuell die besten Hebel versprechen.

The French Connection - a business model and prioritization workshop

stuart — Mon, 19 May 2014 17:05:14 +0000

Last week I had the pleasure of helping a client, IGO SAS, define their business model and prioritize their epics (high level features) for development, allowing them to be able to better explain to investors how they plan to spend "new" money to release value (and start making money for the investors). With the premission of IGO, I´d like to share some feedback from our workshop.

Paris-based IGO develop innovative 3D production and visualization tools for spatial information management markets (such as public administration, risk management, defense) and have developed a unique HTML5 / WebGL visualization tool that helps clients build and publish services across the web. IGO have a good project business but wish to enter a larger global "big 3D data" visualization market with their browser-based HTML5 platform. And to do that they need external investment.

The reason IGO seek support from improuv is:

they are entering a new round of funding but don´t have a clear focus on their business model & vision
they have crucial (money earning) projects running that suck resources from their product development initiatives
they have a range of “must have” core product ideas (epics) and they know (even with funding) that they can´t do them all

We agreed a 1-day workshop to help IGO clarify their product offering and markets and create some focus. Participating in the workshop were the CEO, CTO and head of business development.

The core “tools” used were:

Business Model Canvas (BMC)
Value Proposition Canvas (VPC)
Economic Prioritization

And this is how it went….

Business Model Canvas – getting the business visualized

The business model canvas (ref: http://www.businessmodelgeneration.com/canvas) is a great tool to help visualize your current business (model) and allow you to test different alternatives. Its nice and simple and, for me the most important feature, it promotes a great deal of useful discussion and insight. Using a large blank canvas on the wall, we dug into the core elements of the IGO business and iterated a few alternatives. The session led to deeper insight into the core business model and brought out a need to create a a new product concept that would be better understood in the target markets.

Outcome: agreed business model and common understanding.

Value Proposition Canvas - what value do we really deliver to customers?

A BMC is great for giving an overview of your business and for testing different scenarios. However in our case we needed to dig deeper to check that IGO are truly developing products that meet the needs and expectations of their target market segments. To visualise this we used a Value Proposition Canvas (ref: http://www.businessmodelgeneration.com/downloads/value_proposition_canvas.pdf).

We did this once for the most valuable market segment. Creating the VPC led to a great deal of discussion and debate - what do customers "really" want? what are the pains that can be relieved?, what tasks to they perform? what gains are they looking for, and/or could be delighted by? How does the product offering meet these needs & expecations? what could be the minimum viable product? This session brought out core new insight about the offering, market segments and geographic markets, and led to a new definition (and bundling) of the core product offering.

Outcome: deeper understanding of the market segment needs and new definition of core product offering.

Economic Prioritisation - releasing value faster

Armed with a clearer understanding of the core business, value proposition and product proposition, the next step was to review the high level development initiatives (epics) and prioritise these based upon economic value (to remove the "all are must have" way of thinking). IGO have already defined the core epics that need to enter development to take their product to the next level. However they have experienced difficulty in determining what should be developed and when - often with the result that development is blocked at 100% capacity as numerous "must have" projects enter development and overload the system. To determine an economic prioritisation we borrowed a tool from Lean: Cost of Delay and Weighted Shorted Job First:

Cost of Delay (CoD) = relative value + relative time sensitvity + relative risk reduction/opportunity enablement

Weighted Shorted Job First (WSJF) = Cost of Delay / relative effort

To make this clearer we can take a look at what we did:

Preparation:

list core epics on post-its (you can also do this with features)
place sizing buckets as stickies on the wall (3,5,8,13,20)

Execution:

Value: as a group (CEO, CTO, Sales) place epics on the wall within a "bucket" denoting the relative size in Value (monetray value, value to Brand etc.) in comparison to the other epics. After much discussion, the final order was agreed and the relative Value noted. (not "actual € value", but "is this epic more/less/same value than the other epics assessed so far?").

Time: repeat as per value. This time, however, the group considered how sensitive each epic was to time (e.g. if we release the epic late, or early, do we get more/less value? - there were clear cases where epics released "late" to the market would have significantly less value than if released early).

Risk/Opportunity: Again, the group reordered the epics to reflect the relative amount of risk each epic removes/addresses, or the new opportunities they might open up.

Level of Effort: finally, the group (led by the CTO) estimated the relative level of effort (work/resources) required to bring each epic to the market.

With values recorded for each of these areas, we then calulated the CoD and WSJF for the Epcis and listed them in decending order (by WSJF). WSJF gives a numeric value that means "from an economic standpoint, higher numbers should be released to the market sooner".

The results partly surprised IGO and, after discussion, they found the prioritization extremely beneficial. IGO liked the discussion it promoted and agreed in the overall prioritization - especially as it focused on releasing value faster through a couple of Epics that have tended to be lower prioritsied by the CTO/technical team (but, in fact, bring a quicker value win that will keep investors happy and build a customer base).

Wrap-Up

The final step was to look at the investment "ask" (the target € for the current investment round) and estimate how far down the priority list they can get with 1/3, 2/3 all funding. This estimation allows them to structure the discussion with investors around how much they can achieve at different levels of funding committment.

IGO found the day extremely beneficial and helped then clarifiy their business model and where they need to prioritise their develeopment. As is typical with a French customer, we then headed out for some "de-briefing" on a sunny terrace.... :)

I hope this provides some insight around how these tools can be used in real life. If you want support in creating a similar learning experience then call us and we will be more than happy to organise a workshop.

Philippe, the CTO, relaxing into a Pastis at the end of the day....

Intrinsic Motivation – what is it and how do I get there? - part II

hedi.buchner — Mon, 10 Feb 2014 09:02:00 +0000

In my first blog on intrinsic motivation I talked about the self-determination theory: you need to satisfy the basic human needs for competence, relatedness and autonomy to be intrinsically motivated. In this blog I will introduce the Job Characteristic Model.

Autonomy plays a key role in another model that focuses on motivating people through an optimal design of jobs: the Job Characteristic Model by Hackman and Oldham (1976). They define five core dimensions of work, that lead to psychological states which lead to higher motivation on the job.

The idea is, that it is motivating for a person, if she knows (knowledge of the actual results of the work activities) that she did a good job (experienced responsibility for outcomes of the work) that is important to her (experienced meaningfulness of the work). This positive feedback is motivating to do the best job possible in the future as well.

In order to get to these states a job needs to fulfill five characteristics. I will map them to Scrum in order to highlight, how Scrum can be used to increase motivation:

Skill variety: In order to get the job done, you need to use different skills and knowledge.

In Scrum this is implemented through the cross-functional team setup. The team is responsible for the development of the entire product which involves all kinds of different skills: concept, architecture, design, implementation and testing. A team member should be a T-Shaped person. Next to the technical skills each team member needs social and communication skills .

Task identity: This means that you work the whole work package: from start till the end.

In Scrum this concept can be found in the format of user stories. Within one sprint the team develops a feature or a functional part of a feature that in the end can be presented to the customer.

Task significance: Which consequences do your work results have for the lives of others ? Either within the company or your customers.

In Scrum the most important feedback mechanism to support task significance is the review meeting and close collaboration with the customer in general.

Autonomy: How much freedom does a person have concerning the way the work is planned and done? The higher the autonomy, the more the work results depend on the worker. This leads to higher responsibility.

In Scrum the self-organizing development team is responsible for planning and development. It owns its process and can decide on improvements in retrospectives.

Feedback: Can you get proper feedback on your work performance?

In Scrum there are several feedback loops: the daily, the integration of quality within the sprint gives immediate feedback on the quality of you work, review meetings and retrospective meetings.

There are additional, individual factors that do influence your work motivation: Do you have enough knowledge and skills to perform the job? How big is your desire for growth on the job? Are you satisfied with your environment like payment, co-workers, managers, etc.?

These environment factors play an important role in yet another theory on motivation: in Herzberg’s ‘Two-factor theory’. I will talk about it in my next blog.

OOP Vortrag „Mit dem Hammer auf die Schraube - Wenn Produkte wie Projekte behandelt werden“

jens — Mon, 27 Jan 2014 23:00:00 +0000

Eigentlich geht es in dem Vortrag gar nicht um Agilität, sondern ganz allgemein um IT Management. Ich starte von typischen Problemen, die wir im Beratungsalltag immer wieder sehen: Die Architektur eines Systems ist aus dem Ruder gelaufen, man sieht sich nicht in der Lage, einen Product Owner zu benennen oder jede Entwicklungsaktivität muss direkt an einen Kunden kontierbar sein. In diesem Vortrag entwickle ich die Hypothese, dass alle diese Probleme letztlich Symptome ein und desselben Grundproblems sind: Projektmanagement als dem bestimmenden Organisationsparadigma in der Softwareentwicklung. Projektmanagement also als Teil des Problems, nicht der Lösung?

Das ist eine provokante These. Unterstützung erfährt sie aus der Theorie endlicher und unendlicher Spiele. Mit ihr kann man recht schlüssig erklären, dass Projektmanagement Strategien aus endlichen Spielen einsetzt, um das unendliche Spiel „mit einem Softwaresystem Geld verdienen“ zu spielen. Solche Strategien führen zu eben den typischen Problemen, die wir in der täglichen Arbeit sehen. Zum Glück zeigt uns die Theorie aber auch Strategien für unendliche Spiele, die sich gut auf das Management von Softwareentwicklung übertragen lassen und für die ich ein grobes Modell skizziere.

Wenn Sie neugierig geworden sind, besuchen Sie den Vortrag am Donnerstag 6.2. von 17:00-18:00 auf der OOP in München. Weitere Infos finden Sie auf der OOP Webseite

Intrinsic Motivation – what is it and how do I get there? - part I

hedi.buchner — Thu, 23 Jan 2014 22:01:00 +0000

I’m sure you’ve heard about intrinsic motivation. But what is it? And how can I facilitate it at work?

Pierluigi talks in his blog about motivational coaching (not recommended) and trying to get intrinsic motivation instead. I will present some theories on motivation and how to apply them to facilitate motivation at work in the following blog entries.

Have you read ‘Drive: The surprising thruth about what motivates us’ by Daniel Pink? He writes about the self-determination theory by Edward L. Deci and Richard M. Ryan. It explains how to stimulate intrinsic motivation and how it is related to extrinsic motivation.

Intrinsic motivation means that somebody performs an activity because he enjoys it and it is interesting without getting any external reward.

Extrinsic motivation on the other hand means that the motivation to do some activity comes from receiving tangible rewards, like money or status, or verbal rewards.

Whoever wants to stimulate intrinsic motivation, foster human development and maintain psychological health needs to fulfill the human basic needs for Autonomy, Competence and Social Relatedness/ Purpose.

It has also been shown that tangible extrinsic rewards like money or bonuses, deadlines, threats and competition pressure for an activity undermine intrinsic motivation. We seem to experience this kind of external influences as controllers. They naturally reduce our perceived degree of autonomy.

Yet positive feedback, also an extrinsic reward, enhances intrinsic motivation as it increases both how we perceive our degree of mastery and competence and gives us positive input for our feeling of social relatedness ⁽¹⁾.

In the world of work, as we all know, it is unrealistic to expect everybody to be intrinsically motivated all the time. So Leci and Ryan and a couple of other researcher further investigated on how to use extrinsic motivation and make it more autonomous and self-directed. The idea is that motivation goes along a spectrum of relative autonomy ⁽²⁾.

So the interesting question now is, how do we get to the right end of the spectrum? Not all work related task are per se intrinsically motivating for people. So what can we do, to facilitate internalization?

First, it seems to help if we feel connected to the persons, groups and cultures in which we perform some activity. This relates to the basic need of relatedness.

Do you know that feeling? Although you are not very fond of a task, as long as you do it with your favorite colleague it turns out to be fun?

Second, we are more likely to adopt, or introject, an extrinsic goal if we feel competent enough to achieve it. This relates to the basic need of competence.

Trainings are not my favorite work to do. Yet, if I get enough support from my colleagues and time to prepare them properly, it turns out to be a challenge that I know I can win.

Third, and most important, only if we feel autonomy and self-determination we will integrate the goal. In order to reach that state we must inwardly grasp the meaning and worth of the task at hand.

Writing blogs – definitely nothing I intrinsically enjoy ;) I usually postpone it as long as possible. But from the moment I have chosen a topic I have been thinking about for a while I really enjoy it: I do my research (which I love doing), learn stuff and finally manage to condense it down to a single blog entry. All in my own pace, for the topic I am currently most interested in.

Think about it: what can you do to increase relatedness, competence and autonomy for your co-workers? It might be an unrealistic goal to achieve that everybody is intrinsically motivated but there are means to make work more intrinsically rewarding for them.

⁽¹⁾ Edward L. Deci (1971), Effects of Externally Mediated Rewards on Intrinsic Motivation. Journal of Personality and Social Psychology, Vol. 18, No. 1, 105 - 115

⁽²⁾ Richard M. Ryan and Edward L. Deci (2000),Intrinsic and Extrinsic Motivations: Classic Definitions and New Directions. Contemporary Educational Psychology 25, 54–67

HIP Sprints bei SAFe und spezialisierte Sprints bei Scrum

krishan — Mon, 18 Nov 2013 17:11:13 +0000

Eine der hitzig diskutierten Aspekte des SAFe (Scaled Agile Framework) sind die speziaisierten HIP Sprints. HIP steht hier für Hardening, Innovation und Planning. In früheren Versionen von SAFe wurde diese noch also Hardening Sprints bezeichnet.

In Scrum-Implementierungen betrachten wir die Notwendigkeit einer Stabilisierungsphase normalerweise mit einer gehörigen Prise an Misstrauen – fast immer geht diese nämlich mit einer schlechten Codebasis und suboptimalen Entwicklungspraktiken einher. Daher haben diese Hardening-Sprints auch eine recht scharfe Reaktion in der Scrum – Community hervorgerufen (auch von mir).

Jetzt habe ich festgestellt, dass dieser Kritikpunkt sich zumindest relativiert hat – das gilt für mich nicht nur wegen der Umbenennung

In einer großen Entwicklung muss das einzelne Scrum-Team eine höhere Planungssicherheit garantieren als in einer autonomen Umgebung. Planungssicherheit muss man sich durch einen Puffer erkaufen. Das ist der erste Einsatzzweck für den HIP-Sprint.
Alle Scrum Teams sind an einer Grobplanung der Kadenz von 3-4 Monaten beteiligt und definieren dabei „objectives“, d.h. Ziele, die sie als erreichbar betrachten und „stretch objectives“, das heißt Dinge, die nur bei optimalen Bedingungen erreicht werden. Die Scrum Teams bereiten sich auf dieses große gemeinsame Planungsmeeting vor, das ist das zweite Ziel des HIP Sprint
Drittens ist der HIP Sprint der Zeitraum, in dem Experimente, Lernaktivitäten und ähnliches durchgeführt werden – übergreifend: Innovation. Wenn das Team die beiden anderen Aktivitäten erledigt hat, ist dies die eingebaute Belohnung für eine effektive und gut geplante Arbeit.

Wenn man zurück auf das reine Scrum geht, bleibt eines gleich: die Notwendigkeit von Stabilisierungs-Sprints deutet auf Schwächen in den vorigen Sprints hin: das Ergebnis eines Sprints soll Software in auslieferfähiger Qualität sein.

Allerdings werden in Scrum seit jeher ebenfalls spezielle Sprints diskutiert (und zum Teil heftig umstritten):

Sprint 0 für eine initiale Planung, evtl. auch für eine Kalibirierung der zu erwartenden Velocity
Von einem Product Owner wird erwartet, dass er die Backlog Items so zusammenstellt, dass sich daraus benennbare Inkremente für die Sprints benennen lassen – wenn man es genau betrachtet sind dies ebenfalls spezialisierte Sprints.

How can we learn how to learn?

hedi.buchner — Thu, 24 Oct 2013 22:00:00 +0000

Whenever I am working as a Scrum Master or Coach one of my goals is to help the team to learn how to help themselves. To achieve that, they really need to learn how to learn. But how does it work? One approach is based on the self-management theory by Kanfer, Reinecker and Schmelzer⁽¹⁾. The original approach is a therapeutic process which can be modified for our use. Its goal is to support self regulation and enhance problem solving skills. The coaching approach consists of three phases.

1. Observation

This includes both observation of oneself and feedback from others. Self observation usually kicks in when the coachee is not happy with the way she acted and at the same time is convinced to be able to influence the results. Feedback from the coach can help to merge the outside view and the coachees perceived reality. Coaching questions:

How do you feel?
How do you think the others perceived the situation?
Could you have done anything to avoid the escalation/ influence the situation on beforehand?

2. Evaluation

In the next step the coachee needs to evaluate the importance of the situation and the reaction to the situation. As well it is important to evaluate the influence of these feelings on the coachee. Coaching questions:

Is your evaluation justified? Was the situation really that disastrous?
How do you feel with this evaluation?
Does your evaluation affect (limit or broaden) your options for action?

3. Consequences

In this phase consequences and more possibilities of action are created. Coaching questions:

How would you like to act in the future in a similar situation?
Which conditions could make it difficult to act in the new way?
What will you do if you act in the same way as before?

Do these steps sound familiar? Then keep applying them and make sure next time you explain them to your coachee or team. That will enable them to apply them even without your help.

⁽¹⁾Kanfer, F. H. & Reinecker, H. & Schmelzer, D. (1996; 2. Aufl.): Selbstmanagementtherapie. Berlin

Skalieren ohne Kompromisse

krishan — Sun, 29 Sep 2013 22:00:00 +0000

oder: Culture > Process, culture eats process for breakfast

Dieser Blog ist der Beginn einer Serie, in der die verschiedenen Probleme und Ansätze der Skalierung agiler Methoden beleuchtet wird.

Henrik Kniberg hat auf dem Scrum Gathering in Paris eine sehr inspirierende Keynote (hier die Slides): er berichtete über die Erfolgsgeschichte von Spotify.

Spotifiy ist einer der wichtigen Musik-Streaming Provider und Henrik Kniberg ist einer der profiliertesten Scrum Trainer.

Henrik hat die Erfolgsgeschichte von Spotify mit verschiedenen anderen Erfahrungen in Beziehung gesetzt, bei denen jeweils riesige Geldbeträge „verbrannt“ wurden und hat einige überraschende Entscheidungen von Spotify aufgezeigt.

Zunächst zum Skalierungsmodell: Die Belegschaft von Spotify wächst jährlich um 100 Prozent pro Jahr und es sind zur Zeit mehr als 1000 Personen in 28 Ländern. Die übliche Reaktion von Firmen in dieser Situation ist die, dass man einen Teil der agilen Praktiken zurückfährt und versucht, den Overhead durch traditionelles Management zu reduzieren.

Diesen Trend zeigen auch verbreitete Skalierungsframeworks, die in der agilen Scene zur Zeit heiss diskutiert werden wie SAFe (Scaled Agile Delivery von Dean Leffingwell) und DAD (Disciplined Agile Delivery von Scott Ambler). Über diese beiden Frameworks in Kürze mehr.

Das ist erst einmal eine natürliche Reaktion: das Risiko ist hoch und man zieht sich auf „bewährtes“, d.h. auf vertrautes Territorium zurück.

Kniberg und Spotify kommen auf eine völlig andere - und wie ich denke, eine wesentlich überzeugendere - Lösung: sie stellen zunächst die Frage, was die Probleme beim Wachstum verursacht und kommen zu den Themen

Abhängigkeit zwischen Teams
Prozeduren fangen an im Weg zu stehen
Lernen und die Arbeit in der Organisation verbinden
Leadership und Kultur, die enablen, nicht begrenzen

Abhängigkeit und Autonomie

Ein aktiv verfolgtes Ziel ist die Reduzierung von Handovers (Übergaben) und gegenseitigem Warten. Dafür wurden Praktiken entwickelt, bei denen sich

Team-Autonomie: ein Team hat eine sehr hohe Gestaltungsfreiheit für seine Arbeit. Abhängigkeiten (z.B. Über die Codebasis) schränken diese Autonomie drastisch ein. Anstatt an der Autonomieschraube zu drehen, reduziert man aktiv die Abhängigkeiten.
Open Source Prinzip: ein Team darf Code eines anderen Teams kopieren und verändern, wenn es ein Feature nicht rechtzeitig von diesem bekommt
Nur die notwendige Standardisierung: zum Beispiel hat die herausgestellt, dass das Versionsverwaltungstool GIT ganz gut funktioniert, es wird also von „den meisten“ Teams verwendet.

Prozeduren stehen im Weg

Bei der Einführung von Scrum werde ich öfter gefragt, welche Teile von Scrum man einsetzen muss. Meine Antwort ist da normalerweise: alle. Die Teile, die Schmerzen verursachen, decken auch bisherige organisatorische und technische Defizite und Schwächen auf. Wenn die Teams erfolgreich mit Scrum sind, können sie durchaus darüber hinauswachsen. So gehen die Scrum-Prozesse zum Teil in weiter entwickelten Praktiken auf.

Teams werden autonome „Squads“, die sich in „Tribes“ (departments) zusammenfassen. Personen mit gleichen Aufgaben, z.B. Tester, organisieren sich quer dazu in „Guilds“ (communities of practice).

Alles hat das übergreifende Ziel, Abhängigkeiten zu verringern ohne die Zielrichtung zu reduzieren.

Lernen und zielgreichtetes Arbeiten

Die Guilds, Tribes und Squads helfen nicht nur beim unabhängigen Arbeiten, sondern auch beim „alignment“ (alignment enables autonomy) - diese Idee steht im Gegensatz zu den oben genannten Skalierungsansätzen.

Leadership

Voraussetzung für diese Art des selbstbestimmten kreativen Arbeitens ist ein starkes Augenmerk auf eine Kultur, die diese unterstützt und verstärkt. So versteht das Top-Management seine Hauptaufgabe darin, die richtigen Fragen in die Organisation einzubringen.

Die Guilds veranstalten regelmäßige „Un-Konferenzen“, und in den Squads sind Verhaltensweise wie Blaming und Mangel an Respekt vor den Kollegen streng verpönt.

Und die Software?!

Es stellt sich die Frage, wie weit diese Art der Organisation effizient und effektiv ist. Eine Gemeinsamkeit mit anderen Methoden fällt auf: es wird ebenfalls das Modell eines Release Trains verwendet, aber mit sehr wenig Overhead realisiert: Jedes Feature in der Codebasis, das noch nicht fertig ist, kann mit einem „Feature-Toggle“ stillgelegt werden. Es behindert also nicht, dass der Release rechtzeitig ausgeliefert wird. Daher auch das Bild vom Release-Train: der Zug fährt pünktlich ab - Du bist rechtzeitig da oder nicht.

6 reasons NOT to start an Agile Transformation

krishan — Sun, 08 Sep 2013 06:09:00 +0000

In the last years I have seen my share of problematic Scrum and Agile implementations. Some of them hit unforseeable impediments, but many problems are also foreseeable. Often it starts with wrong goals and assumptions. I present some of them. If you know of other patterns, I would be glad to add them to my little collection.

1. Culture, trust

I do not trust my people to be motivated and competent enough - I want to monitor and evaluate in detail the way they work.

Without developing a culture of trust, your agile efforts will fail.

With an agile transformation, you send a message to your teams that you want their commitment, initiative and creativity. You want them to trust their colleagues and to share their knowledge and experience.

If you send simultaneously the opposite message that you want to control them, these messages will be in conflict and you have created a huge impediment not only for an agile transformation, but for your organization as a whole.

2. Mass production

In my organization, we do only routine jobs and mass production

Look in the Lean Thinking area for a solution. You will find a tremendous amount of knowledge which can help you solving your problems.

Agile draws its basic ideas from Lean Thinking. Both are „people systems“ and both focus heavily on continuous improvement and learning. But: Agile has been adopted specifically to innovative and creative work like software development, and solves some problems differently from Lean.

3. Command and control

Command and control: I do not want a team which organizes their work and improvement

OK, you are not in danger to start with agile.

4. I do not want to invest into my people

Good luck.

This can be illustrated with the following episode:

CFO and CTO are talking about their staff.

CFO: imagine, if we educate them and they leave

CTO: imagine, if we do not educate them and they stay.

5. Good Enough

Our current practices are good enough, we do not need continuous improvement.

Congratulations. If your market changes, if new competitors appear, if your monopoly starts to falter, check again.

Make sure you spot the change in time and have still people on noard who are willing to contribute.

6. The other guys on my golf course

The other guys on my golf course do it.

Agile is too much effort to start seriously out of vanity. Let them fail and wait for a better reason.

Wie überzeuge ich klassische Projektmanager von Scrum?

anja.stiedl — Sat, 02 Feb 2013 01:09:00 +0000

Ich kenne die Rolle des Projektmanagements in großen Unternehmen sehr gut, ich war selbst Teil einer solchen Organisation. Seit ich mit Scrum arbeite und Teams bei der Einführung unterstütze, bin ich immer wieder von Neuem irritiert, wie wenig Widerstand Product Owner dem Wunschdenken von Managern nach festen Planungszusagen entgegensetzen. Denn eigentlich entstanden agile Prozesse aus der Erkenntnis, dass Entwicklungsprozesse nicht auf herkömmliche Art planbar sind.

Oft erlebe ich folgendes Szenario: Da gibt es auf der einen Seite das Scrum Team mit dem Product Owner und auf der anderen Seite den Projektmanager, der ein Pflichtenheft weitergibt und dem Product Owner gleichzeitig mitteilt, wann der Liefertermin ist. Dies ist keine Übertreibung!

Es gibt viele Ursachen für dieses Phänomen z.B. ein Festpreis-Auftrag, der vom Vertrieb ausgehandelt wurde, ein Manager, der gewohnt ist, Entscheidungen zu treffen, oder ein Projektmanagement, das tatsächlich an seine Planung glaubt ....
Glücklicherweise konnte ich bei meiner Arbeit oft Product Owner überzeugen, dass es sich lohnt, die Möglichkeiten von Scrum für eine effektivere und effiziente Produktentwicklung zu nutzen und sich nicht als Ausführende einer vorgegebenen Planung zu sehen.

Hier zwei Beispiele:
Stakeholder Management mit Scrum ist dem klassischem Projektmanagement überlegen.
In einem Großunternehmen sollte eine Softwarekette weiterentwickelt werden. Hierfür wurde eine Projektorganisation aus mehreren Teilprojekten und einem externen Dienstleister aufgesetzt. Schon in den ersten Monaten der Analysephase liefen die Meilensteine aus dem Ruder. Im Schatten dieses Projektes habe ich mit einem Teilprojektleiter ein kleines Scrum Projekt aufgesetzt. Er hat die Product Owner Rolle übernommen und mit den direkten Stakeholdern der Software im Scrum Rhythmus die nächsten Features ausgehandelt und in den Review-Meetings präsentiert.

Die Resonanz beim Großunternehmen war enorm, alle lobten die Transparenz, ihr Mitspracherecht und die kontinuierliche Entwicklungsgeschwindigkeit. Trotz aller Erfolge haben wir es nicht geschafft, agile Methoden im gesamten Projekt einzuführen. Die Projektleitung wollte sich nicht dem Risiko aussetzen, wenn das Projekt scheitert und eine „ungewöhnliche“ Methodik eingesetzt zu haben.
Fazit: Das aktive und transparente Stakeholder Management, regelmäßige Priorisierungs- und Review-Meetings mit Stakeholdern, ein transparentes Product Backlog haben einen Teil der Projektorganisation von den Vorteilen agiler Methoden überzeugt. Wir konnten aber nur einen Teilerfolg erzielen.

Scope Management mit Scrum macht das Projekt wieder lieferfähig.
Die Software-Entwicklung eines großen Hardware-Herstellers hatte ihren Entwicklungsprozess auf Scrum umgestellt. Die Product Owner waren aber weiterhin damit konfrontiert, im Rahmen eines übergeordneten Wasserfall-Prozesses feste Funktionalität zu festen Terminen zu liefern. Interessanterweise wurde Scrum eingeführt, um Liefertermine zuverlässiger einzuhalten und die Qualität der Software zu verbessern. Beides wurde in diesem Unternehmen erreicht. Vor der Einführung von Scrum gab es eine illusorische Planung, die Software Teams wussten längst, dass die Planung nicht einzuhalten ist und waren mehr und mehr demoralisiert. Als die ersten Test-Versionen ausgeliefert wurden, fiel die Diskrepanz zwischen Planung und Realität auf und es kam zur Eskalation. Die Lösung war die Einführung von Scrum, aber es dauerte danach noch ein halbes Jahr, um bei Entwicklern und der Produktorganisation Vertrauen wieder zu gewinnen. Die Product Owner konnten aktives Scope-Management mit den Hardware-Projektleitern betreiben. Diese waren glücklich dass die Software-Releases wieder zuverlässiger in Time geliefert wurden. Das Produkt ging ein Jahr später an den Markt als geplant, aber man hatte durch Scrum das Vertrauen, die effektivste Lösung umgesetzt zu haben.
Fazit: Eine ehrliche und vertrauensvolle Zusammenarbeit, die realistische Einschätzung der Entwicklungsgeschwindigkeit und zuverlässige Lieferungen haben zu einer stabilen und effizienten Zusammenarbeit zwischen Produktmanagement und Software-Entwicklung in diesem Projekt geführt.

Vertrauen - was ist das eigentlich?

hedi.buchner — Sat, 09 Feb 2013 01:09:00 +0000

Gespeichert von Hedi Buchner am Mo, 09/02/2013 - 17:15

In der Arbeitswelt sprechen wir oft davon, wie wichtig Vertrauen ist. Aber was ist Vertrauen eigentlich? Und wie bauen wir Vertrauen auf?

„Vertrauen ist der Wille, sich verletzlich zu zeigen“ (1). Jemandem zu vertrauen ist meistens mit einem Risiko für denjenigen verbunden, der vertraut.

Was bestimmt also, ob wir Andere als vertrauenswürdig ansehen? Hierfür sind drei Faktoren ausschlaggebend (2):

Ich finde dieses Modell sehr anschaulich. Es hilft viele Situationen zu verstehen und gibt in anderen Situation Handlungsoptionen. Was es konkret bedeutet möchte ich an zwei Beispielen zeigen:

Als Scrum Coach stehe ich immer wieder vor der Herausforderung, Vertrauen aufzubauen.
Ich muss es schaffen, das Team von meiner Kompetenz zu überzeugen indem ich ihnen Referenzgeschichten erzähle und von meinen Erfahrungen berichte. In der täglichen Arbeit muss ich beweisen, dass ich ihnen helfen kann ihrem Ziel näher zu kommen.
Als Coach bin ich nur dann erfolgreich, wenn meine Wertvorstellungen und Prinzipien mit denen des Teams übereinstimmen. Dies finden wir meist in Anfangsdiskussionen heraus, aber auch in kritischen Situationen, in denen ich meine Integrität beweisen muss. Vereinbarungen müssen unbedingt eingehalten werden und transparent gehandhabt werden um Missverständnisse auszuschließen.
Erst wenn die einzelnen Teammitglieder spüren, dass mir ihr Wohlwollen am Herz liegt und ich mit ihnen und nicht gegen sie arbeite beginnt die eigentliche konstruktive Arbeit.

In meiner Freizeit klettere ich. Zum Klettern braucht man einen Partner, der einen sichert und dem man in dieser Situation vertraut. Mein Ausflug mit einer Freundin scheiterte leider daran. Ich bin absolut von ihrer Integrität überzeugt, da wir schon länger miteinander befreundet sind. Auch bin ich davon überzeugt, dass sie nur mein Bestes will. Leider hatte ich ihr in dieser Situation nicht die Kompetenz zugetraut, mich korrekt zu sichern. Aber Gott sei Dank ist Vertrauen situational und wir immer noch befreundet!

Was mir persönlich in dem Modell fehlt, ist Offenheit. Damit andere mir vertrauen, muss ich mich öffnen und ihnen ermöglichen sich ein Bild von mir zu machen. Nicht nur derjenige, der vertraut, sondern auch derjenige, der will, dass man ihm vertraut, muss sich verletzlich machen.

⁽¹⁾ Osterloh, M., Weibel, A. (2006), Investition Vertrauen. Prozesse der Vertrauensentwicklung in Organisationen, Gabler: Wiesbaden.

⁽²⁾ Mayer, R. C., Davis, J. H., & Schoorman, F. D. 1995. An integrative model of organizational trust. Academy of Management Review, 20: 709–734.

Werden wir mit Scrum effektiver?

krishan — Mon, 03 Jun 2013 04:03:00 +0000

Effizient (richtig machen) sind wir, wenn wir das was wir tun richtig machen, effektiv (das richtige machen) sind wir, wenn unser Output einen hohen Wirkungsgrad hat.

Ein Maß für Effektivität ist der Kundennutzen im Verhältnis zu Aufwand/Kosten. Agile Methoden wie Scrum oder Kanban bieten einen einfachen Mechanismus, um die Effektivität eines Prozesses zu steigern: In jeder Iteration werden die Produkt-Features mit dem höchsten Wertschöpfungspotenzial identifiziert und priorisiert umgesetzt. So einfach ist es in der Theorie.

Die Praxis sieht häufig so aus:

Fehlende Entscheidungsfreiräume des agilen Entwicklungsteam
Der Product Owner ist nur für einen Ausschnitt des Produktes verantwortlich und muss nach Plan arbeiten. Die übergeordnete Planungsebene denkt aber nicht agil und priorisiert nicht nach der optimalen Wertschöpfung.
Kundennutzen ist nicht transparent
Wie erkennt man das Feature mit der höchsten Wertschöpfung? Das ist nicht einfach. Viele Product Owner haben keine Ahnung welches Feature den höchsten Kundennutzen bietet. Oft haben sie keinen direkten Kontakt zum Kunden oder nur zu einem Vertreter, dem nicht klar ist, wie wichtig Priorisierung für die Effektivität ist. Wie soll man das Richtige entwickeln, wenn alles gleich wichtig ist?
Fehlendes Kunden-Feedback
In vielen Organisationen wird Scrum praktiziert, ohne den Feedback-Prozess für die Produktgestaltung zu nutzen. Review und Grooming Meetings wären eine gute Gelegenheit, um mit den Kunden/Stakeholdern über Kosten-Nutzen und Prioritäten von Features zu verhandeln. Oft nehme ich aber wahr, dass die falschen Leute Entscheidungen unter falschen Annahmen treffen und diese nie überprüft werden.

Es scheint so, dass viele Organisationen den Wert von effektiven Prozessen noch gar nicht erkannt haben und daher Ihre Produktentwicklung nicht wirklich agil umsetzen. Ich verspreche mir viel von der aktuellen Diskussion über „Design Thinking“ und „Lean Startup“, die am Kern dieser Problematik ansetzen und hoffe dass sich agile Denkweisen bald auch weiter vorne in der Prozesskette durchsetzen.

Fehler und Fehlerkultur

krishan — Tue, 19 Feb 2013 18:02:00 +0000

Sven Tiffe hielt beim letzten AgileTuesday, unserem Münchner Scrum-Stammtisch einen sehr interessanten Vortrag über die Rolle der Kultur, oder wie er sagte, der Haltung bei Google.

Klar, es gibt eine Menge von technischen Innovationen bei denen - und Google ist ein sehr technikverliebter "Verein" mit vielen Nerds. Sie pflegen das wohl auch und haben ein sehr ausgefuchstes Bewerbungssystem, bei dem Peer-Review eine große Rolle spielen - und das wird sicherlich bevorzugt weitere technikverliebte Nerds auswählen.

Da würde mich viele Details, die Sven ausgespart hat, brennend interessieren (wie viele andere auch) - aber für die meisten müssten wir wohl selbst bei Google anheuern.

Mich hat nicht die Technik, sondern ein anderer Aspekt bei dem Vortrag fasziniert: die Fehlerkultur.

Was Sven sehr lebendig veranschaulicht hat, war der Zusammenhang, dass gerade die Möglichkeit, Fehler zu machen und offen zuzugeben, eine zentrale Rolle bei der stetigen Verbesserung spielt. So werden bei den Protokollen von Bugreports auch die Klarnamen der Mitarbeiter firmenintern veröffentlicht, Das wiederum ist aber nur möglich, weil sich gleichzeitig niemand Sorgen machen muss, dass das zu Konsequenzen führt. Ein wirklich verblüffendes Beispiel war auch die Geschichte vom Kollegen, der aus Versehen ein internes Memo (mit heftiger Kritik an der Firmenleitung) öffentlich gepostet hat.

Interessant war auch in der anschliessenden (Fishbowl-)Diskussion, wie schwer es fällt, so eine Kultur zum Nennwert zu nehmen. Die Sache mit den Klarnamen in den Fehlerreports kann man noch auf eine unterschiedliche Herangehensweise in den USA zurückführen - aber ich war über manche Missverständnisse schon erstaunt.

"Fehler erlauben" wurde zum Teil missverstanden als "erlauben, mittelmäßige Qualität zu liefern". In meinem Verständnis ist das genau umgekehrt: wenn man Spitzenqualität liefern will, muss man jede Gelegenheit zum Lernen nutzen - und das bedingt auch, dass niemand seine Leichen im Keller versteckt oder verstecken muss.

Das würde auch einen Satz "Google kann sich das wegen seiner Größe erlauben" vom Kopf auf die Füße stellen: Google ist groß geworden, weil es eine Kultur entwickelt hat, in der rigorose Qualitätssicherung auch jede Gelegenheit zum Lernen nutzt und offen legt.

"Es gibt keine Fehler, nur Gelegenheiten zum Lernen" hört man manchmal - es ist leider oft nur graue Theorie - es scheint in manchen Organisationen scheint es mehr zu sein. Auf jeden Fall ist es ein Prinzip zum Nachmachen.

Speed Learning - Scala in 4 Stunden. Ein Experiment auf den XPDays 2012

krishan — Fri, 07 Dec 2012 06:12:00 +0000

Es ist schon ein ambitionierter Titel, den Daniel Zappold und ich uns da ausgedacht haben.

Die Idee für die Session:

Es gibt einige bekannte Parameter, die bestimmen wie wir etwas lernen und wieviel wir davon behalten, sprich: wie nachhaltig ist die investierte Zeit angelegt. Ich versuch jetzt nicht, eine irgendwie vollständige Darstellung davon zu liefern, sondern nur einige Schnipsel, die uns als Motivation gedient haben:

Etwas selbst machen ist wesentlich wirkungsvoller als es nur zu hören. Dabei ist der Grad der Aktivität wichtig und auch eine „Irritation“, die uns aufmerksamer macht.

Das Team ist produktiver wenn es eingeschwungen ist.
Pair Programming verbreitet Wissen in einem Team wie ein Buschfeuer
Man muss sich ein Thema als das seine aneignen, d.h. die „Ownership übernehmen“
Neues Wissen dockt am Besten an bekanntem Wissen an
Wenn man das kombiniert, sollte man sich neue Konzepte sehr schnell aneignen und beherrschen – wir nennen das hier Speed Learning

Wenn man das weiterdenkt, kommt man automatisch dazu, einige frontale Trainings in Frage zu stellen, man könnte ja auch ein Experiment wagen:

Warum kann man nicht ein eingeschwungenes Team in einer unbekannten Landschaft arbeiten lassen. vorausgesetzt, man hat einen „eingeborenen“ Führer dabei, der ein paar Fallen vermeiden hilft.
Warum können nicht einzelne Teammitglieder Themen vermitteln – sie würden die Ownership übernehmen und aktiv einer Erklärung finden

Auf den XPDays konnten wir nicht auf ein eingespieltes Team zurückgreifen - aber wir wollten trotzdem das Speedlearning ausprobieren

Also das Thema des Experiments: wir wollten probieren, wie schnell man sich Kenntnisse aneigenen kann.

Format:

kurze Einführung (5 Minuten) über die Prinzipien
IDE installieren und mit Scala Projekt zum Laufen bringen (die mechanischen Problemem hinter sich bringen). Ziel Hello Workd
Teilnehmer lernen sich kennen und bilden Paare, möglichst mit unterschiedlichem Erfahrungshintergrund und Kenntnisstand
Jedes Paar greift sich eins der vorbereiteten Themen heraus, experimentiert damit und bereitet eine kurze Präsentation vor
Präsentationen der Features und Diskussion (Ownership!)
Danach machen wir eine Kata (in unserem Fall die FizzBazz – Kata) und vergleichen prototypische Lösungen.

Eigentlich hatten wir danach eine zweite Runde mit Themen und eine weitere Kata geplant – mussten wir fallen lassen, weil fast nur Neulinge in der Session waren und die notwendige Diskussion der elementaren Sprachfeatures mehr Zeit als erwartet einnahm.

Alles in allem sind wir sehr zufrieden. Was nehmen wir mit?

Wir – und die Teilnehmer – können die Ideen verwenden um in kurzer Zeit viel Wissen in einem Team aufzubauen und es in kürzester Zeit „auf Speed“ zu bringen
Wir hatten nicht erwartet, dass man so schnell so viel Überblick aufbauen kann – natürlich müssen die Teams jetzt dranbleiben und das Wissen festigen und vervollständigen

Auf jeden Fall war es eine wertvolle Erfahrung, wir können diese uch in unsere nächsten Teamtrainings gut verwenden.

Wissenstransfer im Team

hedi.buchner — Wed, 12 Dec 2012 11:09:00 +0000

„Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt.“ Wie schaffe ich es, Wissenstransfer im Team zu fördern? Welche Konzepte bietet Scrum? Was haben wir konkret im Team implementiert und ausprobiert?

Wissenstransfer ist gerade in der Softwareentwicklung essentiell. Bei den vielen komplexen Problemen mit denen wir uns tagtäglich beschäftigen, ist es wichtig, immer mehrere Wissensträger zu haben, die sich gegenseitig unterstützen und ergänzen können. Nur, wie schafft man es denn, dass das Wissen im Team geteilt wird? Diese Frage hat mich kurz nachdem ich als Scrum Master zu meinem aktuellen Team gekommen bin sehr beschäftigt. Gleich zu Beginn hat uns ein wichtiger Know-How-Träger verlassen und mit ihm auch sein Wissen. Eins unserer Ziele ist es jetzt, Wissensinseln im Team abzuschaffen und alle Teammitglieder an allen Themen zu beteiligen.

Für die Entwicklung verwenden wir Scrum. Mit Scrum werden schon viele Elemente und Konzepte eingeführt, die dabei helfen, Wissen im Team zu verteilen. Sprint Planning, Review, Retrospektive, Daily Scrum - all diese Meetings nutzen Synergieeffekte des Teams, fördern gemeinsame Diskussionen und binden alle Teammitglieder ein. Sie bieten eine Plattform um Probleme, Ideen und Erkenntnisse zu teilen und weiterzuentwickeln.

Uns war das nicht genug. Gemeinsam haben wir in Retrospektiven folgende Praktiken eingeführt:

Pair Programming

Beim Pair Programming arbeiten zwei Entwickler an einer Programmieraufgabe. Vorteile dieser Agile Engineering Praktik sind, dass immer vier Augen den Code betrachten. Kritische Fragen werden schon während der Implementierung gestellt und können sofort bearbeitet werden. Bei uns hat das zu höherer Qualität des Codes und des Produktes geführt und uns dadurch insgesamt schneller gemacht. Zusätzlich gibt es danach mehrere Experten für das bearbeitete Thema und verkürzt darüber hinaus auch die Einarbeitungszeit neuer Teammitglieder.

Mit Pair-Programming habe ich auch schon in meinen früheren Teams gearbeitet. Eins der Teams nutzte eine Pair-Programming Matrix, um sicherzustellen, dass die Paare jeden Sprint, später dann jeden Tag, wechseln.

WIP Limit

Das WIP (Work in Progess) Limit kommt aus der Lean Welt. Grundsätzlich begrenzt das WIP Limit die parallele Arbeit im System. Bei uns definiert es, wieviele User Stories in einem Sprint in Bearbeitung sein dürfen. Wir haben aktuell ein WIP Limit von 3 User Stories für 9 Entwickler. Diese Bedingung kann das Team nur einhalten, wenn alle eng zusammenarbeiten und mehrere Entwickler gemeinsam eine User Story umsetzen. Die Einführung eines WIP Limits hat bei uns zu einem starken Fokus auf die aktuellen User Stories und schnellen Ergebnissen geführt. Das erhöht die Transparenz und verringert das Risiko, weil man viel genauer weiß, welche Features tatsächlich fertig sind. Ein weiterer positiver Nebeneffekt ist auch, dass durch diese intensive Zusammenarbeit erst gar nicht die Möglichkeit entsteht, dass sich Wissensinseln bilden.

Lightning Talks

Um noch bestehende Wissensinseln aufzulösen nutzen wir das Format des Lightning Talks: 15 – 30 minütige Talks, die 1x pro Woche in einem der Entwicklerräume stattfinden. Bis jetzt gab es Talks zu Coding Conventions, produktrelevanten Themen, Konferenzbeiträgen, theoretische Hintergründe zu Konstrukten in Ruby, Besonderheiten von Rails und vielem mehr.

Außerdem nutzen wir die Lightning Talks, um uns auf große, neue Themenkomplexe vorzubereiten. Das Ergebnis einer Recherche zu einem neuen Thema wird dann im Rahmen eines Lightning Talks vorgestellt.

Agile Coach Camp 2012 - leider vorbei

krishan — Sat, 23 Jun 2012 22:06:00 +0000

Jetzt ist das Agile Coach Camp 2012 schon wieder vorbei. Schade. Sehr schade.

Es war das dritte Camp dieser Art, das Format war Open Space wie schon in den letzten Jahren und es war wieder richtig gut.

Es ist uns eine Ehre, dass wir dieses Event mit gesponsert haben und haben das keine Sekunde bereut.

Das Coach Camp ist eine Veranstaltung der besonderen Art: hier treffen sich professionelle Coaches, die zum Teil im sonstigen Leben hart miteinander konkurrieren und tauschen Erfahrungen aus. Ich glaube nicht, das es das in dieser Qualität in vielen Branchen gibt. Auf jeden Fall ist es eine beeindruckende Erfahrung.

Ich selbst war in einer Menge toller Sessions, zum Beispiel

Agile Contracting - hier hat sich die Diskussion sehr schnell von der rein juristischen Betrachtung dahin verschoben, welche implizite und explizite Vereinbarungen man zu Beginn eines Coaching-Engagements treffen muss
Alternative Formen von Retrospektiven - wie kann man Retrospektiven anders gestalten, so dass sie die interessantesten und wertvollsten Meetings der Welt werden
Agile Transformation - welche Erfahrungen gibt es aus den verschiedensten Bereichen, mit denen man in nachhaltige Änderungen in einer Organisation bewirken wird.

Über einige der Sessions werde ich in der nächsten Zeit noch bloggen - so stay tuned.

Agile Coaching Dojo

hedi.buchner — Mon, 13 Feb 2012 12:02:12 +0000

Create a safe and fun environment to try out new ideas and improve. That’s the idea for a dojo of any kind, let it be for improving your coding skills or, like in my case, your coaching skills.

I attended my first coaching dojo in one of our agile lunch sessions at Thoughtcorp, Toronto, Canada and was fascinated by the outcomes. Taking advantage of the different skill and experience levels, there is always something to learn. So when I attended my first office day at improuv last week I was asked to facilitate a coaching dojo here. I chose to use the set up Michael Sahota explains in his blog http://agilitrix.com/2011/04/coaching-skills-dojo/.

Easy enough, I prepared a flipchart stating the skills that we were about to practice:

Oberserving
Listening
Questioning

In addition I drew a little sketch to illustrate the flow of the coaching dojo (thanks to Michael’s drawing talent this was easy)

As we were only 5 people, not the recommended multiple of 3, we had to adjust the set up a little bit. There is a 5min time slot of discussing what the three skills, observing, listening, questioning, actually mean in the context of coaching and what the techniques to achieve great output are. This we did in 2 groups and followed up by presenting our findings to the other group. Then we continued as a group of 5 and assigned the customer role to one person, had two observers and two coaches for each round. All the participants had a couple of minutes to think of a problem they wanted to present as a customer:

“As a software developer I don’t have enough management support for improving the code quality”
“As a product owner I don’t understand the technical details the teams present in the demos”
“As a product owner I want the teams to deliver complete user stories at the end of the sprint”
“How can I include classical risk management in an agile project?”
“As a coach, am I responsible to tell a company that they lack the necessary prerequisites to introduce Scrum?”

Each mini round (5 min) was followed by a lively discussion on how the coaches performed in terms of listening and questioning and about the problem itself (2-3 min). Thanks to our rearrangement, we introduced an immediate feedback loop for the coaches, as one person took on the coach role for 2 subsequent customers and could implement the improvements straight away.

An overall debrief (10 min) was the last step in the dojo. I got very positive feedback on the session and we had ideas on establishing a regular coaching dojo, especially as a platform for discussing real life problems while still improving coaching skills.

The last task was asking the participants to think of an action item, they can focus on practicing: I picked to do some research and practice on circular questioning.

(Curious? I’ll tell you more about it in the next blog)

Continuous Integration

taghi — Tue, 02 Oct 2012 08:02:12 +0000

Zurzeit steigt das Bewusstsein für die Bedeutung von Continuous Integration immer stärker, hier mit eingerechnet sind auch Continuous Deployment und Continuous Delivery. Insbesondere letzteres ist für viele Projekte ein hehres Ziel.

Dieser Trend ist ein gutes Zeichen, da es reflektiert, wie groß der Wunsch ist Qualität in Software hinein zu bekommen. Zum anderen ist es aber auch eine wichtige Grundlage, um agile Methoden einsetzen zu können. Ja, die Idee ist schon älter und wurde mit eXtreme Programming (XP) bereits propagiert. Nur wie viele andere Techniken aus XP brauchte es seine Zeit, um diese in der Praxis umzusetzen. Im agilen Umfeld sehe ich die Notwendigkeit, dass Kombinationen z.B. aus Scrum und XP verwendet werden, um erfolgreich als Team zu arbeiten.

Was macht Continuous Integration (oder auch Continuous Delivery) aus? Man bekommt von einer “neutralen unabhängigen” Instanz schnelles Feedback. Es ist aber auch eine Möglichkeit das agile Mindset zu fördern. Schnelles Feedback erlaubt viele kleine Schritte. Das Team bekommt somit ein zusätzliches Sicherheitsnetz, bei dem man wesentlich weicher fällt als bei einer klassischen Big Bang Integration. Um die Awareness innerhalb und außerhalb des Teams für CI zu schärfen und die aktive Nutzung zu fördern, empfiehlt es sich die Ergebnisse zu visualisieren. Die Visualisierung kann durch Lava-Lampen, Ampeln, einem Statusmonitor oder durch viele andere Mittel kreativ erfolgen. Im Idealfall entsteht eine tolle positive Energie, um den Build immer grün zu halten oder schnellst möglichst wieder grün zu bekommen.

Continuous Integration (oder CD) ist ein Baustein auf dem Weg zu dem Ziel „Delight Customer“.

Was man aus einem Fehlschlag im Coding Dojo lernen kann

krishan — Wed, 22 Jun 2011 20:06:11 +0000

Katas und Coding Dojos sind für mich in letzter Zeit eine immer wichtigere Lernform geworden. Ich kann damit nicht nur das Einrosten meiner Programmierkenntnisse bekämpfen (ich mache zu viele Schulungen und programmiere zu wenig, als es für meine Routine gut ist) sondern ich habe auch einige neue Anwendungsgebiete kennengelernt:

Scrum Master Dojo, wie es auf dem Scrum Gathering 2010 in Amsterdam angeboten wurde (die Session war dort leider nicht so gut wie die Idee)
Ein Coaching-Dojo auf dem Agile Coach Camp. Das wird in Gruppen zu ca. fünf Telnehmer durchgeführt. dabei "spielt" jeweis ein Teilnehmer den Suchenden, zwei agieren als Pair-Coachs und zwei andere beobachten und geben am Ende Feedback.
Neue Programmiersprachen kennenlernen. Ich selbst habe Katas genutzt, um mich einfacher in Ruby und Scala zurecht zu finden.

Jetzt haben wir (Johannes Link hat die Session moderiert) auf dem Agile Coach Camp eine Programmierkata in einer Coding Dojo Session durchgeführt, die, wenn man den resultierenden Code ansieht, völlig aus dem Ruder gelaufen ist.

Auf der anderen Seite haben wir dabei sehr viel gelernt und hatten eine phantastische Retrospektive. Und das kam so (ich muss da ziemlich tief in die Details einsteigen): Wir wollten die "Harry Potter Kata" umsetzen. Diese hat nichts mit Zauberei zu tun, sondern mit einer komplizierten Rabattberechnung bei Kauf der verschiedenen (damals 5) Bände von Harry Potter. Dem Rabattprinzip liegt zu Grunde, dass man mehr Rabatt bekommt, wenn man mehr verschiedene Bücher einer "Suite" kauft. Nachdem man eine Suite zusammengerechnet hat, muss man für weitere Einzelexemplare wieder von vorn anfangen. Zum Beispiel erhält man bei Kauf von 2xBand1, 1xBand2, 1xBand3 einen dreier-Rabatt für den Kauf von Band 1, 2 und 3 - man muss aber für die zweiter Kopie von Band 1 wieder den vollen Preis bezahlen.

Die Stunde der Wahrheit kommt dann, wenn man eine Sequenz von 2xBand 1, 2xBand 2, 2xBand 3, 1xBand 4, 1xBand 5 kauft. Das Programm muss dann herausfinden, dass man billiger fährt, wenn man das als zwei Vierer-Gruppen statt einer Fünfer- und einer Dreiergruppe rechnet. In unserem Dojo haben wir dann auch wie gewohnt mit den ersten Schritten angefangen: ein Buch, zwei Bücher, und so weiter. Ziemlich bald kamen dann aber zwei Wege zum Vorschein: Einer läuft darauf hinaus, wie gewohnt immer neue Testfälle zu hinzuzufügen und den Code schrittweise zu erweitern. Die andere, einen rekursiven Algorithmus zu implementieren, der die verschiedenen Lösungen generiert und dann die besten Ergebnisse auswählt.

Wir haben diese "Spaltung" in der Gruppe nicht erkannt, was dazu geführt hat, dass wir uns öfter gegenseitig den Code mit dem jeweils anderen Ansatz gelöscht haben, weil wir ihn einfach nicht verstanden hatten. Bei unserem Java-Coding-Dojo am 21.6.2011 hatten wir ein ähnliches Problem, da hat Daniel Zappold eine Idee für die Lösung genannt: manchmal muss man auch hier am Anfang eine Design-Session durchführen. Manchmal sind einfach die Aufgaben noch nicht genau genug definiert. Damit wird die Dojo-Session noch "lebensnäher", denn wenn man einen Task als Pair mit TDD umsetzt, ist es auch eine gute Praxis dass man sie zunächst eine TODO-Liste mit den einzelnen Schritten zurecht legt. Jetzt suchen wir nach Ideen, wie man diesen Design-Schritt integrieren kann, der hilft den minimalen Aufwand zu definieren, der am Anfang infach sein muss. Vielleicht kommt am Ende auch eine neue Form heraus, so etwas wie eine Design-Kata. Für Ideen und Erfahrungen sind wir dankbar, wir arbeiten auch daran weiter, bleibt dran.

Agile Unternehmenskultur

hedi.buchner — Tue, 26 Aug 2014 22:00:00 +0000

Was macht agile Unternehmen aus? Wie arbeiten sie? Welche Werte leben sie? Das waren die Fragen, die ich mir und Mitarbeitern, Führungskräften, Product Ownern, Scrum Masters und CEOs agiler Unternehmen in den letzten 10 Monate häufiger gestellt habe.

Im Rahmen meiner Masterarbeit hatte ich die einmalige Gelegenheit dem Mythos Unternehmenskultur näher zu kommen.

Der zentrale Aspekt, der sich durch alle Unternehmen, ob groß oder klein, jung oder alt, gezogen hat, war Vertrauen. Vertrauen, das die Führungskräfte in ihre Mitarbeiter setzen. Vertrauen, dass ihre Mitarbeiter die notwendigen Fähigkeiten und Kompetenzen haben, um das gemeinsame Unternehmen voranzubringen und gemeinsame Ziele zu erreichen. Vertrauen, dass die Mitarbeiter Verantwortung für ihre Arbeit übernehmen. Das Vertrauen und Wissen, dass alle gemeinsam am gleichen Strang ziehen.

Mit diesem Vertrauen wird ein Umfeld geschaffen, in dem Teams autonome Entscheidungen treffen können. In dem sie die Möglichkeit haben über den Tellerrand zu schauen, und sich weiteres Wissen aneignen können.

Mit diesem Vertrauen wird ein Umfeld geschaffen, in dem Informationsverteilung eine Führungsaufgabe ist. Weg von dem Spruch „Wissen ist Macht“, hin zum Verständnis des Unternehmens als Netzwerk. Ein Netzwerk kann nur funktionieren, wenn der Informationsfluss gewährleistet wird. Nur die Kenntnis der entsprechenden Informationen ermöglicht es den Teams, die für das Unternehmen richtigen Entscheidungen zu treffen.

Mit diesem Vertrauen wird eine Atmosphäre geschaffen, in der Feedback respektvoll gegeben und angenommen werden kann. In der Entscheidungen zur Diskussion gestellt und in Frage gestellt werden können. In der Fehler als Chance zum Lernen begriffen werden und deshalb nicht unter den Teppich gekehrt und bestraft werden. In der man sich auf Augenhöhe begegnet.

Wenn dieses Vertrauen nicht da ist sondern formale Kontrollmechanismen, Regeln und Vorgaben eingesetzt werden führt das zu Frust, Demotivation und ‚Dienst nach Vorschrift’. Das kann sich kein Unternehmen erlauben, das innovative und tolle Produkte entwickeln will.

DevOps Transformation: The next step in Agility

taghi — Wed, 04 Nov 2015 03:11:00 +0000

The inherent linear sequencing in Waterfall creates walls and barriers to collaboration between different roles and disciplines in the organisation. One such wall, of particular importance, is the lack of ongoing collaboration and communication between business and development teams. Agile has tried to break down this barrier by bringing the two disciplines to continually work together throughout iterations[1]. Further down the value delivery chain there is often a similar barrier between development and operations. The absence of tight collaboration between these two disciplines has been a major bottleneck, slowing down (and at times paralysing) timely delivery of software increments to customer. In the second decade of Agile, DevOps was born as a movement and a cultural shift to eliminate this very barrier.

DevOps, however, is more than just “dev” plus “ops”. It entails a shift in mind-set to embrace the culture of continuous improvement and continuous delivery of business value across management, engineering, product management, QA, test, release management, business, and basically throughout most of the organisation, just like Agile. That’s why I like to call it DevOps Transformation, to highlight the fact that DevOps is primarily about a transformation rather than tools and technology (more on DevOps pitfalls in my next posts).

Such a transformation affects everyone involved throughout the application lifecycle and is effectively an extension to the PDCA cycle to include every stage in the deployment pipeline:

Let’s take a quick look at the two core practices in DevOps transformation:

Continuous Delivery

Agile manifesto stresses “working software” in two of its principles: “Deliver working software frequently, …” and “Working software is the primary measure of progress.” But how do we get to know if we are delivering working software? Continuous Delivery (CD) is the next natural step to Continuous Integration and is essentially the practice of determining whether you have a working shippable software increment by running the set of changes through a deployment pipeline (see below). This pipeline starts by continuous integration (CI) steps, Upon successful integraton it will then deploy the artefacts to a production-live environment and runs the full suite of automated acceptance tests against it. The pipeline is often triggered by any change to the code base. With this pattern, continuous delivery enables teams to ensure that every change can be released to production (hence working software) with minimal intervention at any point in time.

For continuous delivery to be effective, it heavily relies on automation throughout the pipeline in particular automated testing. It also utilises some of the Lean principles:

Reducing waste (reducing batch sizes, limiting work in progress (WIP), reducing waiting time: Continuous delivery enables you to release smaller set of changes more frequently
Shortening feedback loops: More frequent deployments made possible through continuous delivery will in turn enable faster feedback cycle (more on this later)

Continuous Improvement

Continuous Improvement is the culture of inspecting and adapting, continual validated learning through experimentation and real data (feedback). It is built on many concepts of Lean: shortened feedback loops, Kaizen, and data-driven decision making. Although the practice of continuous improvement can and does exist in many Agile teams, coupled with continuous delivery teams will have access to an extended set of opportunities to learn better and faster through the empirical data and metrics collected throughout the deployment pipeline as well as ALM processes. Some examples of such metrics include:

Core continuous delivery metrics: deployment frequency, deployment lead time, and mean-time to recovery.
Production monitoring providing visibility into operation state of your production environment with metrics on traffic, application performance, availability, scaling, etc.
Customer feedback: real time usage data collected provide feedback on how user interacts with the application as soon as a new version of the application is released.
Automated test data collected through CI/CD pipeline, such as test coverage, failure rates, etc.
Software quality metrics gathered via automatic code analysis done with CI

In my next blog post I’ll explore the benefits and some of the elements of DevOps transformation

Entscheidungssysteme - Was ist das schon wieder?

jens — Tue, 19 Jul 2016 13:13:00 +0000

Im Dezember 2015 traf sich in Aachen zum fünften Mal die "Supporting Agile Adoption" Arbeitsgruppe der Agile Alliance, um neue und spannende Themen rund um Agile Transitionen aufzuspüren und zu bearbeiten (ein ausführlicher Bericht über das Treffen findet sich bei der Agile Alliance). Einer der geladenen Gäste war Pieter van der Meché vom Sociokratisch Centrum Nederlande, mit dem wir über Entscheidungssysteme und ihre Bedeutung für Organisationen diskutiert haben. Das Ergebnis dieser Diskussion haben nun Hendrik Esser (Ericsson), Pieter und ich unter Mitarbeit von Anders Ivarson (Spotify) als White Paper unter dem Titel "Decision Making Systems Matter" festgehalten. das die Agile Alliance letzte Woche publiziert hat (siehe https://www.agilealliance.org/resources/initiatives/supporting-agile-adoption-its-about-change/).

Worum geht es? Entscheidungssysteme - also die Frage, wer wann worüber entscheidet und wie diese Entscheidungen dann in der Organisation Fuß fassen - sind eigentlich ein alter Hut: In der Organisationsentwicklung beschäftigt man sich seit vielen Jahrzehnten mit ihnen und es gibt Theorien, nach denen Entscheidungssysteme das wesentliche Gestaltungskriterium von Organisationen ist. Auch die Soziokratie fokussiert sich auf sie und unterscheidet dabei zwischen zwei Typen von Entscheidungssystemen:

Hierachisch: Für jede Art von Entscheidung ist eine einzelne Person in der Organisation definiert, deren Aufgabe es ist, solche Entscheidungen zu treffen. Der betroffene Teil der Organisation setzt diese Entscheidung dann aufgrund betrieblicher Anweisung um ("Compliance"). Normalerweise werden aufwändigere Entscheidungen in Gremien und entsprechenden Entscheidungsvorlagen vorbereitet, doch letztlich trifft ein "Entscheider" die finale Entscheidung und übernimmt damit die Verantwortung. Dies ist das vorherrschende Entscheidungsverfahren in den meisten Organisationen und auch Gesellschaften.
Partizipativ: Hier kommt eine Gruppe von Individuen zu einer Übereinstimmung und trifft dadurch eine Entscheidung, die sie auch selbst umsetzt, weil jede(r) Beteiligte hinter der Entscheidung steht ("Alignment"). Um Übereinstimmung festzustellen, können formale Abstimmungen erfolgen, Konsens eingefordert werden, oder ein "Konsent"-Verfahren verwendet werden.

Typische Probleme treten nun an der Schnittstelle zwischen (noch immer) traditionellen Unternehmensteilen mit ihren hierarchischen Strukturen und agilen Unternehmensteilen mit ihren partizipativen Elementen auf: Während auf der einen Seite über "Chaos" und "unklare Verantwortlichkeiten" geklagt wird, klagt die andere Seite, dass "unsere Selbstorganisation" nicht respektiert werde und "nicht ausreichend Empowerment" da wäre. Beide Seiten haben ihre Berechtigung, doch kann man das Problem nicht lösen, indem man einfach eine Seite als moralisch überlegen hinstellt und ihre Ansichten als die einzig richtigen. Stattdessen gilt es, eine Lösung für Schnittstelle zwischen den beiden Entscheidungssystemen zu finden, welche die Stärken beider Seiten fördert, ohne diesen Konflikt weiter anzuheizen. In dem White Paper erkunden wir, in wie weit sich Elemente aus der Soziokratie dafür nutzen lassen.

Gewaltfreie Kommunikation - ein Praxisbeispiel

anja.stiedl — Mon, 20 Jun 2016 20:47:00 +0000

Bei der Vorbereitung unserer Session über Gewaltfreie Kommunikation nach Marshall B. Rosenberg fiel mir ein anschauliches Beispiel aus meinem Alltag als Agile Coach ein, bei dem ich mithilfe der vier Schritte der GfK meinem Gesprächspartner helfen konnte, sich in einem Konflikt erst selbst Klarheit über seine Gedanken und Ziele zu verschaffen, bevor er in ein Klärungsgespräch ging. Ich werde es nicht für den Workshop verwenden, doch möchte ich diese Erfahrung hier teilen.

Aber erst mal ein paar Informationen über diese „4 Schritte der Gewaltfreien Kommunikation“:

Beobachtung: man konzentriert sich erst einmal rein auf die Beobachtung der konkreten Handlung, die in dieser Situation geschehen ist. Dabei wird bewusst verzichtet auf Bewertungen und Interpretationen.

Gefühle: im Anschluss hinterfragt man, welche Gefühle mit dieser Handlung ausgelöst werden.

Bedürfnisse: Bedürfnisse sind allgemeine Werte oder Wünsche, die vermutlich jeder Mensch gerne hätte, die einen stärker, die anderen weniger. In diesem Schritt erarbeitet man, welche Bedürfnisse in der Situation erfüllt oder – bei negativen Gefühlen – eben nicht erfüllt wurden.

Bitte: Zuletzt formuliert man eine Bitte, mit der man beim Konfliktpartner um eine konkrete Handlung anfragt, um das eigene, unerfüllte Bedürfnis zufrieden zu stellen.

Marshall B. Rosenberg fasst dies kurz so zusammen:

Wenn ich sehe, dass du A tust, fühle ich B, weil ich das Bedürfnis nach C habe. Deshalb bitte ich dich, D zu tun. Wie wäre dies für dich?

Als Beispiel eine Mutter zu ihrer Tochter (im Teenager-Alter):

Wenn du jeden Morgen diesen kurzen Rock zur Schule anziehst, bin ich enttäuscht und erschöpft, denn ich habe die ewige Diskussion satt und das Bedürfnis nach Leichtigkeit und Harmonie in unserer Familie. Kannst du dich bitte selbständig darum kümmern, dass du die Kleiderregelungen deiner einhältst?

Aber zurück zu dem Arbeitsgespräch, von dem ich erzählen möchte:

Mein Kollege Anton regte sich sehr über einen weiteren Kollegen Robert auf, der eine Email geschrieben habe, um ihn fertig zu machen. Robert habe eine bestimmte Dokumentation im Projekt vermisst, die Antwort von Anton war ihm aber nicht gut genug und so habe er eine Email an verschiedene Manager geschrieben, in der er betonte, dass Anton in Bezug auf dieses Dokument auch keine Ahnung habe, und ihn damit anschwärzte.

Mit der Anwendung der 4 Schritte der GfK kamen wir zu diesem Erkenntnissen:

Beobachtung:

Robert hat Antons Vorschläge in Bezug auf das fehlende Dokument nicht verwendet.
Robert hat eine Email geschrieben.

Hier erwähnte Anton aber auch weitere Beobachtungen, die nicht mit der aktuellen Konfliktsituation in Zusammenhang stehen, insbesondere „Robert grüßt mich nicht.“ Dieser Satz wurde zum Thema für die weiteren GfK-Schritte, da Robert ihn als zentralen Konfliktpunkt bezeichnete.

Als Gefühle benannte Anton, dass er verärgert, enttäuscht und frustriert sei.

Unerfüllt blieb ihm das Bedürfnis nach Sichtbarkeit und Anerkennung.

Als Bitte wünschte sich Anton, dass Robert ihn konkret in Tätigkeiten der Projektarbeit einbeziehen möge.

Insgesamt formulierte Anton für sich diesen Satz:

„Wenn Du mich nicht grüßt, bin ich enttäuscht und frustriert, denn ich möchte, dass mein Einsatz hier für die Abteilung gesehen wird. Könntest Du mir bitte sagen, wie ich dich sinnvoll unterstützen kann?“

Meine Erfahrungen...

Ich gebe dies hier nun alles kurz und knapp wieder, doch man muss sich bewusst sein, dass hinter diesem Satz ein langes Gespräch um Worte und Formulierungen steht. Insbesondere Anfängern der GfK fällt der Unterschied zwischen reinen Beobachtungen und Interpretationen, Gefühlen und Beschuldigungen schwer. Als Coach unterstützt man hier durch genaues Nachfragen, oder durch das Anbieten von verschiedenen Gefühlen oder Gefühlsnuancen.

Seien wir mal ehrlich: werden wir gefragt, wie wir uns fühlen, antworten wir „gut“ oder „schlecht“. Es gibt hingegen ein breites Spektrum dazwischen! Erschrocken, erschüttert oder entrüstet: auf den ersten Blick gleich, doch im Detail ein bisschen anders!

Ebenso schwer fällt es oft, das genaue Bedürfnis zu bestimmen. Für einen Coach hilfreich ist eine Liste von möglichen Bedürfnissen, damit man auch hier den Coachee an das richtige Wort hinführen kann.

Marshall Rosenberg nennt die folgenden allgemeinen Bedürfnisse: körperliches Wohlbefinden, Sicherheit, Liebe, Empathie / Einfühlung, Kreativität, Geborgenheit, Spiel / Erholung, Autonomie / Willensfreiheit, Sinnhaftigkeit.

Ein paar Tage später erzählte mir Anton, dass er ein offenes Klärungsgespräch mit Robert führen konnte und für sich selbst wertvolle Antworten und Sichtbarkeit erhalten hat.
Na, dann war es für mich wertvoll!

Adhocracy - Picks from the ESP Executive Summit London

jens — Thu, 28 Apr 2016 16:12:00 +0000

One of my personal highlights of the ESP Executive Summit in London on April 20th was Julian Birkinshaw's keynote on "New Organising Models in a Complex World". The professor of the London Business School who is designated as one of the fifty worldwide thought leaders in business science presented the core ideas and concepts of his forthcoming book "Fast Forward". He discussed how our economy changes since the past decades and how organizations act to it.
Julian's starting point was the assumption that after having gone through the Industrial Age and the Information Age, we've now entered the "Post-Information Age".

During the Industrial Age capital and workforce were the major business assets in a slowly changing world. The appropriate organizational form in this age was the hierachical Bureaucratic organization. This form was inherited from the military and the churches and adapted to industry needs by Frederic Taylor and his school of management. In these organizations formal position is the major driver for priviledges and recognition. The major competitive advantage during the Industrial Age was the ability to produce with reproducible quality most efficiently. You had a lot of time to optimize your organization.

Starting in the seventies until the late nineties information and knowledge became more and more the dominant business asset, forming the Information Age. Powered by information technology the amount of information you were able to collect and exploit became the major driver for the markets. Consequently new organizational forms emerged, the Meritocracies. in these organizations knowledge and expertise play the predominant role when it comes to privileges and recognition. The power of classical management was reduced to "Business Administration" while hierachical networks of experts play the major role in moving the companies products forward. These organizations are optimized to find the best solution based on the available information. The environment still changed slow enough so a high quality second product could beat an already existing competitive product of mediocre quality. You still had time to find the best solution. Most engineering organizations are prototypes of this form.

Since the last decade information is mostly available for everyone, having two major effects: At first information per se seizes to be a valueable asset anymore. The second effect is that the amount of data available grows quicker than meritocratic organizations can make use of it. Birkinshaw calls this environment the Post-Information Age or Agile Age. With the new challenges a new organization form emerged, Birkinshaw calls Adhocracies (there was some debate on whether is name bears an unjustified negatove connotation). In Adhocracies action and accomplishment take the role that capital and labour played in hierachic organizations and knowledge and expertise play in meritocratic organizations. Finishing fast ist more valued in these organization than striving for the best solution or the most efficient one. When the environment changes while you search for the best solution, the term "best" looses its meaning. Analysis becomes void before you can turn it into action.

This change in organizational forms needed and still needs new ideas and foundations. New movements emerging to support businesses in these envirnoments, like Beyond Budgeting from the administrational side, Post-Heroic Leadership from a management side, Lean Startup from the entrepreneur side, Agile approaches like XP, Scrum or Kanban from the IT side, and finally frameworks like Cynefin and HSD providing the theoretical foundations for these organizations.

To me the beauty of this model doesn't come from novelty but from its consistent connection of approaches of different origins. Most organizations will show a mixture of all three forms, but being able to understand the different value systems and approaches and the connected conflicts between them is very helpful when it comes to conducting an agile transformation. I'm looking forward to Julian's book.

Brain Based Learning – six Trumps and none of them called Donald!

stuart — Sat, 16 Apr 2016 14:04:00 +0000

I just had the pleasure of attending a two day workshop on the topic of brain-based learning from Sharon Bowman: Training from the BACK of the room. This had a deep impact on my approach to training, but also sowed many seeds of thought regarding how these principles, approach and example practices can be effectively used in coaching. In this blog I'll just give you a teaser of what the principles behind "Training from the back of the room" are all about. At the core of the approach are 6 key principles called Trumps (playing card terminology – e.g. an ace trumps a king).

Think of these in the context of a learning situation – this could be a 2 day training course, or a 20 minute sit-down with a busy manager/team member. The concepts are the same – you wish the people/person you are engaged with to experience learning.

Not unlike the Agile manifesto, we can say with these principles that “while there is value in the things on the right (e.g. sitting), we place more value in the things on the left (e.g. movement)”.

1. Movement trumps sitting: When we get up and move around we provide more oxygen to the brain. We avoid “death by sitting”. So keep people active – let the brain breath. Learning situation example: get learners up and moving around – working on walls, walking, talking, stretching etc.

2. Talking trumps listening: Unless you are a superb story teller, learners don´t learn well when just listening. Let people put concepts, ideas, learning in their own words and then they own it – and remember it. Learning situation example: have learners teach-back what they have understood to their partner/group.

3. Images trumps words: Our brain scans for, and processes, visual information extremely well (is that a Tiger I see in the bushes..?). Example: to learn the “trumps” just try to remember the images here – then the ideas will follow. Learning situation example: ask learners to draw icons connected to simple concepts – and remember the icons.

4. Writing trumps reading: writing something down forces us to order our thoughts – the jumble of words in our heads suddenly needs to be formed into crisp ideas or statements that can be written down. Even if we don´t return to our notes, the process of writing helps us order our thoughts and deepens the connection to the content. Learning situation example: provide learners a graphic organiser (e.g. note pages with some empty content spaces) and ask them to write down their key learnings.

5. Shorter trumps longer: Our brains have a tendency to start to shut down after 10-15 minutes if the content (or situation) remains static. Our brain has said “ok, looks like I understand the threat levels here and I can go into a holding pattern until something changes” – this is habituation. Our brain can slip into safe-mode. Therefore we need to help keep the brain alert and engaged. Learning situation example: make concept content sessions (when you are delivering new content) to around 10 minutes (or less) and then have the learner/s engage in some concrete practice to bind the content to experience).

6. Different trumps same: Linked a little to the previous trump – the brain needs stimulus – changing things triggers the brain to become active and start to assess what is happening – the whole brain engages – and we become active. Learning situation example: organise the room differently (funny to see some groups respond when they see they´ll sit in a circle), switch group members, or do something like schedule a “pair talk” where pairs walk around and discuss a topics – also great idea for one-to-one sessions.

That was just a high-level overview of the trumps. The workshop “Training from the back of the room” covers:

- the s ix trumps(principles)
- the 4 C´s (connections-concepts-concrete practice, conclusion) – learning planning method
- practices (a large collection of practices & ideas that can be used to build a more brain-focused learning experience)

So there you go. While the “other Trump, D” may be talking about building fences, these trumps are building bridges to the mind !

For more information please visit: Sharon Bowman’s website.

Hilfe aus dem Management - Das Transition-Team

alexander — Sat, 16 Jan 2016 15:01:00 +0000

Die Umstellung von einer projektorientierten Entwicklung hin zu einer agilen Produktentwicklung ist ein nicht zu unterschätzendes Unterfangen. Gerade dann, wenn das Unternehmen streng hierarchisch organisiert ist, viele Spezialistenabteilungen existieren und auf die Genialität eines Projektleiters als maßgeblichen Erfolgsfaktor vertraut wird. Dagegen das Konzept eines cross-funktionalen, selbstverantwortlichen Produktionsteams zu stellen, ist in vielen Fällen eine Herausforderung.

Problemstellung

Häufig wird zunächst auf Team-Ebene „agilisiert“ - meist ein Team als Pilot, um die neue Herangehensweise auszutesten und Erfahrungen zu sammeln. Dies ist ein vermeintlich schnell umzusetzender Schritt: Umbenennung des Projektleiters in Scrum Master oder Product Owner und die Einführung eines morgendlichen Stand-up Meetings an einem Task-Board. Aber selbst wenn eine Transition eines bestehenden Projektteams mit einer sinnvollen Begleitung stattfindet und auch die Werte einer agilen Produktentwicklung beachtet und gelebt werden, stehen diese Transitionen schnell vor einem großen Problem: Der Übergabe von Arbeitsartefakten in die Restorganisation oder Abhängigkeiten zu anderen Projekten oder bestehenden Deployment-Prozessen.

Nicht selten beobachte ich, dass der Aufbau eines cross-funktionalen Produktionsteams die komplette Struktur und Kultur eines Unternehmens auf den Kopf und in Frage stellt. Gerade dann, wenn dieses Team alle zwei Wochen ein marktfähiges Produktinkrement ausliefern soll und dabei die komplette Produktionskette von der Idee über die Konzeption, das Design, eine testgetriebene Entwicklung bis hin zu einem automatischen und schnellen Deployment mit Livegang abdecken soll.

Ein Scrum Master oder ein Agile Coach, der dies bewerkstelligen möchte, wird dies selten alleine schaffen. Hierzu bedarf es weiterer Unterstützer, die die agile Transition im Unternehmen mit voran treiben. Ein Team von Änderungswilligen - ein Transition-Team.

Ansatz

Dieses Transition-Team hat zur Aufgabe, sich um den Änderungsprozess zu kümmern und Hindernisse, die im Unternehmen existieren, aus dem Weg zu räumen. Diese können mannigfaltig sein:

Zugehörigkeit von Produktions-Team-Mitgliedern zu Spezialistenteams, die nur anteilig in den jeweiligen - meist mehreren - Projekten mitarbeiten.
Eine Vielzahl von unklaren Beauftragungskanälen, über die das Produktions-Team bombardiert wird.
nicht-priorisierte und unter Umständen gegensätzliche Anforderungen
Führungskräfte, die ihren Mitarbeiterstab verwalten anstatt die Produktions-Teams zu unterstützen.
Raumprobleme, die eine Vor-Ort-Zusammenarbeit des Teams nicht ermöglichen.
Probleme durch bestehende Abteilungs-Rivalitäten, die durch die neue Zusammensetzung im cross-funktionalen Team nun zu Tage treten.
Räumliche und kommunikative Trennung zwischen Auftraggeber (häufig Produktmanagement) und dem Produktionsteam.
fehlende Markt- und vor allem Kundenfokussierung
und vieles mehr

Wie man sieht, ist das Themenspektrum sehr breit gefächert und betrifft sämtliche Bereiche einer sinnvoll angelegten Transition und in der Regel auch alle Unternehmensbereiche. Darüber hinaus sind dies Themen, die unter Umständen lange gelebte Vorgehensweisen im Unternehmen in Frage stellen und deshalb heikel sind und nicht selten in ausgewachsene Konflikte ausarten.

Aus diesem Grund sollte die Zusammensetzung des Teams folgenden Anforderungen genügen:

Das breite Aufgabenspektrum sollte sich auch in der Auswahl der Team-Mitglieder widerspiegeln. Sinnvoll ist es hier, eine Auswahl aus möglichst vielen beteiligten Abteilungen und Geschäftsbereichen des Unternehmens zu treffen. Nur so kann sich das Team erfolgreich um sämtliche Probleme und Hindernisse im Unternehmen kümmern.
Die Team-Mitglieder sollten über ein hohes Maß an Macht und/ oder Reputation im Unternehmen verfügen, um Änderungen auch in schwierigen Feldern durchsetzen zu können und den betroffenen Personen sowohl die für Änderungsprozesse völlig normalen Ängste nehmen zu können als auch den Glauben an die Sinnhaftigkeit des Vorhabens zu vermitteln.
Sie sollten sich als Change Agents verstehen und Änderung und die kontinuierliche Verbesserung als wichtiges Gut ansehen und massgeblich voran treiben.
Nicht zuletzt sollten die Team-Mitglieder agile Werte und Prinzipien kennen oder sich diese aneignen und im eigenen Alltag leben. Nur so können die Team-Mitglieder andere Personen im Unternehmen von den Vorteilen einer Transition überzeugen.

In der Regel wird sich ein Transition-Team wie ein agiles Produktionsteam auch ein Backlog aufbauen, das es gewichtet, priorisiert und abarbeitet.

Ebenso würde ich regelmäßige Retrospektiven anraten, um die unternommenen Schritte zu überprüfen, ob sie die gewünschten Erfolge erzielt haben oder aber ein Strategiewechsel notwendig ist. Auch hier gilt: inspect and adapt!

Rollenbeschreibung

Eine konkrete und in Stein gemeißelte Rollenbeschreibung ist im Gegensatz zu einem nach Scrum arbeitenden Produktionsteam nicht vorgegeben oder Bedingung.

Ich habe jedoch die Erfahrung gemacht, dass als Product Owner eines Transition-Teams wahlweise der Scrum Master des Produktionsteams erfolgreich fungieren kann, oder - sofern etabliert und vorhanden - ein Agile Coach. Diese können aus der Erfahrung und aus dem konkreten Produktionsalltag Themen platzieren, bei denen das Produktionsteam regelmäßig an seine Grenzen stößt und die ein politisch gut aufgestelltes Transition-Team helfen kann, zu überwinden.

Einen Scrum Master für das Transition-Team zu etablieren, ist sicher nicht schlecht. Hängt aber maßgeblich von der bereits vorhandenen Erfahrung in agilen Teams ab und vom gusto der beteiligten Personen. Es könnte jedoch die Effektivität des Transition-Teams steigern, andere Personen von agilen Werten zu überzeugen, wenn es selbst nach eben diesen Werten arbeitet. Hier hilft nunmal ein Scrum Master essentiell.

Ansonsten gibt es natürlich die Team-Mitglieder, die sich um die Änderungen im Unternehmen kümmern und den Kontakt zum Produktionsteam halten - den Kern des Teams.

Gewinn

Zweifelsfrei ist der größte Gewinn eines Transition-Teams die Unterstützung eines Agile Coaches oder Scrum Masters, Hindernisse, die dem Produktionsteam begegnen, aus dem Weg zu räumen. Darüber hinaus sollte es Ansprechpartner, Multiplikator und „Marketing“-Organ für das Thema Agilität im Allgemeinen und die agile Transition im Unternehmen sein.

Wie jedes Änderungsvorhaben in Unternehmen ist auch eine agile Transition vielen Vorbehalten und Angstreaktionen ausgesetzt. Diese gilt es, zu lindern und möglichst zu heilen. Dies können im Unternehmen gut vernetzte Personen am besten, da sie einen Vertrauensvorschuss besitzen. Und in einer Gruppe von Mehreren lässt sich das Thema auch leichter streuen, als alleine. Darüber hinaus können die Team-Mitglieder sich mit ihren Erfahrungen gegenseitig befruchten und coachen, sollte ein Thema mal nicht erfolgreich platziert werden können. Dort wo einer der Team-Mitglieder im Änderungsprozess scheitert, kann dann der andere übernehmen. Letztlich hat man mit der richtigen Auswahl der Beteiligten auch Personen an der Hand, die auch weitreichende und schwierigere Änderungsentscheidungen tatsächlich durchsetzen können, da sie über die nötige politische Macht im Unternehmen verfügen.

Gefahren

Wie bereits erwähnt ist die Auswahl der passenden Team-Mitglieder der Punkt, der über den Erfolg oder Misserfolg eines Transition-Teams entscheidet. Wenn die Team-Mitglieder zu wenig Macht im Unternehmen besitzen, werden ihre Bemühungen an neuralgischen Punkten ins Leere laufen. Das Team wird unter Umständen seine Änderungsarbeit aus Mangel an Erfolgen einstellen.

Was ich aber auch beobachte, ist eine Besetzung mit politisch gut aufgestellten Personen, die aber weder die Kernzüge von Agilität verstanden und verinnerlicht haben noch den nötigen Änderungswillen mit sich bringen. Häufig eine Folge aus der wenigen Kenntnis über agile Werte und die dabei geänderten Anforderung an Führung. Im Extremfall wird aus einem Transition-Team eine Art Lenkungsausschuss, der über den inhaltlichen Erfolg des Produktes entscheidet und sich im Grunde nicht mit einer Änderung des bestehenden Systems und der Kultur beschäftigt und somit den Namen Transition-Team zu Unrecht trägt. Damit kommt jede Änderung und Hilfe für die Produktionsteams zum Erliegen.

Fazit

Ein Transition-Team kann bei einer agilen Transition ein sehr hilfreiches Mittel sein, um die Probleme, an die ein oder mehrere Produktionsteams beim Hand-over zu anderen Abteilungen stoßen, aus dem Weg zu räumen.

Wichtig dabei ist die sorgfältige Auswahl der Personen, die in einem solchen Team sitzen. Sie sollten ein hohes Maß an Änderungswillen, ausreichend Know-How im Bereich Agilität und die nötige Macht besitzen, kulturelle und systemische Probleme lösen zu können.

Is your Product Owner writing Acceptance Tests?

hedi.buchner — Tue, 24 Nov 2015 23:00:00 +0000

Were you ever lucky enough to work with a Product Owner who actually writes acceptance tests?

My experience as Agile Coach is that most of the Product Owners don't write acceptance tests. Lucky enough in my last project I was Product Owner. And therefore I decided to establish ATDD within my team.

Within the Scrum Team we quickly agreed that code and product quality is highest priority. We set up a Definition of Done consisting of Unit Tests, Integration Tests and Behavior Driven Tests. Now we are using the Spock and Geb framework to implement our behavior driven or acceptance tests and test features from the user’s perspective.

The syntax is really easy to learn as you describe a situation in the given - when - then format. Each situation then represents a test case.

given: "an empty bank account" // ...

when: "the account is credited $10" // ...

then: "the account's balance is $10" // …

Even if the Product Owner isn’t able to cover all test scenarios it is still very helpful to define the most important ones. I was lucky enough to be able and rely on the support of the whole team to add missing test scenarios.

Whenever I managed to live Acceptance Test Driven Development I immediately benefited from it: it is really helpful to have a structured approach to explore the behavior of the product feature. This definitely enhances the product quality.

It also helps to maintain the overview while switching between different levels of details: stakeholder and customer management and product strategy on the one hand, technical details, daily work and delivering software every sprint on the other hand.

And last but not least: we finally have a living documentation!

Neuigkeiten vom Kanban Leadership Retreat I: Der Kanban Management Professional

jens — Mon, 13 Jul 2015 11:07:00 +0000

Letzte Woche fand in Mayrhofen das jährliche Kanban Leadership Retreat statt, auf dem neben viel Austausch unter anderem auch die aktuellen Veränderungen bei der Lean Kanban University (LKU) diskutiert wurden.Die für viele vermutlich interessanteste Nachricht: Die LKU erweitert ihr Zertifizierungsprogramm um die offizielle Ernennung zum „Kanban Management Professional“ (KMP).

Wie fügt sich der KMP ins LKU Zertifizierungsprogramm ein?

Der KMP bildet zukünftig eine der Voraussetzung für die Zertifizierung zu den bereits etablierten Zertifikaten zum „Kanban Coaching Professional“ (KCP) und zum „Accredited Kanban Trainer“ (AKT).

Wie bekomme ich die Ernennung?

Voraussetzung für die Ernennung zum KMP sind die beiden jeweils 2-tägigen LKU-zertifizierten Trainings „Kanban Foundations I“ und „Kanban Foundations II“. Wer beide Kurse absolviert hat, erhält die Ernennung zum KMP automatisch. Das bisher angebotene Training „Kanban Foundations“ ist weitgehend identisch mit dem ersten Kurs und wird als „Kanban Foundations I“ anerkannt.

Was lerne ich in den Kursen?

Foundations I - The Kanban Method: Elemente eines Kanban Systems, das Pull-Prinzip, STATIK zum Aufbau eines Kanban Systems
Foundations II - Practicing the Kanban Method: Die sieben Fedbackschleifen in Kanban, Planung großer Projekte, Entscheidungsfindung und mehrfache Commitmentpunkte, Terminfindung (Inhalte voraussichtlich)

Kann ich alle Kurse bei improuv machen?

Ja. Unsere Trainingstermine finden sich auf unserer Trainingsseite.

Scrum is about Delivery, not about Planning

krishan — Tue, 07 Jul 2015 05:07:00 +0000

If you watch an arbitrary discussion about Scrum – at a user group, a conference, or any other opportunity – you could easily come to the conclusion that Sprint Planning is the major and most important ceremony in Scrum. People religiously discuss about the format of user stories, the “Definition of Ready”, and whether teams should compare their estimations with what it actually took them to finish a story. It becomes even worse when you look at Scrum tools: They usually offer at least three different approaches to estimation and tracking you can choose from and most users choose all three at once. Observing organizations that take this approach you often come to the impression that they use most of their time for planning, while the rest of their time is wasted complaining about “all this Scrum overhead”.

But Scrum is not about planning! It is neither about Story Points nor Sprint Commitment nor Backlog Grooming. Scrum is about Delivery in first place. And about Learning in second.

What many planning and reporting enthusiasts ignore is the fundamental change that comes with fast sprints. If you deliver every second week (or even more often), you don’t need to invest days into breaking down stories into tasks, estimating them and comparing them to earlier estimates. You don’t need to “track progress” by tasks accomplished. Either a story is done or it isn’t. “The primary measure of progress is working software” is one of the agile practices from the Agile Manifesto and Scrum is no different.

If a team focuses on delivering valuable software at a constant pace, five or ten stories a week, you can simply get rid of all the overhead ceremonies of waterfall as much as you don’t need to provide food, drinking, sleep or combing off to your car, although that was a great idea when you were still using horses to get to the next town.

So why does Scrum feature a Sprint Planning Session anyhow? One important aspect of delivering software is the alignment on what to deliver. Estimating a new feature is an excellent way to think through it in detail. And estimating as a team using planning poker makes sure that you have the diverse competencies of your team aligning on what to build. Planning in Scrum helps you to go through this process in a disciplined way. This simplifies delivery and reduces bad surprises, which is of tremendous value. Nothing more.

And what about all these important client commitments and deadlines you have to take care off? Of course these are important preparations to earn money with the software you delivered. But this has only very little connection to Sprint planning. If you want to predict what the team does, use statistical analysis of what the team actually did deliver – which is way more accurate than analysis of what they thought they’d deliver. You can use all kinds of analysis tools here, probability funnels and empirical planning being only the most prominent ones. As long as the priorities are set right, you will generate way more value than you did without Scrum.

If you do these types of analysis, you may find that the estimation accuracy is among the least important influence factors to the stability of your plans. Most of the times stability is about setting a context in which the team can deliver in a stable frequency. And this does not need more accurate predictions, but a thorough understanding and adoption of agile development practices and an environment that is focused on supporting the teams and not micro-managing them. If you trust your team, let them do their work. If you don’t trust the team you have a completely different problem that no planning approach can solve.

So when you do Scrum, relax about planning. As long as you set the right priorities and the team delivers at a consistent pace, things are fine. And if you have problems with any of these, it is the Retrospectives where this needs to be solved. Just ask your team “What do you need to deliver?” – and for heaven’s sake listen to their answers! If you save two hours per sprint by getting rid of over-accurate planning, these Retrospectives even come for free.

Team-Methoden - Teams in skalierter Umgebung, Teil 3

krishan — Wed, 03 Jun 2015 01:06:15 +0000

Scrum/XP als Grundlage

Teams nutzen in der Regel eine solide Implementierung von Scrum als Hauptgrundlage und liefern wertvolle Software nach jedem Sprint, also in der Regel alle zwei Wochen.

Sie verwenden die Rollen, die in Scrum definiert sind: der Product Owner repräsentiert die Autorität über die umzusetzenden User Stories. Der Scrum Master treibt den kontinuierlichen Verbesserungsprozess auf Teamebene und arbeitet an der Beseitigung von Hindernissen. Die Teammitglieder arbeiten gemeinsam an der Realisierung der Software. Sie sind Spezialisten und gleichzeitig Generalisten, die bei Bedarf auch außerhalb ihres Spezialgebiets aushelfen können.

In Scrum hat sich herausgestellt, dass Teams eine schwere Zeit haben, wenn sie keine adäquaten agilen Softwaretechniken verwenden und das Versprechen, flexibel änderbare Software im Sprinttakt zu liefern, schwer einlösen können. Diese agilen Softwaretechniken kommen aus Extreme Programming und sind normalerweise ein fester Bestandteil der Scrum-Implementierung.

Teams im Kanban-Modus

Manche Teams finden es einfacher, sich selbst als Kanban-Teams zu verstehen, wenn ein Großteil ihrer Arbeit Event-getrieben definiert ist. Das können Teams mit einem hohen Anteil an Wartungsarbeiten sein, vor allem haben aber System-Teams und DevOps einen Aufgabenmix, der die Nutzung von Kanban nahe legt.

Der Vorteil von Kanban gegenüber Scrum kann in einer schnelleren Reaktionszeit für neue Anforderungen und in einem geringeren Planungsoverhead liegen. Kanban nutzt auch stärker Metriken, um die Arbeit des Teams zu verbessern und zu beurteilen. Insbesondere das kumulative Flussdiagramm (cumulative flow diagram, CFD) zeigt sehr schnell die Entwicklung der Wertschöpfung eines Teams und ggfls. ein zu hohes WIP-Limit.

Auf der anderen Seite unterliegen Kanban-Teams ähnlichen Restriktionen wie Scrum-Teams, damit sie effektiv in einem Release Train arbeiten können:

Kanban-Teams haben dieselben Anforderungen an Code-Qualität
Sie brauchen ein Äquivalent zum Product Owner, um schnelle, dezentralisierte Entscheidungen herbeizuführen
Sie übernehmen dasselbe Commitment zu Release-Zielen und managen Abhängigkeiten zu anderen Teams
Sie nehmen an der Release-Planung, den anderen Meetings und der dazugehörigen Planung und Schätzung teil und arbeiten im selben Release-Rhythmus

In einem Release Train können mit diesen Randbedingungen Scrum und Kanban basierte Teams koexistieren und jeweils die für sie beste Arbeitsform nutzen.

Team-Skills und –Qualitäten - Teams in skalierter Umgebung, Teil 2

krishan — Wed, 27 May 2015 22:00:00 +0000

Codequalität und Architektur

In einer größeren Entwicklung wird der Effekt schlechter Codequalität viel stärker wirksam: die Teams verlassen sich nicht mehr auf Zulieferungen, können keine realistischen Vorhersagen machen oder Commitments abgeben.

Eine skalierte Umgebung produziert in aller Regel langlebigen Code, die Effekte schlechter Qualität summieren sich auf und behindern die Lieferfähigkeit nachhaltig. Deshalb ist Codequalität ein zentraler Baustein für ein effektives agiles Team und einen effektiven Release Train.

SAFe zieht daraus die Konsequenzen:

Kontinuierliche Integration beibehalten (erfolgreiche Integration ist der wichtigste Indikator für Codequalität und stellt die agile Qualität des gesamten Organisation in Frage)
So viel Vorausschau wie nötig – mit dem „architectural runway“ werden auf kooperative Weise notwendige zentrale Festlegungen getroffen
Im Takt stabilisieren – auf Teamebene und auf Train-Ebene gibt es regelmäßige diese Stabilisierungspunkte mit dem Sprint Review und dem Release-Review Meeting.

Alignment - Unterschiede zu einzelnen Teams

Da ein SAFe Team nicht mehr autonom über alle Aspekte seiner Arbeit bestimmen kann, muss der Backlog für das Team mit dem übergreifenden Backlog abgestimmt werden, zum anderen, dass kritischen übergreifende Entscheidungen zu Schnittstellen und zur Architektur koordiniert werden müssen.

Der Product Owner, Scrum Master und die übrigen Teammitglieder haben zusätzliche Aufgaben, an der übergreifenden Planung, Koordination und dem Lernprozess des gesamten Trains mitzuarbeiten.

Transparenz

Agile Teams benötigen umfassende Transparenz, um gut funktionieren zu können. Verschiedene Maßnahmen tragen zu dieser Transparenz bei:

Alle Backlogs und der Arbeitsstand aller Teams sind kontinuierlich sichtbar
Die Teams stellen sinnvolle Kennzahlen bereit, die auf funktionierendem, getestetem und abgenommenen Code beruht.
Alle Beteiligten verstehen die Konzepte eines Backlogs, Velocity und Work-in-Progress.

Diese Transparenz muss übergreifend sichergestellt werden, die dazu notwendige offene Umgebung muss durch das Management sichergestellt und unterstützt werden.

Planung und Schätzung

Das einzelne Team leistet auf verschiedenen Ebenen einen Beitrag zur Planung:

Das Team schätzt in seiner Scrum-Rolle seine User Stories (als Teil des IP-Sprint oder in Backlog-Refinement-Meetings) und liefert damit für seinen Product Owner eine Schätzung für die nächsten Sprints
Das Team übernimmt als Ergebnis der Sprint-Planung die Verantwortung für User Stories
Die Teammitglieder nehmen zuvor am Planungsmeeting der Programmebenen-Iteration, dem Programm-Inkrement (PI) teil und erstellen dort eine gröbere Vorausschau für die Sprints während des Programm-Inkrement (PI, der grundlegende Releasezyklus bei SAFe).

The Failure of Cargo Cult

krishan — Mon, 25 May 2015 22:00:00 +0000

Andy Hunt, one of the authors of the Agile Manifesto, has posted a blog post about "The failure of Agile". In spite of its headline, it is a very interesting post and Andy complains about mainly the same problems, that annoy me - and I am sure, many of us: an incomplete understanding of Agile. To me, this is not Agile, it is the absence of Agile. It describes going through the motions without understanding the spirit. Like standing in a circle once a day or defining a regular interval for delivering crap. This is characteristic for a different phenomenon: Cargo Cult. Indeed, Cargo Cult it is a widely spread plague in the agile world. There are more and more people (including me) who become restless about this ever spreading disease and are looking for new ways to approach it. Andy Hunt describes a very interesting approach and proposes a few foundational ideas:

Evidence-based
Dreyfus Skill Model
Local Adaptation
All-Inclusive

and proposes to work incrementally on them: he names the the GROWS method. My understanding of the characteristics are

Evidence-based - like in retrospectives? Yes, good idea. What you need next is a concept of "better", in other words some metrics about practices and results. Otherwise many people will continue to perceive the retrospective a mere tree-hugging event. If we talk about measuring and metrics, we need to have a conversation about how to use them (and how not to use them), which will lead to a renewed discussion about a culture of trust and transparency.
Dreyfus Skill Model - I found it a pretty useful model about how learning steps can be described (some complain about its somehow week scientific foundation, which I don't care about). It gives us a hint how to develop useful and effective learning steps for different people and situations. It does not, however, give a lot of details about how organizational learning happens. Other models like the SECI or Team Ba model (this post is in German, you can find the English source here) can step in here.
Local Adaptation - I am not sure I understood this part, but it looks like using an evidence based approach to selecting the right software method
All-Inclusive - I am curious about that part, because it is the part with the hard work. If you look into the FAQ of the GROWS method, you find "coming soon". Fair enough, the model is open for discussions.

Anyway, I think, Andy addresses one of the crucial road blocks, which we have to address when we want to make Agile a sustaining success. On the other hand, he falls short in describing the overall picture: the problem is not the software, it is the people and the environment of the software development teams. If I had a Christmas wish, it would include a stronger emphasis on the agile culture of the whole company. I would propose a slight rewriting of the four foundational ideas:

Focus on continuous improvement on all levels. Better software is important. Better collaboration and the growing of better products have at least an equally large impact on the success of an organization.
Drive Learning and alignment on dynamic goals as a cornerstone and develop specific measurements, metrics and feedback topics.
Engage the whole organization into growing a Lean and Agile Culture. Use the existing knowledge about Lean (the context in which the concepts of the learning organziation were invented).
Focus on developing values. Values have a longer life and deeper impact than pure practices. Develop a culture of autonomy, trust, respect and excellence.

Teamstrukturen und Einteilung - Teams in skalierter Umgebung, Teil 1

krishan — Thu, 21 May 2015 19:05:15 +0000

Multifunktionale stabile Teams

Die Größe von selbstorganisierten Teams ist begrenzt, erfahrungsgemäß funktionieren sie bis zu einer Größe von ca. 10 Personen, darüber bilden sich Untergruppen, die tägliche Kommunikation leidet. Diese Grenze ist durch die Zahl der Menschen, die wir gleichzeitig im Blickfeld haben können begrenzt und durch langjährige Erfahrung abgesichert.

Teams ersetzen in einer agilen Umgebung die funktionalen Silos einer traditionellen Organisation. Sie bauen, testen und liefern in kurzen Intervallen und ermöglichen damit einen transparenten Projektfortschritt.

Feature Teams

Die meist bessere Strukturierung der Teams ist in Feature-Teams innerhalb eines Release Trains. Teams können damit einfacher in kurzen Zyklen lieferfähig bleiben. Falls dies gar nicht möglich ist, sollten die Teams thematisch strukturiert sein, z.B. zu Produkten, Interfaces oder Subsystemen.

Der Agile Release Train als Team von Teams

SAFe nutzt die Erkenntnisse über effektive Teams und ist effektiv als eine Struktur von „Teams von Teams“ konstruiert. SAFe baut auf multifunktionalen stabilen Teams auf, die die Entscheidungsbefugnis haben, ihre Arbeit selbst zu organisieren und die möglichst an einem Platz zusammenarbeiten. Sie umfassen Entwickler, Tester und alle anderen benötigten Rollen und sie verwenden bewährte agile Methoden insbesondere Scrum und die agilen Softwareentwicklungsmethoden aus Extreme Programming

Der Release Train folgt ähnlichen Strukturen wie das einzelne Team. Er ist ebenfalls selbstorganisiert - wegen der größeren Zahl von beteiligten Personen müssen notwendigerweise neue Strukturen eingeführt werden. Dazu gehören Strukturen, um den Kommunikationsaufwand zu begrenzen - insbesondere finden Meetings mit allen Beteiligten in größeren Intervallen statt und es werden neue Rollen zur Koordination eingeführt.

Scaled Program Planning from the Trenches

stuart — Tue, 17 Feb 2015 07:05:15 +0000

I am a Scaled Agile Framework coach and trainer and it amuses me to sometimes see the blood drain from the faces of Agile practitioners when I say "yeah, I really like SAFe, I´ve learned a lot" :). The reaction comes from interpretation. The Big Picture really is Big. When I give a Leading SAFe course and ask for feedback at the end, participants often say "Wow, I never knew there was so much in it, I´m really going to need to sit down and think about this". It´s been said that one of the best things about the framework is the Big Picture, and one of the worst things about the framework is, yes, you guessed it, the Big Picture. Its big and open to interpretation. One (false) interpretation is that in order to "do SAFe", you need to implement the entire Big Picture, with its full collection of roles, responsibilities, meetings and metrics. But, when asked "how to start", the answer really is" start with what and where it makes most sense to your enterprise". In any case, I´m not going to get bogged down in defending SAFe, or trying to justify it, what I plan to do in this and similar blogs is simply present what I´ve seen implemented "in the field" with living-breathing-paying customers, and then you can decide what is good or not, and what might make sense in your context.

This first blog in the series relates to the Program Level. SAFe talks about four areas of an enterprise that we typically need to address if we are to be successful with Agile at scale:

From the Program level, lets take a short look at the Program Increment Planning Event.

This is often referred to as the “Release Planning event”. This is misleading as we are not planning a release, we are planning an increment of our agile product development program (our aligned set of teams focused on delivering into one value stream). When we actually release is up to the business – we may have continuous delivery, release after each sprint etc. The thing to remember is “develop on (a regular) cadence, but release on demand”. To remove confusion with one customer who felt they were being flooded with new terminology, we call this program increment a “super-sprint”. We sprint the program. This has worked well in building a common mindset.

The use of the super sprint term has proven quite useful as a tool to remind people what we are up to. We say “hey, you are all familiar with working with scrum, well what we now plan is to introduce a super sprint for the whole team-of-teams (Agile Release Train). We´ll start with a “super sprint planning” event where the chief product owner describes the “what” of what is desired over the coming super sprint (typically 5*2wk sprints). You, the teams, will then create a high level sprint-by-sprint plan for what you believe (with the information you have available during the planning event) you can achieve during the super sprint. We´ll align the “business” with the teams and create a set of high-level super-sprint objectives, then we´ll hold a vote to determine how confident we are that we can achieve these objectives during the coming 10 weeks. After working in sprints for 10 weeks, we´ll then hold an inspect & adapt event where we review what we have achieved, look at some metrics, then retrospect on some issues that arose during the super-sprint and find potential solutions to some issues that can positively impact the next super sprint. Repeat”. This is a simplified description of the core elements program level increment in SAFe. But the “sprint” analogy works in connecting the new level of planning with the familiar scrum planning cycle.

In practice we´ve had great success using the planning meeting agenda proposed by SAFe. The typical planning event is planned for two days, but we´ve also had success running this in a single day with release trains (team-of-teams) of less than 7 teams. For a detailed look at this event then come along to one of our Leading SAFe courses where we deep-dive into the program level and carry out an exercise to simulate such an event.

Typical one-day planning agenda:

Inputs for the planning event are:

Prioritized set of features from product management. We often see a set-up with a Chief Product Owner and team Product Owners formed into a product ownership team.
Stories (ideally estimated - a must for a one day event) for the features
Vision and roadmap

The day runs like this:

The business owner (often the CEO or SVP responsible for a value stream) starts with a pep-talk to set the overall mission for the business. Setting the big business context.
The head of product (Chief Product Owner, Product Manager..) presents the vision for the upcoming planning horizon and the high level roadmap. Sets the sense-of-purpose for the team-of-teams. She/he then introduces the priortized features to to the entire team.

Prioritised feature (and stories) laid out prior to planning

Architecture/DevOps then present Architecture and Ops topics that may impact the teams in the coming weeks. Typcally this could the CTO setting the big architecture picture ("we've made a platform decision and this is reflected in stories, we´ll need to support the SDK, we have some new NFRs (non-functional requirements), the continuous integration flow will change etc.). Basically setting the "big picture" for technical issues. The day to day/sprint-to-print technical design still mainly resides in the teams.
The release train engineer (chief scrum master - agile enterprise coach - call the role whatever you like) then reminds the team what the objective of the planning is, discusses practical & logistic issues, and makes sure all roles & goals are known before the first team break-out session starts.
Development teams then "break-out" into their respective teams and start to plan 4 sprints based upon features and stories pulled into their team by the product owner. They leave the 5th sprint (if you are using a 5 sprint planning cadence) free to allow for planning, innovation and (yes, it´s true) a little buffer for work that either spills over from the 4 sprints or emerges from the normal sprint flow). From a LeanAgile perspective, this capacity buffer allows us to "trade uncertain earliness for certain lateness".

After the first break-out session, the Business Owner and product team carry out a management review so discuss what has been learned so far - and face the reality of what is likely to be achievable compared to their original wish-list. They have a chance now to make some changes to the original plan so that they can maximise the value likely to be achieved over the 10 weeks.
After some potential planning changes resulting from the management review, teams go into a second break-out session and continue to plan the 4 sprints. There is a lot of evergy in these break-out sessions, with open communication between teams to discuss dependencies and trade-offs.
With the end of break-out two, teams present their high-level objectives for the 10 week period, identify risks, and take some questions. If accepted (and the business owner/POs have been "doing the rounds" during the second breakout to follow progress), then each teams objectives are collected to create the aggregated team-of-teams (release train) objectives. We now have a high level set of program objectives.
As a group, we review the risks associated with our plans - this usually involves quite a bit of inter-team discussion
Finally, once all objectives have been collected and accepted by the business owner, and risks have been discussed, the team take a confidence vote to indicate how confident their are that we can achieve this set of objectives in 10 weeks. The teams of teams "comittment" at the end of the planning event is a) we are confident that, given what we know now, we can achieve these goals and, b) as soon as things change, we´ll inform product and discuss the changes to objectives.

Tips

I was worried the first time I facilitated such an event: how will it run? will we be able to reach a plan? how can we steer such a large group of people through such an agenda? But it all went well - and has gone well ever since. The planning day/s works. But here are a couple of tips:

Run a simulation exercise (i.e. simulating the actual planning event) with as many people as possible from the teams who will participate. This is critical in surfacing questions, setting expectations, and helping everyone understand the appropriate level of abstraction.
Prepare the features and stories - and estimate (even if you use magic estimation so initially estimate a large number of stories. Remember CICO: crap in, crap out :)
Create a clear vision for the 10 weeks (make it short and with a marketing feel - not a 30 page doc.)
Respect your team - make sure participants know that, ultimately, planning is in their hands
Get trained - if you will follow a SAFe approach - get some trained people on the ground
Continually challenge the plan - if the plan doesn´t change during the 10 week "super sprint" - then something is probably wrong :)

NEXT BLOG: ok, so that´s a little about the program planning event. Next time I´ll talk about one great output of this event - the Program Board. And how we´ve been using (and adapting) this with customers.

Pimp up your meetings! - a move "Management Status Update" to Agile Peer Review.

stuart — Mon, 20 Apr 2015 18:04:00 +0000

I'm up in the North of Germany supporting a customer improve their Agile practices and their probability of getting a complex multi-platform product out into the market. I´m not allowed to say who they are, but let's just say that they face a range of common challenges and that they plan to enter a competitive international market that places a high value on simplicity and usability.

The brief subject of this blog is the "horror twice-per-month status update meeting". A meeting where the Business Owner (CEO), Management team (CEO-CTO-COO) would come together with the PO´s of Agile teams to "report on status". On observing the meetings we noticed that they were using traffic-light reports to report on sub-project status (green=really good, everything is going just swell, amber=some problems but, honest, really not too bad, almost good!, red=bad, and so we´ll just try to avoid using that color). What was clear from talking to people before and after the meetings was that in the meeting no-one actually really knew the whole "status" (or certainly weren´t feeling the need to verbalize it). Things did not look too good. No-one felt good going into or coming out of the meeting. The only learning seemed to be - this meeting sucks!

To escape the horror of the status meeting, we´ve started to use a meeting format we ourselves use in improuv. Now you all probably know improuv and that we are all happy, smily agilists - but we are not hippies! We also need to get things done! When we come together as a team we need to update each other briefly on what we´ve been doing, are doing and will be doing, we need to share and create knowledge, and we need to surface and discuss relevant (to this group) topics that need attention/discussion/decision/agreement. And we need to do all this in a timebox that doesn´t require caffeine and Acupuncture to keep us alert and active until the end of the meeting :)

The new Peer Review with the customer now follows the following format:

Timebox: 1.5 hrs

Participants: Management team, Chief Product Owner/Product Owners, Key Stakeholders, agile coaches

Location: held "standing up" in front of big visible charts (see image below)

Moderator: Agile Coach (or member of the team)

Agenda:

1) The Standup

Each participant gets up to 2 minutes to give a brief update on:

- what my team and I have been doing in the past 2 weeks (relevant highlights)

- what we are currently working on

- what is planned (highlights) for the coming 2 weeks

- any major impediments relevant to this meeting group (not discussed unitl 2nd phase of meeting)

NOTE: when doing this for the first time, important to brief participants and ask them to gather their thoughts "before" the meeting - if not then you´ll get a lot of rambling unstructured comment :)

2) The Market Place

This part of the meeting lets the team dig into issues and impediments that need to be addressed. To structure this we use a board. Here is how we do it (see the board below):

- each participant is asked to write down issues (on postits/cards) that they wish to bring up and discuss in the group

- they are then asked to standup, place them on a board, and simply read out what they have on the card (but no discussion). Issues are placed on the board in three swimlanes:

--> less than 2 minutes: these are thinsg that I, as a participant, think we can discuss/agree/decide very quickly - in less than 2 minutes

--> 5 minutes plus potential 2 minute extensions: I think this is a larger topic that may take 5 minutes or a little more

--> 15 minutes plus potential 2 minute extension: bigger topics that will need some time to discuss

Timeboxing: the moderator needs to keep strict timeboxes. When the time comes to "extend" the timebox for the 2nd and 3rd swimlanes, the moderator first asks the team if they wish to extend the timebox (thumbs up/down). And only if the group decide it´s worth continuing do you continue for another couple of minutes (you may agree to take an issue offline, park it until another time etc.)

MODERATION: this phase needs good timekeeping = good moderation. For this customer, the senior Agile Coach takes over this role. In other cases the moderation role rotates through the team.

3) The Theme Section (Knowledge exchange)

This part of the meeting is used to deep dive into other relevant topics. The topics can be agreed and communicated before the meeting or, as often happens, someone from the management team come to the meeting with one or two keep topics/updates/issues that they wish/need to discuss and reyolve within this group. Whatever best works for you!

Feedback from the team: "wow, I´m surprised how much value we now manage to get out of this meeting"

Give this approach a try - and inspect & adapt as you go.

Agile Teams brauchen eine Agile Organisation

krishan — Mon, 06 Apr 2015 04:04:15 +0000

Skalierung, Kultur und Agile Evolution - Teil 1

Teams existieren nicht in einem abschotteten Universum: sie sind Teil eines Organisation und sind entsprechend starken Einflüssen der Organisation ausgesetzt. Wenn man also meint, dass es ausreicht, in einem Team zu arbeiten, um die Kultur nachhaltig zu verändern, steuert auf einen frustrierenden Fehlschlag zu.

Lernen als verstandenes Ziel der Organisation

Die Beschreibungen von beschleunigtem Lernen haben eine gemeinsame stille Voraussetzung: die Organisation als Ganzes versteht die Notwendigkeit des ständigen Lernens.

Das bedeutet, dass

Die Aufgabenstellung es überhaupt ermöglicht, Inkremente zu liefern
Altlasten und unnötige Komplexität als zu adressierendes Problem verstanden werden
Das Team eine gewisse Stabilität haben muss
Alte Denkgewohnheiten und andere schlechte Erbschaften regelmäßig bearbeitet werden
Die Führungskräfte des Teams verstehen müssen, wie Führung, Motivation und Performance eines Teams zusammenhängen.

Aufgabenstellung und die Fähigkeit, Inkremente zu liefern

Product Owner finden es zunächst regelmäßig schwer, Aufgaben so zu gliedern, dass das Team überhaupt die Möglichkeit hat, am Ende jeden Sprints Werte zu liefern. Dabei ist dies die Schnittstelle, die vielleicht am wirkungsvollsten die Arbeit des Teams mit seiner Aussenwahrnehmung verknüpft: besser, regelmäßigere, zuverlässigere Lieferung in kurzen Abständen wirkt sowohl

nach innnen - das Team überprüft seine Arbeit und kann schnell Defizite erkennen und beseitigen
nach außen - nichts ist so sehr geeignet, das Vertrauen in die Arbeit herzustellen und damit den Rücken freizuhalten. Die agile Arbeitsweise zeigt ihre positiven Auswirkungen und immunisiert gegen Kontrollreflexe, die der Vorgesetzte haben mag.

Altlasten und unnötige Komplexität

Allerdings ist dies nicht immer so einfach zu erreichen: in der Regel arbeitet man auf der Basis einer bestehenden Code-Basis, die oft zu wenig strukturiert ist, Komponenten zu stark koppelt und oft auch nicht einmal über eine solide Basis an automatisierten Tests verfügt. Eine solche Codebasis zu erneuern ist langwierig und kostspielig.

Bei einer Einführung einer agilen Arbeitsweise müssen sich das Team und die Organisation (konkret: die Vorgesetzten) darüber klar sein, dass eine erhebliche Investition nötig ist, um die Vorteile nachhaltig zu erreichen und zu sichern.

Stabilität eines Teams

Ein weiteres Missverständnis is auch oft zu beobachten: ein Team entspricht nicht immer einem Projekt. Wenn man versucht, zu jedem neuen, vielleicht kleinen Projekt passgenau eine eigene Mannschaft zusammenzustellen, hat man zum einen dauernd eine andere Zusammenstzung der "Teams", zu anderen führt das dazu, dass jede Person typischerweise in vielen Kontexten arbeiten muss: das ist genau keine Umgebung, in der organisatorisches Lernen begünstigt wird.

Teams sollten stabile, langfristige Organisationseinheiten darstellen, während in vielen Firmen die Projekte wechseln und sich auch zun Teil überlappen. Das stellt die übliche Matrixorganisation auf den Kopf, in der die optimale "Ressourcesnauslastung" im Mittelpunkt steht.

Denkgewohnheiten und andere schlechte Erbschaften

Eine ganze Menge an Prozeduren kann ein Hindernis dafür darstellen, dass das Team eine gemeinsame Zielstellung und Ausrichtung entwickelt: von der Persönlichkeit eines einzelnen Vorgesetzten bis hin zu Incentives, Karrierebildern, Belohnungssystemen in einer Firma.

Eine Fiktion muss man noch nennen: in vielen Darstellungen von Scrum und anderen agilen Umgebungen steht das gute Team der bösen Aussenwelt gegenüber. Das alte Scrum-Bild von dem Huhn und dem Schwein ist das schönste Beispiel dafür.

Aber die Teammitglieder bilden in ihren Erwartungen und Verhaltensweisen die selben Werte ab, die allgemein in einer Firma gelebt werden:

Karriere und Teamverantwortung werden als Konflikt verstanden
Schuldzuweisungen sind fast immer der erste Reflex, wenn etwas schief geht

Deshalb ist eine Einführung von Aglität nicht einfach ein neuer Prozess - es ist vielmehr der Start zu einer tiefgreifenden Änderung in der Arbeit und der Zusammenarbeit, in den Erwartunge und den Zielen - kurz gesagt, der Kultur.

Teil 1: Vier Vorteile agiler Teams

Teil 2: Beschleunigtes Lernen ist Team-Lernen

Teil 3: Grenzen der Agilität in einem Team

Beschleunigtes Lernen ist Team-Lernen

krishan — Wed, 11 Feb 2015 10:02:15 +0000

Skalierung, Kultur und Agile Evolution - Teil 2

Beim Stöbern in meinen Unterlagen bin ich neulich wieder auf den bekannten Text gestoßen, in dem zuerst Scrum genannt wird: "The new new Product Development Game" von Hirotaka Takeuchi und Ikuriro Nonaka aus Harvard Business Review vom Januar 1986. Allerdings wird nicht Scrum in unserem Sinn als eine Entwicklungsmethodik für (meist) Softwareentwicklung genannt, sondern als Aspekt von Lean Development. Interessant sind die Schwerpunkte, die darin gesetzt werden: der erste ist die Vermeidung von Übergaben - Scrum wird darin in einen Gegensatz zu einem Stafettenlauf gesetzt:

Instead, companies in Japan and the United States are using a holistic method—as in Rugby, the ball gets passed within the team as it moves as a unit up the field.
This holistic approach has six characteristics: built-in instability, self-organizing project teams, overlapping development phases, “multilearning,” subtle control, and organizational transfer of learning. The six pieces fit together like a jigsaw puzzle, forming a fast flexible process for new product development. Just as important, the new approach can act as a change agent: it is a vehicle for introducing creative, market-driven ideas and processes into an old, rigid organization.
Under the old approach, a product development process moved like a relay race, with one group of functional specialists passing the baton to the next group … Under the Rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish.

Besonders ein Abschnitt hat meine Neugierde geweckt, der Abschnitt über das Lernen:

The shift from a linear to an integrated approach encourages trial and error and challenges the status quo. It stimulates new kinds of learning and thinking within the organization at different levels and functions. Just as important, this strategy for product development can act as an agent of change for the larger organization.

Spannend - aber mir war das noch nicht konkret genug, das erklärt noch nicht viel darüber, wie das funktionieren soll. Aber tatsächlich hat Nonaka mit Noburo Konno und anderen daran gearbeitet, wie dieses beschleunigte Lernen funktionieren könnte und hat einen dynamischen Prozess dafür beschrieben: das SECI-Modell für Wissensentwicklung. Der Prozess beruht auf einem Zusammenspiel von implizitem ("tacit") und explizitem Wissen und beschreibt zyklische oder spiralartige Phasen:

S - Socialization: in diesem Schritt wird Wissen durch implizite Erfahrung erworben, z.B. indem man nebeneinander arbeitet oder eine andere Form von physischer Nähe und direkter Erfahrung
E - Externalization: im nächsten Schritt wird das Wissen explizit ausgedrückt, das heisst, es wird in eine verstehbare Form gebracht, in der Dritte es verstehen können. Hier wird das Wissen auch für andere Teammitglieder zugänglich und es wechselt von einer rein impliziten in eine explizite Form.
C - Combination: damit ist auch die Voraussetzung gegeben, das neue Wissen in einen breiteren und komplexeren Zusammenhang zu stellen. Das ist eine Kernvoraussetzung für eine Systematisierung und Verallgemeinerung.
I - Internalization: im vierten Schritt des Zyklus werden die neuen Erkenntnisse in die tägliche Arbeit integriert und werden wieder Teil des persönlichen Skill Set.

Team-"Ba" als Voraussetzung

Das zitierte Papier nennt "Ba" als eine Grundlage für diesen Prozess. Ba ist Konzept, das einen gemeinsamen Bereich beschreibt, wie einen Arbeitsplatz oder Teamraum, gemeinsame Erfahrungen oder Einstellungen, in dem sich die Art von Beziehungen entwickeln können, die so ein gemeinsames Lernen ermöglichen.

Darum sind Teams so wichtig

Das hat für mich einige Fragen beantwortet, warum stabile selbstorganisierende Teams mit einem gemeinsamen Arbeitsplatz so wichtig sind

Sie bieten einen stabilen Rahmen für einen stetigen Austausch und hohe Bandbreite für gemeinsames Lernen
Teams in einem gemeinsamen Arbeitsraum können die Beziehungen und das Vertrauen aufbauen, das für die Entwicklung des Ba nötig ist
Selbstorganisation schafft den Grad von Autonomie, die für diese Art von Austausch unverzichtbar ist

Diese Vorteile muss man unbedingt mitnehmen, wenn man Agil im Grossen einsetzen will.

Teil 1: vier Vorteile agiler Teams

Teil 2: Beschleunigtes Lernen ist Team-Lernen

Teil 3: Grenzen der Agilität in einem Team

Vier Vorteile agiler Teams

krishan — Thu, 02 Apr 2015 02:02:00 +0000

Skalierung, Kultur und Agile Evolution - Teil 1

Warum ist Skalierung so schwer? Und weiter ausgeholt: warum ist es überhaupt so schwer, eine gute agile Implementierung umzusetzen? Man sollte sich einmal gründlicher ansehen, wie die Ergebnisse in einem guten, kleinen agilen Team aussehen und daraus ableiten, wie eine Skalierung, eine Umsetzung in einer realen Organisation und eine nachhaltige Implementierung aussehen müssten. Dann ergibt es auf einmal viel mehr Sinn, warum jetzt alle Welt von agilem Management redet - und andere meinen, Agil würde nur "die da unten" in der IT interessieren.

Die vier Vorteile agiler Teams

Kleine stabile Teams haben erstaunliche Ergebnisse erbracht. Mit ihnen wurde der Code geknackt, wie man effektiv, zuverlässig und kreativ Software entwickeln kann und es lohnt sich, genauer hinzusehen, wie das erreicht wird: diese Vorteile will man ja auch in größer skalierten Umgebungen und in anderen Bereichen mitnehmen. Idealerweise soll die gesamte Firma davon profitieren - vorher muss man allerdings verstehen, wie diese Vorteile zustande kamen.

1. Beschleunigtes Lernen

Lernen in Teams wird in seiner Bedeutung grob unterschätzt: Teams und jedes ihrer Mitglieder lernen ununterbrochen im Verlauf eines Entwicklungsprozesses: neue Techniken, Zusammenhänge mit anderen Komponenten, Auswirkungen von Rahmenbedingungen und Anforderungen – wenn man einmal anfängt genauer hinzusehen, wird die Liste endlos.

Die Intensität, mit der Lernen betrieben wird, bestimmt nach kurzer Zeit die Entwicklungsgeschwindigkeit eines Teams mit.

Agile Teams haben diese Erkenntnis hineinkonstruiert: Lernen funktioniert in Teams am effektivsten.

2. Vorhersagbare Entwicklung

Mit den agilen Softwaretechniken wurde eine wichtige Anforderung an die Softwareentwicklung insgesamt eingelöst: eine belastbare Aussage über den Entwicklungsstand. Die Haupttechnik dafür ist wiederum Testautomatisierung, testgetriebene Entwicklung und Entwicklung in kleinen vertikalen Schnitten. Diese Vorgehensweise deckt auch Defizite, Unklarheiten und Widersprüche in den Vorgaben.

3. Schnelles Feedback und belastbare Fortschrittsberichte

Eng damit zusammen hängt die Fähigkeit, in kurzen Abständen Ergebnisse vorzuzeigen. Damit wurde eine weitere weitverbreitete "Krankheit" in der Entwicklung kuriert: die lange Zeit bis zu der Vorführung der ersten Ergebnisse und der Zwang, viele Details extrem früh festzulegen.

4. Mehr Spass und Motivation in der Entwicklung

Es gibt sie noch, die Zweifler, aber die Beweislast ist erdrückend: bei Wissensarbeit ist einer der entscheidenden Produktivitätsfaktoren die innere Motivation der Akteure selbst. Während man die Motivation bei einfachen Tätigkeiten durch Kontrolle, Druck und direkte Anreize ersetzen kann, ist das bei allen Tätigkeiten, die auch nur rudimentär kreativ sind, nicht mehr zielführend. Agile Teams können dies nachhaltig ändern - viele haben schon die Erfahrung gemacht, wie produktiv die Arbeit in einem eingeschworenen Team sein kann, und wie intensiv wir die Euphorie wahrnehmen und in Erinnerung behalten.

Teil 1: Vier Vorteile agiler Teams

Teil 2: Beschleunigtes Lernen ist Team-Lernen

Teil 3: Grenzen der Agilität in einem Team

Das „Kanban System“ – oder was Kanban eigentlich ist (Teil 2)

jens — Thu, 30 Oct 2014 23:00:00 +0000

In meinem letzten Blog-Eintrag hatte ich über das Kanban-Objektiv geschrieben als ersten Schritt hin zu einer Kanban Einführung. Diesmal geht es darum, mit Hilfe eines Kanban Systems die ersten Veränderungen in der Organisation anzustoßen. Dieser Blog-Eintrag basiert ebenfalls auf einem Teil des Stoffs aus den ersten 90 Minuten unseres neuen Kanban Grundlagen Kurses.

Im letzten Blog-Eintrag hatte ich diskutiert, wie das Kanban Objektiv eine neue Sichtweise auf den Wertschöpfungsprozess liefert. Dabei ging es aber nur um Visualisierung, noch nicht um Veränderungen des Prozesses. In der Regel führt bereits diese Visualisierung zu neuen Erkenntnissen und Verbesserungen im Prozess, aber das ist noch nicht der eigentliche Kern von Kanban.

Dieser entsteht erst durch ein komplettes Kanban System, zu dem das Kanban Objektiv nur der erste Schritt ist.

Nachdem man den Wertschöpfungsprozess mit Hilfe des Kanban Objektivs visualisiert hat, wird es Zeit, die erste und vielleicht wichtigste Veränderung im Management anzugehen: Nicht mehr Mitarbeiter oder „Ressourcen“ zu managen, sondern den Durchfluss von Arbeitsergebnissen durch die Organisation. Ziel ist dabei normalerweise, eine möglichst hohe Durchflussrate zu erreichen, also z.B. eine möglichst kurze Zeit von der Idee bis zum Ausrollen am Markt. In Anlehnung an die Durchlaufzeit bei der Produktion wird diese Zeit auch „Lead Time“ genannt. Eine möglichst kurze Lead Time hat verschiedene Vorteile:

Sie erlaubt schnelle Reaktion auf Veränderungen im Markt, also Agilität im eigentlichen Sinne
Sie reduziert den Umfang der notwendigen Vorausplanung und damit den Verwaltungsaufwand
Sie erlaubt schnelleres Lernen und vermindert damit das wirtschaftliche Risiko
Sie reduziert insgesamt das Risiko – was fertig ist, ist fertig

Kanban geht diese möglichst kurze Lead Time von der Prozessseite aus an und ergänzt sich damit sehr gut mit anderen agilen Praktiken wie Continuous Deployment, die das Problem von der technischen Seite angehen. Beide Konzepte können daher unabhängig voneinander genutzt werden.

Der einfachste Weg, den Durchfluss zu beschleunigen ist es, Liegezeiten zu eliminieren. Das hört sich einfacher an, als es ist, weil es oft die Art und Weise, wie Teams miteinander arbeiten vom Kopf auf die Füße stellt. Kanban bietet dafür ein einfaches Werkzeug an: Man begrenzt die Anzahl von Aufgaben, an denen gleichzeitig gearbeitet wird: das legendäre „Work in Progress Limit“, kurz „WiP Limit“. Spätestens wenn man dieses Limit erreicht hat, sollte man sich erst einmal darauf konzentrieren, die bereits angefangenen Aufgaben abzuschließen, statt immer neues halbfertiges Zeug zu produzieren. In der Regel wird nicht nur die Arbeit insgesamt limitiert, sondern jede einzelne Stufe im Entstehungsprozess erhält ihr eigenes WiP-Limit.

Je kleiner Aufgaben sind, umso leichter fällt einem das. Daher erzeugt Kanban Druck hin zu kleineren Aufgaben und Inkrementen, was wiederum die Reaktionsfähigkeit der Organisation verbessert.

Hat man einmal die Menge an Arbeit im System beschränkt, entsteht ein neuer Effekt: Sobald ein Stück Arbeit fertig gestellt ist, entsteht wieder Freiraum für neue Arbeit, das System zieht also genau so viel Arbeit ein, wie es erledigen kann. Dieses „Pull System“ funktioniert auch über mehrere Arbeitsstationen hinweg: Wenn die weiter hinten liegende Station neue Arbeit gezogen hat, wird an der Station davor wieder Platz, ebenfalls neue Arbeit zu ziehen. Ich stelle mir das immer vor, wie ein Strohhalm. Arbeitsstationen ohne WiP-Limit sind dabei wie Löcher in einem Strohhalm – sie geben den Unterdruck nicht weiter, das Pull System funktioniert nicht mehr.

Ein solches System funktioniert nicht auf Anhieb problemlos, sondern wird Schritt für Schritt aufgebaut. Dafür benötigt man ein System der kontinuierlichen Verbesserung, an der alle beteiligt sind. Hier ist nicht das zentralisierte „Vorschlagswesen“ gemeint, das schon in vielen Organisationen gescheitert ist, sondern eine Kultur, in der Entscheidungen so weit unten getroffen werden, wie möglich, und der Prozess denen gehört, die ihn für ihre Arbeit benötigen.

Erst diese drei Bestandteile, WiP-Limits, Pull-System und kontinuierliche Verbesserung bilden das eigentliche Kanban-System. Erst dieses System etabliert einen Lernzyklus und damit langfristigen Nutzen. Wer sich auf ein volles Kanban-System einlässt, wird das in der Regel über einen langen Zeitraum für Verbesserungen nutzen können. Wer eines der Elemente schleifen lässt, wird früher oder später keinen Wert mehr in Kanban sehen und irgendwann die „nächste Sau durch’s Dorf treiben“.

Die "Kanban Lens" oder was Kanban eigentlich ist (Teil I)

jens — Mon, 13 Oct 2014 11:10:00 +0000

Der erste Schritt in der Kanban Methode ist die Betrachtung der existierenden Arbeitsabläufe in einer speziellen Sichtweise, quasi durch das „Kanban Objektiv“. Diese Sichtweise liefert die Transparenz, die man benötigt, um den weiteren Verbesserungsprozess zu steuern und zu überwachen. Dieser Blog-Eintrag basiert auf einem Teil des Stoffs aus den ersten 90 Minuten unseres neuen Kanban Grundlagen Kurses.

In den sechs bis sieben Jahren, die Kanban mittlerweile in die agile Szene einsickert, haben sich die erstaunlichsten Theorien entwickelt, was Kanban denn so sei. „Das ist für Leute, die nicht den Mut haben, Scrum einzuführen“ hört man gelegentlich, oder „Kanban ist, wenn man sich ein Board an die Wand schraubt und nicht mehr plant.“ Beides ist ungefähr so zutreffend wie der Satz „XP ist, wenn man das Design weglässt“, also falsch. Aber was ist Kanban denn dann?

Kanban bzw. genauer die „Kanban Methode“ ist eine Management-Methode, um die Auslieferung von Wissensarbeit („Service Delivery“) zu verbessern, als Katalysator für Verbesserungen zu wirken und das ganze Geschäft besser an den Markt anzupassen („Evolving a Business to be ‚Fit for Purpose’“). Soweit die aktuelle „offizielle“ Definition des Kanban-Erfinders David Anderson (Stand November 2014).

Wie immer, wenn ein ziemlich komplexes Gedankengebäude auf einen Satz reduziert wird, steckt da sehr viel drin, was man nicht auf Anhieb herausliest. Anders formuliert: So extrem hilfreich ist das noch nicht. Also muss man noch mal einen Schritt näher herangehen und sich die Methode etwas genauer ansehen.

Anders als Scrum oder XP macht die Kanban Methode zunächst keine Vorgaben, wie man am besten arbeiten sollte. Sie kennt keine vorgegebenen Rollen oder Rituale und auch kaum Artefakte. Stattdessen startet man bei der Kanban Methode mit der existierenden Organisation. „Beginne mit dem, was Du heute tust“ und „Wenn Du anfängst, respektiere existierende Rollen, Verantwortlichkeiten und Titel“ sind auch zwei der vier Grundprinzipien der Kanban Methode. Auf die anderen beiden Prinzipien komme ich nachher noch.

„Wenn man etwas besser machen will, muss man auf jeden Fall etwas anders machen“ stellte einst einer der Urväter der IT Beratung Jerry Weinberg fest und so ist die Kanban Methode mit „Ändere nichts“ offensichtlich unzureichend beschrieben. Die erste Änderung besteht nämlich darin, die aktuelle Situation durch das „Kanban Objektiv“ („Kanban Lens“) zu betrachten, sich also eine andere Sichtweise auf die Arbeit zu erarbeiten. Diese Sichtweise besteht aus drei Annahmen, die aufeinander aufbauen:

Kreative Arbeit ist service-orientiert, zumindest wenn die Arbeit in einem wirtschaftlichen Kontext stattfindet. Es gibt also jemanden, für den das Ergebnis der Arbeit eine Dienstleistung darstellt. In der Softwareentwicklung sind das die Anwender (bzw. die Stakeholder), für die Rechtsabteilung sind das die Kaufleute, Fach- und Finanzexperten des Unternehmens und für ein Lektorat die Leser, das Marketing und die Autoren. Verbesserungen müssen direkt oder indirekt zu einer für diese Kunden spürbaren Verbesserung führen, sonst bleibt sie Selbstbeschäftigung.
Diese Services werden schrittweise mit Hilfe eines Workflows erstellt. Sie werden also nicht durch einen einzelnen genialischen Akt erschaffen, sondern in mehreren Schritten, die möglicherweise – aber nicht zwingend – arbeitsteilig bearbeitet werden.
Die einzelnen Schritte dieses Workflows bestehen aus Aktivitäten zum Erkenntnisgewinn. Für eine Rechtsabteilung stellen also die einzelnen Kapitel eines Vertrages keine Schritte des Workflows dar, sondern die verschiedenen Stufen der Ausarbeitung und Verhandlung, in denen man eine gemeinsame Sicht auf die gewünschte Regelungen gewinnt und diese dann in möglichst passende juristische Konstrukte übersetzt.

Keine dieser Annahmen sind selbstverständlich. So ist Erkenntnisgewinn häufig iterativ und kein linearer Workflow. Es ist daher wichtig, zu verstehen, dass hier nur ein „Objektiv“ beschrieben wird. Die Kanban Methode behauptet also nicht, dass diese Annahmen aufgrund eines höheren Modells „wahr“ sind, sie empfiehlt lediglich, den Status Quo einmal durch das „Objektiv“ dieser Annahmen zu betrachten. Also so ähnlich, als würde man den Herzschlag mit Hilfe der 12 Ableitungen eines EKGs betrachten. Niemand käme auf die Idee, zu behaupten, dass diese 12 Kurven der Herzschlag sind, oder ihn auch nur hinreichend vollständig modellieren. Dennoch kann man mit einer entsprechend fundierten Ausbildung eine ganze Menge über den Zustand des betrachteten Herzens herausfinden.

Wie setzt man das Kanban-Objektiv konkret ein? Zunächst bildet man den oft recht komplizierten Arbeitsablauf mit Schleifen und Zyklen auf einige wenige Stufen des Erkenntnisgewinns ab. Nehmen wir als Beispiel eine traditionelle Softwareentwicklung bei der Entwicklung und Test getrennte Abteilungen sind, die sich die Arbeit über ein ausgefeiltes Fehlermanagementsystem hin und her schieben. Durch das Kanban-Objektiv betrachtet könnte man hier statt eines komplexen zyklischen Workflows zwei Stufen des Erkenntnisgewinns sehen: Die Entwicklung als erste Stufe, sowie „Test und Debug“ als zweite Stufe. Für die zweite Stufe sind zwei Abteilungen gleichzeitig zuständig, aber das stört nicht. Es geht schließlich um die zunehmende Reife der Software, nicht um Zuständigkeitsgerangel. Dies ist damit gemeint, sich auf den Service zu konzentrieren, der geliefert werden soll, nicht auf die Ablauf- oder Aufbauorganisation.

Ein weiterer Schritt ist der Fokus darauf, wie Arbeit in dieses System kommt – und warum. Welche Arten von Arbeit gibt es? Von wem kommen sie? Und welcher Geschäftswert ist jeweils mit ihnen verbunden? Wie verändert sich dieser Wert mit der Zeit? Mit diesen Fragen koppelt die Kanban-Methode an die wirtschaftlichen Rahmenbedingungen.

Schließlich wird verfolgt, wie die Arbeit an den Services durch das System fließt. Dafür schlägt die Kanban Methode einige leistungsfähige Praktiken zur Verfügung, wie Kanban Boards, Cumulative Flow Diagrams und Distribution Charts.

Wenn Sie bis hierher aufmerksam gelesen haben, werden Sie feststellen, dass es bisher nur um Visualisierung ging, die Sicht durch das Kanban Objektiv. Am Prozess selbst haben wir noch nicht das mindeste geändert (Systemisch betrachtet ist das bereits eine entscheidende Veränderung, aber das wäre ein eigener Blog-Post). Wer allerdings beim Status Quo stehen bleibt und sich über die Visualisierung freut, nutzt noch nicht die Kanban Methode (Gelegentlich liest man für diese Stufe den Begriff „Proto-Kanban“). „’Starte mit dem, was Du jetzt tust’ heißt nicht ‚Bleibe bei dem, was Du jetzt tust’“ meint David Anderson dazu.

Die eigentliche Veränderung erfolgt aufgrund der aus der Visualisierung gewonnenen Erkenntnisse in kleinen Experimenten, also evolutionär. „Einigt Euch darauf, Veränderung evolutionär voran zu treiben“ ist dann auch das dritte der vier Grundprinzipien. Die Visualisierung gibt einem die Möglichkeit, festzustellen, ob diese Experimente erfolgreich waren, oder nicht. Nachdem evolutionärer Wandel sich nicht mit aufwändigen Genehmigungsprozeduren vereinbaren lässt, muss dieser Wandel auf allen Ebenen der Hierarchie möglich sein und vorangetrieben werden, womit wir beim vierten und letzten Grundprinzip wären: „Ermutige Führung auf allen Ebenen“.

Einen ersten Schritt in diesem Wandel macht man in der Regel ganz am Anfang oder zumindest sehr früh, wenn man die Kanban Methode anwendet: Die Einführung eines „Kanban Systems“. Was es damit auf sich hat (und wie hier endlich Praktiken wie WiP-Limits ins Spiel kommen) ist das Thema meines nächsten Blog-Eintrags.

Über das IKEA Starterkit, Spotify und Frameworks

krishan — Mon, 18 Jun 2018 16:06:18 +0000

Das IKEA Küchen-Starterkit ist eine wunderbare Erfindung: ich brauche es, wenn ich bei meinen Eltern ausziehe und die erste eigene Wohnung einrichte. In diesem Fall kann es mir wirklich den Tag retten: Ich kann meine Küche benutzen, auch wenn ich vorher keinen Plan davon hatte.

Wenn man allerdings wirklich ohne eigene Vorkenntnisse herangeht (bei mir war das so), dann wird der Start trotzdem holprig. Aber es hilft trotzdem.

Was das Starterkit aber nicht verhindern kann: dass ich keine Lust und/oder Talent habe und über kurz oder lang doch wieder nur bei Tiefkühlpizza lande.

Wenn ich dranbleibe, dann werde ich an die Grenzen stoßen und mir zusätzliche Werkzeuge, Töpfe etc. besorgen müssen.

Wie passt das Starterkit zu agilen Frameworks

Ich finde das eine wunderbare Metapher für Frameworks.

Wenn ein Team Scrum einführt, dann ist es eine gute Idee, das im ersten Schritt „by the book“ zu machen – nur dann kann Scrum nämlich seine Funktion erfüllen und Dysfunktionen in der gegenwärtigen Arbeit aufdecken, d.h. Schmerzen erzeugen.

Analog gilt aber auch, dass der Rahmen irgendwann zu starr wird, wenig Optionen zur Weiterentwicklung bietet. Das schönste Beispiel dafür ist Spotify: der Start mit Scrum, eine solide Implementierung von agilen Praktiken und agilem Mindset – und dann war die Organisation so weit, dass sie weitere Experimente wagen konnte und die Prinzipien und Praktiken weiterentwickelt hat.

Keine Blaupause zum Kopieren

Henrik Kniberg hat einen Snapshot dieser Weiterentwicklung publiziert und er wird nicht müde zu betonen, dass es eben das ist: eine Momentaufnahme, keine feste Struktur und auch keine Blaupause, die außerhalb der Spotify-Umgebung unverändert funktionieren kann.

Starten, Lernen, Hinterfragen

Was daraus für mich die wichtigsten Lehren für einen Start mit agilem Arbeiten sind

Starten mit dem Übernehmen von Erfahrungen, beim Starterkit wie bei agilen Praktiken
Weiterentwickeln und einen tieferen Einblick in Zusammenhänge erwerben. Das klingt einfach, aber ist ziemlich tricky: man muss ein System verstehen, um es sinnvoll gestalten zu können
Zu guter Letzt: man muss ständig in Frage stellen, was gestern noch gut genug war.

Authentisch Führen - Authentic Leadership

krishan — Mon, 11 Jun 2018 09:06:00 +0000

Bill George hat einen Punkt: er sagt in seinem Buch, dass Leadership nicht einfach nur Rolle oder Stil ist, sondern dass vorrangig die Authentizität wichtig ist.

Diese hat fünf Elemente:

Das Ziel verstehen
Konsistente Werte leben
Führen mit Herz
Beziehungen etablieren
Selbstdisziplin zeigen

Gut, das ist erst einmal recht allgemein und der Rest des Buchs hat mich für dieses Thema nicht so viel weitergebracht. Es hat allerdings zu ein paar anderen Themen der Unternehmensführung ein paar gute Einsichten (wenn es interessiert: sieben Todsünden beim Auftreten am Markt) und es wird mir persönlich ein bisschen zu esoterisch. Bill George packt die richtige Einsicht, dass man sich diese Authentizität nicht einfach durch lesen aneignen kann, in die Methapher, dass man durchs Fegefeuer gehen muss.

Leadership im 21. Jahrhundert

Das zweite Buch, True North, von 2008, hat mich dann mit den Begriffen versöhnt. Es konkretisiert die Kernpunkte in einer Tabelle:

Charakteristika	20tes Jahrhundert-Leader	21tes Jahrhundert-Leader
Image	Charismatisch	Werte-getrieben
Fokus	US-zentriert	Globale Sicht
Motivation	Eigeninteresse	Das beste für die Organisation
Erfahrung	Perfektes Resume	Lernen durch Herausforderungen
Zeithorizont	Kurzfristig	Langfristig
Herangehensweise	Hierarchische Führung	Verteilte Führung
Größte Stärke	IQ	EQ (emotionale Intelligenz)
Persönlicher Massstab	Externe Bewertung	Intrinsischer Beitrag

Die true North Elemente

Er hat immer noch fünf Elemente, aber die neue Formulierung finde ich viel eingängiger:

Selbstwahrnehmung
Werte
Sweet Spot
Support Team
Integriertes Leben

Und dann hat er noch das Konzept des Sweet Spot zwischen Motivation und Fähigkeiten. Das, finde ich, ist ein perfekter Einstieg in die Betrachtung, was Leadership in einer agilen Umgebung sein sollte.

Skalieren jenseits von Frameworks

krishan — Mon, 04 Jun 2018 02:06:00 +0000

Agil im Großen wird allzu oft als die Auswahl zwischen zwei Frameworks gesehen: SAFe oder LeSS. Gelegentlich kommt noch ein drittes (Phantom-) Framework dazu: Spotify.

Die Entscheidung zwischen LeSS und SAFe ist zu einem großen Teil eine Make-or-buy-Entscheidung, das Spotify-Framework ist einfach ein Missverständnis.

Lasst mich das erklären.

Buy = SAFe

Das Scaled Agile Framework hat als große Stärke sein Big Picture. Damit kann es suggerieren, dass alles ganz einfach, man muss einfach nur ausrollen. Das ist auch seine größte Schwäche: das Big Picture. Es kann in eine Falle führen. Es verleitet dazu, dass Unerfahrene meinen, sie könnten eine große agile Transition anstoßen, nur weil sie die Icons interpretieren können.

Make = LeSS

LeSS startet ganz anders: Am Anfang wird ein Verständnis für Zusammenhänge (systemisches Denken) verordnet, dann werden in Prinzip die Scrum Regeln neu erklärt („jedes Team braucht genau einen PO, aber niemand hat gesagt, dass ein PO nur ein Team haben kann“). Und - die größte Stärke: LeSS bietet einen ausgezeichneten Baukasten von Praktiken. Die größte Schwäche bei LeSS ist sein Absolutheitsanspruch. Es stellt den Anspruch, dass man die organisatorischen Strukturen damit ersetzen kann (und sogar muss). An dieser Stelle verlieren sich mich: große Organisationen brauchen mehr formale Strukturen, auch wenn ich die Einschätzung teile, dass sie sehr oft dysfunktional sind und tiefgreifend verändert werden müssen.

Leider sind Anfänger damit völlig überfordert. (von SAFe übrigens auch – aber der Realitätsschock setzt später ein).

Spotify: ein Schnappschuss auf Beyond Scrum

Was als das Spotify-Framework bekannt wurde, ist die brilliante Darstellung eines Zwischenstands in der Agilen Implementierung bei Spotify von Henrik Kniberg. Spotify hatte mit Scrum angefangen und hat seine Praktiken kontinuierlich weiterentwickelt. An einer Stelle haben sie dann die Rollen umbenannt, um die Konflikt mit den Konnotationen aus dem ursprünglichen Scrum zu vermeiden.

Es war nie gedacht, das Modell einzufrieren oder gar als Blaupause für andere Organisationen zu benutzen.

Beyond Frameworks

Spotify hat allerdings einen Benchmark gesetzt: wie kann man – ausgehend von einem Framework – die Praktiken kontinuierlich weiterzuentwickeln.

Das einzige, was zu einem Verständnis führen kann: tiefer einsteigen. Bei den Needs und Pains der Organisation starten und dann die Prinzipien und Praktiken zusammenstellen, die zur Lösung beitragen. Ich sehe ein paar Elemente, die für eine langfristige Weiterentwicklung nötig sind:

Systemverständnis vertiefen und mit einem tieferen Einblick in Zusammenhänge arbeiten.
Pains und Need sammeln, die Situation analysieren und daraus Erfolgsbedingungen destillieren
Experimente mit bekannten Praktiken durchführen und Erfahrungen sammeln: was ist wertvoll, was kann man ignorieren, was sollte man vermeiden
Leadership: Authentizität, Rolle und Stil entwickeln
Transformation = Orientierung + Transition + Evolution: vorausplanen, dass und wie man die Lösung stetig weiterentwickeln muss

Ich werde in nächster Zeit einige dieser Punkte genauer beleuchten.

Start with Why - Sinek´s Golden Circle

krishan — Mon, 28 May 2018 04:00:00 +0000

In vielen Diskussionen erwische ich mich dabei, dass ich die Frage einwerfe "welches Problem lösen wir denn gerade". Manchmal wirkt es Wunder, um eine Konversation wieder ins richtige Fahrwasser zu bringen. Ich bin vor einiger Zeit über den "Golden Circle" gestolpert - in der Tat war es ein Kunde, der es in seiner Organisation intensiv nutzt.

Simon Sinek hat die Fokussierung auf das Ziel wunderbar eingängig auf den Punkt gebracht und er stellt es auch wunderbar dar, es ist eines der meistgesehenen Youtube-Videos (18 min - oder die Kurzfassung in 5 min).

Für mich was die Terminologie zunächst verwirrend

Why - das übergreifende Ziel, die Vision oder Grundüberzeugung
Für uns, improuv, könnte das so aussehen:
Wir wünschen uns, dass Menschen in einer interessanten, erfüllenden und angenehmen Arbeitsumgebung arbeiten können und wollen.
How - der Unterschied
zum Beispiel:
Eine angenehme Arbeitsumgebung ist nur nachhaltig, wenn sie auch für die Organisationen effektiv ist. Wir arbeiten daran, gemeinsam mit den Beteiligten die Fähigkeiten und Strukturen zu erarbeiten, die eine solche Umgebung bereitstellen.
What – konkrete Aktionen, Produkte und Services
zum Beispiel:
Wir bieten Coaching für Organisationen und Trainings für Personen an, die sich auf diesen Weg machen.

Ich hatte bisher eine andere Zuordnung der Begriffe verwendet: Für die Ziele hatten wir "Why – What - How" verwendet. In unserer internen Aufstellung hatten wir die drei Begriffe "Identität - Vision - Mission" verwendet, die sich eins zu eins auf den Golden Circle abbilden lassen

Aber das Konzept ist zu gut – und zu gut kommuniziert - um es zu ignorieren. Ich passe meinen Sprachgebrauch und meine Materialien an.

Und nicht vergessen: seht euch unbedingt das Youtube-Video an (oder seht es euch wieder an).

John Doerr´s OKR Superpowers und Agile Leadership

krishan — Tue, 22 May 2018 08:38:00 +0000

John Doerr benennt in seinem Buch „Measure what Matters“ vier „Superpowers", die die Wirksamkeit von OKRs ausmachen:

Superpower #1: Focus und Commitment auf Prioritäten

Effektive Organisationen konzentrieren ihre Arbeit auf die wichtigen Dinge und sie haben eine klare Vorstellung davon, was sie tun und was sie nicht tun. OKRs ermutigen dazu, frühzeitig harte Entscheidungen zu treffen und ermöglichen eine klare Kommunikation zwischen Abteilungen, Teams und Individuen.

Superpower #2: Alignment und Connect für Teamarbeit

Mit der Transparenz über die Ziele, die durch OKRs vermittelt wird, werden die Aktivitäten jedes einzelnen mit den Firmenzielen in Verbindung gebracht. Der Clou entsteht durch die Kombination von top-down und bottom-up Kommunikation über Ziele: top-down vermittelt die Bedeutung der Arbeit jedes Einzelnen, bottom-up erzeugt Motivation und ermöglicht eine Vielzahl von Innovationen. Nicht zuletzt bringt die umfassende Transparenz neue Chancen zum Alignment über Teamgrenzen hinweg.

Superpower #3: Zielverfolgung und Accountability

OKRs sind im Kern datengetrieben. Damit ermutigen sie periodische Checkin´s, kontinuierliche Anpassung der Aktionen und sie ermöglichen eine Verantwortlichkeit, die keine Schuldzuweisung beinhaltet. Sie unterstützen damit eine kollegiale Kultur mit Kommunikation auf Augenhöhe.

Superpower #4: Stretch für Amazing

OKRs motivieren uns zum Engagement über das Normalmass hinaus, dazu, erstaunliches zu erbringen. Mit der Freiheit, Fehlschläge ohne Sanktionen zu erfahren, erweitern sie unsere Fähigkeit, unsere kreativsten und ambitioniertesten Seiten zu erfahren.

Die OKR Superpowers und Agile Leadership

Für mich war es eine interessante Übung, die Superpowers mit meinen Prinzipien des Agile Leadership „Focus – Enable – Align – Empower“ abzugleichen.

Focus und Commitment auf Prioritäten – das ist das einfachste, es fast gleich mit dem Fokussieren von Leadership, es geht weiter und macht es konkret
Alignment und Connect für Teamarbeit – OKR fokussiert damit die Teams. Agile Leadership hat zusätzliche Tools, mit denen die Voraussetzungen für Teamarbeit geschaffen werden.
Zielverfolgung und Accountability – Accountability und Nachverfolgbarkeit ist eine Voraussetzung dafür dass das Empowerment nachhaltig gelebt werden kann und das ggenseitige Vertrauen stetig validiert und gestärkt wird.
Stretch für Amazing - das hat keine Entsprechung im Leadership-Modell

Es bleibt noch Enablement aus Agile Leadership – dafür wiederum gibt es keine direkte Entsprechung in den OKRs.

Strategie entwickeln und Strategie umsetzen

Was bleibt, ist für mich die Überzeugung, dass OKRs ein Mittel ist, auf das man als Agilist nicht mehr verzichten will, wenn man es einmal kennen gelernt hat. Und dass man noch weitere Synergien heben kann, sobald man damit einmal angefangen hat. Demnächst rede ich über den nächsten Schatz, den man haben kann: die Erweiterung des Big Room Planning in großen Teams.

OKRs sind ein starkes Bindeglied zwischen einer Strategie, den Leadership-Aktivitäten zur Vermittlung und der Umsetzung und Implementierung der Strategie: sie erlauben, die Verbindung empirisch zu prüfen und mach die Strategie-Umsetzung messbar.

Focus@Scale mit Objectives und Key Results (OKRs)

krishan — Thu, 17 May 2018 10:01:00 +0000

Ich habe kürzlich die Idee von Agile Leaderhip erläutert: der Zyklus von Focus – Enable – Align – Empower. Es ist Zeit, dazu einige Tools vorzustellen. Unser Werkzeug der Wahl sind OKRs. OKRs – die Abkürzung für Objectives and Key Results – ist eine Methode zur Zielsetzung für Organisationen, die auf agile Praktiken perfekt passt und die eine wirksame Fokussierung bewirkt.

Wir glauben, dass wir damit ein paar Aspekte zu Fokussierung und Alignment klarziehen können, die uns schon länger geplagt haben. Insbesondere kann ich damit das schwammige Thema Mindset operationalisieren. Das liegt mir im Magen, seit David Snowden die Mindset-Diskussion mit „the lastest action-avoiding Bullsh*t“ titulierte.

OKRs in fünf Minuten

OKRs sind sehr einfach: eine Organisation setzt sich Ziele (z.B. für ein Jahr) und messbare Key Results. Objectives sind qualitativ und ambitioniert. Sie stellen sicher, dass Organisationen und Individuen den richtigen Fokus haben. Key Results sind Konkretisierungen in kürzeren Abständen, z.B. pro Quartal. Diese Key Results sind messbar, also quantifizierbar, wir können durch sie bestimmen, ob wir das Ziel erreicht haben. Objectives und Key Results gehören zum Problemraum, sie sind keine Aktivitäten oder Tasks, die zum Lösungsraum gehören.

Das neue daran: Ziele werden für Personen, Teams und die gesamte Firma entwickelt und dann verhandelt (im Gegensatz zu: von oben nach unten durchgereicht/kaskadiert). Und sie sind transparent für die ganze Firma.

Objectives können notwendige operative Ziele sein, OKRs ermutigen aber auch ehrgeizige Ziele, die nicht sicher erreicht werden – stretch objectives, sog. „roofshots“ für vielleicht erreichbare Ziele. Reife Organisationen wagen sich auch an „moonshots“, die sehr unwahrscheinlich vollständig erreicht werden, aber bei denen allein der Versuch schon positive Effekte hat.

Damit das funktionieren kann, dürfen OKRs nicht an persönliche Belohnungen oder eine Zielerreichung gebunden werden, da sonst fast sicher der Effekt einsetzt, dass die Personen ihre persönliche Belohnung optimieren anstatt nach dem besten Beitrag zu den Firmenzielen zu suchen.

Diese beiden Elemente: Alignment statt Kaskadierung und Transparenz haben das Potenzial zu einem zentralen Katalysator für eine Änderung der Firmenkultur.

Taylor, Drucker, Grove und Google

Die Management-Prinzipien zu Anfang des 20. Jahrhunderts waren von einem klaren Command-und Control Mindset geprägt. Die Konzepte von Taylor und Ford verlangten eine klare Trennung von Managern – deren Aufgabe Planung war – und Arbeitern, die nur ausführten und nichts mit der Planung zu tun hatten.

Peter Drucker formuliere 1954 das Konzept „Management by Objectives“, mit dem er den Blick auf individuelle Stärken und Verantwortung lenkte und gleichzeitig eine gemeinsame Richtung mit den Zielen der Organisation etabliert. Die Mitarbeiter hatten damit eine Sicht auf die übergreifenden Ziele, was für Wissensarbeiter eine wesentlich bessere Struktur darstellt. Leider ist MBO inzwischen oft auf KPIs reduziert, in Silos eingesperrt, nicht transparent und – absolut tödlich für ein Alignment auf gemeinsame Ausrichtung – an Boni gekoppelt.

Was wir heute OKRs nennen, wurde von John Doerr auf der Basis der Management-Prinzipien des legendären intel-CEO Andy Grove entwickelt. Doerr wurde später Venture-Kapitalist und brachte diese mit zu Google. Bei Google wurden sie das strukturierende Organisationsprinzip.

Agilität und OKRs

Agilität und OKRs sind für mich eine perfekte Kombination:

Agilität stellt das Mindset bereit, miteinander auf Augenhöhe zusammenzuarbeiten
Agilität fordert Transparenz, damit sie funktionieren kann. OKRs stellen einen wesentlichen Faktor zur Änderung einer Organisation dar.
Verhandeln statt kaskadieren, Alignment und Autonomie, Accountability sind in der Agilität wichtige Treiber und werden mit OKRs in konkrete Aktivitäten übersetzt

Weshalb wir nun ICAgile-Zertifizierungen anbieten

anja.stiedl — Mon, 14 May 2018 12:05:00 +0000

Als einer der ersten Anbieter im deutschsprachigen Raum kooperiert improuv nun mit ICAgile und bietet mit dem Training “Choose Your Methods - Agile Mindset” die erste ICAgile-Zertifizierungen zum “ICAgile Certified Professional” an, in dem Teilnehmer die Grundlagen und Rahmenbedingungen für Agilität kennenlernen und Methoden wie Scrum, Kanban und Design Thinking in praktischen Übungen selbst erfahren.

Ich werde immer wieder gefragt, warum wir die neue ICAgile-Zertifizierung in unser Programm mit aufgenommen haben.

Vor einigen Jahren fand ich meinen Einstieg in die Welt der agilen Arbeitsmethoden über Entwicklungswerkzeuge im XP und Scrum mit seinen Rollen, Events und Artefakten. Mit der Zertifizierung kam die praktische Anwendung und meine agile Reise begann. Scrum war die populärste Methode und das Zertifikat des “Certified ScrumMasters” war das allseits anerkannte Mittel, um Kenntnisse über Agilität nachzuweisen. Ein typischer Weg, wie ihn viele andere auch gegangen sind.

Bis heute hat sich das Spektrum agiler Methoden weiterentwickelt:
Es gibt mehr agile Methoden, deren Fokus nicht mehr auf der Zusammenarbeit in einem Team liegt, sondern immer öfter in der team-, abteilungs- oder portfolioübergreifenden Kommunikation, Koordination und Entscheidungsfindung. Agilität beschränkt sich nicht auf die Software-Entwicklung, sondern überspannt alle Bereiche im Value Stream der Organisation. Neue Themen wie DevOps oder Business Agility finden zunehmend Aufmerksamkeit und reihen sich in das agile Gedankengut ein. Ehemalige ScrumMaster fungieren als Agile Coaches und coachen damit auch andere Methoden als Scrum.

Ebenso ist die Landschaft agiler Zertifikate bunter geworden: alleine wir beteiligen neben den Zertifikaten der Scrum Alliance am den Zertifizierungsprogrammen der Scaled Agile Foundation und der Lean Kanban University. Warum also auch noch IC Agile, inwiefern unterscheiden sich nun die Zertifikate von ICAgile von denen anderer Trainingsanbieter?

ICAgile ist methoden-neutral

Der Fokus von ICAgile liegt stets die Vertiefung von Mindset und Kenntnissen im Thema Agilität, zum Beispiel durch Schulungen in Richtung Coaching und Facilitation, Agile Entwicklung, Agiles Testen, Management und Leadership, Skalierung und so weiter.

Entsprechend sind auch die Lernziele auf den Entwicklungspfaden von ICAgile methoden-neutral. Sie sind bewusst so gestaltet, dass sie auf Agilität fokussieren und nicht einzelne Richtungen oder Methoden vertreten. Andere Zertifikate hingegen zielen oft ab auf die Vermittlung eines einzelnen Frameworks, einer Rolle, einer besonderer Methodologie, nicht so sehr auf die zugrunde liegende agile Philosophie.

Als Beispiel fällt mir Scrum ein, wo die entsprechenden Trainings auf die einzelnen Rollen des Scrum Masters, Product Owners oder des Developer Teams abzielen. ICAgile strebt an, alle Disziplinen zu vermitteln, wie auch des Managers oder des Marketings in agilen Organisationen.

Großes Angebot an Zertifizierungen

Der zweite Punkt liegt in der Tiefe der angebotenen Zertifikate. ICAgile bietet 3 Stufen der Zertifizierung an: Professional, Expert und Master. Der Professional Level ist wissensbasiert. Zur Erlangung eines Zertifikates auf Experten-Level muss man ausreichend praktische Erfahrung nachweisen und vor einem Ausschuss von Experten demonstrieren. Die innovationsbasierte Stufe der Master-Zertifikates erfordert die Demonstration von Experten-Wissen in mehreren Richtungen, sowie die Mitwirkung in der agilen Community.
Damit ist ein Entwicklungspfad geschaffen, in dem z.B die Kompetenz des agilen Coachings aufgebaut wird. Nach einem Professional Level über die Grundlagen von Agilität folgen 2 Professional Level, die sich mich Agile Team Facilitation und Agile Coaching befassen. Am Ende dieses Weges steht die kompetenzbasierte Zertifizierung zum “ICAgile Certified Expert Agile Coaching”. Dies spiegelt die Anforderung wieder, dass jeder Agile Coach Wissen im Bereich von Team Facilitation, wie auch im Bereich des Agile Coaching haben muss und dieses auch vor einem Gremium demonstrieren können muss. Zudem bietet ICAgile acht verschiedene Richtungen der Zertifizierung an mit mehr als 21 Zertifikaten, die erreicht werden können.

Akkreditierung von Kurs und Trainern

Als letzten Punkt möchte ich den Zulassungsprozess von ICAgile anbringen. Bevor ein Traininganbieter eine ICAgile Zertifizierung anbieten darf, muss das Kurs-Material mit ICAgile besprochen werden, um sicherzustellen, dass alle Learning Objectives abgedeckt sind, die im ICAgile Curriculum definiert sind. Diese Learning Objectives sind durch eine Kommission internationaler Experten definiert, die als Vordenker im jeweiligen Bereich gelten. Ebenso wie der Kurs, muss sich auch jeder Trainer einem Akkreditierungsprozess unterziehen, um vertieftes Wissen in diesem Gebiet, wie auch im Aufbau des Kurses zu zeigen. Somit wird die hohe Qualität des Kurses durch den Trainingsanbieter sichergestellt.

Diese Punkte fassen für mich die Vorteile zusammen, die Zertifikate über ICAgile bieten, und dies möchte ich unterstützen! Deshalb habe ich mich bei den Kollegen dafür eingesetzt, dass wir mit ICAgile kooperieren und freue mich, dass wir jetzt die ersten Zertifizierungs-Trainings zum ICAgile Certified Professional anbieten können: Choose Your Methods: Agile Mindset.

Focus - Enable - Align - Empower

krishan — Sat, 12 May 2018 21:38:00 +0000

Selbstorganisierte Teams sind der Kern von Agilität. Damit ist die Hoffnung verbunden, dass sich quasi über Nacht alle Motivationsprobleme in Luft auflösen. Umso größer ist das Erstaunen, wenn es so nicht klappt.

Oft sind gar nicht die Voraussetzungen geschaffen, damit Teams autonom arbeiten können: sie haben keine Informationen bzw. Orientierung über die Richtung, in die es gehen sollen. Und es wird von ihnen erwartet, dass sie einfach funktionieren. Allerdings muss vor dem "dürfen" noch das "können" und das "wollen" kommen. Daraus ergeben sich auch Aufgaben, die Manager erfüllen müssen, damit Selbstorganisation funktionieren kann - und damit sie mit gutem Gewissen Verantwortung delegieren können.

Ich stelle dazu drei Szenarien vor, wie das im ganz kleinen, d.h. in einem Sprint-Planungsmeeting, bei einem Team allgemein und als Führungsaufgabe in einer Firma aussehen könnte:

Focus - Orientierung geben

Selbstorganisierte Teams haben in der Regel nicht die Autonomie in der Zielsetzung, diese kommt wesentlich von außen.

In einem Scrum Sprint-Planungs-Meeting ist das eine Einleitung des Product Owner zu seinen Zielen für den Sprint.
In einem Team ist das die klare und kommunizierte Produktvision.
Für Führungskräfte im Allgemeinen ist das "Management by Objectives" - was sowohl klassisch in einer Command-und-Control Version als auch agil gestaltet werden kann. Letzteres ist Thema für einen weiteren Blogbeitrag.

Enable - Informationen bereitstellen und Skills vermitteln

Der nächste Schritt ist, das "können" der Teammitglieder sicherzustellen.

Im Sprint-Planungs-Meeting ist das die Herstellung eines gemeinsamen Verständnis über die PBIs (Product Backlog Items), z.b. die Erläuterung durch den Product Owner.
Im Team ist die regelmäßige Reflektion der individuellen und gemeinsamen Skills und ggfls. das Organisieren von Lernzielen und Recherchen. Das ist eine Aufgabe von Scrum Master und Product Owner, die Thematisierung in Retrospektive-Meetings spielt dabei eine tragende Rolle.
Als Führungsaufgabe wird dies of als Personalentwicklung beschrieben. In einem agilen Kontext ist die Unterstützung der langfristigen Entwicklung eine der zentralen Aufgaben eines Leaders.

Align - sicherstellen, dass alle die gleichen Ziele verfolgen

Alignment heisst eigentlich sicherzustellen, dass man gleiche Ziele teilt. Es ist einer der am häufigsten missverstandene (oder missbrauchte) Begriff in Organisationen. Alignment dient oft als Ersatz für Compliance, für mich in diesem Kontext ein Synonym für, na ja, platt gesagt, Gehorsam.

Im Sprintplanungs-Meeting folgt auf die Erläuterung der PBIs eine Diskussion über Machbarkeit und Varianten der Umsetzung. Dabei fliesst das Know-How des Teams, Präferenzen und Ideen aus dem Meeting selbst ein. Selten bleibt dabei ein PBI unverändert, und der wichtigste Nebeneffekt ist das Vertrauen, dass ein gemeinsames Verständnis erzielt wurde und dass es ein Resultat gemeinsamer Arbeit ist.
Im Team ist Alignment eine ständige Aufgabe, angefangen mit der Organisation eines Ziele-Workshops, und weiter mit dem regelmäßigen Inspect-and-Adapt, was ebenfalls eine regelmäßige Aufgabe für Retrospektiven ist.
In der agilen Organisation ist ein sehr mächtiges Mittel die Nutzung von OKRs (Objectives and Key Results), OKRs wurde bei intel erfunden und bei Google weiterentwickelt. Es ist eine Form von "Management by Objectives", bei der Ziele nicht kaskadiert, sondern zwischen den Ebenen verhandelt werden.

Empower - die Verantwortung übergeben

Jetzt kann ein Manager Verantwortung abgeben: das "Wollen" und das "Können" ist geklärt, jetzt kann man über "dürfen" reden:

Im Sprintplanungs-Meeting vereinbart man das Sprintziel und das Team übernimmt die Verantwortung.
Das Team bekommt die Autonomie, die Erledigung der Aufgaben selbständig zu organisieren.
In der Organisation sind die Voraussetzungen geschaffen, weniger Hierarchie und mehr Netzwerk und Selbstverantwortung zu leben. Das beseitigt Bottlenecks, erhöht die Motivation und die Schnelligkeit, mit der die Organisation reagieren kann. Es macht sie, kurz gesagt, agiler.

Eine schöne Übung für einen PO-Kurs

krishan — Fri, 04 May 2018 15:24:00 +0000

Die FidoDido Übung für die PO-Rolle

Er/sie ist kein umbenannter Projektleiter und auch kein Backlog-Administrator, sondern end-to-end dafür verantwortlich, dass das bestmögliche Produkt entsteht.

Ich habe in meinem Product Owner-Kurs eine durchgängige Übung, in der ein fiktiver Smartphone-Hersteller versucht, an die Weltspitze anzuknüpfen. Dabei durchlaufen die verschiedenen Schritte, die bei einer Neuentwicklung anfallen, vom Pitch bis zum ersten Sprint.

Ich bin dabei, diese Übung etwas aufzufrischen und habe nach ähnlichen Konzepten recherchiert und dabei ist mir die Ganztages-Übung von Mishkin Berteig aufgefallen. Sie ist wirklich hübsch und integriert mehrere Schritte, die bisher durch mein Raster gefallen sind.

Die Teilnehmer der Übung gehen durch mehrere Aktivitäten bei der Entwicklung eines Produkts:

Produktvision
User Personas
Business Value
Backlog Items
Schätzen und finanzielles Modell

Auf der anderen Seite lässt dieses Modell einige Schritte aus, die im Wesentlichen für Product Owner in grossen Umgebungen interessant sind - ich habe damit eine Möglichkeit mehr, mich an Bedürfnisse und Fragen der Teilnehmer anzupassen.

Danke, Mishkin - auch für die großzügigen Nutzungsbestimmungen.

Drei Thesen zum Jahresauftakt 2018

krishan — Sun, 07 Jan 2018 11:37:00 +0000

Dieses Jahr wird neue Herausforderungen bringen. Ich habe ein paar Gedanken zusammengefasst, was dieses Jahr für mich und die agile Welt bringen könnte.

Ich sehe drei Trends:

1. Agiles Management und Agile Führung werden das Buzzword des Jahres.

Im letzten Jahr hat sich schon abgezeichnet, dass Agilität stärker von oben getrieben wird und dass nicht mehr die IT sondern die Personalabteilungen eine agile Transformation vorantreiben. Agile Teams fliegen schon lange nicht mehr unter dem Radar: es wird für Unternehmen dringender, agile Ansätze in die übrigen Strukturen und in eine ganzheitliche Strategie zu integrieren.

2. Die Frage wird wichtiger, wie man eine Agile Transformation nachhaltig erfolgreich macht.

Wir alle haben zu oft erlebt, dass ein Team erfolgreich agile Praktiken anwendet und auch umfassend versteht – nur um dann vom Management wieder „zurück zur Arbeit“ geschickt zu werden. Die Guerilla-Taktiken haben das Ende ihrer Wirksamkeit erreicht. Nachhaltigkeit von agilen Strukturen und Praktiken ist nur in Sicht, wenn man die ganze Firma mitnimmt, und das heisst, das obere Management genauso wie das mittlere Management, das despektierlich die „Lehmschicht“ genannt wird. Das führt uns zur Frage wie nachhaltige Führung und Strukturen einer agilen Firma aussehen können.

3. Wir brauchen mehr Reflexion und weniger Methoden

Oftmals wird die Frage gestellt: „Scrum oder Kanban“, und später: „mache ich es richtig“. Das sind legitime Fragen, wenn man entschlossen ist, agil einzuführen. Nach mehr als 10 Jahren Erfahrung mit agilen Transitionen stelle ich heute andere Fragen:

Welches Problem will ich lösen? - Das ist die Frage mit der ich starte.
Welche Praktiken helfen bei der Lösung dieses Problems? - Agilen Methoden sind grossartig als Starter-Kit. Aber genauso wie das Küchen-Starterkit von IKEA haben sie keine Antwort auf alle Fragen des Lebens, sondern wir müssen lernen, sie weiter zu entwickeln – das gilt genauso wie bei Küchengeräten und unseren Kochkünsten. Erfolgreiche Teams und Firmen nutzen ein Mix-and-match von Scrum und Kanban und anderen Methoden wie XP für die Entwicklungspraktiken.
Wie entwickle ich die Fähigkeiten meiner Organisation in Richtung einer agilen Kultur? - Zum Beispiel: vom Scrum Master zum Coach für mehrere Teams, zu pragmatischen Regeln zum Aufbau einer skalierten agilen Umgebung und zur Nutzung von agilen Führungsprinzipien – aber da sind wir wieder am Anfang dieses Blogs angekommen.

Vielleicht ist das die Gemeinsamkeit dieser Punkte: Agilität braucht für den Erfolg ein tieferes Verständnis der Zusammenhänge.

Dazu ein Zitat von W.E.Deming: „The system that people work in and the interaction with people may account for 90 or 95 percent of performance“.

Design Thinking: Was Führungskräfte wissen sollten

martin.stroebele — Tue, 12 Dec 2017 13:30:00 +0000

Design Thinking und Führung – ein spannender Themenbereich! Am vergangenen Wochenende habe ich dazu beim dtcamp in Nürnberg eine Session angeboten und inspirierende Gespräche geführt.

Besonders die folgenden zwei Fragen werden immer wieder diskutiert:

1. Wie können Führungskräfte zum Erfolg von Design Thinking Teams beitragen?
2. Wie können Führungskräfte mit Design Thinking noch erfolgreicher sein?

Für beide Fragen relevant: Die drei „Hauptzutaten“ für Design Thinking. Das Team, der Prozess und der Raum.

Das Team

Design Thinking hilft interdisziplinären Teams dabei Produkte und Services zu entwickeln, die Kunden wirklich begeistern. Einer der wichtigsten Erfolgsfaktoren dabei: Das Team sollte möglichst viele Perspektiven einnehmen können und eine gute Diskussion führen können. Die Diversität ist also hilfreich, z. B. in Bezug auf

- Beruf / Rolle / Aufgabe
- Herkunft / Kultur
- Alter
- Geschlecht
- Persönlichen Erfahrungen

Der Prozess

Egal wie der Prozess im Detail ausgestaltet wird und welche Methoden angewendet werden, die Grundprinzipien funktionieren und verhelfen multidisziplinären Teams zu innovativen Ergebnissen.

Meine drei Highlights:

- Trenne zwischen Problem- und Lösungsraum und starte damit, dass Du Dich in die Situation Deiner Kunden / Nutzer versetzt und Ihre Bedürfnisse verstehst.
- Trenne zwischen divergierendem Denken (Optionen entwickeln) und konvergierendem Denken (Optionen bewerten).
- Arbeite in schnellen Iterationen: Schnell ins Tun zu kommen ist wichtiger als die eine, perfekte Idee zu suchen.

Hier der bekannte „Double Diamond“:

Weitere Darstellungsformen finden sich im vorigen Artikel zum Thema „Drei Design Thinking Aspekte, die jeder Product Owner kennen sollte“

Der Raum

Für diese Art zu arbeiten braucht ein Team einen geeigneten Raum. Eine freundliche, helle Atmosphäre ist förderlich für die Kreativität, Offenheit und die Kommunikation im Team. Es gibt darüber hinaus aber auch harte technische Anforderungen:

- Der Raum sollte groß genug sein und Bewegungsfreiheit z. B. für den Prototypenbau bieten.
- Der Raum muss wandelbar und flexibel nutzbar sein. Arbeiten sollte im Sitzen und im Stehen möglich sein – alleine oder in (Teil-) Gruppen.
- Wandflächen sind Arbeitsflächen und sollten möglichst einfach nutzbar sein. Für Post-Its, zum Sammeln von Artefakten, zum Beschreiben.

Was tun?

Wie können nun Führungskräfte zum Erfolg von Design Thinking Teams beitragen? Häufig wenn ich diese Frage stelle, bekomme ich erst einmal Antworten auf eine andere Frage: WAS NICHT TUN?

Meine Sammlung aus den letzten Wochen (WAS NICHT TUN):
- Lösung oder Lösungsweg vorgeben
- Im Detail entscheiden wollen
- Mitarbeit im Design Thinking Projekt für Mitarbeiter als eine Aufgabe unter vielen Aufgaben definieren
- Bei Problemen zuerst den Schuldigen suchen
- Internen Wettbewerb durch individuelle Leistungsanreize fördern

Und was statt dessen tun?

Meine Empfehlung für alle Führungskräfte lautet: Wenn Sie Design Thinking in Ihrer Organisation / Ihrem Bereich / Ihrem Team einsetzen wollen, gehen Sie in drei Schritten vor.

Schritt 1: Lernen

Verschaffen Sie sich einen Überblick über die wichtigsten Methoden und Prinzipien. Verstehen Sie für welche Ihrer Themen und Teams Design Thinking gut geeignet und wo vielleicht andere Methoden schneller zum Ziel führen.

Schritt 2: Anwenden

Wenden Sie Techniken aus Design Thinking selbst an - zum Beispiel für Ihren Strategieprozess. Es lohnt sich: Die komplexen Aufgabenstellungen in der Strategiearbeit rufen geradezu danach mit innovativen Problemlösungsstrategien bearbeitet zu werden.

Schritt 3: In die Organisation tragen

Definieren Sie erste Themen, die sie mit Design Thinking angehen wollen und schaffen Sie einen Raum für Experimente.

Sie fördern die Innovationsfähigkeit ihrer Organisation insbesondere mit drei klaren Bekenntnissen:

- Lernen ist wichtiger als Wissen
- Schnell ins Tun kommen ist wichtiger als das Vermeiden von Fehlern
- Vertrauen und Transparenz ist wirksamer als Weisung und Kontrolle

Interessiert?

Sie sind Führungskraft und wollen sich, Ihr Team oder Ihre Organisation auf den Weg machen zu mehr Innovation? Tipp: Werfen Sie einen Blick auf das improuv-Trainingsprogramm. Neben den öffentlichen Trainings bieten wir auch individuelle inhouse-Schulungen an und unterstützen Sie als Coach und Berater.

Pragmatisch Skalieren: jenseits der Methoden

krishan — Thu, 02 Nov 2017 17:04:00 +0000

Wir arbeiten an einem neuen Konzept zu Agiler Skalierung.

Wir führen jetzt schon einige Zeit methodenbasierte Trainings zu agiler Skalierung, vor allem zu SAFe und Less durch. Wir haben gelernt, dass es wichtig ist, die Konzepte und Prinzipien hinter den Praktiken zu diskutieren, weil man nur mit diesem Hintergrund die Praktiken an die spezifische Situation anpassen kann. Trotzdem kommt immer wieder der Blick auf die Prinzipien zu kurz, er wirkt irgendwie immer wie eine Fussnote.

Deshalb haben wir uns entschlossen, die Frage von einer ganz anderen Richtung anzugehen: wir starten bei den Bedürfnissen: warum will ich skalieren und woran sehe ich, dass ich erfolgreich bin. Dann machen wir uns auf die Suche nach den „golden Nuggets“, der wertvollsten Teile der einzelnen Frameworks und stellen sie in den Kontext des Kundennutzens.

Diese Vorgehensweise ist nicht einfach. Sie erfordert, dass man schon die Prinzipien einordnen und mit eigenen Erfahrungen verknüpfen kann. Sie fordert mehr Geduld und den Umfang mit Experimenten, das Verlassen der Komfortzone.

Dafür gewinnt man die Chance, nicht nur eine Methode einzuführen, sondern die Gemeinsamkeiten und Unterschiede zu verstehen seine eigene Transformation zu treiben.

Und: man kann mit einem rationaleren Blick in der heiss geführten Diskussion teilnehmen.

in kürze Teil 2: Golden Nuggets - was ich aus jeder Methode mitnehmen will

Enterprise Services Planning – Ein Mangement System für die gesamte Organisation

jens — Fri, 15 Sep 2017 09:29:00 +0000

Wenn wir im Management praktische Beispiele für die Transparenz zeigen, die wir mit Kanban Systemen erzeugt haben, lösen wir damit in der Regel das aus, was ich als den „Harry and Sally-Effekt“ bezeichne: „Ich möchte genau das, was die Frau da drüben hatte“.

Enterprise Services Planning oder kurz ESP ist nun ein Ansatz, diese Transparenz auch für die gesamte Organisation zu nutzen, also über das Management einzelner Services hinaus. Welche neuen Möglichkeiten ergeben sich, wenn man klar definierte Services, stabile Durchlaufzeiten, Service- und Blockerstatistiken und ähnliche Einblicke hat? Wie kann man diese Transparenz nutzen, um sich intern besser aufzustellen? Was kann man daraus über die Fitness der Organisation lernen, den eigenen Markt zu bedienen?

ESP adressiert also ein Gebiet, das von agilen Ansätzen bisher nicht abgedeckt wurde, nämlich die Planung und Steuerung größerer Organisationen. Es steht damit nicht in Konkurrenz zu anderen Skalierungsansätzen wie SAFe oder LeSS, sondern kann komplementär zu ihnen eingesetzt werden, wobei auch nicht-agile Bereiche integriert werden können.

Vier größere Bereiche werden von ESP behandelt (siehe Bild):

Strategie: Hier stehen Fragen nach dem Markt im Vordergrund: Entspricht die Qualität der Services den Anforderungen des Marktes? Arbeiten wir mit der richtigen Marktsegmentierung? Haben wir ausreichend Fähigkeiten, um innovative Ideen anzugehen? Und wie grenzen wir die dabei entstehenden Risiken sinnvoll ein?
Risiko Management: Welche Risiken sind für uns wichtig? Haben wir den richtigen Risiko-Mix? Wie müssen wir unsere Organisation oder technischen Lösungen verändern, um häufig eintretende Risiken zu reduzieren?
Planung: Wie können wir probabilistische Planung verwenden, um das Portfolio und die Kapazitäten anzupassen? Wie können wir vermeiden, dass sich Vorhaben gegenseitig kannibalisieren?
Anforderungsmanagement: Wie stellen wir sicher, dass Fähigkeiten und Anforderungen an die verschiedenen Services zusammenpassen? Welche Optionen gibt es, die Anforderungen zu reduzieren? Wie managen wir komplexe Anforderungsworkflows?

Dafür interpretiert ESP die Organisation als Ökosystem interagierender Services. Es hilft, wenn diese Services jeweils als Kanban Systeme organisiert sind, ist aber nicht unbedingt notwendig. Sie können die organisatorische Transparenz von ESP auch als Treiber nutzen, um den Einsatz von Kanban auszuweiten und Agilität zu fördern.

Wenn Sie mehr zu ESP lernen wollen, melden Sie sich für unser Enterprise Services Planning Seminar an, das wir gemeinsam mit Alexei Zheglov anbieten, einem der Begründer von ESP. Sie haben die Wahl zwischen den 2-tägigen "Executive Track" und dem 5-tägigen "Become an Expert Track.

Der größte Referenzanwender von ESP ist derzeit eDreams Odigeo in Barcelona, der weltweit größte Reiseanbieter im Internet, der u.a. die Marken opodo, eDreams und Travellink betreibt
(Foto: J. Coldewey, mit freundlicher Genehmigung von eDreams odigeo).

On Agile Thinking and Respect

jens — Fri, 18 Aug 2017 16:08:00 +0000

Though many team members new to Agile (and unfortunately also some Agile bloggers) think that only management has to change, practice shows that both sides have to adopt new behaviors and models.

Agile is way more than Scrum, but in this particular case the five Scrum values of Respect Courage, Focus, Openness and Commitment provide good guidance. I particularly found Pete Behrens’ definition of Respect helpful in this context: “Respect (lat: Look or view again): Curiosity about how others view things, and a willingness to consider their perspective.”
Mutual respect is one of the core attributes an Agile organization needs to develop. It is the foundation to establish an aligned vision between management and staff, which is the replacement for compliance-driven command & control management in an Agile organization.

From a manager’s perspective respect means to be open and honest with your goals and the responsibility split intended. Using explicit delegation levels (as originally defined by Tannenbaum and Schmidt and made popular by Jürgen Appelo) and delegation poker have proven to be very powerful tools to negotiate and clarify boundary conditions and expectations. Managers need to understand that teams need sufficient freedom and empowerment to make fast decisions and new teams first need to learn how to use this freedom.

Team members on the other side need to understand that self-organization does not mean full autonomy on all decisions. Managers still have legal and organizational responsibilities and (should) have a more global perspective than the often localized perspective of a team. This needs active negotiation of responsibilities and delegation levels and the willingness to commit both to the empowerment and the liabilities that come with responsibilities.

Both parties need to understand that this is a mutual learning effort. So when your manager makes decisions your team should have been involved into (at least from your perspective), you should show Openness and Courage to address this with all due Respect – not to blame your manager (“Alas, finally I can take revenge on being blamed for 30 years…”), but to find ways to avoid these type of conflicts in the future.

And when you as a manager think your team doesn’t live up to their responsibility or demands more empowerment than you are ready to give, you should demonstrate Courage, Openness and Respect by working out what information or insight is missing for the team to make better decisions. Mature Agile managers usually challenge their teams by going on one or two delegation levels above what the team demands for.

Finally it is important to appreciate that both parties shall fail every now and then on this path. So both parties should treat failures as an opportunity to learn together, rather than an opportunity to blame each other. The place to discuss conflicts on responsibilities and find better ways to deal with them in the future is the Retrospective (or one of the Kanban Reviews if you’re using the Seven Cadences). And be prepared to have many Retrospectives until everybody has completely embarked on Agile Thinking.

Drei Design Thinking Aspekte, die jeder Product Owner kennen sollte

martin.stroebele — Thu, 17 Aug 2017 15:08:00 +0000

"Agile geht nicht mehr ohne Design Thinking!“, so rief mir neulich mein improuv-Kollege Krishan zu. Ich mag ihn für solche zugespitzten Zitate, denn es steckt ein wahrer Kern dahinter. Product Owner, die in einer agilen Produktorganisation die Verantwortung für Produkte und Services übernehmen, sollten sich in der Tat Design Thinking genauer anschauen.

Ich halte dabei folgende drei Punkte für besonders wertvoll:

1. Die Prinzipien hinter Design Thinking.

Meine Favoriten:

a. Think user centered
b. Work in multidisciplinary teams
c. Dare to be wild
d. Show – don’t tell
e. Build on ideas of others

Die Prinzipien helfen dabei im Team Raum für gute Ideen zu schaffen und Lösungen zu entwickeln, die echte Bedürfnisse adressieren.

2. Der Design Thinking Prozess.

Innovation als steuerbarer Prozess? Zumindest hilft der Design Thinking Prozess dabei. Es gibt ihn in unterschiedlichen Darstellungsformen. Die beliebtesten Varianten im Überblick:

Der „Double Diamond“, der auf den British Design Council zurückgeht.

Die Essenz:

• Trenne zwischen divergierendem Denken (Optionen entwickeln) und konvergierendem Denken (Optionen bewerten und verdichten).

• Trenne zwischen Problemanalyse und Lösungsfindung.

Weitere Infos:
http://www.designcouncil.org.uk/news-opinion/design-process-what-double…

Der 5-stufige Prozess wie ihn die d.school an der Stanford University beschreibt:

Die Essenz:
• Starte beim (potenziellen) Benutzer und baue Empathie auf. Versetze Dich in seine Situation.
• Fokussiere Dich bewusst auf eine konkrete Fragestellung.
• „Build to think and test to learn“: Baue haptisch erlebbare Prototypen als Teil des Lösungsprozesses und teste sie früh. So lernst Du Deine potenziellen Nutzer noch besser kennen und bekommst weitere Impulse für das Lösungsdesign.

Weitere Infos:
https://dschool-old.stanford.edu/sandbox/groups/designresources/wiki/36…

Die 4 Schritte, die Marc Stickdorn in „This is Service Design Thinking“ definiert:

Die Essenz:

• Design ist kein linearer Prozess. Nutze die Kraft von Iterationen!
• Starte mit einem „shitty first draft“.

3. Die Design Thinking Tools

Design Thinker nutzen eine Vielzahl von Tools, die insbesondere in den frühen Phasen der Produktentwicklung sehr wertvoll sein können. Nicht alle sind neu, viele sind hilfreich.

Einige meiner Favoriten:

Customer Journey Mapping

Welchen Weg legt mein Kunde zurück? Gedanklich, physisch, emotional? An welchen Stellen trifft er auf mein Produkt oder meinen Service? Über welche Kanäle interagiert er mit uns? Welche Bedürfnisse hat er in diesem Moment? Und wie geht es ihm dabei? Sehr hilfreiche Fragen: Hier Antworten zu finden und sie visuell aufzubereiten und zugreifbar zu machen – darum geht es bei einer Customer Journey Map. Ein sehr hilfreiches Tool, das flexibel auf die jeweilige Fragestellung anpassbar ist.

Buchempfehlung: „Mapping Experiences“ von Jim Kalbach
http://shop.oreilly.com/product/0636920038870.do

Crazy eight

Bei dieser Kreativtechnik geht es darum, in acht Minuten acht radikale Ideen möglichst visuell darzustellen. Das Ziel ist dabei in kurzer Zeit möglichst viele Ideen zu generieren. Quantität vor Qualität – die Bewertung der Ideen kann warten.

Web-Empfehlung: www.gamestorming.com (dort unter 6-8-5)

Ideen-Galerie

Die ideale Fortführung nach einer Ideation-Session. Hier geht es darum Ideen zu bewerten und weiterzuentwickeln.

• Vorbereitung: Die Teilnehmer skizzieren jede Idee einzeln auf einem A4-Blatt. Die wichtigsten Aspekte der Idee sollten selbsterklärend erkennbar sein. Was ist der Kern? Welches Problem löst die Idee? Für wen ist die Lösung geeignet / gedacht?
• Die Ideenskizzen werden einzeln an der Wand aufgehängt oder auf einem großen Tisch ausgelegt.
• Die Galerie ist eröffnet: Die Teilnehmer gehen im Raum von Idee zu Idee und bilden sich einen Überblick.
• Feedback: An jede Idee werden drei Sticky Notes angehängt, in unterschiedlichen Farben:

o Grün: Was mir an dieser Idee gefällt.
o Gelb: Was mir dazu noch einfällt.
o Rot: Was wir beachten sollten.

• Die Teilnehmer notieren auf diesen StickyNotes ihr Feedback.

Interessiert?

Du bist PO und wolltest Dich schon lange mal mit Design Thinking beschäftigen? Dann schau Dir das improuv-Trainingsprogramm an. Neben den öffentlichen Trainings bieten wir auch individuelle inhouse-Schulungen an.

SAFe 4.5 - die wichtigsten Neuerungen auf einen Blick

krishan — Mon, 17 Jul 2017 15:15:00 +0000

SAfe 4.5 ist im Juni freigegeben worden und bringt einige neue Features.

Manche sind kosmetischer Art, aber es gibt auch wichtige Erweiterungen und Klarstellungen.

Neue Delivery Pipeline

Die wohl wichtigste Erweiterung ist die Delivery Pipeline.
Sie baut nach wie vor auf dem Mantra „Develop on Cadence, Release on Demand“ auf, mit dem sichergestellt werden soll, dass das System jederzeit lieferfähig ist.
Offenbar wurde das aber bisher nicht in jeder Implementierung erfolgreich umgesetzt, so dass jetzt sehr viel Sorgfalt in die detaillierte Beschreibung fließt, wie eine erfolgreiche Pipeline aussehen muss.
Die Beschreibungselemente sind

Continuous Exploration, wo sichergestellt werden soll, dass regelmäßig neue Anforderungen des Marktes und der Kunden betrachtet werden und dass in Kooperation mit Kunden und anderen Stakeholdern neue Epic bzw. Features gefunden werden
Continuous Deployment, die Infrastruktur, die sicherstellt, dass neue Feature auch zuverlässig, in hoher Qualität und in kleinen Inkrementen bis in eine Staging-Umgebung geliefert werden können.
Continuous Delivery beschreibt, was nötig ist, wie die Features in die Staging- und Produktionsumgebungen geliefert werden können, damit man jederzeit liefern kann. Dies wird jetzt deutlicher als bisher von den Releasezyklen getrennt, die von externen Marktanforderungen, von strategischen Entscheidungen, Compliance-Freigaben und von vielem mehr beeinflusst werden können.

Integration von Lean Startup-Strategien

Nicht weniger wichtig ist die Integration von Ideen aus dem Lean Startup, mit der das Problem angegangen wird, dass der Fluss von Epics durch das Gdesamtsystem sehr linear aussah.
Vor allem in der Explorationsphase wird deutlich, dass die Beschreibung jetzz wesentlich iterativer als bisher ist. SAFe bezieht sich auf Lean Startup Strategien und das Lean UX Modell. Das heisst, dass ein Epic keinen Business-Case mehr bekommt, sondern eine Hypothese. Diese wird in einer ersten Version bis zur Marktreife entwickelt (als MMF, minimal marketable feature), dann wird entschieden, ob und wie oft weitere Versionen / Erweiterungen entwickelt werden. Dadurch kann der endgültige Umfang deutlich von der ursprünglichen Planung abweichen und es wird ein expliziter Lernzyklus in die Entwicklung eines Epic eingebaut - manche Epics werden dadurch auch nie fertig, sondern werden kontinuierlich weitgerentwickelt.

DevOps als Kultur- Organisations- und technische Aufgabe

DevOps wird als primär als organisatorische und kulturelle Aufgabe beschrieben: der wichtigste Punkt ist das Aufbrechen traditioneller Silos (Entwickler, Tester, etc.) in crossfunktionale Teams, die gemeinsam eine häufige Lieferung neuer Funktionalität sicherstellen können. Erst auf dieser Grundlage können die Werkzeugketten (die dann aber auch nötig sind) Wirksamkeit entfalten.

Die Einführungsstrategie ist konkreter geworden

Bei der Einführung werden wesentlich deutlicher die Erfolgsbedingungen und die Rollen bei einer SAFe Implementierung genannt als bisher.

Viele kleine Änderungen

Das Big Picture wird weniger komplex. Das Big Picture ist bereinigt worden und übersichtlicher geworden: zu viele Details drohten die Übersichtlichkeit zu gefährden. Das gilt umso mehr, als im Laufe der Zeit immer mehr Informationen dazugekommen sind. Dazu gehört auch das Herauslösen der verschiedenen optionalen Rollen in die Randleiste, die Spanning Paleete - es wir so zu einen klarer, dass z.B. Das Systemteam je nach Bedarf auf verschiedenen Ebenen angesiedelt werden kann. Pro Konfiguration werden auch verschiedene Rollen angeboten, was Erfahrungen aus verschiedenen Anwendungen repräsentiert.
Neue Konfigurationen. Die SAFe-Konfigurationen sind überarbeitet worden, um den Aufwand zur Anpassung zu reduzieren und sie zielgerichteter auf Anwendergruppen zuzuschneiden.
Umbenennungen. Verschiedene Umbenennungen sollen Quellen für Missverständnisse beseitigen. Die wichtigsten sind
• Die Value Stream Ebene heisst jetzt Solution-Ebene, insbesondere gibt es jetzt den Solution Train, einen Train of Agile Release Trains
• Das Budget-Verfahren heisst jetzt Lean Budgeting
• SAFe bekommt einen neuen Namen - es heisst jetzt „SAFe for Lean Enterprises“ - damit soll auch ein erweierter Anspruch für die Enwicklung komplexer "Systeme von Systemen", etwa aus Hardware- und Softwarekomponenten formuliert werden.

On Agile Thinking and Respect

jens — Fri, 18 Aug 2017 15:08:57 +0000

When Agile is introduced into an organization it completely changes the relationship between managers and staff. While traditional management models utilize the formal power of managers and compliance as the major tool to generate consistent behavior, Agile approaches emphasize self-organization and what the Organizational Development calls “Catalytic Leadership”. Though many team members new to Agile (and unfortunately also some Agile bloggers) think that only management has to change, practice shows that both sides have to adopt new behaviors and models.
Agile is way more than Scrum, but in this particular case the five Scrum values of Respect Courage, Focus, Openness and Commitment provide good guidance. I particularly found Pete Behrens’ definition of Respect helpful in this context: “Respect (lat: Look or view again): Curiosity about how others view things, and a willingness to consider their perspective.”
Mutual respect is one of the core attributes an Agile organization needs to develop. It is the foundation to establish an aligned vision between management and staff, which is the replacement for compliance-driven command & control management in an Agile organization.
From a manager’s perspective respect means to be open and honest with your goals and the responsibility split intended. Using explicit delegation levels (as originally defined by Tannenbaum and Schmidt and made popular by Jürgen Appelo) and delegation poker have proven to be very powerful tools to negotiate and clarify boundary conditions and expectations. Managers need to understand that teams need sufficient freedom and empowerment to make fast decisions and new teams first need to learn how to use this freedom.
Team members on the other side need to understand that self-organization does not mean full autonomy on all decisions. Managers still have legal and organizational responsibilities and (should) have a more global perspective than the often localized perspective of a team. This needs active negotiation of responsibilities and delegation levels and the willingness to commit both to the empowerment and the liabilities that come with responsibilities.
Both parties need to understand that this is a mutual learning effort. So when your manager makes decisions your team should have been involved into (at least from your perspective), you should show Openness and Courage to address this with all due Respect – not to blame your manager (“Alas, finally I can take revenge on being blamed for 30 years…”), but to find ways to avoid these type of conflicts in the future.
And when you as a manager think your team doesn’t live up to their responsibility or demands more empowerment than you are ready to give, you should demonstrate Courage, Openness and Respect by working out what information or insight is missing for the team to make better decisions. Mature Agile managers usually challenge their teams by going on one or two delegation levels above what the team demands for.
Finally it is important to appreciate that both parties shall fail every now and then on this path. So both parties should treat failures as an opportunity to learn together, rather than an opportunity to blame each other. The place to discuss conflicts on responsibilities and find better ways to deal with them in the future is the Retrospective (or one of the Kanban Reviews if you’re using the Seven Cadences). And be prepared to have many Retrospectives until everybody has completely embarked on Agile Thinking.

Die Lieferpipeline in SAFe 4.5

krishan — Mon, 31 Jul 2017 06:00:00 +0000

SAFe 4.5 legt wesentlich mehr Wert auf die Beschreibung guter Praktiken für eine Lieferpipeline, die eine solide Grundlage für einen zuverlässigen, effektiven und kontinuierlichen Wertstrom bildet. In einigen Implementierungen hat eine Unterschätzung dieser zugrundeliegenden Notwendigkeiten zu bestenfalls gemischten Erfolgen geführt.

Neu ist die explizite Beschreibung der iterativen und experimentellen Natur des Produktentwicklungsprozesses auf einer hohen Ebene. Zum einen schlägt sich das in der Beschreibung von Epics als Hypothesen nieder. Zum anderen ist das die Grundlage für eine explizite Aufnahme der Lean Startup Strategie und der Betrachtung des Kundennutzens mit den Lean-UX (User Experience) Prinzipien.

Die Continuous Delivery Pipeline eines Agile Release Trains repräsentiert die Workflows, Aktivitäten und Automatisierungen, die für eine kontinuierliche Wertschöpfung und Lieferung für den Endbenutzer erforderlich sind.

In SAFe besteht diese Pipeline aus vier Elementen:

Continuous Exploration, wo sichergestellt werden soll, dass regelmäßig neue Anforderungen des Marktes und der Kunden betrachtet werden und dass in Kooperation mit Kunden und anderen Stakeholdern neue Epic bzw. Features gefunden werden
Continuous Deployment, die Infrastruktur, die sicherstellt, dass neue Feature auch zuverlässig, in hoher Qualität und in kleinen Inkrementen bis in eine Staging-Umgebung geliefert werden können.
Continuous Delivery beschreibt, was nötig ist, wie die Features in die Staging- und Produktionsumgebungen geliefert werden können, damit man jederzeit liefern kann. Dies wird jetzt deutlicher als bisher von den Releasezyklen getrennt, die von externen Marktanforderungen, von strategischen Entscheidungen, Compliance-Freigaben und von vielem mehr beeinflusst werden können.
Entwickeln im Takt, Liefern nach Bedarf. Die Trennung des Entwicklungstakts von der kontinuierlichen Lieferung bleibt ein Mantra in SAFe und wird in Version 4.5 noch stärker betont als bisher. Damit wird sichergestellt, dass das System jederzeit lieferfähig ist und dass der Enticklungsfortschritt in einem definierten Zustand ist. Offenbar wurde das aber bisher nicht in jeder Implementierung erfolgreich umgesetzt, so dass jetzt sehr viel Sorgfalt in die detaillierte Beschreibung fließt, wie eine erfolgreiche Pipeline aussehen muss.

Zusammen bieten diese vier Elemente die Grundlage für eine integrierte Lean und Agile Strategie für die schnellere Freisetzung von Wert für den Kunden und vermeiden einen Rückfall auf einen linearen Prozess.

Die neue SAFe Version 4.5 - was bedeutet das für die Anwendung

krishan — Mon, 24 Jul 2017 06:07:00 +0000

Die neue Version 4.5 von SAFe ist gerade erschienen und das bietet Anlass, nicht nur über die Änderungen in SAFe selbst nachzudenken, sondern auch über die Entwicklungen in der Agilität im Allgemeinen zu reflektieren.

Neue Mitbewerber sind erkennbar: das LeSS-Framework ist fertig, jetzt auch gut dokumentiert und hat sich als klarer Zweiter im Markt für Agile Skalierungsframeworks etabliert. Damit ist es so etwas wie ein Zweikampf geworden. Interessant ist dabei auch die klare Abgrenzung durch die erheblichen konzeptionellen Unterschiede: Während SAFe darauf setzt, schnell zu starten und für die meisten Vorschläge einen initialen Vorschlag zu machen, konzentriert sich LeSS viel stärker auf den notwendigen Kulturwandel als notwendige Voraussetzung. SAFe setzt darauf, dass die kulturellen Änderungen im laufenden Betrieb umgesetzt werden. Es zeigt sich bei unseren Kunden, dass die beiden Frameworks für sehr verschiedene Ausgangssituationen interessant sind.

Einige der Erfahrungen beim Einsatz sind auch in die Änderungen von 4.5 eingeflossen: man sieht ein klares Bemühen, mögliche Gründe für Implementierungs-Fehlschläge zu identifizieren und zu adressieren. Insbesondere die neue Einführungsstrategie und die wesentlich erweiterte und überarbeitete Liefer-Pipeline sind hier zu nennen.

Neue Diskussionen erzeugen auch neue Missverständnisse: so wie man SAFe als Blaupause verwenden kann (es sei nochmals betont: man wird ohne ein tiefes Verständnis der systemischen Zusammenhänge keine erfolgreiche Implementierung stemmen), so werden auch Erfahrungsberichte wie die der schwedischen Firma Spotify als Blaupause angewendet, wenn man über agile Transformation nach dem Spotify-Framework redet: Spotify ist aber kein Framework, sein Beitrag zur Agilität ist nicht die Umbenennung von Teams zu Squads, sondern der Beitrag ist substantieller: wie kann man Vertrauen und Alignment skalieren und dabei nutzbar machen, die Software-Codebasis radikal zu entkoppeln. Das Vertiefen des Verständnis für agile Prinzipien wird in der nächsten Zeit eher noch stärker als bisher die Agenda in der Anwendung aller Frameworks bestimmen.

Das gilt umso stärker, als Agilität definitiv den Mainstream erreicht: die meisten großen Unternehmen setzen auf agile Transformation und für viele von ihnen hat sich auch das Verständnis von Agilität verändert: es ist ein umfassender und nachhaltiger Kultur- und Strategiewandel, Agilität ist nicht mehr auf die da unten im „Maschinenraum“ begrenzt, es umfasst Agile Geschäftsentwicklung und damit den Arbeits- und Aufgabenbereich des Top-Managements: Agilität steht dafür, auf allen Ebenen neue Fähigkeiten für die Firmen zu erschließen. Dazu brauchen wir nicht nur die Frameworks als Werkzeuge, sondern auch ein umfassendes Verständnis aller Beteiligten auf jeder Ebene.

Die wichtigsten Erfindungen von Spotify

krishan — Mon, 25 Jun 2018 07:34:00 +0000

Die veröffentlichten Prinzipien von Spotify sind für viele faszinierend. Wahrscheinlich ist ein wichtiger Faktor dafür, dass Agilität bei Spotify einfach funktioniert.

Ich füge meine eigene Interpretation hinzu. Ich kenne auch nur die öffentliche Darstellung von Henrik Kniberg auf verschiedenen Konferenzen, daher mein Beipackzettel: es ist eine weitere Interpretation.

Für mich kann man den Erfolg auf einen wesentlichen Grund zurückführen: Agiles Mindset ist Chefsache und wird konsequent gelebt, z.B. in einer rigorosen Orientierung auf Mitarbeiterzufriedenheit. Das hat wohl zu einer sehr reifen und verantwortlichen Organisation geführt.

Darüber hinaus sind es zwei Schlüsselerfindungen, die mich beeindruckt haben: Radikal lose Kopplung und Skalieren von Vertrauen

Lose Kopplung

Teams (ja, sie heißen nicht mehr Teams, aber trotzdem) können deshalb sehr autonom arbeiten, weil Spotify eine Policy entwickelt hat, um die Code-Abhängigkeiten zu minimieren. Darüber hinaus kann ein kann den Code eines anderen Teams klonen und weiter bearbeiten. Aus einer synchronen Abhängigkeit und damit einem potenziellen Blocker wird eine asynchrone Aufgabe, regelmäßig wieder zu konsolidieren. Wie gesagt, eine Lösung einer reifen Organsiation.

Skalieren von Vertrauen

Woraus entsteht Glaubwürdigkeit und Vertrauen? Aus nachgewiesener Kompetenz, Transparenz, gemeinsamen Zielen und regelmäßigem Austausch. Spotify hat mit den Gilden und Tribes die Strukturen, einen solchen Austausch zu leben und die Kompetenz und Transparenz regelmäßig zu hinterfragen.

Vollzeit-Scrum Master?

Bei Spotify hat nicht mehr jedes Team einen Vollzeit-Scrum Master – stattdessen können sie auf Coaches zurückgreifen, wenn sie das Gefühl haben, einen solchen zu benötigen. Ein Beispiel wäre für mch Konfliktmoderation, oder auch die Adressierung eines externen Problems, das eskaliert werden muss.

Das entspricht auch meiner Erfahrung in vielen Teams: sie brauchen jemanden, der regelmäßig den Austausch am Laufen hält, die meisten anderen Aufgaben kann ein erfahrenes Team selbst stemmen.

Aligned Autonomy

Alignment ist eine Voraussetzung für Autonomie – das ist eine der Formulierungen, die aus dem Spotify-Umfeld bekannt geworden sind. Ja, stimmt – ich stimme zu und setze noch den Zusammenhang der Fokussierung. Mehr dazu in einem früheren Blogeintrag.

Verbreitung

Es gibt nun verschiedene agile Implementierungen, die sich auf das Spotify-Modell berufen. Ich habe damit meine Probleme: zum ersten bestreiten die Autoren, dass es ein allgemeines und wohldefiniertes Spotify-Framework gibt. Zum zweiten sehe ich eine Tendenz, nur die Nomenklatur zu übernehmen und den Mindset-Teil zu übersehen. Mir ist es egal, ob jemand Teams umbenennt – ob aber eine neue Wortwahl wirklich zielführend ist, wag ich doch zu bezweifeln.

improuv - Agile Leadership

hedi.buchner — Tue, 16 Apr 2019 14:04:19 +0000

Nach 7 Jahren als Agile Coach und Gesellschafterin bei improuv bin ich seit 1. Februar Geschäftsführerin – gemeinsam mit Christoph Mathis und Jens Coldewey.

Nachdem ich das verflixte 7. Jahr größtenteils in Elternzeit verbracht habe, kam ich mit einem frischen Blick auf improuv zurück – und habe mir gemeinsam mit Jens und Christoph drei Fragen gestellt:

Was macht improuv aus?

Uns alle vereint ein Streben nach Exzellenz. Wir wollen wachsen, lernen und neue Möglichkeiten ausloten - wir wollen neue Ideen entwickeln und experimentieren – wir wollen den Status Quo in Frage stellen, und den Menschen und unsere Kunden in den Mittelpunkt.

Wie arbeitet improuv?

Wir sind der Überzeugung, dass uns das am Besten im Team gelingt (das gilt übrigens auch für die Geschäftsführung), indem wir uns Offenheit für neue Ansätze bewahren und uns Zeit nehmen für Reflexion und Augenhöhe. Wir sind im Herzen agil, nutzen die Prinzipien und leben die Kultur. Durch unsere langjährige Erfahrung mit agilen Transitionen haben wir unsere Expertise aufgebaut. Wir haben die Entwicklung von agil miterlebt und mitgestaltet. Von der Graswurzelbewegung bis in die Führungsebenen der Unternehmen.

Wir als improuv sehen uns dabei als Katalysator für die zielgerichtete Entwicklung von Menschen und Systemen: Unsere Themen sind Enablement und Empowerment.

Wie schaffen wir das?

Daran arbeiten wir tagtäglich gemeinsam mit unseren Kunden. Wir begleiten sie in ihrer Agile Evolution – vom Start der agilen Transformation hin zu einem agilen und resilienten Unternehmen. Das schaffen wir durch viel Erfahrung, Organisationsentwicklung, Trainings zu agilen Methoden, Skalierungsansätzen und Führungskonzepten. Mit agilem und systemischem Coaching für Teams, Führungskräfte, Value Streams und Organisationen. Und durch den Aufbau von internen und firmenübergreifenden Netzwerken und Communities zum Wissenaustausch.

Für Christoph, Jens und mich sind das mehr als genug Gründe, um improuv als Geschäftsführer zu unterstützen. Und es zeigt uns auch nochmal, was für eine großartige Arbeit Angelika Drach geleistet hat, die improuv gemeinsam mit Christoph gegründet hat und zu dem gemacht hat, was es heute ist. Herzlichen Dank Angelika, genieße deinen wohlverdienten Ruhestand!

Wir freuen uns sehr darauf, improuv gemeinsam mit allen Kollegen und Kunden weiterentwickeln und gestalten zu dürfen.

Beyond Budgeting und Agile Transition - wie passt das zusammen?

jens — Fri, 12 Apr 2019 06:47:00 +0000

Agile Transitionen sind mittlerweile aus der Innovatorenecke herausgekommen und die meisten größeren Organisationen haben eine oder mehrere Initiativen laufen, um „Agilität einzuführen“ - was immer das im konkreten Fall heißen mag. Es ist inzwischen auch klar, dass es bei weitem nicht damit getan ist, Scrum in ein paar Teams zur Softwareentwicklung einzuführen. Die Einführung von Agilität berührt viele Aspekte einer Organisation: Wie werden Budgets verteilt und überprüft? Wie werden persönliche Ziele festgelegt? Nach welchen Kriterien wird die Organisation wirtschaftlich geführt? Wie funktionieren Governance und Controlling in einer agilen Organisation?

Agile Vorgehensweisen hatten nie den Anspruch, Antworten auf alle diese Fragen zu finden. Ansätze zur Skalierung wagen sich ein wenig in diese Bereiche vor: SAFe geht bis in die Portfolioplanung und Kanban leistet mit seinen Überlegungen zu „Fit for Purpose“ und Operations Reviews Beiträge zur Unternehmenssteuerung. Fragen der klassischen Unternehmenssteuerung werden aber bewusst offengelassen.

Glücklicherweise ist Agilität aber nur ein Mitglied einer ganzen Reihe von Bewegungen, die sich seit den 1990ern damit beschäftigen, Unternehmen flexibler, schneller und oft auch menschlicher zu machen. Wenn es an Fragen der Unternehmenssteuerung geht, finde ich Beyond Budgeting eine der spannendsten Bewegungen und das aus mehreren Gründen:

Beyond Budgeting liegt ein Wertesystem zugrunde, das dem agilen Wertesystem sehr ähnelt. Beide legen den Fokus auf die Kunden, sie gehen davon aus, dass Mitarbeiter grundsätzlich gute Leistung bringen wollen und nicht von ihren Vorgesetzten zur Arbeit gezwungen werden müssen und sie sehen Lernen als wesentliche Fähigkeit einer Organisation.
Beyond Budgeting kommt aus einer Community von Controllern, also denen, deren Aufgabe die Steuerung von Unternehmen ist.
Beyond Budgeting wird seit zum Teil über 25 Jahren in verschiedenen großen Unternehmen vor allem in Skandinavien verwendet, um die Probleme klassischer Governance zu vermeiden. Unter ihnen befinden sich lokale Champions, wie die Svenska Handelsbanken in Schweden und internationale Schwergewichte, wie Equinor - ehemals Statoil - in Norwegen.

Der Name „Beyond Budgeting“ ist verwirrend, weil er suggeriert, es ginge nur um die Ablösung von Budgetierungsritualen. Selbst große Beratungshäuser verbreiten die (falsche) Auffassung, Kern von Beyond Budgeting wäre ein rollierender Budgetierungsansatz. Stattdessen besteht Beyond Budgeting im Kern aus sechs Führungsprinzipien und sechs Management Praktiken, die häufig als die zwölf Prinzipien des Beyond Budgeting referenziert werden.

Einen tieferen Einblick bieten die zwölf Videos auf https://bbrt.org/the-beyond-budgeting-principles/12-beyond-budgeting-pr…, in denen die Mitglieder des Core Teams, das sich der Weiterentwicklung von Beyond Budgeting verschrieben hat, die einzelnen Prinzipien erklären.

Wenn also die agile Transition an ihre organisatorischen Grenzen stößt, könnte es sinnvoll sein, wenn sich die Unternehmensführung Beyond Budgeting ansieht. Es hilft nicht nur, Hindernisse gegen Agilität aus dem Weg zu räumen, sondern dürfte auch einige weitere Probleme in anderen Bereichen der Organisation zu lösen, selbst wenn diese in die Agile Transition gar nicht involviert sind.

Wardley Mapping - ein großartiges Werkzeug zur Strategie-Entwicklung

krishan — Fri, 15 Feb 2019 06:47:00 +0000

Im Dezember hatte ich einen richtigen Glücksgriff: ich war auf einer gemeinsamen Masterclass von Simon Wardley und Dave Snowden.

Dave Snowden ist ja schon seit einiger Zeit bekannt über seine Beiträge zur Komplexitätstheorie, sein Cynefin Framework.

Simon Wardley hingegen tauchte auf meinem Radar erst vor ca. einem halben Jahr auf. Dabei sind seine Arbeiten zum Teil auch zehn und mehr Jahre alt, nur nicht so bekannt. Simons Arbeit ist jedoch auch ein grundlegend neuer Beitrag.

Das Seminar – „master class“ – war neben einem kurzen Überblick über die Theorien eine Fundgrube von Ideen, wie die beiden Konzepte gemeinsam genutzt werden können.

Der Glücksgriff war, Simon anzusprechen, ob er auf der Agile World eine Keynote halten will. Zu meiner Überraschung hat er Zeit und Lust dazu.

Aus diesem Anlass schreibe ich eine Folge von Blogs, um seine Schlüsselkonzepte weiterzugeben.

Im Kern stehen Landkarten, „maps“. Maps sind ein Konzept, das, richtig angewendet, Visualisierung wesentlich wirksamer machen kann.

Simons erstes Beispiel: wie kann man sich die klassische Schlacht bei den Thermopylen visualisieren – und zeigt, etwas polemisch eine SWOT-Graphik als Kontrast.

Seine eigenen Maps, die Wardley-Maps, sind ganz spezifisch für strategische Analyse konstruiert.

Die X-Achse, ist die Bewegungsrichtung von Produkten. Sie starten als Genesis, also neue Erfindung, werden als nächstes in Handarbeit nach Bedarf hergestellt, dann werden sie zum Produkt und zuletzt zur Commodity. Die Y-Achse zeigt die Sichtbarkeit aus Sicht der Kunden.

Darüber liegt ein strategischer Kreis, der mit der Situationsanalyse beginnt, dann die Handlungsoptionen untersucht und schliesslich mit der Entscheidung und Ausführung endet. Zu den verschiedenen Stationen des Kreises hat Simon auch einen großen Katalog von Patterns und Heuristiken gesammelt.

Jeder dieser Schritte ist es wert, genauer beleuchtet zu werden und das werde ich in der nächsten Zeit auch tun. Wardley Mapping ist ein großartiges Werkzeug, es hat uns improuvies schon geholfen, aus ein paar schwierigen Situationen schlau zu werden und bessere Entscheidungen zu treffen. Also: später mehr.

Lernende Organisation und Agilität

zoi — Mon, 12 Nov 2018 09:58:00 +0000

Ohne Lernen neigen Organisationen dazu, Bewährtes zu wiederholen und nur oberflächliche und kurzfristige Verbesserungen zu erzielen. Diese kurzfristigen Anpassungen sind nicht ausreichend, um für die komplexen Herausforderungen der Zukunft gewappnet zu sein.

Für uns als Unternehmensberatung ist organisationales Lernen Teil unserer Dienstleistung und gleichzeitig ein Unternehmenswert, eine gemeinsame, verbindende Haltung. Leider ist das Konstrukt Lernende Organisation sperrig und wird als wenig praxisrelevant empfunden.

Im Rahmen meines Studiums der Wirtschaftspsychologie habe ich mir deswegen die Frage gestellt, wie Unternehmen eigentlich in der Praxis die Handlungsfelder zur Lernenden Organisation umsetzen und welche Maßnahmen dabei helfen. Dieser Frage bin ich in einer qualitativen Studie nachgegangen.

Die theoretische Grundlage bildeten die Arbeiten von Senge sowie Marsick & Watkins. Senge habe ich wegen seiner holistischen und integrativen Betrachtungsweise ausgewählt. Wo seine Theorien und Modelle zu unspezifisch und abstrakt waren, habe ich die konkreten und klar definierten Handlungsrichtlinien von Marsick & Watkins hinzugezogen. Der wesentliche Beitrag der beiden Forscher liegt in der Operationalisierung des Konstruktes und der daraus resultierenden Messbarkeit.

Die Komplexität und Vielschichtigkeit der lernenden Organisation spiegelt sich in der Anzahl und Bandbreite der gefundenen Kategorien wieder. Insgesamt habe ich aus der inhaltsanalytischen Auswertung der Interviews 15 Kategorien abgeleitet. Alle zu erwähnen würde den Rahmen diesen Posts sprengen. Deswegen sind hier nur einige der Ergebnisse angerissen, die wir gut aus der agilen Praxis kennen.

Integration von Lernen und Arbeiten

Hier geht es vor allem darum Lernen als Teil der täglichen Arbeit zu integrieren. Das passiert dort wo Interaktion zwischen Individuen stattfindet. Formate die das unterstützen sind bspw. Communities of Practice, Retrospektiven, aber auch das gute alte Daily. Die Formate helfen Lernen zu institutionalisieren und von individueller auf Team Ebene zu übertragen.

Teams

Teams scheinen überhaupt das Herzstück der Lernenden Organisation zu sein und das Zauberwort heißt Kollaboration. Sie findet dort statt wo Teams stabil über einen längeren Zeitraum miteinander arbeiten. Auch dieses Konzept kennen wir aus der agilen Welt. Teams brauchen weiterhin Dialogfähigkeit um eine gemeinschaftliche und zweckorientierte Ausrichtung zu bekommen und aus Fehlern zu lernen. Dabei hilft Vertrauen und Offenheit. Mediation, Moderation und Retrospektiven können dabei unterstützen. Auch wenn das in den Interviews explizit nicht erwähnt wurde, so muss ich doch hier an die Arbeit des Scrum Masters denken.

Ein weiterer wichtiger Aspekt in Zusammenhang mit Teams ist Freiraum. Diesen brauchen sie um zu lernen und neue Impulse zu bekommen. Möglichkeiten um diesen Freiraum herzustellen sind Open Spaces, Hackathons, interaktive, interne Konferenzen, Meet-ups, Learning Lunches und Agile Days.

Mindset

Eines der grundlegenden Handlungsfelder der Lernenden Organisation ist die Arbeit mit mentalen Modellen. Mentale Modelle sind tief verwurzelte Annahmen und Bilder, die einen Einfluss auf unsere Wahrnehmung und Interpretation der Welt haben und handlungsleitend wirken. Sie entstehen durch persönliche Erfahrungen und sind stark Kontextabhängig, weswegen es kein einheitliches Bild der Welt oder einer Organisation geben kann. Sie können Lernen behindern indem sie zu den immer gleichen Handlungsweisen verleiten, nach dem Motto „das haben wir schließlich schon immer so gemacht“ . Transparenz ist die notwendige Bedingung um Sichtbarkeit zu erzeugen. Daraus kann dann Alignment entstehen. Wie tragen Agile Methoden dazu bei? Durch Reflexion, Retrospektiven, Imaginations- und Visualisierungsworkshops kann die Auseinandersetzung mit mentalen Modellen gefördert werden und so helfen zu neuen, gemeinsamen Modellen der Realität zu gelangen.

Führung

Lernende Organisationen werden durch einen ermöglichenden und unterstützenden Führungsstil, sowie der hohen Motivation Ihrer Mitarbeiter aktiv gestaltet. Dazu braucht es Handlungs- und Entscheidungsfreiräume und die Möglichkeit zu reflektieren und zu experimentieren. Lernen wird dadurch ein wertstiftender Teil der alltäglichen Arbeit. Dabei ist es wichtig, die Unternehmensziele und Visionen im Auge zu behalten.

Wer mehr erfahren möchte, kann mich gerne kontaktieren, die Arbeit haben und gerne auch diskutieren.

Last but not least, möchte ich mich ganz herzlich bei meinen Kollegen Angelika und Krishan bedanken die mir den Rücken freigehalten haben, damit ich unglaubliche 40 Din A4 Seiten Interviewmaterial auswerten konnte. Tausend Dank!!

SAFe PI Planning bei Siemens Mobility - Tag 2, Herausforderungen und Lösungen

tina.rieger — Fri, 13 Dec 2019 08:59:00 +0000

Tag 2 – Finalisierung des PI Planning

Planning Adjustment und Team Breakout 2

zum Teil 1

Zum Start des 2. Tages des SAFe PI Planning stellten die RTE und das Product Management die im Management Review getroffenen Entscheidungen vor. Danach starteten die Teams in ihr zweites Team Breakout, wo sie ihre Planung vom Vortag fortsetzten und die Anpassungen aus dem Management Review berücksichtigten.

Inspect and adapt: An Tag zwei versuchte Simone ein neues „Scrum of Scrums“ Vorgehen. Diesmal organisierten sich die Scrum Master selbstständig und aktualisierten am Board nach eigenen Zeitplan den Fortschritt der Planung. Die Scrum Master waren sehr zufrieden mit dem neuen Vorgehen, da sie weniger in dem Planungsfluss mit den Teams gestört wurden.

Final Plan Review

Direkt nach der Mittagspause fand um 13 Uhr das Final Plan Review statt, in dem alle Teams ihre finalen Pläne vorstellten. Mit Blick auf die Timebox fokussierten sich alle Teams bei ihrer Präsentation auf die Veränderungen gegenüber dem Vortag sowie auf die identifizierten Risiken. Aus dem Plenum kamen nur noch wenige Fragen auf und die Planung wurde übernommen.

Program Risks

Anschließend wurden die Programm Risiken der einzelnen Teams, die das Erreichen der Ziele des Programminkrements beeinträchtigen könnten, genauer besprochen. Die Risiken wurden im Plenum vorgestellt und direkt am Risiko Board klassifiziert:

Resolved – Die Teams sind sich einig, dass das Risiko kein Problem mehr darstellt.
Owned – Das Risiko kann im Meeting nicht gelöst werden, jemand übernimmt die Verantwortung für die Bearbeitung.
Accepted – Manche Risiken sind Fakten oder Möglichkeiten, die man einfach nur verstehen und akzeptieren muss.
Mitigated – Die Teams haben einen Plan um die Auswirkung des Risikos zu reduzieren.

Confidence Vote

Nachdem alle finalen Pläne und Risiken bekannt waren, konnte der Confidence Vote stattfinden. Gewählt wurde das "Fist of Five" Prinzip. Die Anwesenden bewerteten, für wie realisierbar sie die Planung ihres Teams halten. Wenn der Durchschnitt drei Finger oder mehr beträgt kann das PI Planning verabschiedet werden, was hier der Fall war. Die Personen mit einem Vote von 2 wurden gebeten, ihre Gründe dafür zu teilen.

Planning Retrospective and Moving Forward

Jedes PI Planning endet mit einer Retrospektive und der Besprechung der nächsten Schritte. Die Fragen dieser Retrospektive waren:

What I liked about PI Planning?
What can be changed to improve PI Planning?

Die letzten Schritte des Tages: alles fürs Protokoll und die Nacharbeiten fotografieren, abbauen und zusammenpacken. Da die Teams schon während des PI Planning die Feature, User Stories und Enabler im System erfasst hatten, können alle direkt mit der Sprint Arbeit starten.

Cross Cutter

An beiden Tagen gab es parallel zu den Breakout Phasen sogenannte "Cross Cutter" Sessions wo Themen diskutiert wurden, die teamübergreifend für die Planung relevant sein können. Die Teilnahme war freiwillig und für jeden offen. Diese Form des Austausches wurde als sehr hilfreich angesehen, weswegen die Cross Cutter Sessions sicherlich wieder Teil des nächsten PI Planning sein werden.

ENDE Tag 2

Herausforderungen und Lösungen

Auch bei Siemens Mobility gab und gibt es einige Herausforderungen auf ihrer PI Planning Reise, wie bspw.

Die Koordination von Dependencies
Transparenz herzustellen beim Draft und Final Plan Review ohne die Time Box zu sprengen
Die SMARTe Formulierung von PI-Objectives
Alle Beteiligten an einen Ort versammeln
Uvm.

Das ART Team der Siemens Mobility hat beschlossen, sich für jedes PI Planning eine relevante Maßnahme auszuwählen, in der sie sich bewusst verbessern wollen. Das schafft Offenheit bei den Kollegen sich auf das neue Umfeld einzulassen und erreicht eine gesunde, kontinuierliche Verbesserung in der Kommunikation und in der cross-funktionalen Zusammenarbeit. Zudem stärkt es das Alignment.

improuv Coach: Taghi Paksima

PI Planning bei Siemens Mobility - Vorbereitung und Tag 1

tina.rieger — Fri, 06 Dec 2019 09:02:00 +0000

Siemens Mobility hat vor rund einem Jahr mit SAFe begonnen und vor kurzem das inzwischen 4. PI Planning durchgeführt. Wie ein PI Planning bei Siemens Mobility abläuft wollen wir im Folgenden kurz beschreiben.

Zum 4. PI Planning trafen sich rund 90 Kolleginnen und Kollegen in München, um gemeinsam die nächsten 6 Sprints ihrer Produktentwicklung zu planen.

Wie wesentlich das Meeting bei einer SAFe Implementierung ist, wird durch den Satz der SAFe Autoren deutlich: „If you are not doing it, you are not doing SAFe.“

Das PI Planning durchläuft verschiedene Phasen, die ausführlich auf der Seite: https://www.scaledagileframework.com/pi-planning beschrieben sind. SAFe schlägt eine Standardagenda vor, die über zwei Tage geht, an der sich auch Siemens Mobility orientiert hat.

Agenda PI Planning

Beim ersten Lesen wirkt es selbsterklärend und super einfach. In der Praxis bringt es die ein oder andere Herausforderung mit sich, denn: „Gelesen ist noch nicht verstanden – verstanden ist noch nicht einverstanden – einverstanden ist noch nicht gelebt.“

Die Vorbereitungsphase

Das PI Planning ist nicht nur ein wichtiges sondern auch ein relativ aufwändiges Meeting, was entsprechend intensiv vorbereitet werden muss. Damit die Veranstaltung ein Erfolg wird sind insbesondere Vorbereitungen in drei Bereichen nötig:

Herstellen einer organisatorischen Basis: Abstimmung zwischen Produktmanagement und Business Owner über die strategische Ausrichtung, Betrachtung der Team Struktur
Vorbereitung der Präsentation für das PI Planning: Aktualisierung der Vision, Abgleich mit Backlog, Darstellung der wichtigsten Objectives und Features
Organisation des Termins: Infrastruktur, Räumlichkeiten, Einladung, Agenda

Simone ist Release Train Engineer (RTE) der Siemens Mobility. Sie weiß, als Hauptorganisatorin der Veranstaltung, Unterstützerin der Kolleginnen und Kollegen im Vorfeld, Impulsgeberin im SAFe Kontext und als Moderatorin des PI Plannings, dass sie direkt nach einem PI Planning mit der Planung des nächsten beginnen sollte.

Face-to-Face

Trotz der geografischen Distanz zueinander hat es die Siemens Mobility geschafft, fast alle der teilnehmenden Kolleginnen und Kollegen vor Ort zu versammeln. Die face-to-face Möglichkeit brachte gleich mehrere positive Effekte mit sich, die uns auch von Teilnehmern bestätigt wurden:

"Wir konnten viel intensiver miteinander arbeiten und aufeinander eingehen. Das ermöglichte uns leichter unser PI Planning Ergebnis zu erarbeiten und uns zu committen."
"In den Pausen und am Abend konnten wir uns persönlich austauschen und besser kennenlernen."
"Der persönliche Kontakt hilft uns in der täglichen Zusammenarbeit, denn dadurch können wir Worte und Handlungen unserer Kollegen im Alltag besser einschätzen."

Tag 1 - Start des PI Planning

Bevor pünktlich 9 Uhr das PI Planning startete mussten die Materialien verteilt, die Technik geprüft, 12 Team Stationen und das Dependency Board aufgebaut werden. Ganz nach dem agilen Prinzip haben spontan Teilnehmer angeboten, uns zu unterstützen. Damit war sicher, die Vorbereitungen im Raum sind rechtzeitig abgeschlossen.

Vom Business Context bis zum Planning Context

Simone startete das PI Planning indem sie alle Anwesenden über den Ablauf informierte. Danach gab sie an den Business Owner ab, der einen Überblick über den geschäftlichen Kontext und die langfristig geplante Ausrichtung präsentierte.

Im Anschluss gab der Chief Architect einen kurzen Einblick zur technischen Architektur und den gewünschten Praktiken, bevor zwei Kollegen den aktuellen Status der Testautomatisierung und die geplanten nächsten Schritte vorstellten. Hierbei haben sie sich für eine Präsentation im Interview Format entschieden, was sehr auflockernd war. Als Abschluss der Auftaktveranstaltung erläuterten die Produktmanager ihre im Vorfeld erarbeitete Produkt Vision, Objectives und Top 25 Features.

Ein kleiner Tipp von uns: es ist wichtig sich Pausen zu gönnen, um dann wieder mit voller Kraft weiterzumachen.

Direkt nach der Mittagspause ging es mit dem Planning Context weiter. Dort stellte die RTE den Planungsprozess vor, erläuterte die nächsten Schritte des Tages und die erwarteten Ergebnisse und Ziele des Meetings. Ganz bewusst mit Bezug auf die Inhalte vom Vormittag.

Team Breakout 1

Während der 1. Team Breakout Phase von 3 Stunden schätzten die Teams ihre Kapazität für jeden Sprint, entwickelten und verfeinerten die einzelnen Inhalte, die zur Realisierung der Features und Enablers beitragen und planten diese in die jeweiligen Sprints auf ihren Team Board ein. Zudem wurden erste Risiken und Abhängigkeiten identifiziert. Die Abhängigkeiten zu anderen Teams wurden teamübergreifend abgestimmt und auf dem Program Board visualisiert.

Während der Team Breakout Phase trafen sich mehrmals die Scrum Master der Teams mit dem RTE zum „Scrum of Scrums“, um die Fortschritte der Planung zu besprechen.

Draft Plan Review

16 Uhr das Draft Plan Review. Hier stellten die Teams in großer Runde ihre Planungen aus der ersten Breakout Phase vor, adressierten erste erkannte Risiken und Abhängigkeiten und holten sich Feedback ein. Eine große Herausforderung in den ersten PI Plannings war die Einhaltung von Timeboxen bei den Präsentationen. Alle haben daran gearbeitet und es diesmal geschafft, diese einzuhalten.

Nach dem Draft Plan Review gab es Zeit für Networking, was auch dankend genutzt wurde.

Management Review

Für Business Owner, Chief Architect und das Product Management ging es in den letzten Agendapunkt des Tages. In dieser Phase stimmt sich das Management über den Umfang der Planung ab, nimmt notwendige Änderungen vor und löst aufgekommene Abhängigkeiten auf. Ausgewählte Features wurden für dieses PI Planning gestrichen und die Betrachtung von Risiken wurde nochmals in den Fokus gestellt. Die RTE moderierte das Review. Ziel des Management Reviews war es alle Entscheidungen zu treffen, die notwendig sind um erreichbare Ziele zu formulieren.

Das Management Review dient klassisch dem Alignment und der Teamunterstützung. Mit den Ergebnissen dieses Meetings planen die Teams am nächsten Tag weiter.

Hier gehts zu Teil 2

improuv Coach: Taghi Paksima

Das Buch Agile

krishan — Tue, 03 Sep 2019 08:45:00 +0000

Die DACH30 Arbeitsgruppe ist ein Zusammenschluss von agilen Coaches und Change Agents aus grossen Unternehmen in D-A-CH. In dieser Arbeitsgruppe gibt es intensive Diskussionen um ein gemeinsames Verständnis - in diesem Zusammenhang wurde das "Book of Agile" erarbeitet. Es beschreibt ein gemeinsames Grundverständnis über Agilität.

Das Grundverständnis

Die meisten Menschen in der Unternehmenswelt sind sich einig, dass Flexibilität und Agilität wesentliche Fähigkeiten in dem dynamischeren und weniger vorhersehbaren Geschäftsumfeld von heute sind. Die Digitalisierung beschleunigt den Bedarf an Organisationsstrukturen und Prozessen, die in der Lage sind, schnell auf Veränderungen zu reagieren.
Moderne Geschäftsansätze nutzen den Wissenspool von Agile, Lean und Systems Thinking, um Business Agilität zu erreichen. Agile Unternehmen unterscheiden sich grundlegend von traditionellen Unternehmen - nicht nur bei der Entwicklung von Kundenlösungen, sondern auch bei der Unternehmensführung und den internen Abläufen.

Die spezifischen Probleme grosser Unternehmen

Etablierte Unternehmen haben oft Angst, ihre Betriebssysteme zu aktualisieren, um ihre Agilität zu erhöhen, wenn sie die wichtigsten Praktiken und Denkweisen aufgeben, die ihr Wachstum in der Vergangenheit unterstützt haben. Dies scheint eine besondere Herausforderung für Großunternehmen zu sein.
Natürlich wird es kein universelles "Lean-Agile-Betriebssystem" geben, das auf allen "Enterprise Hardware-Systemen" läuft. Das Betriebssystem muss speziell für jedes Unternehmen entwickelt werden. Es lassen sich jedoch einige Muster beobachten, die eine erfolgreiche Umsetzung der Agilität wahrscheinlicher erscheinen lassen.
Große Unternehmen stehen vor besonderen Herausforderungen, agile Prinzipien in ihre Prozesse, Governance-Systeme und Unternehmenskultur zu integrieren.

Im Buch Agile geht es um die Herausforderungen dieser Unternehmen.

Download des Buches

Wie Agile Coaches HR ins Transformations-Boot holen - und damit Schiffbrüche vermeiden – Teil 2

Sabine — Tue, 03 Dec 2019 11:15:00 +0000

Teil 1 - Teil 3

Nachdem ich mich im ersten Teil mit der Frage beschäftigt habe, warum und wie agile Coaches HR mit ins Boot holen sollten, geht es jetzt um die konkrete Umsetzung.

Ja, es lohnt sich, mit HR zu reden, da beide Seiten davon profitieren können. Wie könnten jetzt konkrete Lösungen aussehen? Wir wissen ja, dass es für eine agile Transformation kein Patentrezept gibt und jedes Unternehmen seine eigene Reise antreten muss. Genauso wenig gibt es diese Patentrezepte für den Beitrag, den HR leisten kann. Es gibt allerdings eine Fülle von inspirierenden Beispielen, von denen ich einige herausgreifen möchte. Ich unterscheide in bewährter agiler Manier zwischen Prinzipien (generelle Leitlinien für unser Handeln, einigermaßen kontextunabhängig) und konkreten Praktiken (immer kontextabhängig).

Sourcing / Recruiting und Onboarding

Prinzipien:

Die besten Mitarbeiter ansprechen (Employer Branding): "The right people in the right seats" - das schafft ein Unternehmen heute nur noch, wenn es seinen Mitarbeitern Freiräume und Möglichkeiten zur Gestaltung aufzeigen kann. Um die begehrten, gut ausgebildeten Millennials zu ergattern, muss ein Unternehmen sich um ein positives Image bemühen. Es gibt unterschiedliche Untersuchungen darüber, was Millennials suchen und brauchen, und natürlich gibt es auch hier enorme individuelle Unterschiede (ich weiß wovon ich rede, ich bin die Mutter von zwei solchen Exemplaren). Mit Sicherheit sind sie als Digital Natives technikaffin. Sie legen Wert in der Regel auf Selbstverwirklichung und lassen sich Zeit, ihren Weg zu finden. Die Sinnhaftigkeit der Arbeit spielt für viele eine große Rolle.
Auf die Wünsche der Kandidaten eingehen: Weil sich potenzielle neue Mitarbeiter nicht über einen Kamm scheren lassen, sollten wir uns also auf jeden Menschen einlassen, um herauszukriegen, was ihnen in der Arbeit wichtig ist. Welche ihrer Vorstellungen kann unser Unternehmen ihnen anbieten? Flexible Arbeitszeiten? Home Office? Weiterbildungsmöglichkeiten? Die Möglichkeit zum gesellschaftlichen Engagement?
Die richtigen Mitarbeiter gewinnen: In der Vergangenheit wurden Einstellungen sehr stark nach vorhandenen Fähigkeiten oder Erfahrungen vorgenommen. Für ein agiles Unternehmen spielt das Mindset eine noch wichtigere Rolle. Passt es zu der gewünschten, neuen Unternehmenskultur? Mit einem "growth mindset" traue ich anderen (und mir selbst) zu, beliebige Fähigkeiten zu erlernen und flexibel in unterschiedliche Aufgaben im Unternehmen hineinwachsen zu können.
Gelegenheit zum gegenseitigen Kennenlernen geben: ein Vorstellungsgespräch oder Assessment Center nur mit Vorgesetzten und Personalern vermittelt beiden Seite keinen realitätsnahen Eindruck. Auf jeden Fall sollte der Kandidat das zukünftige Team kennenlernen. Vielleicht gibt es ja einen Team-Tag oder auch einen normalen Arbeitstag, in den der Kandidat hineinschnuppern kann?
Das zukünftige Team in die Entscheidung einbeziehen: Wer letztendlich die Entscheidung für eine Neueinstellung trifft, hängt von der Organisationskultur ab. In einigen Unternehmen ist diese Entscheidung dem Team überlassen, in anderen den Führungskräften. In diesem Fall sollten sie aber zumindest die Meinung des Teams einholen.
Neue Mitarbeiter in die Organisationskultur einführen: z.B. durch Mentoren, Buddy Systeme
Akzeptieren, dass Mitarbeiter das Unternehmen wieder verlassen werden: Auch wenn man sich viel Mühe bei der Auswahl gibt, ist es ganz normal, dass man nach einer gewissen Zeit feststellt, dass man doch nicht zusammenpasst. Dieser Prozess sollte fair gestaltet sein. Der Kandidat hat Anspruch auf ein offenes und konstruktives Feedback. Dies gilt natürlich nicht nur für neue Mitarbeiter.

Beispiel:

Bei Menlo Innovations ist Pair Programming ein wichtiges Arbeitsprinzip und der Kern der agilen Zusammenarbeit. Wie kann man beim Bewerbungsprozess herausfinden, ob sich der Bewerber dazu geeignet ist? Während eines Bewerbertages arbeiten die Kandidaten in wechselnden Paaren an typischen Aufgaben und werden dabei von Mitarbeitern beobachtet. Das Ziel und Bewertungskriterium ist dabei nicht, sich selbst besonders positiv darzustellen, sondern den Partner! Die Beobachter entscheiden auf dieser Basis über den nächsten Schritt, eine dreiwöchige Probearbeit. Auch die Scrum Alliance hat von diesem Vorgehen bei Neueinstellungen inspirieren lassen.

Bei improuv haben wir eine Hiring-Gruppe ins Leben gerufen. Die Hiring Gruppe besteht aus 3 Kollegen aus unterschiedlichen Tätigkeitsbereichen. Uns war wichtig, alle Perspektiven aus unserem Unternehmen abzudecken, nämlich aus der Geschäftsführung, aus dem Back Office und aus der Beratung bzw. Coaching. Die Hiring-Gruppe ist vom gesamten Unternehmen befähigt Kandidaten zu suchen, Interviews zu führen und eine Vorauswahl zu treffen. Ist ein Kandidat in der engeren Auswahl, wird dieser eingeladen, um das gesamte improuv Team kennenzulernen. In dem Kennenlerntermin mit dem Gesamtteam bekommt der Kandidat kleine Aufgabe, z.B. die Moderation einer kollegialen Fallberatung. Die Entscheidung, ob der Kandidat einen Arbeitsvertrag angeboten bekommt, trifft das gesamte Team.

Leistungsbeurteilung und Zielvereinbarungen

Prinzipien:

Anerkennung ist wichtiger als finanzielle Anreize: Für viele Unternehmen ist Geld immer noch das hauptsächliche Anreizsystem, wenn sie Verhalten aufbauen wollen. Aus der Psychologie und der Forschung ist jedoch gut bekannt, dass Geld als Motivationsmittel überschätzt wird und sich sogar negativ auf die Motivation auswirken kann. Immaterialle Anreize wirken oft stärker - und kosten sogar weniger. Die Anerkennung der Leistung durch Vorgesetzte und Teams ist einer dieser Anreize.
Neue Modelle zur fachlichen und persönlichen Weiterentwicklung: Klassische Karrierepfade waren in der Vergangenheit oft gleichbedeutend mit dem Erklimmen einer disziplinarischen Führungs-Leiter (vom Teamleiter zum Abteilungsleiter usw.). In einem agilen Unternehmen ist dieses Karrieremodell stark in Frage gestellt: der einzelne Mitarbeiter trägt mehr Verantwortung, das mittlere Management ist nicht mehr so stark besetzt. Eine horizontale Karrierestufe kann bedeuten, seine fachliche Expertise zu erweitern und damit komplexere Aufgaben innerhalb eines Teams oder teamübergreifend übernehmen zu können.
Förderung des kundenorientierten Handelns statt Ausrichtung auf Hierarchien: Kundenorientierung ist ein wesentliches agiles Prinzip. Teams in agilen Unternehmen werden zunehmend funktionsübergreifend und kundenorientiert aufgestellt. Der Dienst am Kunden gewinnt Bedeutung gegenüber dem Dienst am Vorgesetzten und sollte daher auch stärker bewertet werden.
Gratifikationen auf Team-Ebene (wenn überhaupt) statt individueller Boni: Wenn wir den Wert der Teamleistung predigen, am Ende des Jahres aber Einzelleistungen belohnen, machen wir uns komplett unglaubwürdig! Die Teams können gemessen werden an ihrem Beitrag zum Unternehmenserfolg (z.B. durch Systeme wie Beyond Budgeting oder Objectives and Key Results (OKR), das auch bei improuv im Einsatz ist).
Kontinuierlicher Mitarbeiterdialog statt langfristiger Zielvereinbarungen: Statt in Personalkonferenzen nur über High Potentials zu sprechen, erhält jeder Mitarbeiter ein holistisches Feedback von Kollegen und ggf. Kunden und Vorgesetzten, das auch Lernen, Weiterentwicklung und Unterstützung von Kollegen einbezieht. Dabei wird sowohl das "Was" (Ergebnis) als auch das "Wie" (Vorgehen) bewertet.

Beispiel:

Bei Sipgate GmbH gibt es ein auf einer Formel basierendes Gehaltsmodell (Lean Salary Modell), das Gehaltsverhandlungen überflüssig macht. Die Formel berücksichtigt Betriebszugehörigkeit und Erfahrung. Dieses Beispiel zeigt, dass das Gesamtpaket stimmen muss und Geld dabei nur eine Komponente ist. Auch die Lernerfahrungen, die das Unternehmen mit diesem Ansatz gemacht hat, sind interessant.

Wie auch bei sipgate sind Gehaltsverhandlungen bei improuv überflüssig, da wir ein transparentes Gehaltsmodell haben. Das Gehaltsmodell bei unseren Coaches, Trainern und Beratern ist ausgehend vom erwirtschafteten Umsatz unter Berücksichtigung allgemeiner Kosten. Jeder Mitarbeiter bei improuv kennt das Gehalt des anderen Kollegen, aber auch die Kostenstruktur unserer Firma. Folglich gehen wir sehr bewusst mit Investitionen um und entscheiden große Investitionen im Plenum. Diese Transparenz hilft uns, informierte Entscheidungen zu treffen und verhindert, dass Entscheidungen und Investitionen als unfair wahrgenommen werden oder unklar sind.

Im nächsten Blog werde ich Euch noch einige Aspekte von HR und agiler Führung vorstellen.

improuv - Agile Leadership

hedi.buchner — Tue, 16 Apr 2019 14:41:00 +0000

Nach 7 Jahren als Agile Coach und Gesellschafterin bei improuv bin ich seit 1. Februar Geschäftsführerin – gemeinsam mit Christoph Mathis und Jens Coldewey.

Was macht improuv aus?

Wie arbeitet improuv?

Wir als improuv sehen uns dabei als Katalysator für die zielgerichtete Entwicklung von Menschen und Systemen: Unsere Themen sind Enablement und Empowerment.

Wie schaffen wir das?

Wir freuen uns sehr darauf, improuv gemeinsam mit allen Kollegen und Kunden weiterentwickeln und gestalten zu dürfen.

Wie Agile Coaches HR ins Transformations-Boot holen - und damit Schiffbrüche vermeiden

Sabine — Wed, 11 Sep 2019 09:09:19 +0000

Teil 2 - Teil 3

“Schon dieser Name - Human Resources! Menschen sind doch keine Ressourcen!” So oder ähnlich höre ich manche Agilisten sich äußern, wenn es um HR geht. Gleichzeitig fahren sie mit ihrer agilen Transformation gegen den Eisberg. Dass ein agiles Unternehmen mehr ist als nur die IT oder die Produktentwicklung oder die Summe ihrer Scrum-Teams, dürfte sich herumgesprochen haben. Auch HR und seine Aufgaben sind Teil des Unternehmens.

Mit welchen Problemen schlagt ihr euch als Agile Coaches gerade herum? Es sind nicht "die richtigen" Leute an der richtigen Stelle im Unternehmen? Ihr tut euch schwer, agile Rollen neben oder anstatt von bereits bestehenden Rollen zu definieren? Ihr findet keinen Zugang zu den Managern? Vielleicht kann ja HR helfen, diese Wände einzureißen oder zumindest aufzubohren.

In dieser Blogserie geht es darum,

Gründe für eine intensive und frühzeitige Zusammenarbeit zwischen Agilen Coaches und HR herauszustellen,
grundlegende Prinzipien für diese Zusammenarbeit zusammenzufassen,
anhand von drei HR-Themenfeldern (Sourcing, Leistungsbewertung und Führung) zu erläutern, wie die Umgestaltung im agilen Sinne aussehen kann.

Warum sollten Agile Coaches HR mit ins Boot holen?

"First Who, then What: If we get the right people on the bus, the right people in the right seats, and the wrong people off the bus, then we’ll figure out how to take it someplace great.” Dies ist eine wesentliche Erkenntnis aus den Untersuchungen im Buch Good to Great (In diesem Buch wurden Unternehmen, die über einen Zeitraum von 15 Jahren besonders erfolgreich waren, auf ihre charakteristischen Merkmale hin untersucht.) .Mein ehemaliger Chef Gerhard Hastreiter drückt so aus: "Nichts prägt eine Organisation so sehr wie ihre Personalentscheidungen". Und genau das ist die wesentliche Aufgabe von HR. Diese Bedeutung habe ich selbst lange unterschätzt. In meiner Zeit in Großunternehmen hatte ich mit HR nur bei Einstellung, Kündigung, internem Stellenwechsel u.ä. zu tun. Der HR-Chef war dem CFO direkt unterstellt - aufschlussreich was den Stellenwert von Finanzen und Mitarbeitern angeht! In vielen kleinen Unternehmen hat HR eine rein administrative Funktion. Wofür die Personalabteilung im einzelnen zuständig ist, ist sehr vom Unternehmen abhängig. Hier eine kleine Auswahl:

Mitarbeiter an Bord bringen: Kooperation mit Hochschulen, Employer Branding, aktives Sourcing und Onboarding
Mitarbeiter an Bord halten: Aus- und Weiterbildung, Qualifizierungen, Karrieremöglichkeiten aufzeigen und bei der Umsetzung unterstützen, Ansprechpartner und Sparringspartner sein
Sich von Mitarbeitern trennen: Planung und Umsetzung von Einzelmaßnahmen und bei organisatorischen Änderungen
Führungskräfte unterstützen und beraten: Aufstellung und Änderungen der Organisation, Stellenbesetzungen, Nachfolgeplanung, Talente identifizieren und fördern, Managementinstrumente zur Verfügung stellen (Zielvereinbarungen, Performance Reviews, MItarbeiterzufriedenheit, …), kulturelle Themen (Führungsstil, Werte,..), rechtliche Themen
Sonstiges: Personaladministration (Gehaltsabrechnung, Zeiterfassung…), Sozialpartnerschaft mit dem BR, Personalcontrolling

Der Bezug dieser Themen zu einer agilen Transformation ist offensichtlich, oder? Wir erkennen: HR hat Expertise und Ownership in vielen Kernprozessen, die, wenn nicht einbezogen, sehr leicht zum Hindernis bei der agilen Transformation werden können. Also ist HR ein wichtiger Stakeholder, der enge Kontakte zu anderen wichtigen Stakeholdern hat (Management, BR...). Gerade für externe Coaches ist dieses Netzwerk essentiell. Die Personaler kennen viele Aspekte der Unternehmenskultur und können als Sparringspartner allzu träumerisch veranlagten Coaches dabei helfen, gefährliche Untiefen und Gegenströmungen zu erkennen und zu umschiffen. Wenn wir HR also frühzeitig ins Boot holen, kann uns einiges an Schiffbrüchen erspart bleiben.

Wie sollten Agile Coaches HR mit ins Boot holen?

Zunächst mal: zielgruppengerecht kommunizieren! Die Bedürfnisse unserer HR-Gesprächspartner erkennen und darauf eingehen! Wir können nicht davon ausgehen, dass die HR-Kollegen die agilen Buzzwords kennen. Wenn wir ihnen mit Scrum, Kanban, Produktinkrement und Retrospektiven kommen, werden wir sie eher abschrecken. Mit Stichworten wie Selbstorganisation in Teams und lernender Organisation werden wir eher auf ihr Interesse stoßen. Also: einfache Sprache nutzen, weg von den Praktiken hin zu den Werten und Prinzipien (das gilt auch für den Umgang mit anderen Stakeholdern!).

Da die Aufgaben des Personalwesens und natürlich auch die Menschen, die dort arbeiten, sehr unterschiedlich sind, bediene ich mich eines vereinfachenden Konstrukts. Ich möchte euch Lisa vorstellen, unsere HR-Persona. Sie ist 35 Jahre als und hat einen Master in Psychologie. Sie ist extrovertiert, begeisterungsfähig und kommunikativ. Sie legt viel Wert auf gute menschliche Beziehungen und arbeitet gern im Team. Sie möchte die Arbeitswelt mitgestalten, an interessanten Themen und Projekten mitarbeiten und sich selbst weiterentwickeln. Veraltete Führungsmodelle und starre HR-Tools und -Prozesse sind ihr ein Graus.

Mit einigen unserer agilen Werte werden wir bei Lisa offene Türen einstoßen:

Individuals and interactions over processes and tools: Auch Lisa möchte den Menschen in den Mittelpunkt rücken.
Responding to change over following a plan: Auch Lisa möchte Veränderungen aktiv mitgestalten.

"Working software" und "Customer orientation" hat Lisa bisher nicht so sehr auf dem Schirm. Wie sollte sie auch? Sie sitzt in einer Zentralabteilung, die keinen direkten Anteil am Wertstrom hat. Dies könnte aber eine interessante Weiterentwicklungsperspektive für Lisa sein: das Geschäft des Unternehmens besser zu verstehen. Daher ist es auch wichtig, die - hoffentlich geklärte - Motivation, das "Warum" der agilen Transformation aus Business-Sicht zu vermitteln. Nicht vergessen: Agil ist kein Selbstzweck, sondern soll dem Unternehmen helfen, seine Geschäftsziele besser zu erreichen. So kann HR nah am Business sein und seinen Beitrag dazu leisten, statt nur Standard-Prozesse zu implementieren.

Wenn wir mit unserer Überzeugungsarbeit erfolgreich waren, haben wir mit Lisa eine starke Partnerin an unserer Seite. Mit ihren Kontakten zu Mitarbeitern und insbesondere Führungskräften kann sie eine neue und spannende Rolle als agiler Change Agent spielen. Und sicher hat sie Ideen, wie sie und ihre Kollegen agile Arbeitsweisen für ihre interne Zusammenarbeit nutzen können, die sie mit eurer Hilfe weiter ausbauen kann.

In den nächsten Teilen dieser Serie werde ich anhand von mehreren Themengebieten Beispiele aufzeigen, die zeigen, was man konkret machen kann.

Interesse an einer Vertiefung des Themas? Dann besuchen Sie unser Training - Agile HR. Wir freuen uns auf Sie und vielleicht kommt Lisa ja auch.

Mehr Scrum Masterinnen braucht das Land! - Gründe für das erste Certified Scrum MasterINNEN Training

Sabine — Wed, 11 Sep 2019 09:09:19 +0000

Gerade ist mir beim Aufräumen dieses Bild in die Hände gefallen. Es zeigt die Gruppe der Certified Scrum Trainer beim Scrum Gathering in Prag, 2015. Es gibt nur eine Frau darauf, und das bin ich.

Mittlerweile gibt es ca. 25 CSTs im deutschsprachigen Raum - und ich bin immer noch die einzige Frau! Auch unter den Certified Enterprise Coaches bin ich die einzige Frau. Und das obwohl Coaching eindeutig in den Bereich “Arbeit mit Menschen” fällt und daher eher dem klassischen Interessengebiet von Frauen zuzuordnen ist. Eine Studie zeigt, dass z.B. im HR-Bereich deutlich mehr Frauen (70%) als Männer tätig sind (der Prozentsatz bei den Führungspositionen in diesem Bereich sieht leider ganz anders aus). Auch der akademische Nachwuchs bei HR-Masterstudiengängen ist mit 80% sehr frauenlastig. Dem gegenüber steht der immer noch geringe Anteil von Frauen in MINT-Fächern: der Anteil der Absolventinnen im Studienbereich Elektrotechnik und Informationstechnik lag 2016 bei 11% (immerhin eine Steigerung um 2 Prozentpunkte seit 2008). Das ist wahrscheinlich einer der Gründe, warum ich immer noch vergeblich auf eine weibliche “Verstärkung” warte: Um Certified Scrum Trainer zu werden, muss man erst mal als Scrum Master seine Sporen verdienen. Und die Scrum Master kommen immer noch zum großen Teil aus der IT.

Ich habe keine Statistik in meinen meinen Scrum-Master-Trainings erhoben, aber gefühlt sind es ca. 20% Frauen dort. Ich erinnere mich noch an ein Product-Owner-Training, wo es mehr Teilnehmerinnen als Teilnehmer gab!

Warum es in den Informationstechnik immer noch so wenige Frauen gibt, ist oft diskutiert worden. Es werden Gründe genannt wie:

Schlechtes Image (der Programmierer gilt als “Nerd”)
Frühkindliche Sozialisierung und stereotype Geschlechterrollen
Angst vor den Problemen, die mit der Arbeit in einer männerdominierten Sparte
Glaube, dass Familiengründung und Beruf in der Informatik unvereinbar seien

Es gibt viele Argumente, die für eine technische Ausbildung sprechen, allen voran die guten Berufsperspektiven und wirklich interessante Tätigkeitsfelder. Ich selbst habe Elektrotechnik studiert und viele Jahre lang Software entwickelt. Das hat mir Spaß gemacht und mir viele Perspektiven eröffnet. Das Fehlen eines solchen Hintergrundes sollte aber potenzielle Scrum Masterinnen nicht abschrecken: ihr müsst nicht nicht unbedingt eine versierte Programmiererin sein. (Interessant, die Rechtschreibkorrektur unterschlängelt das Wort “Programmiererin” und schlägt stattdessen “Programmierer” vor). Wohl wahr, die Scrum Masterin soll mit ihrem Team an der Verbesserung der technischen Fähigkeiten arbeiten, aber das muss sie nicht unbedingt selbst leisten. Im Gegenteil, gute Programmierer*innen sind häufig versucht, schnell mal selbst Hand anzulegen, weil das einfacher ist und schneller geht als die Kollegen dabei zu coachen. Leider verstehen viele Auftraggeber die Rolle des Scrum Masters immer noch als eine Mischung aus technischem Experten, Teamleiter und Projektleiter, der nebenher ein Jira-Task-Board verwaltet und Einladungen zu Meetings über Outlook verschickt. Und dann hat es eine Scrum Masterin ohne technischen Hintergrund natürlich schwer.

Zum Glück ist der Wert von Diversität in Teams mittlerweile erkannt und akzeptiert, und viele Unternehmen sind aktiv auf der Suche nach geeigneten Frauen. Gerade in der agilen Welt können wir Frauen einen besonderen Beitrag leisten: Studien zufolge legen Frauen besonderen Wert auf ein zwischenmenschliches Verhältnis (“ Individuen und Interaktionen…”) am Arbeitsplatz. Und nehmen wir das oft vergessene Prinzip Nr. 8 aus dem Agilen Manifest: “nachhaltige Entwicklung” (sustainable pace). Für Frauen ist die Vereinbarkeit von Familie und Arbeit bei der Berufswahl immer noch wichtiger als für Männer. Noch immer sind es eher die Frauen, die sich um die Kinder kümmern. Zwar nehmen immer mehr Männer Elternzeit in Anspruch, aber meistens nur zwei Monate. Das hohe Tempo, das in vielen Organisationen gang und gäbe ist, der Druck, Überstunden zu machen und ständig erreichbar zu sein: all das hat mit familienfreundlichem Denken wenig zu tun. Wir Frauen können einfordern, dass dem Bekenntnis zum “Erfolgsfaktor Familie” auch Taten folgen. Ich bin sehr froh, in einer Firma wie improuv zu arbeiten, wo die familiäre Situation berücksichtigt wird. Vielleicht haben wir deshalb einen Frauenanteil von über 50% - auch bei den Agilen Coaches.

Was könnte helfen, Frauen Mut zu machen, den Weg einer Scrum Masterin einzuschlagen?

Mehr Vorbilder und Mentor*innen. Es gibt gerade eine tolle Initiative, LIA100 (Lean In Agile for Women), die herausragende Frauen und ihren Anteil zur agilen Community herausstellen. Schaut euch mal das Interview mit Lyssa Adkins an, um nur eine von ihnen zu nennen.

Mehr Austausch mit anderen Frauen. Ein Beispiel: habt ihr schon mal erlebt, dass ihr ein einem männlich dominierten Team nicht so richtig zu Wort kommt und vielleicht sogar dauernd unterbrochen werdet? Nicht aus bösem Willen oder mangelndem Respekt; euren männlichen Kollegen ist dieses Verhalten wahrscheinlich gar nicht bewusst. Ihr seid nicht die einzigen! Es tut gut, das festzustellen und sich darüber auszutauschen, was frau in so einer Situation tun kann.

Gegenseitige Förderung. Zum Beispiel haben wir uns als Certified Scrum Trainerinnen vor zwei Jahren beim Scrum Gathering in Dublin darauf verständigt, uns gegenseitig und auch Trainer-Kandidatinnen zu unterstützen. Women in Agile vereinigt mehrere von diesen Aspekten.

Und jetzt die gute Nachricht: Anna Rudat (die hoffentlich bald die zweite Certified Scrum Trainerin in Deutschland wird) und ich haben uns entschieden, ein Certified Scrum MasterINNEN Trainingnur für Frauen anzubieten. In diesen drei Tagen können wir nicht nur die Learning Objectives der Scrum Alliance abdecken, sondern uns über Themen austauschen, die für uns als Frauen interessant und wichtig sind. Es ist ein Experiment, mit dem wir unsere Hypothese testen wollen, dass es ausreichend Bedarf für so ein reines Frauentraining gibt. Ihr könnt uns dabei helfen, indem ihr die Botschaft an mögliche Teilnehmerinnen verteilt.

Wardley Maps und die drei Horizonte

krishan — Thu, 28 Feb 2019 06:29:00 +0000

Simon Wardley hat eine Form und Codes gefunden, mit der strategische Überlegungen über Zeit und Einflussfaktoren gut abbildbar und kommunizierbar sind. In einem früheren Artikel Wardley Mapping - ein großartiges Werkzeug zur Strategie-Entwicklung berichtete ich darüber.

Die 'drei Horizonte' waren eine mir direkt einleuchtende Perspektive. Gleich gehe ich darauf ein, weshalb sie es nicht mehr sind.

Mit dem Konzept werden drei Aspekte von Strategie oder Governance beschrieben.

Horizont 1: Das aktuelle Geschäft. Jede Organisation weiss, was ihr aktuelles Geschäft ist
Horizont 2: Produkte in Entwicklung oder Erprobung. Mehr oder weniger weiss man schon, wie die nächsten Produkte aussehen. Es fehlt noch ein wenig Flexibilität, um Wissen zu Markt oder Funktionsweise zu bekommen und einzubauen.
Horizont 3 beschreibt die noch nicht bekannten Umstände, Mechaniken und Produkte. Das ist das Feld von Experimenten, von Probieren und hoher Unsicherheit.

Die drei Horizonte sind wesensverschieden und verlangen ganz eigenen Fähigkeiten und Werkzeuge um die Ziele zu erreichen. Also braucht es auch eigene Metriken, vielleicht andere Werkzeuge und Führungsmethoden. In einer natürlich unvollständigen Tabelle ist eine erste Näherung so:

	Horizont 1 0-12 Monate	Horizont 2 12-36 Monate	Horizont 3 36-72 Monate
Ziele	ökonomisches Ergebnis maximieren	'cross the chasm' — es werden signifikante Erlöse generiert	neues Geschäft generieren
True North	flow maximieren	ständige Verbesserung	disruptive Ideen
Metriken	Erlöse vs Planung Marktanteil Profitabilität	erfolgreiche Verkäufe, Zielkunden	B2C: Mundpropaganda funktioniert B2B: Branding funktioniert
Werkzeuge	Lean Kanban	Scrum Scaled Agile Framework	Design Thinking Lean Startup

In dieser Tabelle stecken schon viele Hinweise dazu, wie Innovationsbereiche zu gestalten sind. Auch liefert das Modell eine mögliche Antwort auf die häufige Frage: 'kann/soll man Agile für alles verwenden?'.

Eine Unschärfe ist die Dauer der Horizonte — sie sind eher metaphorische Größenordnungen als tatsächliche Zeitangaben.

Was mich mehr beschäftigt: das Modell zeigt Optionen, mit einer gegebenen Situation umzugehen — doch es gibt weniger Hinweise darauf, woran man eine Situation erkennen kann, wie man also zuverlässig feststellt, in welchem Horizont man sich befindet.

Bis hierher schon machen Wardley Maps Freude: ich kann damit belastbarere Diagnosen stellen und Hinweise für sinnvolle Aktionen ableiten.

Was noch besser ist: er hat über die Jahre eine ganze Menge von Frühindikatoren zusammengestellt, mit denen sich Indizien für die Zuordnung eines Produkts zu einer Stufe ableiten lassen. Hier erstmal ein Ausschnitt aus der rohen Tabelle - wir werden die in der nächsten Zeit noch auseinandernehmen und genauer betrachten:

Stage of Activity	Genesis	Custom	Product(+rental)	Commodity(+utility)

Characteristics
Ubiquity	Rare	Slowly increasing comsumption	Rapidly increasing consumption	Widespread and stabilising
Certainty	Poorly understood	Rapid increases in learning	Rapid increases in use / fir for purpose	Commonly understood (in terms of use)
Publication types	Normally describe the wonder of the thing	Build / construct / awareness and learning	Maintenance / operations / installation / feature	Focused on use
General properties
Market	Undefined market	Forming market	Growing market	Mature market
Knowledge management	Uncertain	Learning on use	Learning on operation	known / accepted
Market perception	Chaotic (nonlinear)	Domain of experts	Increasing expectation of use	Ordered (appearing of being linear) / trivial
User perception	Different / confusing / exciting / unpredictable / surprising	Leading edge / emerging	Common / disappointed if not used or available	Standard / expected
Perception in Industry	Competitive advantage / unperdictable / unknown	Competitive advantag / ROI / case examples	Advantage through implementation / features	Cost of doing business / accepted
Focus ov Value	High future worth	Seeking profit / ROI	High profitability	High volume / reducing margin
Understanding	Poorly understood / unpredictable	Increasing understanding / development of measures	Increasing education / constant reflection of needs / measures	Believed to be well defined / stable / measurable
Comparison	Constantly changing / a differential / unstable	Learning from others / testing the water / some evidential support	Future difference	Essential / operational advantage
Failure	High / tolerated / assumed	Moderate / unsurprising but disappointed	Not tolerated, focus on constant improvement	Operational efficiency and surprised by failure
Market action	Gambling / driven by gut	Exploring a "found" value	Market analysis / listening to customers	Metric driven / build what is needed
Efficiency	Reducing the cost of change (experimentation)	Reducing the cost of waste (Learning)	Reducing the cost of waste (Learning)	Reducing the cost of deviation (Volume)
Decision Drivers	Heritage / culture	Analysis & synthesis	Analysis & synthesis	Previous experience

Agiles Unternehmen und Transformationsmodelle - Meine Vorausschau 2019

krishan — Fri, 22 Feb 2019 06:28:00 +0000

Im letzten Jahr habe ich drei Thesen zum Jahresauftakt 2018 veröffentlicht. Darin waren die Voraussagen

Agiles Management und Agile Führung werden das Buzzword des Jahres.
Die Frage wird wichtiger, wie man eine Agile Transformation nachhaltig erfolgreich macht.
Wir brauchen mehr Reflexion und weniger Methoden

In allen drei Bereichen ist ziemlich viel passiert. Agile Führung nimmt in unserem Portfolio und, so weit ich sehe, in der öffentlichen Debatte einen immer größeren Platz ein. Bei der Agilen Transformation erscheint uns das noch deutlicher. Unsere Kunden spitzen das auf die Frage zu: wir wollen keine Ressourcen von euch, sondern ein Konzept.

Bei der Frage nach "weniger Methoden" sieht das Bild für mich differenzierter aus: auf der einen Seite nimmt die Nachfrage etwa nach SAFe stetig zu. Der Wunsch nach einem Modell äußert sich auch in der immer breiteren Verwendung des Spotify-Vokabulars. Dabei ist nicht immer klar, ob das einfach eine Umbenennung von bestehenden Strukturen ist oder ob wirklich eine strukturelle und kulturelle Änderung damit verbunden ist. Auf der anderen Seite tut sich einiges, das auf eine stärkere Betonung der konzeptionellen Sicht und eine tiefere Einsicht in Zusammenhänge hindeutet.

Zeit, sich den neuen Tendenzen zuzuwenden:

1. Die Agilisierung des Gesamtunternehmens rückt in den Vordergrund. Auf der einen Seite repräsentiert das einen Trend von operativen und taktischen Änderungen zu immer strategischen Rolle von Agilität. Wenn wir uns erinnern: von agiler Softwareentwicklung zu Produktentwicklung, die (immer besser verstandene) Differenzierung von Output und Outcome, hin zum Aufkommen der Diskussion um eine agile Organisation. Agile Führung bleibt in diesem Kontext wichtig, wird aber zu einem Element eines Gesamtbilds, in dem die Sichten auf Lieferfähigkeit, Innovation und Kultur alle eine eigenständige Rolle spielen. Die Buzzwords des Jahres 2019 werden dabei um globales Optimum, Flow/Wertstrom statt Silos und Innovation kreisen.

2. Wir werden einige Transformationsmodelle sehen, die den Wettbewerb um die Gestaltung agiler Transformationen stärker anfachen. Es gibt inzwischen genug Erfahrungen mit Transformation, die Verallgemeinerungen erlauben, ohne in die Falle einer simplen Blaupause zu laufen. Wir selbst sind mit der Agilen Evolution dabei und ich werde in der nächsten Zeit einige dieser Modelle vorstellen.

3. Die Großunternehmen werden eine stärkere öffentliche Rolle bei der Gestaltung spielen. Das ist eine Fortsetzung des Trends von 2018 ("mehr Reflexion, weniger Methoden"), aber es geht nicht mehr nur um Reflexion. Vielmehr ist die ernsthafte und tiefgreifende Integration agiler Konzepte in die Strukturen der Organisationen angesagt. Für mich äußert sich das an der Verschiebung abstrakter Modelle auf eine operationale Ebene aud breiter Front - hier einige Beispiele:

OKRs (Objectives and Key Results) als eine kooperative Form der Zielfindung in Unternehmen, die auch als Katalysator für eine Operationalisierung des Mindsets und eine adäquate Führung für Wissensarbeiter wirken können
Kompetenzmodelle für eine lean-agile Organisation, mit denen eine stabile Verankerung der entsprechenden Strukturen getrieben wird.
Neue Capabilities zur schnellen Anpassung - wir unterscheiden Kompetenzen von Personen und Capabilities als Fähigkeit von Organisationen - die das Thema "Business-Agilität" ebenfalls greifbar und gestaltbar machen
Entwicklung und Integration von strategischen Herangehensweisen wie Beyond Budgeting, Agile Governance und Wardley Mapping in die intensive Nutzung von Denkweise der Agilität im Unternehmensalltag.

Diese Entwicklungen reihen sich in eine globale Tendenz: Agilität wir mehr und mehr als ein Toolkit neben anderen gesehen, Ich definiere Agilität als die Tools, die eine schnellere Anpassung an neue Anforderungen ermöglichen. Wenn wir das weiter denken, dann wird Agilisierung mehr und mehr ein Aspekt von Organisationsentwicklung.

Vier Thesen zu Agile HR

stefanie — Thu, 16 Jan 2020 15:21:41 +0000

Agile Arbeitsweisen bei einzelnen Produkten, Produktsparten oder Abteilungen sind für Menschen in Organisationen längst nicht mehr neu. Vielmehr wird eine Organisation, die die nötige Flexibilität und die Unterstützung für Agilität liefert, mehr und mehr zur Voraussetzung. Hindernisse und Stolpersteine sind vielmals noch starre und weniger flexible Rahmenbedingungen. Aus unseren Beobachtungen heraus zählen HR Prozesse oft zu diesen starren Rahmenbedingungen, genau diese heißt es aufzubrechen und mitarbeiterzentriert zu gestalten.

Wie steht es um HR in der Organisation?

HR wird mehr denn je benötigt, jedoch in einer neuen Gestalt
Es braucht mitarbeiterzentrierter und flexibel agierende HR Abteilungen
HR muss eine zentrale Rolle in der agilen Transformation spielen
Das „Wozu“ und „Womit“ muss von HR verstanden werden
Die Organisation braucht Sparring und Unterstützung von HR, und zwar individuell
HR muss den Wandel und die Entwicklung immerzu und maßgeblich mit vorantreiben

Nachfolgend skizzieren wir eine fundamentale Veränderung, die als Zielbild dienen darf:

Weg von Standardisierungen bei Recruiting, Onboarding und Stellenprofile,
hin zu individueller Bedürfnisorientierung und Marktsituation

Die Basistätigkeiten der HR Abteilung prägen viele Aspekte der Arbeitsumgebung. Sie sind nicht leicht zu ändern, haben aber dann eine tiefe Wirkung auf das Erlebnis der Arbeitsumgebung.

Recruiting ist eine Tätigkeit für alle Mitarbeiter in der Organisation, es geht um mehr als Stellen nach zu besetzen
Onboarding ist flexibel und startet direkt nach Vertragsunterschrift
Kandidaten gestalten die Stellenprofile mit

Compensation und Rewards sind nicht Verhandlungssache und individuell,
sondern fair und transparent

Kompensationen werden leicht als Belohnungen wahrgenommen und steuern das Verhalten - oft sind damit starke Fehlsteuerungen verbunden, im schlimmsten Fall sind sie ein starkes Hindernis für die Entwicklung kooperativen Verhaltens und agile Arbeit insgesamt. Daher

Faires und transparentes Gehalt
Rewards hängen ausschließlich an Organisationszielen

Feedback findet nicht mehr jährlich statt,
Ziele sind nicht länger an Personen gebunden

Feedback fördert und fordert nicht, wenn es jährlich geschieht. Feedback ist Teil der Weiterentwicklung und gehört zu Führung, Coaching und Mentoring.

Zielfindung richtet sich ausschließlich an Organisationsziele und ist transparent
Feedback darüber geschieht regelmäßig und bedürfnisorientiert

Weiterentwicklung kommt nicht mehr aus dem Weiterbildungskatalog,
Karriereplanung wird nicht mehr im stillen Kämmerchen verhandelt

Ebenso muss das Thema "Weiterbildung" aus dem Bereich interner Konkurrenz herausgezogen werden und Teil einer gemeinsamen Weiterentwicklung ("enablement") für die Mitarbeiter und die Organisation als Ganzes werden.

Weiterentwicklung und Lernen ist ein ständiges, zentrales und bedürfnisorientiertes Thema für alle
Karriereplanung und Karrierepfade sind transparent und offen gestaltet

Wir plädieren und appellieren sehr deutlich dafür, HR intensiv bei der agilen Transformation einzubinden, und dazu braucht HR auch die Möglichkeit sich verändern zu dürfen. Nur wenn HR eine zentrale Rolle spielen darf und kann, kann sich eine Organisation sinnvoll und nachhaltig transformieren.

Shareholder oder Stakeholder Value

krishan — Wed, 29 Jan 2020 16:27:41 +0000

Agilität ist zunächst eine Metapher für Anpassbarkeit und wie wir es meist in der Vergangenheit diskutiert haben, für Softwareentwicklung. Das zeigt sehr schön die Anekdote zur Wahl des Namens „Agil“ als Überschrift des Agilen Manifests: die erste Wahl war „adaptive Softwareentwicklung“, aber es war unglücklicherweise der Name der Beratungsfirma eines der Autoren -. und so einen großen Vorsprung wollten ihm die anderen nicht gewähren. Also entstand der Name „Agil“.
Die riesige Veränderungskraft der Agilität wurde erst im Lauf der Zeit deutlich. In dem Maß, in dem sich der Scope ausweitete und heute stehen strukturelle und kulturelle Fragen des Organisationsdesigns im Mittelpunkt. Um nur einige Ziele aufzugreifen, die dabei sind, zum Konsens zu werden:

Arbeit muss wieder Spass machen
Wissensarbeit ist anders als Industriearbeit
Agilität schafft eine win-win Situation
Nachhaltigkeit wird ein immer zentraleres Geschäftsziel, auch wenn sich die Welt immer schneller dreht.

Wenn man an den Rändern der „Agilen Sphäre“ herumhört, stösst man auf neue Impulse, die die Themen aufgreifen, die wir auch immer wieder treiben. Meine Kollegin Sabine Canditt hat mich neulich auf eine Initiative aufmerksam gemacht, die ich noch nicht kannte: den US-Amerikanischen Business Round Table, eine Gruppe von CEOs großer Firmen in den USA.
Dieser Round Table hat eine neue Sicht entwickelt, was eine nachhaltigere Sicht auf den Zweck von Organisationen entwickelt und betont eine umfassendere Sicht auf mehrere verschiedene Stakeholder.

Das weicht insbesondere von der strikten Sicht der 90er Jahre („shareholder value“) ab.
Ja klar , diese CEOs sind keine Engel und nach europäischen Massstäben gibt es da viel zu kritteln. Mich interessiert dabei aber nicht, dass das Glas halb leer ist, sondern, dass sich da etwas tut - und was ich sehe, sind langfristigere Tendenzen als das Kommen und Gehen der Trumps dieser Tage.
Was schreibt der Business Round Table denn konkret

Während jedes unserer einzelnen Unternehmen seinem eigenen Unternehmenszweck dient, teilen wir eine grundlegende Verpflichtung gegenüber allen unseren Stakeholdern. Wir verpflichten uns dazu:

Unseren Kunden einen Mehrwert zu bieten. Wir werden die Tradition amerikanischer Unternehmen fördern, die bei der Erfüllung oder Übererfüllung der Kundenerwartungen führend sind.
In unsere Mitarbeiter zu investieren. Dies beginnt damit, sie fair zu entlohnen und wichtige Vorteile zu bieten. Dazu gehört auch, sie durch Schulung und Ausbildung zu unterstützen, die dazu beitragen, neue Fähigkeiten für eine sich schnell verändernde Welt zu entwickeln. Wir fördern Vielfalt und Integration, Würde und Respekt.
Wir gehen fair und ethisch korrekt mit unseren Lieferanten um. Wir sind bestrebt, den anderen Unternehmen, ob groß oder klein, die uns bei der Erfüllung unserer Aufgaben helfen, als gute Partner zu dienen.
Wir unterstützen die communities, in denen wir arbeiten. Wir respektieren die Menschen in unseren Gemeinden und schützen die Umwelt, indem wir nachhaltige Praktiken in allen unseren Unternehmen anwenden.
Wir schaffen langfristigen Wert für unsere Aktionäre, die das Kapital bereitstellen, das es den Unternehmen ermöglicht, zu investieren, zu wachsen und zu innovieren. Wir verpflichten uns zu Transparenz und effektivem Engagement gegenüber den Aktionären.

Jeder unserer Stakeholder ist von wesentlicher Bedeutung. Wir verpflichten uns, für alle von ihnen Werte zu schaffen, für den zukünftigen Erfolg unserer Unternehmen, unserer Gemeinden und unseres Landes.

Was springt für uns Agilisten dabei heraus? Es sind Anknüpfungspunkte für die Werte und Ziele, die wir verfolgen.
Meine Frage an euch wäre: welche Initiativen dieser Art gibt es denn noch? Es wäre schön, wenn wir noch mehr solcher Punkte verbinden könnten, Gespräche zwischen neuen und alten Initiativen initiieren und so zu einer umfassenderen Sicht und neuen Synergieeffekten kommen könnten.

Agile Tuesday am 10.3.2020: TestMaster - der neue Superhero in der agilen Softwareentwicklung?!

christian-braun — Sun, 01 Mar 2020 09:58:00 +0000

Katja Meyer und Susanne Ambros diskutieren am 10.3.2020 die Frage: "Ist der Testmaster der neue Superhero in der agilen Softwareentwicklung?"
Als Tester*in in einem großen, agilen Projekt ist dir sicher auch schon einmal der Gedanke gekommen, dass es im Projekt schneller vorangehen könnte, wenn jemand das große Ganze im Auge behalten würde. Dass es sinnvoll wäre eine zentrale Person im Test zu haben, die nicht nur Test-Impediments erkennt und beseitigt, sondern auch teamübergreifend Testdaten verwaltet, Testaktivitäten koordiniert und bei Not am Mann auch hands-on die Teams unterstützt. Jemand, der alle test-relevanten Angelegenheiten projektweit und nicht nur auf Teamebene im Auge behält und die Probleme aus erster Hand durch seine Testerfahrung kennt.

Diese Aufgaben werden in der klassischen Softwareentwicklung teilweise vom Testmanager übernommen. In agilen Projekten kann diese Lücke natürlich von den Testern der Teams gefüllt werden – entweder von Einzelpersonen oder von Zusammenschlüssen wie Communities of Practice. Dennoch zeigt unsere Erfahrung, dass sich häufig niemand findet, der diese Aufgaben übernehmen kann oder möchte.

Daher stellen sie eine neue Rolle in der Qualitätssicherung vor: Der TestMaster hat einen ausgeprägten Hintergrund und hands-on Erfahrung in den verschiedenen Bereichen des Testens und ist die Kontaktperson für alle Teams für das Themengebiet Test. Außerdem synchronisiert und koordiniert der TestMaster die Testaktivitäten aller Teams und ermöglicht dir und deinem Projekt so, dass eure Ziele schneller und effektiver erreicht werden können.
Freut Euch auf neue spannende Erkenntnisse!

Rückblick Agile Tuesday Februar: From Agile to Agility – und was ist mit HR ?

christian-braun — Sun, 01 Mar 2020 14:16:00 +0000

Natalija Hellesø diskutierte mit mehr als 60 Teilnehmern intensiv die Frage, welche Rolle HR in agilen Veränderungen spielen und wie agiles Arbeiten auch dort gelingen kann!
Was können agile Prinzipien im HR Bereich überhaupt bewirken? Welche Voraussetzungen sind nötig, damit HR flexibler werden kann und wo fange ich an? Agilität, HR und das liebe Geld – was ist mit Vergütung ?
Vielen Dank für eure zahlreichen Beiträge und die intensiven Diskussionen!

Agile Tuesday am 11.2.2020: From Agile to Agility – und was ist mit HR ?

christian-braun — Sat, 01 Feb 2020 14:20:00 +0000

Agile Methoden in der IT sind längst Standard, agile Transformationen in aller Munde und Business Agility – also agiles Arbeiten in der gesamten Organisation - das neue Thema.

Natalija Hellesø geht an diesem Abend der Frage nach, welche Rolle HR in diesen Veränderungen spielen und wie agiles Arbeiten auch dort gelingen kann! Anhand von konkreten Beispielen, Erfahrungsberichten und interaktiven Übungen beleuchtet Sie das Thema „Agile & HR“ aus unterschiedlichen Perspektiven und diskutiert, was schon heute möglich ist, u.a.:

Was können agile Prinzipien im HR Bereich überhaupt bewirken? Personalentwicklung agil - Wie sieht das konkret aus? Welche Voraussetzungen sind nötig, damit HR flexibler werden kann und wo fange ich an? Agilität, HR und das liebe Geld – Was ist mit Vergütung ?
Wir freuen uns auf Personaler, Agilisten und alle, die neue Formen der Zusammenarbeit gestalten möchten!

Agile Tuesday Rückblick Januar: Lean Portfolio Management – der Fisch stinkt vom Kopf?

christian-braun — Sat, 01 Feb 2020 14:26:00 +0000

Lean Portfolio Management - am 14.1. diskutierten Stuart Fish und Taghi Paksima mit zahlreichen Besuchern intensiv LPM. In einer Übung zu "participatory budgeting” konnten die Teilnehmer die neuen Informationen in der Praxis anwenden.

Vielen Dank für die aktive Teilnahme.

Agile Tuesday am 14.1.20: Portfolio Management - der Fisch stinkt vom Kopf?

christian-braun — Wed, 01 Jan 2020 14:27:00 +0000

The topic Taghi Paksima and I (Stuart Fish) would like to introduce on Tuesday is “Lean Portfolio Management”. It´s an interesting topic for those of us helping organisations move towards business agility. A few years ago, when I joined Improuv, we supported Agile teams who would eventually say “hey, now that we live and love team agility, we´re frustrated that the other teams we interact with are not agile! - we can´t perform to our true potential”. In the past couple of years we have seen a large shift towards scaling agility in organisations. But now we often hear “now that we have teams-of-teams aligning and synchronising towards common goals, we find we are held back by the organisation and budgeting processes that contradict agility at the team level - we can´t perform to our true potential!”. So, while lean and agile principles have helped us form teams-of-agile teams, we need also need to look at agility in the budgeting and portfolio processes so that “agility” is lived at both team and strategic enterprise level. This brings us to Lean Portfolio Management (LPM). LPM is all about finding ways to define and evolve business strategy, strategic OKRs, and the large business and technical initiatives that let us realise our business strategy. And to do this in way that allows us to constantly inspect and adapt our strategy, budgeting and initiatives to continually adapt to changing customer and market needs. An LPM approach at the level of large initiatives (not stories or features) gives a financial and strategy framework that supports agile team-of-teams and agility at the team level. So team agility+program(area/tribe/nexus etc..) agility and portfolio agility gives companies a chance to experience agilty at the whole business level. Unfortunately, much as this seems to make sense, it seems very difficult for companies to shift from traditional yearly project-based portfolio planning to more adaptive Lean/Agile Portfolio Management. We need to coach and inform the people who manage strategy and budgeting.

On Tuesday (14.1.) we shall give an overview of LPM from a Scaled Agile perspective. But what is interesting here is that the approach is basically framework independent. We shall share one approach to LPM, and then we´ll run a little exercise in “participatory budgeting” which is one way that organisations can try to allocate budget across larger initiatives by gathering the opinions of a wider group (e.g. team members, product/program owners, business owners, architects, key customers etc.). In participatory budgeting, more people in an organisation are empowered to participate in the budgeting process - an approach widely used in the public sector to allocate public funds to local government services.

We hope you can join and participate in the discussion.

OKR - eine etwas andere Perspektive

zoi — Fri, 13 Mar 2020 12:51:10 +0000

Als ich zum ersten mal von OKR´s hörte, war ich Feuer und Flamme. Dazu muss man wissen: ich bin in einem Konzern „sozialisiert“ worden. Im Vertrieb! Das heißt Jahr für Jahr endlose Diskussionen über Umsatzsteigerungen und damit verbundene variable Gehälter. Als Mitte des Jahres die Ziele endlich da waren, hat es keinen mehr interessiert was im Markt abgeht und wie wir darauf reagieren können. Es war immer das gleiche und wenig motivierend. Teilweise konnten wir die Ergebnisse durch harte Arbeit beeinflussen, vieles jedoch lag ausserhalb unserer Reichweite (i.e. Sanktionen, Pleiten, Aufkäufe etc.) Deswegen hörten sich die OKR´s so gut an! Endlich weg von statischen Umsatzzielen, hin zu flexiblen und relevanten Objectives und Key Results.

Die vielen Veranstaltungen die ich danach besuchte, lieferten mehr oder weniger die gleichen Informationen darüber was OKR sind, woher sie kommen und wie man sie gut implementieren kann. Manche Ansätze waren spannender als andere, aber sie ähnelten sich alle in ihrer Aussage darüber, dass OKR ein relativ einfaches und effektives Werkzeug sind um Unternehmensziele zu erreichen. Als Wirtschaftspsychologin interessierten mich jedoch andere Fragen. Wie erleben Menschen die Einführung von OKR? Was muss beachtet werden, damit kein Stress oder Überforderung entstehen? Und warum verfolgen manche Menschen ihre Ziele mit Ausdauer und Energie und andere nicht? Von Beteiligten und Kunden hörte ich recht unterschiedliche Geschichten. Auf der einen Seite Begeisterung und auf der anderen Seite Frust. Warum war es so? Woran könnte es liegen und was braucht es um OKR nachhaltig im Unternehmen einzuführen?

Ich bin diesen Fragen auf den Grund gegangen und habe Ziele im allgemeinen und OKR im speziellen aus psychologischer Perspektive analysiert. Dabei ging es hauptsächlich darum die Anforderungen zu verstehen, die durch anspruchsvolle und spezifische Ziele für Individuen und Gruppen entstehen. Dazu bin ich tief in die Motivationspsychologie eingetaucht und habe Ziele aus der psychologischen Brille im Arbeitskontext betrachtet.

Was habe ich dabei gelernt?

Die Vorgabe von schwierigen, spezifischen und erreichbaren Zielen ist eine wichtige Voraussetzung für Leistungshandeln. Schwierige Ziele wirken aktivierend und erhöhen die Ausdauer. Spezifische Ziele schaffen Klarheit über den geforderten Leistungsstandard und reduzieren so die Varianz der Leistung. Sind Ziele hingegen vage formuliert, kann eine ganze Bandbreite an Handlungsergerbnissen passend sein. Untersuchungen zeigen, dass bei vagen Zielen die Zufriedenheit trotz schlechterer Ergebnisse höher ist. Der Zielursprung, ob partizipativ oder über "tell and sell" ist dabei unwichtig (Latham & Locke, 2002; Nerdinger, 2013; Wegge, 2004)
Das OKR-Konzept greift die oben genannten Erkenntnisse der Zielsetzungstheorie von Locke und Latham (1991) auf und entwickelt darauf basierend ein Zielmanagement-Modell für Unternehmen
Wichtig für die Zielakzeptanz und die Zielbindung und somit für die Leistungsbereitschaft ist die Zielpassung oder Motiv-Ziel-Kongruenz. Die Zielpassung beschreibt die Übereinstimmung der impliziten und expliziten Motive eines Individuums (Schmitt & Brunstein, 2004; Sevincer & Oettingen, 2009; Wegge, 1998). Diesen Aspekt konnte ich in der vorhandenen OKR Literatur nicht finden.
OKRs sind ein gutes Tool um Ziele zu setzen, sie geben jedoch wenig Antworten darauf wie die Ziele auch erreicht werden können. In der Psychologie wird in diesem Zusammenhang zwischen Prozessen der Zielsetzung und des Zielstrebens unterschieden (Gollwitzer, 1995, 1997)
Im OKR Konzept werden keine interindividuellen Unterschiede wie Fähigkeiten, Fertigkeiten und dispositionelle Faktoren berücksichtigt. Zielorientierung ist ein solcher dispositioneller Faktor. Er schafft einen impliziten, mentalen Referenzrahmen, innerhalb dessen Individuen eine Leistungsituation bewerten und darauf reagieren (Nerdinger, 2004, 2013). So empfinden Menschen mit einer Leistungszielorientierung herausfordernde Aufgaben als Bedrohung, da sie ein hohes Maß an Misserfolgsrisiko in sich bergen. Personen mit Lernzielorientierung sehen schwierige Aufgaben als Chance zu lernen und Ihre Kompetenzen weiterzuentwickeln. Während die ersteren bei schwierigen Aufgaben eher maladaptive Verhaltensmuster entwickeln und sich von den Ziele distanzieren, entwickeln die zweiten adaptive Verhaltensmuster und reagieren mit Ausdauer, Lösungsorientierung und erhöhter Anstrengung ( Sevincer & Oettingen, 2009, Vande Walle, et al., 1999).

Die Zielsetzungstheorie (Locke & Latham, 1991) nennt neben der Zielschwierigkeit und Zielspezifität auch einige andere Parameter die eine Auswirkung auf die Leistung haben . So spielen die Selbstwirksamkeitserwartung, Aufgabenkomplexität, Feedback sowie die Zielbindung und Zielwichtigkeit eine Rolle. Zu diesen Dimensionen schweigt sich die OKR Literatur aus.

Abb. 1: Modell der Zielsetzungstheorie nach Locke und Latham (1991)

Picken wir uns z.B. die Aufgabenkomplexität heraus. Untersuchungen zeigen, dass die Aufgabenkomplexität sowie Fähigkeiten und Fertigkeiten einen Einfluss auf die Leistung haben. Je schwieriger das Ziel bei einfachen Aufgaben, desto höher die Leistung. Dieser Effekt kehrt sich bei komplexen Aufgaben um. Erfolg und Leistung hängen bei komplexen Aufgaben von den zur Verfügung stehenden Handlungsstrategien ab. Sind diese nicht vorhanden oder müssen erst erlernt werden, wirkt sich das zunächst leistungsmindernd aus. In dieser Lernphase binden schwierige Ziele die Aufmerksamkeit in Richtung Zielerfüllung, behindern dadurch das Lernen und führen zu unsystematischem herumprobieren (Wegge, 2004; Kanfer et al., 2017). Warum ist das wichtig? Agile Methoden entfalten ihr Potential bei komplexen Aufgaben unter hoher Unsicherheit. Das heißt zwangsläufig, dass vor allem am Anfang Lernen ein wesentlicher Teil der späteren Zielerreichung ist. Henrik Kniberg veranschaulicht das sehr schön in seinem Video "Agile Product Ownership in a Nutshell". Wie wäre es also, vor allem am Anfang einer Entwicklung, Lern- statt Leistungsziele zu definieren? Das wäre für mich ein spannendes Experiment. Im OKR Konzept werden keine Aussagen zu Lernzielen und Aufgabenkomplexität getroffen. Das kann bei den Beteiligten zu Stresserleben und Frust führen.

Abb. 2: Product Ownership in a Nutshell (Kniberg, 2012)

Das Beispiel oben ist nur eines von vielen und es macht deutlich, dass ein vermeintlich einfaches Framework nicht Antworten auf alle Fragestellungen und Probleme bieten kann. Vielmehr sollte es die Bedürnisse sowie die Ausgangssituation in der Organisation und der Teams berücksichtigne und daran angepasst werden.

Welche Implikationen ergeben sich aus meiner Analyse für die Praxis:

→ Lernprozesse und Zielverfolgung hängen in Zukunft eng zusammen.

Zielsetzungsprogramme sollten durch unterstützende Personalentwicklungsmaßnahmen flankiert werden, damit die Mitarbeitenden die notwendigen Fähigkeiten und Fertigkeiten zur Zielerreichung entwickeln können. Siehe dazu auch unsere Blogbeiträge zu Agile HR.
Formulierung von Lernzielen statt Leistungszielen bei innovativen und herausfordernden Tätigkeiten (Seijts et al., 2004; VandeWalle et al., 1998)
Gestaltung der Arbeitsumgebung, um die Motivation sicherzustellen (z.B. nach dem Job-Characteristics-Modell von Hackmann & Oldham, 1976)
Trainings zur Steigerung der motivationalen Kompetenz um eine bessere Motiv-Ziel-Passung hinzubekommen (Schmitt & Brunstein, 2004)
Das Rubikon-Modell von Heckhausen & Gollwitzer (1987) könnte als Rahmen für die Ableitung von Maßnahmen entlang der unterschiedlichen Handlungsphasen unterstützend sein

Wer mehr wissen möchte, kann mich gerne unter zoi.natsiopoulou@improuv.com kontaktieren und mit mir diskutieren. Ich freue mich darauf.

Verteilt ist das neue Co-Located

zoi — Mon, 23 Mar 2020 15:51:51 +0000

Große Organisationen stehen sehr oft vor verschiedenen Herausforderungen, wenn sie beschließen agil zu werden. Sie finden sich in einem Spannungsfeld zwischen historisch gewachsenen Strukturen und dem Wunsch nach Veränderung wieder. Diese gewachsenen Strukturen lassen sich oft nicht mit einem Big Bang auflösen.

Ein Beispiel dafür ist die Forderung nach crossfunktionalen Teams, die co-located sind. Das ist oft nicht möglich, da aus der Historie heraus verschiedene Funktionen und Expertisen in unterschiedlichen Standorten zusammengeführt und entwickelt wurden.

Für Agile Coaches und Scrum Master bedeutet dies, dass sie mit der Situation von verteilten Teams umgehen müssen. Da hilft es nicht mit erhobenem Zeigefinger zu predigen, sondern diese Herausforderung pragmatisch anzugehen, und den Teams zu helfen, diese zu meistern und sich zu entwickeln.

Was hilft:

Mindestens einmal sollten sich alle treffen und kennenlernen - und wenn das im Moment nicht klappt, ist es umso wichtiger, es nachzuholen, wenn wir uns wieder persönlich treffen können.
Technologie zur Verfügung stellen (Video, Audio, Räume), die funktioniert. Tut sie das nicht, geht wertvolle Zeit verloren und die Nerven liegen blank - das sollte man vermeiden.
Nutzt ein Tool, mit dem man interaktiv arbeiten kann, wie Concept Board oder ähnliches. Und vergesst nicht, die Teammitglieder zu trainieren, damit sie es auch nutzen können.
Aktiviert eure Teilnehmer auch am Anfang einer Remote Session.
Eine klare Moderation durch den Scrum Master oder Agile Coach hilft, Remote Sessions wertvoll zu machen.
Bereitet die Session gut vor. Templates im Concept Board helfen. Wir haben z.B. einen Feature Splitting Workshop mit einem Remote Team gestaltet, in dem wir einen Wissensvermittlungsteil und einen interaktiven Teil hatten und das Concept Board entsprechend gestaltet haben.
Bei Remote Meetings gilt noch viel mehr als in üblichen Meeting: keine Gefangenen. Also nehmt nur Kollegen mit dazu, die dabei sein müssen und wollen - sonst entsteht Frust.

Lean Agile Portfolio Management - bringing agility to the Strategy and Portfolio level in times of accelerating change

stuart — Thu, 23 Apr 2020 17:07:16 +0000

Hello, and welcome to this short blog on Lean Agile Portfolios.

A week ago, I did a Brown Bag Session about this topic.

https://www.youtube.com/watch?v=pomAEBJ4tEQ

Brown Bag Session Lean Portfolio Management Overview

In this blog I´ll cover three things. First, what do we mean by a Portfolio. Second, what common characteristics do we observe in Lean Agile Portfolios, and third, what pragmatic steps have our customers taken to start transforming to a Lean Agile Portfolio. But before I start, I´d like to mention why this is an especially important theme at this point in time. There are really two things.

Enterprise Agility, not just Team agility in times of rapid change

Customers have come to us recently expressing the concern that, while “Lean Agile” is starting to be adopted and lived at the team and program level, their overall strategic and budgeting process is still base around traditional project portfolio management, yearly budgeting, and a focus on funding projects and not the people and teams who deliver value. These companies are finding that they cannot reach their enterprise business goals such as “faster to market”, “more adaptive”, “more customer focused” because the two worlds of “project” portfolio management and program/team Agility don´t fit together. Companies are starting to learn that the strategic portfolio and budgeting process needs to reflect the lean-agile principles that they are living at the team level. In this way they can ultimately deliver the outcomes the company is looking for, and become more resilient in a rapidly changing world.

The second reason is, of course, the chaotic corona world we are now in. The current demand for rapid change and adaptation makes most 2019-devised enterprise plans and budgets for 2020 seem out-of-date and redundant.

Lean Agile Portfolio Management provides the principles and mindset that companies can use to react faster and more focused to changing conditions and market expectations.

So what IS a Portfolio?

I`ll start with an example. My niece decided she wanted to become a professional photographer. To get into “photography school” she needed to submit a portfolio of her work. In her case, this was a collection of different types of images - some portraits, landscapes, differing light conditions and subjects etc.. So there were many different images, but together, for her, the collection had a common “Focus” - “Purpose” and “Value”. Therefore her Portfolio was a Collection of items that have a common Focus-Purpose-Value.

Fig.1 My niece´s photographic portfolio

Now how does this transfer to Enterprise Portfolios? Here we also have collections. But these collections comprise Large Strategic Initiatives. The big business and technical things that will power our portfolio (and business) over the medium to long term. At the Portfolio level we are typically talking about initiatives that run into many hundreds of thousands, or millions of Euros. We are not talking about features and stories here.

Fig. 2 What bounds an Enterprise Portfolio?

This portfolio of strategic initiatives is often bundled together through a common Vision, Customer segmentation or a specific value proposition. The Portfolio is formed around a common Strategy, which impacts how much the enterprise invests in that Portfolio and the budgeting decisions within the portfolio.

So this are typically how we see an “enterprise portfolio”. However most Large enterprises typically manage multiple portfolios. Let‘s take an Insurance company as an example. It may have a portfolio for Property Insurance, another for Life Insurance, and a third for Industry. Each of these Portfolios is bundled together via a common Focus - Purpose and Value. And each of them is managed through Lean Agile Portfolio principles and practices.

Fig. 3 An Enterprise with multiple portfolios (Property, Life, Industry)

Lean Agile Portfolios contain the strategy, investments and significant initiatives to validate, adapt and deliver the strategy, bundled around a common focus, purpose and value. The realisation of portfolio strategy is enabled through agile teams and programs.

What does a Lean Agile Portfolio look like?

Now let‘s look at what we typically observe within Lean Agile Portfolios. One of the first things we´d expect to see would be Transparency. Typically this means we have a Portfolio Kanban process that is helping us manage the flow of value. It makes the things we are working on, the throughput of value, and the tradeoffs we are making, transparent.

Fig. 4 A portfolio Kanban provides transparency and (opportunity for) flow management

A second element is transparency over DEMAND and CAPACITY. We typically find the scope of demands in large Portfolios far outstrips our ability to deliver that through the teams and programs. By making this transparent we can then start to address questions of priorities, de-scoping, focusing on outcome and not output etc. We wish to balance demand and capacity to be able to deliver the most valuable outcomes for the Portfolio.

Fig. 5 We wish to balance demand and capacity (stop "committing" to more work than can actually be done )- focus on value outcome

We then then expect to see alignment. We have a large number of people contributing to the Portfolio. We have senior business executives, finance and controlling, business owners, agile programs (Areas, Agile Release Trains etc.), we have agile teams, etc. etc. – and it is the “people” who actually deliver the value outcomes. Therefore a major aim of Lean Agile Portfolio Management is to align and synchronise the “people” and the “vision” and “strategy. This is crucial so that we all understand the Focus, Purpose and Value the portfolio stands for - and this in turn gives us a north star that helps guide us in our local decision making.

Fig. 6 We need to align everyone within the portfolio to the overall vision and strategy

A forth element we expect to find in a Lean Agile Portfolio is a focus on funding people, teams & value streams, and not Projects. We want to stop funding and organising around projects, and start funding and organising around value. In doing so, we have more freedom and flexibility to focus on optimizing value rather than on “project completion”.

Fig.7 Stopping funding projects and start funding value streams

Finally, we see our Plan-Do-Check-Act cycle at the portfolio levels. We have cadence-based Strategy, Portfolio and Budget Review. At regular intervals we inspect and adapt to ensure we are focused on the right things based on the right learning.

Fig. 8 We move from yearly strategy and budget cycles to cadence-based inspect & adapt cycles focused on outcome

The Portfolio is now starting to exhibit the same lean agile values and principles (and practices) we see working at the team and program levels. We now have a better chance of reaching our enterprise goals in times of accelerating change, complexity and uncertainty.

Sounds nice! But what about doing this in practice?

To help answer this, I gathered together the experiences we have made with a number of customers during 2019/2020. These are the Pragmatic Steps they have followed along their Lean Agile Portfolio journey. So what have they actually being doing? Here are stickies I gathered:

Well, the first step is to Define and Align on what the scope of the Portfolio actually is. What IS the actual portfolio? How do we define it? Who is needed, and what products & services are “in” and “out” of this portfolio. This is important as we often have different opinions about what our Portfolio is or could be. So first define the boundaries of the portfolio – and align on this.

A second step is to visualise the current portfolio through a Portfolio Kanban. What initiatives are in progress? What is currently scoped for the coming period? What things are in the pipeline and could be future initiatives. How balanced is demand versus our realistic capability to deliver? Here we are taking a Kanban approach of “visualise your work”. This transparency forms the basis for Lean Agile Portfolio Management.

The third step is to define the roles and responsibilities within portfolio management. We expect to see senior executives, business owners, Lean Agile Competence/change teams taking roles here. We need to be clear about what needs to be done, and who can contribute to this.

The next step (and, yes, you can re-order these steps depending on your context) is to define the Strategy of the portfolio, and what themes and high level initiatives need to be considered for the portfolio to be successful. Approaches such as Wardley Mapping, may be used to map out the business landscape and identify strategic opportunities. Our experience has been that many customers are using OKRs (Objectives and Key Results) to define and communicated their strategic goals. The “initiatives” they generate are focused upon contributing to the desired key results.

Once we have established these first steps, companies tend to invest more time in refining their high level demands. Perhaps creating lightweight lean Business Cases, and sorting the backlog of initiatives based upon value based ordering such as cost-of-delay. They are starting to discuss tradeoffs between initiatives and making hard decisions about what needs to take priority for the portfolio to be successful.

The next step is to address the budgeting approach. Companies start to move away from a yearly budget and strategic planning cycles to a quarterly cycle. The quarterly budget review takes a hard look at where value is actually being created, where not, what has been learned from the market from customers, and makes budget and strategic adjustments accordingly.

A final step is where we see that companies have implemented cadence based planning at the strategy and budgeting level, and have evolved ways to provide "just enough" strategy and budgeting guidance to align everyone to enterprise strategic goals, and provide a north star for the agile teams and programs within the portfolio.

Companies are taking a pragmatic approach to transforming towards Lean Agile Portfolios. This process can take a few months, but more likely it is part of a change process over a longer time span. But take note: if your strategic portfolio is "old school" and the teams and programs have embraced lean agile, don´t be surprised if you are hearing senior people say "now our teams are agile, but we don´t seem to be achieving our strategic goals the way we hoped..". Transform your portfolio and stop holding the people who actually deliver value back !!!

Final words

Ok, thats what I wished to share with you in this short blog. There is a lot to Lean Agile Portfolio Management. but moving from traditional project portfolio management to Lean Agile Portfolio Management has the opportunity of allowing organisations the chance to release a lot more value.

If you are interested in learning more, and are perhaps in the process of trying to (or are thinking about starting to) make this change, then Improuv can support you in three ways:

Please give us a call if you want to talk about our experiences with Lean Agile Portfolio and how could help help you get up-and-running more effectively.

If you are interested specifically in digging much deeper into this topic then join one of our Lead Portfolio Management trainings/workshop - click here for more info.

I hope you can take something positive away from this blog, and I look forwards to any comments and feedback.

Stuart.fish@improuv.com / +49 171 318 4380

Scaling @ Home Connect: How scaling agile is helping Home Connect deliver new and exciting ways for consumers to interact with their home appliances.

stuart — Thu, 23 Apr 2020 20:23:22 +0000

In this article I'd like to share the experiences of one of our customers who has been going through a journey of scaling agile to deliver consumer services that many readers probably use (or have at least seen emerging on our latest home appliances).

Home Connect is a digital service offering enabling consumers to connect to, and interact with, their household appliances - from the washing machine to the oven, to the coffee machine or the vacuum cleaner. It can not only switch appliances on and off, it can also select programs, adjust timers, set appliances to eco mode and much more. A range of supporting digital services around cooking, baking, washing, cleaning etc. create an enhanced experience around connected home appliances.

Home Connect is part of the BSH Hausgeräte GmbH which, with around 61,000 employees, is one of the world's leading companies in the home appliance industry. BSH brand portfolio includes known brands such as Bosch and Gaggenau. With Home Connect, BSH offers a cross-brand, cross-category platform as the basis for a rapidly growing ecosystem of connected home appliances and consumer-oriented services that enable digital experiences in home. Home Connect is a core part of the BSH digital strategy. You can learn more about Home Connect by visiting: https://www.home-connect.com/

The Approach

To meet the increasing demand for innovative digital services to support and connect home appliances, BSH created it´s Home Connect offering to establish a globally leading platform in home appliance connectivity. A decision was made in 2018 to reorganise the Home Connect development program around Lean Agile principles, and to use SAFe as a basis. Improuv, who were already working with SAFe in another part of BSH, were brought in to support the transition to scaled agile, working closely with internal BSH stakeholders and coaches. The challenge in early 2018 was to support the transformation of a large number of teams and roles (both internal and external), spread across a number of countries, from a traditional organisation into a lean agile team-of-teams.

A Value Stream Workshop was held to define the scope of Home Connect and define the first Agile Release Train, key roles, challenges and opportunities. A coordinating steering group, Home Connect Core, was established to support the initial set-up, staffing and training of the train. This includes champions who help steer the change through the organisation. Key roles, such as the Release Train Engineer, were established and the people coached in their role. Team members went through SAFe for Teams training, and additional roles (such as product owners and product management) received role specific training.

While teams were previously working with Agile practices, they were component based. The decision was taken to shake-up the program and form the agile release train around self-designed feature teams. This was a fairly radical step at the time. A large team-forming event was organised where the participants formed teams (within certain pre-conditions) and took part in various team building activities. Home Connect now had teams, core roles and a backlog of features to form the basis of the first all hands “Program Increment (PI) Planning”.

The first PI Planning took place in April 2018 and was a major success. A great team-of-teams atmosphere was created and the program got off to a good start. During the initial program increments (each circa 10 weeks), the train continued to build out its testing strategy, communities of practices, integration approach etc. to build a more robust end-to-end delivery train and learning organisation.

The Change

During late summer/early Autumn 2018 BSH made a strategic decision to place more focus on the Home Connect app. and decided upon a major re-launch of the service and concept in 2019. This triggered two things: 1) it was decided to reappraise the offering and, 2) the release train was to be re-organised based upon learning gained so far. The innovation approach taken was to run a set of Google Design Sprints (design-thinking based) to help identify new customer centric opportunities. This was an intensive time and resulted in significant new customer and product insights that, in turn, were reflected in the program backlog.

A second Value Stream workshop was held to help redefine the program and to revisit the existing team structure. It was found that the initial decision to create pure feature teams was causing some challenges (and in some cases resulting in large teams) and therefore a decision was made to redefine smaller teams around product sub-parts/thematic areas - within which the teams would focus. At the start of the next PI in November 2018, a second team-forming event was held where, again, participants were empowered to form teams, but within a new set of pre-conditions. This resulted in eight agile teams.

The Train is on the tracks

The agile release train travelled through 2019 and delivered the strategic goal of relaunching the Home Connect offering with an exciting set of services. At the time of writing in Q1 2020, Home Connect is rolling out new customer value on a regular basis, and is improving with each Program Increment.

Key leanings include:

# Train everyone – help people understand what this might mean for them, and why the change is happening.

# Empower the teams and the program – include the future agile release train members in the set-up and development of the train.

# Invest in “the spirit” – help build an “identity” around the train – help people feel they belong to something unique and valuable, something they are creating.

# Inspect & Adapt, Inspect & Adapt, Inspect & Adapt – be excited and ready to change based upon learning. Nothing is set-in-stone.

# Understand it is a transformation – it is not a question of “rolling out agile”, it is a question of transformation, and that means people and mindset – something that takes time, is built upon experience, and affects each individual differently.

I hope this case study provides some insight into how larger enterprises are scaling agile to deliver better products. If you wish to learn more about our experiences in coaching organisations along their pragmatic agile transformation then please just get in contact. We like talking about this!

Lead coaches from Improuv GmbH: Stuart Fish & Dennis Wagner.

Lean Agile Portfolio Management - bringing agility to the Strategy and Portfolio level in times of accelerating change

stuart — Thu, 23 Apr 2020 08:25:14 +0000

Hello, and welcome to this short blog on Lean Agile Portfolios.

Enterprise Agility, not just Team agility in times of rapid change

Lean Agile Portfolio Management provides the principles and mindset that companies can use to react faster and more focused to changing conditions and market expectations.

So what IS a Portfolio?

Fig.1 My niece´s photographic portfolio

Fig. 2 What bounds an Enterprise Portfolio?

Fig. 3 An Enterprise with multiple portfolios (Property, Life, Industry)

What does a Lean Agile Portfolio look like?

Fig. 4 A portfolio Kanban provides transparency and (opportunity for) flow management

Fig. 5 We wish to balance demand and capacity (stop "committing" to more work than can actually be done )- focus on value outcome

Fig. 6 We need to align everyone within the portfolio on the overall vision and strategy

Fig.7 Stopping funding projects and start funding value streams

Fig. 8 We move from yearly strategy and budget cycles to cadence-based inspect & adapt cycles focused on outcome

Sounds nice! But what about doing this in practice?

Final words

If you are interested in learning more, and are perhaps in the process of trying to (or are thinking about starting to) make this change, then Improuv can support you in three ways:

Please give us a call if you want to talk about our experiences with Lean Agile Portfolio and how could help help you get up-and-running more effectively.

If you are interested specifically in digging much deeper into this topic then join one of our Lead Portfolio Management trainings/workshop - click here for more info.

I hope you can take something positive away from this blog, and I look forwards to any comments and feedback.

Stuart.fish@improuv.com / +49 171 318 4380

Das agile HR Manifest und Chancen für HR

stefanie — Wed, 20 May 2020 09:13:00 +0000

Wenn es um agile Transformation bei unseren Kunden geht, beobachten wir häufig starre und wenig mitarbeiterorientierte HR Prozesse. Wir sehen und verstehen HR als wichtige Schlüsselfunktion und Enabler wenn es um das Thema agile Transformation geht. Gerade weil HR mit Herausforderungen und Problemstellungen konfrontiert ist, sehen wir viele Gestaltungsmöglichkeiten und Chancen.

Problemstellungen die wir bei Unternehmen wahrnehmen:	Chancen und Möglichkeiten die wir daraus ableiten:
Starre und wenig ansprechende Stellenbeschreibungen	Stellenbeschreibungen gestalten Kandidaten mit und haben dadurch Entwicklungsmöglichkeit
Reaktives und unflexibles Recruiting	Es werden nicht Stellen (nach-)besetzt sondern interessante Menschen für Organisationen gesucht
Schleppende und mühsame Onboarding Prozesse	Onboarding beginnt nach der Vertragsunterschrift um Mitarbeiter sofort zu integrieren
Starke Gehaltsunterschiede und damit hohe Unzufriedenheit bei den Mitarbeitern	Faire und transparente Gehaltsstrukturen, so dass Verhandlungen nicht nötig sind
Mitarbeiter die ein bonusgetriebenes Verhalten aufzeigen	Intrinsische Motivation durch gemeinsame Organisationsziele die transparent sind
Mitarbeiter- Jahresgespräche werden als Last wahrgenommen und quälen HR, Führungskraft und Mitarbeiter	Regelmäßiges Feedback, dass fördert und fordert, sowohl die Führungskraft als auch den Mitarbeiter, ohne Involvierung von HR
Weiterentwicklung kommt aus der Gießkanne und ist reglementiert	Weiterbildung ist ein zentrales Thema in das investiert wird um die besten Mitarbeiter zu haben und ein attraktiver Arbeitgeber zu sein
Karriereplanung wird oftmals unter der Hand vereinbart und als unfair wahrgenommen	Karriereplanung ist ein offener Prozess
Starker Formalismus im HR Bereich	Weniger Bürokratie, mehr Flexibilisierung. Automatisierung, wenn sie Sinn macht
Wenig Verständnis aus HR für Agilität und keine Involvierung bei der Transformation	Mitarbeiter aus HR haben das "Wozu" und "Womit" der Veränderung verstanden und sind Teil der Transformation

Wenn wir die Chancen und Gestaltungsmöglichkeiten im Kopf behalten und uns das agile HR Manifest ansehen, dann fällt uns auf das ein konsequenter Wertewandel angestoßen wurde. Klar ist, es geht um mehr Fokus und Gewicht auf Themen wie Netzwerkarbeit, Transparenz, Anpassungsfähigkeit, Inspiration, intrinsische Motivation und Ambition. Weniger wichtig, aber nicht unwichtig sind Hierarchie, Geheimhaltung, Vorschriften, externe Belohnung und Verpflichtung.

Gespannt, aber auch neugierig stellen sich einige Fragen:

Wie kann ein solcher Wandel durchlaufen werden?
Was benötigen die Menschen in Personalabteilungen damit das das Agile HR Manifest und deren Prinzipien zum Tragen kommen?
Welcher Gap tut sich nun auf womit startet HR als erstes?

Agiles HR Manifest

Collaborative networks over hierarchical structures
Transparency over secrecy
Adaptability over prescriptiveness
Inspiration and engagement over management and retention
Intrinsic motivation over extrinsic rewards
Ambition over obligation

https://www.agilehrmanifesto.org/

Das Zitat von Pia Maria Thoren unterstreicht abermals den unumgänglichen Wandel der HR bevorsteht:
„Furthermore, in an Agile organization, HR’s role, just like the organization’s mindset, must shift. For Agile to work effectively, it’s important that the company structure and culture match up.”
Radical Approach for HR & Managers - Pia-Maria Thoren

Flow oder Silo - die Struktur einer Organisation

krishan — Mon, 27 Apr 2020 04:40:06 +0000

Die meisten Organisationen reden zuerst über die Aufbauorganisation oder die Hierarchie und über die strukturellen Einheiten oder Silos. Das wichtigste Ziel hierbei ist Effizienz und Ressourcenauslastung und das war über lange Jahre fast der einzige Gesichtspunkt. Der Grund dafür liegt schilicht darin, dass es eine optimale Struktur ist, wenn Märkte und Umgebungsbedingungen sich nur langsam ändern.

Da sich das geändert hat, kommt einem anderen Prinzip eine ständig steigende Bedeutung zu: dem Flow oder der Ablauforganisation. Wenn ein Arbeitsablauf über mehrere Abteilungen verteilt ist, entsteht an jeder Abteilungsgrenze ein Abstimmungsbedarf und damit eine Grenze, wie schnell Änderungen implementiert werden können. Wenn man also die Ablauforganisation zum dominanten Prinzip macht, wertet man die Schnelligkeit, in der man Änderungen umsetzen kann, tendenziell höher als Kostenoptimierung und Ressourcenauslastung.

Eine Frage der Kosten

Es ist, wie so oft, eine Frage der Kosten - wobei man sinnvollerweise die Kosten arten einbeziehen sollte, die durch die Entscheidung am stärksten beeinflusst werden: die Opportunitätskosten, v.a. die Kosten verpasster Gelegenheiten wegen zu langer Zeiten zur Implementierung von Änderungen versus die Transaktionskosten, v.a. die Kosten, die jedesmal bei einer Änderung anfallen.

Das heisst: ja, schneller zu sein verringert die Latenzzeiten und verringert das Risiko, Geschäft zu verpassen, aber es hat seinen Preis.

Neben dieser pauschalen Betrachtung kann man noch ein paar weitere Kriterien entwickeln, bei denen die beiden Grundideen nebeneinander gestellt werden. Wohlgemerkt: es sind nicht entweder-oder Entscheidungen, sondern Fragen der Abwägung.

Das Zielsystem

Zunächst wollen wir der Frage nachspüren, welche Probleme die jeweiligen Ansätze lösen, also woran sie sich messen lassen wollen:

Silo	Flow
Auslastung ist der zentrale KPI, wenn es um kostspielige Ressourcen geht.	Flexibilität zählt umso mehr, wenn sich die Anforderungen schnell ändern und wenn Reaktionszeit wichtig wird.
Kosten Kostenoptimierung ist eng mit Standardisierung und Skaleneffekten vernküpft. Sie sind auch ein wichtiger Treiber für Standardisierung und Serienfertigung.	Zykluszeit ist im Lean-Universum zu Recht eine der zentralen Messgrößen. Sie ist darüber hinaus ein mächtiges Instrument, um Optimierungspotential zu identifizieren.

Offene Fragen

Wenn man die Prioritäten von der anderen Seite betrachtet, also versucht, die Defizite zu benenne, werden einige Aspekte noch besser deutlich:

Silo	Flow
Durchlaufzeit Verschiedene Planungsinstanzen brauchen eine Vorlaufzeit zur Koordination	Konsistenz Das Verfolgen konsistenter Ziele in der gesamten Organisation benötigt zentrale Vorgaben oder Vereinbarungen. Das führt in größeren Organisationen zu einer Hierarchie, um den Kommunikationsaufwand im Griff zu behalten
Agilität/ Reaktionszeit Abstimmungsaufwand, wenn ein Arbeitsablauf Abteilungsgrenzen überschreitet.	Skill Wenn Menschen mit gleichen Kompetenzen in verschiedenen cross--funktionalen Teams verstreut sind, muss gewährleistet werden, dass die Weiterentwicklung und das Teilen und Übernehmen von Erfahrungen (also auch Standisierung) vorangestrieben werden.

Wie skaliert die Struktur

Silo	Flow
Finde die Niere Das ist ein eingängiger Ausdruck aus dem SAFe Framework. Er sagt, dass es manchmal schwer ist, die Wertströme in einer großen Organisation mit vielen Produkten und shared Services aufzufinden.	Netzwerk von Flows In einem größeren Massstab finden sich mehrere Wertströme oder Flows, mit unterschiedlichen Taktzeiten und wiederum komplexen Abhängigkeiten. Eine große Herausforderung ist die Vereinfachung dieser Beziehungen mit dem Leitbild, den gesamten Ablauf end-to-end zu betrachten.

Es zeigt sich, dass eine der Entscheidungen mit den tiefsten Konsequenzen, die nach der strukturellen Ausrichtung der Organisation, gar nicht so einfach zu treffen ist. Es ist nicht die Frage nach gut und böse, als die sie manchmal stilisiert wird.

Agile Lernreise - die Brown Bag Session

krishan — Mon, 27 Apr 2020 09:08:38 +0000

Letzte Woche, am 23. April, habe ich eine Brown Bag Session über die agile Lernreise gegeben. Darin gab es ganz kurz eine Vorschau, worum es sich dabei dreht.

Keine Angst, es bleibt nicht dabei. In der nächsten Zeit werden wir Stück für Stück Details dazu veröffentlichen.

Hier nur zum Start:

Lernreise heisst, Enablement ganzheitlich und von der Kundenseite her zu denken. Enablement hat zwei Seiten: Skillentwicklung für Personen (aka Workforce development) und Entwicklung von Capabilities für die Organisation. Ich bleibe hier beim ersten Aspekt.

Skillentwicklung hat verschiedene Ausprägungen, je nach Rolle und Standpunkt. Hier ein paar erste Ideen dazu:

Personen setzen sich ein Ziel für die Weiterentwicklung, wir liefern handlungsleitende Konzepte
People Leads moderieren die Lernreisen ihrer Mitarbeiter, wir liefern ihnen ein Framework
Organisationen entwickeln/treiben im Rahmen ihrer Strategie (-entwicklung und -umsetzung) eine strategische Workforce-Planung.

Der Trainingsmarkt wird sich ändern - das wissen wir nicht erst seit gestern. Die Veränderung hat nur dramatisch an Tempo und Tiefe zugelegt.
Für improuv und für euch alle wirft das Fragen auf, die wir zwingend beantworten müssen. Das ist ein Anfang.

https://youtu.be/WQdi0uAdV2o

Kim, Charly und ihre Kollegen

krishan — Tue, 05 May 2020 12:43:21 +0000

Darf ich vorstellen? Kim, Charly und ihre Kollegen. Das ist die Geschichte einer Lernreise - na ja, das allererste Kapitel. Ich versuche die Erfahrung, wie man sich einer neuen Art der Arbeit nähert, aus der Sicht der Handelnden zu beschreiben. Handelnde, nicht Betroffene oder Beteiligte. Aber lassen wir sie selber sprechen: bei der Agile Learning Journey.

Wir werden in der nächsten Zeit weiter sehen, wie sie ihre Arbeit gestalten und umgestalten.

Ja, richtig, vielleicht sollte ich noch etwas Kontext liefern.

Man kann eine agile Transformation aus verschiedenen Gesichtspunkten beschreiben.

Einer ist die Sicht der Organisationsstruktur. Die Matrix kippen, Ablauf- vor Aufbauorganisation, Wertstromorientierung sind nur ein paar Namen dafür. Das ist wahrscheinlich die wichtigste einzelne Änderung.

Ein anderer Gesichtspunkt ist die Sicht der Kultur: Vertrauenskultur, Fehlerkultur, oder andere. Dieser Gesichtspunkt ist genauso wichtig, dabei gibt es aber einen Haken: Kultur kann man nicht einfach machen. Kultur ist das wie, in unserem Kontext, wie die Menschen in einem Unternehmen miteinander umgehen und arbeiten.

Ein dritter Aspekt ist die Produktarchitektur. Sie ist die vielleicht klarste Interaktion mit der Aussenwelt (wenn ich mal die mahnenden Worte meines Brand-Beraters ignoriere).
Und ein vierter Punkt sind die Skills der Personen und die Fähigkeiten von Teams. Ohne qualifizierte Personen funktioniert nichts, und Teams sind aus gutem Grund das „Golden Nugget“ der Agilität, der Punkt, den man nicht ignorieren kann, ohne das ganze Gebäude zum Wackeln zu bringen.

Damit fange ich also an, und wir werden sehen, was sie für sich erreichen können und wo ihnen das System Grenzen setzt. Das ist der Punkt, an denen es nicht mehr zielführend ist, im System zu arbeiten, sondern wo sie am System arbeiten müssen. Dann werden wir auch sehen, wo sie Hilfe brauchen.

Viel Spass bei der Agile Learning Journey

Boost oder Backlash

krishan — Tue, 12 May 2020 09:30:59 +0000

Was Corona mit der Agilität macht.

Agilität hat ja den Anspruch, die Flexibilität eine Unternehmens zu erhöhen. Dann müsste man erwarten, dass jetzt die Stunde der Agilisten schlägt. Tut es aber nicht, zumindest nich durchgängig.
In mehreren Unternehmen bekomme ich mit, dass gerade ein ganz anderer Wind herrscht. Zurück zu Command und Control, Ansagen, die ganz alte Nummer. Das erscheint mir erstmal ziemlich paradox und ich suche eine Erklärung.

Laloux' Gesellschaftsstufen als Erklärungsmuster?

Kollegen haben die Laloux-Kategorien herangezogen und beobachtet, dass sich der Typ ihrer Organisation ein oder sogar zwei Stufen zurückentwickelt. Frederick Laloux (Reinventing Organizations, 2014) beschreibt, wie sich Gruppen / Gemeinschaften entwickeln - oder zurückentwickeln, wenn sie unter Stress stehen. Dabei verwendet er Typen

Stammesgesellschaft: Diese Organisationsform wird vor allem durch Machtausübung gegenüber Untergebenen dominiert. Im eher chaotischen Umfeld hält Angst die Organisation zusammen. Beispiele sind Mafiastrukturen.
Traditionell: Eine stark autoritäre Organisation mit formalisierte Rollen in einer Hierarche und strikten Prozessen. Beispiele hierfür sind viele Behörden.
Modern: Konkurrenz, Expansion und Profite dominieren diese Organisationsform. Beispiel hierfür sind typische Großunternehmen.
Postmodern: Neben die Hierarchie rücken gemeinsame Werte in den Vordergrund. Empowerment wird zum wichtigen Mittel um herausragende Motivation zu erreichen.
Evolutionär: Hier sind Selbstmanagement, Ganzheitlichkeit, Authentizität und Ausrichtung auf den Sinn die bestimmenden Elemente.

Ich finde es eine schöne Beschreibung von Archetypen, kann aber daraus nicht viel Erkenntnis für mögliche Reaktionen in der jetzigen Situation ziehen - es ist mir zu deskriptiv, zu fatalistisch, zu viel Schicksal. Wenn ich diesem Modell folge, muss ich mich in mein Schneckenhaus zurückziehen und überwintern.

Das kann zwar angemessen sein, um die Beharrungskräfte eines Systems auszunutzen (ich habe das auch schon getan), ist aber nicht wirklich befriedigend und hat wenig Handlungsperspektive.

Kann uns Cynefin helfen?

Vielleicht komme ich weiter, wenn ich nicht Laloux, sondern David Snowden’s Cynefin Framework zur Analyse heranziehe, und tatsächlich werde ich da fündig: Cynefin unterscheidet Kontexte und kategorisiert Muster für angemessene Aktionsmuster:

Offensichtliche Kontexte: das dominante Aktionsmuster ist: wahrnehmen - kategorisieren - reagieren. Das ist die Welt der kodifizierten 'best practices', klarere Restriktionen und fester Hierarchie. Das klassische Beispiel ist die Fließbandarbeit.
Komplizierte Kontexte: ein Beispiel ist die Reparatur eines Flugzeugs am Boden. das dominante Aktionsmuster ist wahrnehmen - analysieren (im Gegensatz zum einfacheren Einordnen) - reagieren. Die Praktiken sind nicht „best practices“, d.h. nicht abschliessend definiert, sondern „good practices“, d.h. es gibt Erfahrungswerte, aber deutlich mehr Spielraum. Auch das Führungsbild ist anders: in dem Wartungsbeispiel wäre das ein Team Lead, der sich von den Spezialisten in seinem Team beraten lässt. Das Wissen ist das Erfahrungswissen der Mitarbeiter und normalerweise ein Handbuch oder ähnlich.
Komplexe Kontexte: hier gibt es viele Überraschungen, weniger Vohersagbares. Das dominante Aktionmuster ist: testen („probe“) wahrnehmen - reagieren. Das kann man leicht in das Haupt-Vorgehen in einem agilen Entwicklungsprojekt übersetzen, in dem Experimente einen „discovery“ oder Erkenntniszyklus speisen, der über den Backlog in einen „delivery“-Zyklus wie den Scrum Sprints eingeht. Hier ist das selbstorganisierte Team angemessen und die Führungsbilder rund um den „servant leader“. Noch ein Blick auf die Rolle des Lernens: Prozessbegleitendes Lernen und kontinuierliche Verbesserung sind in diese Prozesse fest eingebacken - über Mechanismen wie „probe“, d.h. die Durchführung von Experimenten und Veranstaltungen wie den regelmäßigen Retrospektiven.
Chaotische Kontexte: das ist die typische Notfallsituation wie Feuerwehreinsatz oder Verkehrsunfall mit Schwerverletzten. Das Aktionsmuster ist: Handlen, Wahrnehmen, Reagieren („act, sense, respond“). Es ist keine Zeit zum Diskutieren. Beim Lernen nutzt man das Wissen, das man vorher angesammelt hat.

Die aktuelle Situation enthält für das Business Umfeld einige Elemente von Chaos - in einigen Branchen wie Luftfahrt, Touristik und evtl Automobil ist es eindeutig chaotisch. Jetzt setze ich das agile Toolkit daneben, das hauptsächlich für komplexe Umgebungen entwickelt wurde und jetzt wundere ich mich nicht mehr, dass die Führungsetagen weniger geneigt sind, auf die Meinung der Agilisten zu hören. Wenn ich will, dass die Ideen, Werte und das Menschenbild weiterhin eine Rolle spielen, muss ich Antworten finden, die in diese Zeit passen. Die können darüber entscheiden, ob die Agilität in den Firmen zurückgedrängt oder befördert wird.
Bevor ich dazu komme, möchte ich noch Faktoren aufzählen, die für einen Boot oder einen Backlash sprechen könnten.

Was einen Backlash begünstigt

Das gute alte Muskelgedächtnis der Organisationen: das Wort hat Ken Schwaber seit den Anfangszeiten von Scrum verwendet, um zu beschreiben, dass Organisationen dazu neigen, wieder in altgewohnte Bahnen zu verfallen - umso mehr, wenn sie mit Stress-Situationen konfrontiert sind
Die Reaktion der Verlierer der Agilität: wie bei jedem anderen Change gibt es auch bei Einführung agiler Strukturen Verlierer: Menschen, die Positionen, Einfluss, gewohnte Privilegien und Entscheidungsbefugnisse verlieren oder denen das ganze einfach unangenehm ist, weil es ihrer persönlichen Art zu arbeiten widerspricht. Die kommen aus der Deckung und nutzen die Situation
Und schließlich die oberflächliche Ähnlichkeit zwischen einer hierarchischen Planung und Arbeitsteilung, die in einer einfachen oder komplizierten Umgebung gute Ergebnisse bringt. Es erscheint einfach passend, die alten Muster wieder herauszuholen und zu re-etablieren.

Das große Missverständnis dabei entsteht durch die oberflächliche Ähnlichkeit - und das Gleichsetzen - der Führung in komplizierten bzw. chaotischen Umgebungen.

Was für einen Boost spricht

Resilienz, d.h. die Fähigkeit, auf Überraschungen zu reagieren, ist essentiell, um heil aus der aktuellen Situation herauszukommen. Wenn es gelingt, diese Fähigkeit, die der Agilität zugeschrieben werden, zu aktivieren, können sie sehr nützlich, wenn nicht essentiell sein.
Business Agility. Dazu ist ein weiterer wichtiger Baustein notwendig: das Verständnis, dass Agilität beim Agieren auf einem veränderlichen Markt anfängt und dass sich die Ideen zu Strukturen und die Kultur daraus ableiten: sie sind ein Beitrag zu einem florierenden Unternehmen. Allzu oft wird Agilität auf das Befolgen bestimmter Regeln, wie zum Beispiel den Scrum Prozeß reduziert. Das führt zum dritten Punkt:
Agilität ist kontextbedingt. Sie trägt mit einer konsequenten Orientierung auf empirisches Arbeiten, (d.h. die Konsequenzen auf Erfahrungen in das Handeln einfließen lassen) den Aspekt des Lernen in den Mittelpunkt der Arbeit: Arbeiten ist Lernen (Peter Senge)

Boost statt Backlash - Ideen zur Stärkung der Agilität in der Krise

Stabilisierung und Vergewisserung der Werte. Wenn man die Werte der verschiedenen Kontexte nebeneinander legt, fällt sofort eine Konstante ins Auge: Respekt. Der Spiegel im Verhalten der Menschen ist: verantwirtliches Handeln - Accountability. Wenn man dieses Wertepaar stärkt, kann man gerade in der Krisensituation eine langfristig wirkende Stärkung der Kultur der Organisation erreichen.
Fokus auf den Wertbeitrag der Agilität: Resilienz hat heute ihren Wert, in einer chaotischen Umgebung speist sie sich zu einem erklecklichen Teil aus den gelernten Lektionen der Vergangenheit: wie können diese Lektionen effektiv aktiviert werden, welche Strukturänderungen sind angelegt, die nutzbar gemacht werden können, wo gibt es Vertrauenskapital, das man aktuell nutzen kann.
Das Zielbild schärfen, oder: wie kommt man aus der chaotischen Situation wieder heraus. Es ist verführerisch, die Kommandostrukturen als Reaktion auf die Krise zu aktivieren - und sie dann einfach aktiv zu belassen („bitte, geht doch“). Sie sind aber nicht nachhaltig gut, sie brauchen Gelerntes auf, d.h. sie zehren vom gesammelten intellektuellen und kulturellen Kapital. Agilität muss zur Antwort auf die Frage beitragen, wo und wie die angemessenen Strukturen, Arbeitsweisen und Kultur für eine hoffentlich wieder „nur“ komplexe Welt wieder etabliert werden.

Ich glaube, dass das die Reaktion auf diese Situation wichtig für die Wahrnehmung des Beitrags der Agilität für das Wohlergehen der Menschen und der Organisationen sein wird. Wir Agilisten können ernsthafter Partner für die Nutzung verschiedener Wissensquellen und Konzepte sein, wenn wir uns nicht einfach beleidigt in unser Schneckenhaus zurückziehen.

Wie COVID 19 das Arbeiten mit Menschen verändert

stefanie — Wed, 20 May 2020 08:49:46 +0000

Seit einigen Wochen befinden sich viele von uns im Home Office und arbeiten remote. Für die meisten von uns ist es neu, Workshops oder Meetings, bei denen wir es gewohnt waren, persönlich teilzunehmen, nun auch remote zu machen. Besonders herausfordernd sind beispielsweise OKR Plannings oder auch PI Plannings.

Eine ganz besondere Herausforderung ist das remote Arbeiten für Organisationen und Teams, die gerade erst begonnen haben, neue Arbeitsweisen auszuprobieren und mitten in einer Transformation stecken. Arbeiten mit Individuen in herausfordernden Situationen ist ohnehin schon schwer - nun bekommt dies eine zusätzlich Dimension. Über den Bildschirm ist ein Ausschnitt der Körperhaltung sichtbar, aber die Körpersprache bleibt verborgen. Auch Mimik und Gestik kommen über eine Videokonferenz nicht in Gänze zum Vorschein. Das kurze informelle Gespräch beim Kaffee ist nicht mehr möglich. Einfach kurz ein paar Worte im Aufzug oder im Flur zu wechseln fehlt ebenso. Die zwischenmenschliche Komponente leidet massiv in der aktuellen Zeit - auch wir als erfahrene Coaches merken das sehr.

Um eine kleine Abhilfe zu schaffen haben wir den „Agile Helpdesk“ ins Leben gerufen. Wir unterstützen Sie bei sämtlichen Fragestellungen rund um Agilität und bieten Ihnen kleinere Coaching Sitzungen an. Sie können auch während der Corona Einschränkungen von unserem Experten Know How profitieren und sich von unseren erfahrenes Coaches coachen lassen.

Schreiben Sie uns eine E-Mail an agilehelp@improuv.com

Wir freuen uns auf Ihre Kontaktaufnahme!

Agile Transition in die Leere - Wenn die Wirksamkeit ausbleibt

jens — Thu, 02 Jul 2020 08:31:55 +0000

Die verordnete Zwangspause der Coronazeit führt bei vielen Coaches und Transitionsteams zu der Frage, wie die Transition eigentlich bisher gelaufen ist und wie es weitergehen soll, wenn das Gröbste überstanden ist. Wenn das Dauerfeuer des Tagesgeschäfts mal nachlässt, folgt oft Ernüchterung. „Offen gestanden sind wir nicht besonders wirksam“ haben wir die letzten Wochen häufiger gehört. Keine erfreuliche Erkenntnis, wenn man mit viel Enthusiasmus losgezogen ist, das eigene Unternehmen zu verbessern.

Mangelndes methodisches Wissen ist normalerweise nicht das Problem. Die Coaches sind in der Regel gut ausgebildet und auf dem Stand der Diskussion. Auch bei den handwerklichen Fähigkeiten hapert es selten: Moderation, Change Management, Führungsqualitäten sind alle auf hohem Niveau. Und es gibt auch die ein oder andere Managerin, die die Ideen aufgegriffen hat und gute Erfolge vorweisen kann. Aber von der erhofften Welle ist man noch mindestens so weit entfernt, wie am ersten Tag – wenn nicht weiter: Da gibt es den Abteilungsleiter, der nur irgendwelche Metriken haben will. Oder seine Kollegin, die zwar mal angefragt hatte, sich dann aber eigene Coaches geholt hat, die aber von echter Agilität keine Ahnung haben. Was ist da nur schiefgelaufen?

Ein Muster, das wir in solchen Situationen häufiger sehen, ist Lösungsfokus. Die Teams haben viel Aufwand und Herzblut investiert, um Agilität zu erklären, die Vorteile für die Organisation und was man alles ändern muss. Wer diese Vorteile nicht sieht, der muss blind sein, oder aber böswillig das "Alte Denken" verteidigen. Einer von denen, die raus müssen, wenn wir erfolgreich sein wollen. Oder ist es gar nicht so einfach?

Eine alte Faustregel empfiehlt, den Fehler erst einmal bei sich selbst zu suchen. Nicht, weil er unbedingt dort liegen muss, sondern weil man auf das eigene Verhalten mehr Einfluss hat. Statt sich nutzlos zu ärgern, kann man auch mal die Perspektive wechseln und den widerspenstigen Manager als Kunden sehen und die Transition als Produkt. Für den methodisch versierten Coach eröffnet sich dadurch ein ganzer Werkzeugkasten, um sich Handlungsoptionen zu erarbeiten. Wie wäre es mit einer klassischen Produktvision? Zielgruppen, Bedürfnisse, Angebot und Mitbewerber sind auch in einer Transition spannende Aspekte, um herauszufinden, was wirklich gebraucht wird. Oder wie wäre es mit der Aufteilung des eigenen Angebots für verschiedene Kundensegmente? Vielleicht ist das Angebot, für das die Leiterin der Innovationsabteilung so schwärmt, für den Betriebsleiter nicht wirklich attraktiv, weil sie schlichtweg sehr unterschiedliche Aufgaben haben.

Hat man erstmal Zielgruppen identifiziert, bietet es sich an, mit einer klassischen Value Proposition Canvas ein attraktives Wertversprechen für die einzelnen Zielgruppen zu erarbeiten. Die Schwierigkeit liegt dabei darin, auch für die scheinbar widerspenstigen Manager die Bedürfnisse zu analysieren. Will man wirklich ein Angebot für den machtgeilen Kontrollfreak erarbeiten? Oder verrät man damit nicht sein eigenes Wertesystem?

Wer vor dieser Frage steht, ist vielleicht weniger einem pathologischen Soziopathen aufgesessen, als den eigenen Vorurteilen. Man könnte alternativ auch mal annehmen, dass der Wunsch nach Kontrolle nicht Zeichen einer Persönlichkeitsstörung ist, sondern eher einem bestimmten Bild professionelle Managements entspringt und dem Wunsch einfach gute Arbeit zu machen. Für diese Bedürfnisse könnte man doch etwas anbieten, ohne sich verbiegen zu müssen. Wenn es gelingt, an diesem Wunsch nach guter Arbeit anzuknüpfen, kann man vielleicht das Verständnis erweitern, wie "professionelles Management" aussehen kann und so neue Handlungsoptionen eröffnen. Wenn das gelingt, so zeigt die Erfahrung, hat man oft nicht nur ein Problem gelöst, sondern auch gleich einen neuen Mitstreiter gewonnen.

Wie bei jeder agilen Produktentwicklung muss man sich natürlich darüber im Klaren sein, dass jede Annahme über eine Zielgruppe nur eine Hypothese ist und validiert werden sollte. Damit hat man schon wieder ein paar neue Ideen für das nächste Backlog Refinement.

Wenn man also mit der eigenen Wirksamkeit unzufrieden ist, könnte es daran liegen, dass man eine Lösung anbietet, für die die Kunden einfach kein passendes Problem haben. Oder sie mögen die Lösung nicht. Der agile Werkzeugkasten enthält genügend Ideen, wie man sein eigenes Angebot an den Bedürfnissen seiner Kunden ausrichten kann, ohne dabei die eigene Vision zu verraten.

Mehr über den Aufbau von Agilen Transitionen erfahren Sie in unseren Certified Agile Leadership Kursen. In unseren Certified Scrum Product Owner Trainings können Sie mehr über Visionen und Hypothesen lernen. Der Umgang mit einer Value Proposition Canvas ist eines der Themen aus dem Advanced Certified Scrum Product Owner Training.

Agile Trainings - Mit Abstand oder Remote?

jens — Wed, 08 Jul 2020 15:16:39 +0000

Nach einem Vierteljahr Corona machen sich drei unserer Trainer*innen Gedanken, welche Vor- und Nachteile Remote Trainings gegenüber Präsenzveranstaltung haben. Die Teilnehmer*innen:

Alisa Ströbele: Akkreditierte Kanban Trainerin und Coach
Jens Coldewey: Akkreditierter Kanban Trainer, Certified Scrum Trainer und Coach
Sabine Canditt: Certified Scrum Trainerin seit über zehn Jahren

Jens: Willkommen zu unserem Blog-Chat-Experiment. Wir haben uns - wie könnte es anders sein - ein Corona-Thema vorgenommen: Trainings Remote, oder doch lieber Face-To-Face? Lasst uns mit Remote Trainings starten: Wie fühlt es sich als Teilnehmer an, an einem Remote-Training teilzunehmen?

Sabine: Es fühlt sich ok an, ich bin in meinem Home Office und habe keinen Stress mit der Anreise.

Alisa: In den letzten Wochen war ich in beiden Rollen unterwegs - als Teilnehmerin und als Trainerin bei den Remote Trainings. Wie hat es sich als Teilnehmerin angefühlt? Ich war sehr neugierig ob es überhaupt klappt: die ganze Technik, Menschen von überall auf der Welt... Also es hat sich nach Neuland angefühlt ;)

Sabine: Für mich war es, wie ich es aus vielen Meetings kenne. Ich war immer versucht, nebenher E-Mails zu lesen oder andere Sachen parallel auf meinem Rechner zu machen.

Jens: Wenn Du immer nebenher Sachen gemacht hast, wie effektiv war das Training dann für Dich?

Sabine: Ich bin auch bei Präsenztrainings nicht immer bei der Sache ;-). Die wesentliche Frage ist, wie stark man als Teilnehmer*in aktiv ist. Wenn es genügend Übungen und Interaktionen gibt, ist es ok. Ich war noch nicht in einem remote Training als Teilnehmerin, das sich über mehrere Tage erstreckt hat. Eher in der Größenordnung von Stunden.

Jens: Wie sehen Interaktionen Online aus?

Alisa: Ein Mix: Kurzer frontaler Input, viele Kleingruppen-Übungen, Einzel-Reflexionen, vielleicht ein Quiz oder kleine Umfrage. Und wenn dabei die Inhalte spannend sind und die andere Menschen sympathisch, gibt es eine große Chance, dass alle konzentriert bei der Sache bleiben.

Sabine: Ich finde, ein Unterschied ist die Verwendung der Tools. Manchmal klappt das nicht sofort oder gar nicht, und das ist dann frustrierend.

Jens: Das kenne ich aus anderen Remote-Konferenzen: Man verbraucht gefühlt die halbe Zeit, bis die Technik klappt. War das bei Euren Trainings auch so?

Sabine: Da war es unterschiedlich. In zwei Trainings null Probleme, in einem furchtbare Probleme. Wir haben zwei Vorbereitungs-Sessions gebraucht, bevor wir die Teilnehmer technisch an Bord hatten. Da sind zum Beispiel die Probleme mit Zoom, das in einigen Firmen nicht akzeptiert ist. Ich als Trainerin finde es sehr anstrengend, mich immer wieder an neue Tools gewöhnen zu müssen, und brauche immer eine gewisse Einarbeitung, bevor ich halbwegs sicher damit umgehen kann.

Alisa: Die Tools spielen eine sehr große Rolle. Ich hatte bisher wenig Tool-Frust gehabt. Es kommt bestimmt noch ;) Und ja, ein Technik-Check Session vorab fand ich als Trainerin essenziell.

Jens: OK, Perspektivenwechsel zur Trainerin: Was ist für Euch besser an Remote Trainings?

Sabine: Keine Anreise. Wenn das Trainingsmaterial einmal steht, so gut wie keine administrative Vorbereitung, also nichts ausdrucken lassen, keine Flipcharts vorbereiten etc. Kein Aufräumen nach dem Training. Keine Berge von Altpapier. Pausen, die wirklich Pausen sind.

Jens: Also bei “keine Anreise” kann ich mich anschließen, ich fand aber gerade die ersten Trainings enorm aufwändig in der Vorbereitung: Miro Boards vorbereiten, auf die Teilnehmerzahl abstimmen, nochmal gute Ideen von den Kolleg*innen klauen…

Sabine: Ja, die Anfangsinvestition war enorm. Beim ersten Training habe ich ca. eine Woche gebraucht. Ich habe einige Experimente gestartet, um zum Beispiel herauszufinden, wie ich einen Ersatz für Flipcharts finde, um online visualisieren zu können. Danach konnte ich einigermaßen mit den Tools umgehen. Für das zweite Training habe ich dann deutlich weniger Vorbereitungszeit gebraucht. Wenn ich die Trainings nun wiederhole, baue ich ein paar Verbesserungen ein, und das wars. Ich kann da mit meinem Miro-Material besser arbeiten als zum Beispiel mit gedruckten Materialien oder Texten in Word oder Confluence, wo es mir immer die Formatierung zerschießt ;-(.

Jens: Das Problem kenne ich - mit Deiner Word-Installation… ;-) Im Ernst: Ich finde es auch toll, wenn ich problemlos Videos und Web-Links einbauen kann und auch die Teilnehmer ihre Best-of-Videos gleich über miro teilen können. Das geht im Präsenztraining leider nicht.

Alisa: Ich würde nicht sagen “besser” oder “schlechter”. Es ist anders. Es gibt andere Möglichkeiten (z.B. visuell, unterschiedliche Formate…) und auch die Freiheit von überall auf der Welt Trainings zu machen und das auch für die Menschen zu ermöglichen, die sonst nicht dabei sein könnten. Und ja, ich bin dabei die “Grenzen” auszutesten. Wie ist es mit weniger sachlichen Themen? Wie ist es mit “In Verbindung” und “auf der gleichen Welle” zu sein - da sammle ich gerade meine Erfahrungen.

Jens: Hast Du die Freiheit genutzt? Die Trainer*in vom Baggersee…? :-)

Alisa: Nein, aber die Idee, zu Opa nach Schwabenland zu fahren und von da aus ein Training zu geben, steht an (er hat mittlerweile Glasfaser).

Jens: Klingt nach einem Plan.

Sabine: Ich war als Beobachterin bei einem Training dabei, das ein Trainer in München, Alexey Subbotin, (pro bono) für eine Gruppe in Nepal gegeben hat. Das war absolut faszinierend. Die Leute waren so dermaßen motiviert, dankbar und glücklich, dass sie dieses Training bekommen konnten. Ich habe mir auch überlegt, Trainings aus der Wohnung meiner Mutter zu geben. Ich müsste nur meinen Laptop und meinen zweiten Bildschirm einpacken. Dazu ist es aber dann doch nicht gekommen.

Jens: Das finde ich eine coole Idee: Pro bono Trainings für Länder, die es sich sonst nicht leisten könnten.

Sabine: Auch das Zusammenarbeiten mit Co-Trainern lässt sich remote einfacher organisieren, was mehr Gerechtigkeit bringt für Aspiranten, die in Ländern leben, von denen sie nicht dauernd nach Europa oder die USA reisen können, um Co-Trainings zu geben.

Alisa: Das Thema “Co-Training Remote” finde ich auch spannend. Es ist schon viel anders, als vor Ort zusammen zu grooven.

Sabine: Also: ich finde remote Trainings bequemer, aber die wichtigsten Argumente für mich sind nicht meine eigene Bequemlichkeit, sondern der ökologische Footprint und das nicht vorhandene Ansteckungsrisiko.

Jens: Der ökologische Footprint ist aber nicht ganz so trivial, wenn ich alleine den CO2-Ausstoß höre, den man angeblich durch das Streamen von Spielfilmen

verursacht - und die Stimmen, die sagen, dass solche Rechnungen falsch sind…

Sabine: Ich denke vor allem daran, dass die Reisen wegfallen. Wenn wir unsere Präsenztrainings in München geben, fällt das für uns nicht so ins Gewicht. Aber die Teilnehmer reisen ja auch.

Jens: Nach so vielen Vorteilen stellt sich natürlich auch die Frage nach den Nachteilen. Welche seht Ihr da?

Sabine: Ich glaube dass das “Bonding”, die sozialen Beziehungen unter den Teilnehmern nicht so gedeihen. Wie wichtig ist das für den Trainingserfolg? Letztendlich gedeihen sie besser als ich das erwartet hätte, was auch von den Teilnehmern bestätigt wird. Generell ist das Feedback bei den remote Trainings sehr gut (NPS 10). Das liegt vielleicht an der geringeren Erwartungshaltung. Weiterer Nachteil für mich als Trainerin ist, dass ich mich schwerer tue, ein Gefühl für die Stimmung im Raum zu entwickeln. Also: sind die Teilnehmer*innen interessiert oder müde? Einfach mal durchlüften geht allerdings auch remote, auch Lockerungsübungen, das kann sogar ganz witzig sein.

Alisa: Ich habe es oben bereits erwähnt: Die Möglichkeit Beziehungen aufzubauen ist natürlicher, wenn wir einander nicht über die Bildschirme angucken. Für mich als Trainerin ist es viel anstrengender, die Stimmung der Teilnehmer wahrzunehmen, weil ich schlicht nicht alle auf einmal sehen kann. Was in einem Präsenz-Training absolut natürlich und nebenher läuft, musste ich mir technisch aufbauen: mehrere Monitore nutzen, die Teilnehmer-Ansicht immer an einem der beiden Monitore haben.

Jens: Nachdem ich die letzten zwei Tage mein erstes Präsenztraining unter Corona-Bedingungen gegeben habe, bin ich mir aber auch nicht so sicher, ob die Beziehungen nicht auch unter dem Abstands-Gebot leiden. Ich habe aber trotzdem die Gespräche beim Mittagessen genossen und die kurzen Unterhaltungen in den Pausen. Ich hatte tatsächlich viel mehr den Eindruck, Beziehungen aufzubauen und nicht nur Gesichter in Bildschirmen zu sehen.

Sabine: Da gebe ich dir absolut recht. Wie wir schon besprochen haben, sind die Vorteile eines Präsenztrainings unter Corona-Abstandsbedingungen aus meiner Sicht nicht so riesig, dass ein Ansteckungsrisiko dadurch gerechtfertigt ist. Für mich als alternde und eher introvertierte Trainerin sind die Remote-Trainings mittlerweile weniger anstrengend als die Präsenztrainings. Die Anzahl der Trainingsstunden pro Tag sind geringer, und wir machen mehr Pausen. Ich erhole mich viel besser, wenn ich in den Pausen in die Küche gehe und was koche, oder einen Spaziergang mache, oder auf der Terrasse Zeitung lese.

Jens: Das “alternd” fällt jetzt aber unter “fishing for compliments”!

Sabine: Komm du mal in mein Alter, dann weißt du, was ich meine ;-)

Jens: Ich fasse zusammen: Online Trainings funktionieren deutlich besser, als wir ursprünglich dachten und eröffnen einige neue Möglichkeiten - aber der Beziehungsaufbau funktioniert besser wenn man beieinander ist. Wer liefert jetzt noch “famous last words”?

Alisa: Es ist kein entweder oder, sonder ein sowohl als auch, was entsteht. Und es ist gut so :-)

Jens: Danke für den Chat und noch einen schönen Abend!

Alisa: hehe, war schön ;) Danke euch!

Agiles Event Management einer Konferenz in Corona-Zeiten

Sabine — Fri, 02 Oct 2020 09:22:42 +0000

Kernbotschaften

Agiles Wissen und Erfahrungen können für unterschiedliche „Produkte“ nützlich sein
Effektives Arbeiten in einem dedizierten Team (nicht Vollzeit) mit PO und SM funktioniert gut
Visionen und Ziele tragen das Team
Erfahrungen ermöglichen, das agile Toolkit vielfältig zu nutzen

Agiles Arbeiten wird meist mit Softwareentwicklung in Verbindung gebracht. Immer häufiger kommen Fragen aus anderen Bereichen: Wie kann man die Prinzipien und Praktiken übertragen. Das möchten wir an einem Beispiel zeigen, das wir kürzlich durchgeführt haben: die Vorbereitung einer Konferenz. improuv lädt jährlich zur Agile World ein, normaler Weise eine 2tägige Präsenzveranstaltung mit über 200 Teilnehmern. Dieses Jahr kam uns Corona in die Quere. Wir wollen mit Euch teilen, wie wir auf diese drastische, unvorhergesehene Änderung agil reagiert haben und auf ein remote-Format umgeschwenkt sind. Wir hatten nur eine kurze Zeitspanne, um die Konferenz auf die Beine zu stellen, und auf Erfahrungen aus den letzten Jahren konnten wir nur begrenzt zurückgreifen.

So fing es an:

(Sabine) Als ich gefragt wurde, ob ich die PO-Rolle für die Agile World übernehmen könnte, meldeten sich zwei Seelen in meiner Brust: die eine, die Innovator-Seele, sagte: „Cool, eine remote Konferenz, das ist was Neues! Klar mache ich das!“ Die andere, die vorsichtige Seele, warnte: „Pass auf, du überhebst dich total. Du hast null Erfahrung mit sowas, jede Menge andere Dinge an der Backe. Und wer ist überhaupt das Team?“ Entscheidend war für mich, Team-Mitglieder aus dem Marketing und dem Backoffice an Bord zu bekommen, Erfahrungsträger bei der Organisation der bisherigen Agile Worlds und Techies, die sich mit Konferenztools, Registrierungstools und ähnlichem auskannten. Die Initiative war so wichtig für die Firma, dass diese Leute zumindest einen Teil ihrer Zeit mit den Vorbereitungen verbringen konnten.

Zum Glück fand ich sieben freiwillige Enthusiasten, die bereit waren, im Orga-Team mitzuarbeiten. Es waren nur noch fünf Wochen bis zum bereits angekündigten Termin! Es gab bereits ein Programm von Präsentationen, aber mehr auch nicht. Keine Webseite, keine Registrierungsmöglichkeit, und kein Konzept für die remote-Konferenz. Als erstes brauchten wir also eine Produkt-Vision: „die coolste agile Konferenz auf Deutsch“. Sie sollte nicht nur interessante Inhalte bieten, sondern auch Spaß machen und Möglichkeiten zum Netzwerken bieten. Wir definierten Erfolgskriterien für die Zufriedenheit der Teilnehmer*innen und Sprecher*innen, die kommerzielle Seite, usw.. Wir starteten unter enormem Zeitdruck, und ich bin sehr froh, dass ich eine Scrum Masterin an meiner Seite hatte.

(Smaranda): So, ich übernahm die Rolle des Scrum Masters. Zuerst verschaffte ich mir einen Überblick darüber, wo wir gerade stehenim Team – dem Kontext angemessen – effektiv zusammenarbeiten. Wir hatten kein Vollzeit-Team, einen definierten Endtermin und noch 5 Wochen Zeit. Für die Zusammenarbeit im Team kamen unterschiedliche Tools zum Einsatz, wie Trello für die Koordination der Aufgaben im Team, Confluence als Informationsplattform, Miro für kreative Zusammenarbeit.

Wir holten das Team ins Boot, indem alle in die Vision und die Ziele eingeweiht wurden und setzen – der Situation angepasst – kurzfristig Termine auf. Nach einem Check-In besprachen wir in diesen Online-Treffen die jeweiligen Themen, die vorher vom PO priorisiert worden waren. Nach dem Pull-Prinzip nahm sich jedes Teammitglied die Aufgaben, die es übernehmen wollte. Dabei waren große Hämmer, wie „Coaching Clinic konzipieren und durchführen“ als auch kleine Sachen wie „Sponsoren auf die Webseite bringen“. Wir besprachen Herausforderungen, generierten neue Ideen, trafen Entscheidungen im Team. Die Zeitabstände unserer Treffen variierten und waren abgestimmt auf die jeweiligen Phasen. In der letzten Woche vor der Konferenz trafen wir uns täglich. Die Motivation im Team war hoch und alle zogen an einem Strang.

Dann waren wir soweit. Die Agile World fand statt und es lief alles in allem sehr gut. Einen Großteil unserer Ziele hatten wir erfüllt, und auch aus den nicht erfüllten hatten wir einiges gelernt.

In einer Retrospektive mit allen Beteiligten sammelten wir nach dem FLAP-Prozess (Future considerations, Lessons learned, Accomplishments, Problem Areas) Feedback zur Agile World und leiteten die ersten Schritte ab. Mit den Vorbereitungen der nächsten Agile World starten im September, so dass wir nicht wieder in so einen Zeitdruck geraten ????.

(Sabine) Ich bin sehr glücklich mit dem Ergebnis und dem tollen Team! Da ich selbst nur begrenzt Zeit einbringen konnte, war ich sehr froh, dass das Team so selbständig und eigenverantwortlich gearbeitet hat. Besonders schön war, dass wir unseren Erfolg in einem richtigen Biergarten feiern konnten – endlich mal wieder face-to-face nach der langen Corona-Pause.

Fazit:

Agile Methoden sind für unterschiedliche Anwendungsfelder nützlich und lassen sich gut übertragen. Mit der entsprechenden Erfahrung sind wir in der Lage, das agile Toolkit dem Kontext angemessen zu nutzen und anzupassen. Die Rolle des Product Owners und Scrum Masters sind dabei wertvoll, um das Produkt voranzutreiben und Struktur und Teamgeist zu fördern.

Es ist Zeit für Wandel – auch bei improuv.

hedi.buchner — Mon, 05 Oct 2020 15:05:12 +0000

Vor knapp eineinhalb Jahren, am 1. Februar 2019, haben wir hier in unserem Blog schon mal einen ähnlichen Beitrag gepostet:

Wir, Jens und Hedi, haben gemeinsam mit Krishan (aka. Christoph Mathis) die neue/alte Geschäftsführung gebildet, nachdem eine unserer Gründerinnen, Angelika Drach, in den Ruhestand ging.

Heute gibt es wieder eine Veränderung: Krishan hat sich zum 1. Oktober 2020 aus dem operativen Geschäft und der Geschäftsführung von improuv zurückgezogen. Er bleibt weiterhin Gesellschafter und Visionär – und damit eng mit improuv verbunden. Wir, Jens und Hedi, führen die Geschäftsführung von improuv fort.

Wir möchten an dieser Stelle einen kurzen Rückblick und dann auch einen Blick nach vorne wagen.

In den letzten eineinhalb Jahren haben wir sehr viel von Krishan gelernt. Mehr als in allen Jahren davor, weil wir die Chance hatten, teilweise sehr intensiv zusammenzuarbeiten.

Krishan hatte seit jeher viele Rollen bei improuv inne:

Angefangen als Gründer und Unternehmer, ist und war eine seiner Lieblingsaufgaben strategische Arbeit, visionäre Ideen entwickeln und Innovationen zum Leben zu erwecken.

Aber nicht nur konzeptionelles Denken ist eine von Krishans Leidenschaften. Er ist ganz klassisch ein Macher und hat in vielen Fällen das Konzept des Minimum Viable Products gelebt. Und dann weiterentwickelt - basierend auf dem Feedback unserer Kunden.

Krishan hat ein ungeheuer breitgefächertes Wissen und die Fähigkeit, abstrakteste Konzepte miteinander zu verknüpfen und daraus neue Modelle zu bilden. Die Kombination mit seiner Neugierde, die ihn immer wieder dazu bringen, aus seinem riesigen Netzwerk Communities zu bilden, haben improuv geprägt und zu dem Unternehmen gemacht, das es heute ist.

Ohne Krishan gäbe es improuv als Firma von Querdenkern, mutigen Coaches und leidenschaftlichen Agilisten nicht. Wir wollen wachsen, lernen und neue Möglichkeiten ausloten – wir wollen neue Ideen entwickeln und experimentieren – wir wollen den Status Quo in Frage stellen, und den Menschen und unsere Kunden in den Mittelpunkt.

Das Gute ist, wir können weiterhin unsere inspirierenden Diskussionen zu Agilität und adaptiven Organisationen im Rahmen eines Agile Think Tanks weiterführen - nur werden wir sie in Zukunft wohl eher an den Flaucher oder nach Italien verlegen müssen ;).

Und wir werden auch weiterhin gemeinsam an neuen Produkten und Dienstleistungen arbeiten, die unsere Kunden auf ihrem Weg in Richtung Business Agility empowern. Wir sehen uns dabei auch in Zukunft als Katalysator für die zielgerichtete Entwicklung von Menschen und Systemen: Unsere Themen sind Enablement und Empowerment.

Lieber Krishan, vielen Dank für Deine Energie, Kreativität und Inspiration.

Agile Tuesday Dezember – Agile in Marketing & Sales

christian-braun — Tue, 01 Dec 2020 09:17:00 +0000

Aufgrund der aktuellen Situation findet der Agile Tuesday nicht im Hofbräuhaus statt, sondern als Zoom Meeting.
Wir schicken euch die Einwahldaten am 08.12. via Xing-Benachrichtigung gegen 17:00 Uhr direkt zu. Bitte beachtet, dass Ihr diese Benachrichtigung bei einer Anmeldung am 08.12. nach 17:00 Uhr nicht mehr erhaltet. Auf Anfragen bzgl. der Zugangsdaten während des Events können wir leider nicht eingehen.

Hier geht´s direkt zum Xing-Event

Agile in Marketing & Sales: Mit Kanban und Flight-Levels zum erfolgreichen Launch!

Ein Hersteller von Hausgeräten plant mit einem völlig neuen Produkt einen neuen Markt zu erobern. Hierfür setzt er ein hochklassiges Team aus >20 Marketing & Sales-Professionals auf, die im Hintergrund mit mehreren Agenturen zusammenarbeiten. Schnell treten Probleme in diesem hochkreativen Umfeld auf: Werden wir das alles bis zum Produkt Launch schaffen ? Was sind unsere Prios? Wer macht eigentlich was? Wie bekommen wir Abhängigkeiten und Konflikte in einer Welt von funktionalen Silos (Website, Campaign, Sales etc.) in den Griff? Auf unserer Lernreise haben wir sehr gute Erfahrungen mit dem Flight Levels-Modell von Dr. Klaus Leopold gemacht. Auf unterschiedlichen Levels konnten wir erfolgreich Kanban und Scrum anwenden um Transparenz, Planbarkeit und am Ende einen erfolgreichen Produkt Launch erzielen.

Wir freuen uns unsere Erfahrungen in dieser hoch interaktiven Session gemeinsam mit Euch zu teilen und kontrovers zu diskutieren!Viele Grüße
Euer Agile Tuesday Team

Remote und interaktiv. Bring Your Own Beer ;-)

Agile Tuesday November am 10.11. – Remote und Agile Leadership

christian-braun — Sun, 01 Nov 2020 09:19:00 +0000

Aufgrund der aktuellen Situation findet der Agile Tuesday nicht im Hofbräuhaus statt, sondern als Zoom Meeting.
Wir schicken euch die Einwahldaten am 10.11. via Xing-Benachrichtigung gegen 17:00 Uhr direkt zu. Bitte beachtet, dass Ihr diese Benachrichtigung bei einer Anmeldung am 10.11. nach 17:00 Uhr nicht mehr erhaltet.

Hier geht´s direkt zum Xing-Event

Remote Leadership – was haben Remote Leadership und Agile Leadership gemeinsam? – mit Hedi Buchner

Der zweite Lockdown ist da. Und selbst wenn wir insgeheim alle gehofft haben, dass alles bald wieder „normal“ wird – normal ist und bleibt erstmal arbeiten mit Abstand. Das bedeutet Zusammenarbeit, die auf Vertrauen, Verlässlichkeit und Accountability basiert. Hört sich irgendwie bekannt an, oder? Aber was mache ich da eigentlich als Führungskraft? Vor der gleichen Aufgabe stehen auch Kolleginnen, die mit agilen Teams und Organisationen arbeiten und diese führen. Ich werde ein Modell für Agile Leader vorstellen und mit Euch erarbeiten, wie es sich auf die Remote Situation anwenden lässt.

Wir freuen uns auf Euch!

Viele Grüße
Euer Agile Tuesday Team

Remote und interaktiv. Bring Your Own Beer ;-)

Agile Tuesday am 13.10.: Agile Tuesday Oktober – Spiral Dynamics in der LV 1871 – ein Erfahrungsbericht

christian-braun — Thu, 01 Oct 2020 08:21:00 +0000

Aufgrund der aktuellen Situation findet der Agile Tuesday nicht im Hofbräuhaus statt, sondern als Zoom Meeting.
Wir schicken euch die Einwahldaten am 13.10. via Xing-Benachrichtigung rechtzeitig direkt zu.

Hier geht´s direkt zum Xing-Event

Agile Tuesday Oktober – Spiral Dynamics in der LV 1871 – ein Erfahrungsbericht

Die Lebensversicherung von 1871 a.G. – kurz LV 1871, ein mittelständischer Lebensversicherer mit Sitz in München, setzt schon seit etlichen Jahren auf agile Methoden und Frameworks. Im Zuge unserer Transformationsreise haben wir in den letzten Jahren auch zunehmend begonnen, die kulturellen Aspekte von Agilität zu betrachten und unser Handeln danach auszurichten. In einem kurzen Impuls stellt Oliver Fischer, Organisationsentwickler und Agiler Coach bei der LV 1871, vor, was das Graves-Kulturmodell bzw. Spiral Dynamics ist, gibt eine kurze Einordnung von Agilität in Spiral Dynamics und schließt mit Beispielen ab, wie die LV 1871 Spiral Dynamics in der Praxis nutzt.

Wir freuen uns auf Euch,

Viele Grüße,

Oliver und euer Agile Tuesday Team

Remote und interaktiv. Bring Your Own Beer ;-)

Agile Tuesday am 08.09.: „Transforming the world of work - wie wir nachhaltige Änderungen bewirken können“

christian-braun — Tue, 01 Sep 2020 08:22:00 +0000

Aufgrund der aktuellen Situation findet der Agile Tuesday nicht im Hofbräuhaus statt, sondern als Zoom Meeting.
Wir schicken euch die Einwahldaten am 08.09. via Xing-Nachricht rechtzeitig direkt zu.

Agile Tuesday – "Transforming the world of work - wie wir nachhaltige Änderungen bewirken können“

Ich finde Veränderungen echt schwierig. Bei persönlichen Veränderungen kämpfe ich gegen meine innere Schweinehündin und die Macht der Gewohnheit. Corona hat mich gelehrt, dass das Verhalten einer ganzen Gesellschaft sich innerhalb kurzer Zeit ändern kann. Aber sind diese Änderungen auch nachhaltig?

Diese Frage stellt sich auch bei agilen Veränderungsprozessen in Organisationen. Als Teil einer Organisation trage ich Mitverantwortung dafür, dass Veränderungen langfristig zu Verbesserungen führen. Nachhaltige Agilität heißt für mich, auf Veränderungen nicht nur zu reagieren, sondern sie anzustoßen und mitzugestalten. Und damit beginne ich am besten bei mir selbst. Ich habe kein erprobtes Patentrezept und möchte daher mit euch in die Diskussion gehen, damit wir gemeinsam von unseren Erfahrungen lernen können.

Wir freuen uns auf Euch,

Viele Grüße,

Sabine und euer Agile Tuesday Team

Remote und interaktiv. Bring Your Own Beer ;-)

Agile Tuesday am 14.4. - Nail It Before You Scale It (Zoom Meeting)

christian-braun — Wed, 01 Apr 2020 08:26:00 +0000

Agilität lebt von Feedbackschleifen. Während die kontinierliche Verbesserung bzgl. Prozess in den Retros gut funktionieren kann, sehe ich nur äußerst selten, dass auch das Produkt nennenswert adaptiert wird. Es ist traurigerweise so, dass alles, was wir aus Lean Startup oder Design Thinking nutzen könnten, nach Projektstart kaum noch stattfindet.

Vor 3 Jahren habe ich (Sebastian Heglmeier) in einem Vortrag von Jeff Patton ein einfaches, lustiges und vor allem wirkungsvolles Modell kennengelernt. Ich verwende es seitdem ständig, wenn ich über Risikomanagement auf Produktebene rede, wenn ich einen Door Opener brauche, um Experimente zu wagen und Annahmen nochmal zu überprüfen statt stur vor sich hinzubasteln.

Und darum gehts in dieser Session. Remote und interaktiv. Bring Your Own Beer ;-)

Bei Interesse bitte eine Email an sigrid.hoffer-wehselau@improuv.com schreiben - Sie erhalten dann rechtzeitig die Einwahldaten.

Von der Online Session zur Lernreise: Fortbildung in Zeiten der Pandemie

jens — Thu, 03 Dec 2020 11:56:14 +0000

Als mein Handy am Nachmittag des 29. Februars wieder Netzabdeckung bekam, ahnte ich noch nicht, dass die drei Nachrichten auf meiner Voicebox die Vorboten eines Umbruchs waren, wie ich ihn bisher nicht erlebt hatte. Glücklicherweise hatten meine Frau, mein Sohn und ich die Faschingsferien nicht genutzt, um wie in vorigen Jahren in Tirol alpin Ski zu fahren, sondern wir waren zum Langlaufen in eine Selbstversorgerhütte in einem abgelegenen Seitental hinter Bayerisch Zell gegangen, weitab von jeder Funkabdeckung. Und so hatte ich nicht mitbekommen, wie die Kollegen eine Stornierung nach der anderen entgegennehmen mussten. Zwölf Tage später war improuv im Homeoffice und alle Trainings für die nächsten drei Monate waren storniert - mit ungewissen Aussichten für die Zeit danach.

Wir standen exakt vor der Situation, die wir mit unseren Kunden in Trainings und Workshops immer wieder diskutiert hatten: Agilität bedeutet, schnell auf Veränderungen von außen reagieren zu können. Nun, die Veränderung war da. Ohne Vorwarnung traf sie auch uns unvorbereitet. Trainings sind normalerweise der stabile Pfeiler unseres Geschäfts. Termine werden oft sechs Monate im Voraus vereinbart, und zumindest die Zertifizierungstrainings sind auch inhaltlich eher stabil. Probleme in der Logistik sind normalerweise der größte Störfaktor, wenn Paketdienste Sendungen zwei Wochen lang durch ihre Zentren kreisen lassen, statt sie rechtzeitig zu liefern.

Nun war dieses Geschäft binnen zwei Wochen in die chaotische Domäne gerutscht. Und existenziell bedroht. Würde sich improuv als agil genug erweisen, diese Bedrohung in eine Chance umzuwandeln?

Die kurze Antwort auf die Frage lautet: Ja, wir haben es geschafft. Die wesentlichen Zutaten dafür waren Teamarbeit und enge Kommunikation, vertrauensvolle Zusammenarbeit mit unseren engsten Kunden, schnelle Lieferung neu konzipierter Live-Online-Trainings und die Bereitschaft alle ausgetretenen Pfade neu zu denken. Das passt nicht nur zufällig gut zu den vier Werten des Agilen Manifests.

Ich möchte hier aber nicht in die Details der folgenden Wochen eingehen, sondern über den Wandel schreiben, der sich heute, neun Monate nach diesem Einschlag immer stärker herausbildet. Irgendwann wird es wieder ein Leben ohne Infektions- und Lockdown-Gefahr geben, aber ein "Zurück in die Vergangenheit" wird nicht stattfinden. Stattdessen sehen wir immer klarer, wie eine Nach-Corona-Trainingswelt aussehen könnte.

Virtuelle Lieferung

Da ist zum einen der offensichtliche Wandel hin zum Live-Online-Training. Wir wissen mittlerweile, wie man auch über das Internet Trainings so gestalten und takten kann, dass sie dennoch spannend und unterhaltsam bleiben und die Teilnehmer*Innen voranbringen (Hier könnt Ihr einen internen Erfahrungsaustausch verfolgen). Noch immer bekommen wir zuverlässig nach jedem Training das Feedback "Ich hätte nie gedacht, dass ein Online Training so viel Spaß machen kann". Es wird für uns immer klarer, dass Online Trainings nicht nur ein Notbehelf in der Pandemie sind, sondern gekommen sind, um zu bleiben.

Das bedeutet nicht, dass die "guten alten" Präsenztrainings ausgedient hätten: In den kurzen Phasen in denen wir unseren Kunden beide Formen anbieten konnten, haben sich etwa 50% für Präsenztrainings entschieden. Stellt man dann noch in Rechnung, dass die Vorliebe für Online Trainings oft pandemische Gründe hatte, bleibt ein Potenzial von vielleicht 20-30% von Teilnehmer*Innen, die vor allem die Vorteile von Online Trainings sehen: Man muss nicht anreisen, es lässt sich besser in die Berufsabläufe integrieren und gerade in internationalen Organisationen ist die Arbeit mit Headset und Videofenster ohnehin tägliche Routine. Zudem ist der logistische Aufwand deutlich geringer, zumindest wenn die technische Infrastruktur einmal etabliert ist.

Was geringe Fixkosten ermöglichen

Das eigentliche Potenzial von Online Trainings liegt unseres Erachtens aber gar nicht darin, die klassischen Zwei-Tages-Trainings anders zu liefern. Das eigentliche Potenzial liegt darin, dass die geringeren "Fixkosten" neue Trainingskonzepte erlauben. Statt des großen Trainings, das alle notwendige Lernziele in zwei Tage presst, werden kleine Häppchen von ein oder zwei 90-Minuten Blöcken zu speziellen Themen angeboten. Unser Angebot zu Online Retrospektiven ist ein erster Vorgeschmack, womit wir in den nächsten Monaten rechnen. Die Teilnehmer*Innen können solche Häppchen deutlich besser in ihre Tagesplanungen integrieren und die Hürden zur Teilnahme sind deutlich geringer.

Auch im Zertifizierungsbereich sehen wir erste Tendenzen in diese Richtung: Die Scrum Alliance hat das bisher zweitägige "Certified Agile Leader I" Programm in drei eintägige Module aufgespalten, die man sich je nach eigener Situation zusammenstellen kann. Ob diese Häppchen langfristig nur eine weitere Option für Trainings bilden werden, oder die klassischen zwei- bis fünftägigen Trainings verdrängen werden, ist unseres Erachtens noch nicht absehbar.

Es geht um Fähigkeiten

Verschiebt sich ein wesentlicher Teil der Trainings auf kleinere Häppchen, entsteht ein weiterer Trend, der bereits vor Corona sichtbar war: Diese Häppchen können auf Dauer nicht alleine für sich stehen, sondern müssen aufeinander aufbauen und es den Teilnehmer*Innen erlauben, sich individuelle Pfade zusammenzustellen. Zu Ende gedacht führt dies hin zu kompletten Lernreisen, die über Monate oder sogar Jahre laufen. Gerade im Inhouse Bereich stellen wir zunehmend auch Lernreisen als Kombination aus klassischen Trainings, Live-Online-Trainings, Kohortenarbeit und individuellen Coachingangeboten zusammen, die individuell auf die Bedürfnisse der Kunden zugeschnitten sind. Hier zeigt sich ein allgemeiner Trend in der Personalausbildung: Weg von den punktuellen Trainings hin zum systematischen Aufbau von Fähigkeiten. Die Grenze zwischen Training über Mentoring hin zum Coaching wird dadurch fließend, nicht nur in der Ausbildung der Führungskräfte.

Ob dieser Aufbau von Fähigkeiten innerhalb oder außerhalb von Zertifizierungsprogrammen geschieht, ist eine individuelle Entscheidung der Kunden und steht nicht mehr am Anfang

Noch sind die zugrundeliegenden Geschäftsmodelle unerprobt und wenn es an die wirtschaftlichen Details geht, sieht das Verhandlungsergebnis oft genug doch wieder recht konventionell aus. Wir rechnen aber nicht damit, dass das in fünf Jahren noch immer so ist.

Die Experten starten langsam die Diskussion über ein Ende der Pandemie und eine Rückkehr zu dem Leben zuvor. Für das Trainingsgeschäft ist aber klar, dass es keine solche Rückkehr geben wird. Es ist einmal wieder Zeit für einen Wandel.

Chatblog: Der Scrumguide 2020

jens — Fri, 11 Dec 2020 10:34:28 +0000

Seit November gibt es eine neue Version des Scrum Guides und seit dieser Woche auch die offizielle deutsche Übersetzung. Aber was bringen die Veränderungen? Und wie sind sie eigentlich gemeint? Im heutigen Chat-Blog unterhalten sich zwei unserer Certified Scrum Trainer über ihre Sicht auf die Änderungen.

Jens: Hallo Sabine, Ihr habt gestern schon mal kräftig Champagner getrunken! Was war der Anlass?

Sabine: Ooh, merkt man mir das noch an? Na, so wild war es nicht, bei mir ein Gläschen Rotwein, bei anderen nur Tee oder Wasser. Anlass war die erfolgreiche Übersetzung des Scrum Guides 2020. Daran haben wir mit einem kleinen Team gearbeitet und uns besonders gern Sonntag nachmittags dazu getroffen.

Jens: Der neue Scrum Guide hat ja drei Jahre auf sich warten lassen. Ich habe so meine eigenen Gedanken zu den Veränderungen, aber mich interessiert erstmal Deine Meinung: Champagner, oder doch eher Leitungswassser?

Sabine: Ob der neue Guide die Welt erheblich verbessern wird, wird sich zeigen. Unterm Strich halte ich die Version 2020 für eine Verbesserung. Es gibt ein paar Neuerungen, die aus meiner Sicht in die richtige Richtung gehen. Ganz oben auf meinem persönlichen Wunschzettel stand die Produkt-Vision. Diese Wunschliste existiert übrigens wirklich, jeder kann dort was eintragen. Die Vision gibt es zwar jetzt nicht, dafür aber immerhin ein Produkt-Ziel.

Was bringt das Produkt-Ziel?

Jens: Gerade beim Produkt-Ziel bin ich mir gar nicht so sicher! Der PO war ja bisher eher so die Schnittstelle in die “böse” Business-Welt. Jetzt hat Scrum damit gebrochen und angefangen, sich auch nach “vorne” in der Wertschöpfungskette zu orientieren. Geht dadurch nicht eher ein wenig Gestaltungsspielraum verloren? Und wenn ja, was gewinnt man dadurch?

Sabine: Man gewinnt Alignment. Es entsteht der Blick auf das “Große Ganze”, der dem gesamten Scrum Team hilft, gemeinsam dafür Verantwortung zu übernehmen. Und zu erkennen, welchen Beitrag jede:r einzelne Developer:in dazu leistet. Die Einführung der Accountabilities anstelle der Rollen ist eine weitere Änderung, die in diese Richtung geht: Kein Development Team mehr, das Aufträge vom PO ausführt, sondern gemeinsame Accountability (Ergebnisverantwortung) des Scrum Teams, jeden Sprint ein wertvolles Increment zu erzeugen.

Jens: Da bin ich absolut bei Dir: Die Gesamtverantwortung des Teams halte ich auch für eine Kernidee bei Scrum, und wenn die Einführung der Accountabilities dazu beiträgt, finde ich das toll. Aber lass uns noch ein wenig bei dem Produkt-Ziel bleiben. Mein Problem ist: Ich habe viele Produkt-Visionen gesehen und viele Storymaps, Business Model Canvasses und ähnliches, die die Aufgabe erfüllen sollen, einen Business-Kontext herzustellen. Aber wer oder was ist ein Produkt-Ziel?

Sabine: Ein Produkt-Ziel ist ein Business-Ziel, SMART. Im Gegensatz zu einer Produkt-Vision, die eher un-SMART und fuzzy sein kann.

Jens: Oder sein sollte. ;-) Ist ein Produkt-Ziel dann so etwas wie ein Objective plus Key Result?

Sabine: Ja, so könnte man das übersetzen. Ich habe das Fehlen eines übergeordneten Ziels immer als Manko gesehen. Es sah so aus, als ob das Product Backlog aus dem Nichts entsteht. Diese Lücke haben wir ja dann in unseren PO-Trainings mit unterschiedlichen Tools gefüllt, wie du ja schon geschrieben hast. Jetzt ist dieses übergeordnete Ziel auch im Guide verankert. So ergibt auch das Sprint-Ziel mehr Sinn, als Schritt in Richtung des Produkt-Ziel.

Die Rückkehr der Commitments

Jens: Das führt uns zu meinem persönlichen Highlight: Der Einführung von Commitments, die jeweils Artefakten zugeordnet sind. Also dem Product Backlog das Produkt-Ziel, dem Sprint Backlog das Sprint-Ziel und dem Increment die Definition of Done. Das finde ich einfach sehr elegant!

Sabine: Ja, das ist eine schöne Struktur, die man sich leicht merken kann. Das Commitment war ja früher (vor 2017) schon mal drin als Teil des Sprint Plannings. Es ist rausgeflogen bzw. durch “Forecast” ersetzt worden. Viele (ich nicht) haben das bedauert, weil dadurch Verbindlichkeit verloren gegangen sei. Die können sich jetzt besonders freuen.

Jens: Da gehöre ich eher Deiner Fraktion an: Ich kann mich erinnern, schon Mitte der Nullerjahre mit Simon Roberts über das Commitment auf die Sprint-Planung gestritten zu haben - und dabei von ihm gelernt zu haben, dass es ja schon damals um das Sprint-Ziel ging, nicht um die ausgewählten Items. Ich halte aber Mangel an Verbindlichkeit für kein praktisch relevantes Problem - nach meiner Erfahrung wollen gute Teams liefern.

Für mich ist der zentrale Gewinn die zusätzliche Bedeutung, die drei Commitments nun bekommen. Nach meiner Erfahrung sind Sprint-Ziel und Definition of Done die Stiefkinder in den meisten Teams.

Nicht mehr nur Software

Sabine: Das bringt mich zu der grundsätzlichen Frage, welche Auswirkungen Änderungen im Scrum Guide auf die Praxis haben. Die Definition of Done war schon immer da, trotzdem wurde sie in der Praxis oft nicht streng eingehalten.

Zur praktischen Anwendung habe ich den Eindruck, dass der neue Guide noch weniger konkrete Anleitung gibt, als es beim letzten der Fall war. Hinweise, wie etwas umzusetzen ist, sind kaum noch vorhanden. Die Interpretation erfordert aus meiner Sicht einiges an Erfahrung.

Jens: Hm, ein wichtiger Punkt! Der Erfolg von Scrum beruhte meines Erachtens auf seiner relativen Einfachheit und der praktischen Umsetzbarkeit, gerade im Vergleich zu Extreme Programming (da musste man schon eine Menge können, um mitspielen zu dürfen). Also nicht dass XP nicht praktisch umsetzbar gewesen wäre, aber eben nur mit technischem Können. Wenn Scrum sich jetzt Richtung “eleganter akademischer Methodik” bewegt, könnte das schwierig werden. Aber sind dafür nicht auch wir Trainer:innen da?

Sabine: Zum einen sollte durch den neuen Guide Scrum noch unabhängiger von Software-Entwicklung werden. Schon in der 2017-Version war nicht von Software die Rede. Dass man ohne solide technische Kenntnisse wie XP mit Scrum gute Software entwickeln könne, war und ist ein gefährlicher Irrglaube. Das schlanke Framework verführt zu diesem Irrglauben. Ich lasse in meinen Trainings die Teilnehmer:innen brainstormen, was zu Scrum gehört, was nicht, und was sie zusätzlich noch können und wissen sollten, damit am Schluss was Wertvolles herauskommt. Und ja, genau darauf hinzuweisen, welche Lücken es gibt und wie man die agil füllt, ist eine der Aufgaben von uns als Trainer:innen bzw. Coaches.

Jens: Die Öffnung Richtung Hardware (back to the roots…) und auch Organisationsentwicklung ist offensichtlich und auch für mich ein echter Gewinn. Wir machen ja zum Teil schon spezifische Scrum-Master und Product-Owner-Kurse für Hardwareentwicklung.

Noch ein anderes Thema, wo ich Bauchweh habe: Es gibt keine Selbstorganisation mehr (schnüff!). Stattdessen wird nur noch von Selbst-Management gesprochen. Warum das denn?

Abschied von der Selbstorganisation?

Sabine: Die offizielle Begründung ist, dass Selbstorganisation bedeutet: das Scrum Team entscheidet das Wer und das Wie. Bei Selbstmanagement entscheidet es das Wer, Wie und auch das Was. Selbstmanagement ist also mehr Entscheidungsfreiheit im Scrum Team. Ich persönlich finde Selbstmanagement klarer, vielleicht auch weil er nicht so inflationär gebraucht wird wie Selbstorganisation. Den Begriff trifft man an unterschiedlichsten Stellen, in biologischen, sozialen und anderen Systemen, und immer ist die Bedeutung etwas unterschiedlich.

Jens: Da kommen wir jetzt in eine Grundsatzdiskussion rein. Ich sehe gerade den Reiz von Selbstorganisation darin, dass es ein universelles Prinzip unserer Welt ist, das überall Anwendung finden kann. Aber Du hast natürlich recht, dass es gerade im agilen Bereich sehr inflationär - ich möchte fast sagen - missbraucht wird. Es wird mit Autonomie, Demokratie, Anarchie oder Managementfeindlichkeit verwechselt. Da haben wir offensichtlich die letzten zwanzig Jahre keine gute Arbeit geleistet, das zu erklären.

Sabine: Selbstorganisation findet als Default-Verhalten halt immer statt, wenn niemand sie verbietet oder einschränkt. Ist es wirklich das, was Organisationen wollen? Wir sprechen in unseren Leadership-Trainings ja ausführlich darüber, dass Selbstorganisation Führung benötigt, um Fokus zu setzen und Alignment zu gewährleisten.

Jens: Und deshalb bin ich sehr glücklich: Endlich ist der “Servant Leader” gestorben! Juhu!

Sabine: Ja, es ist für mich ein weiteres Highlight, dass der:die Scrum Master:in jetzt ein:e echter Leader:in mit Accountability für die Effektivität des Scrum Teams ist und nicht “nur” ein Servant Leader! Damit wird die Rolle aufgewertet, und das wird auch Zeit.Viele Organisationen zweifeln an, dass ein:e Scrum Master:in überhaupt notwendig ist. Die Frage für mich ist, wie wir die Notwendigkeit noch klarer machen können.

Jens: Ein wenig Sorge habe ich ja, dass jetzt die “Scrum Faschisten” übernehmen, aber vielleicht hilft es ja auch, dass Scrum Master:innen mehr wertgeschätzt werden. Ich habe mit dem Servant Leader immer Probleme gehabt, weil ich ihn außerhalb der Scrum-Welt nicht gefunden habe und mir damit der Anknüpfungspunkt zu modernen Führungsansätzen gefehlt hat.

Der Punkt mit den Doppelpunkten

Eine letzte Frage: Warum hast Du mir beim Schreiben eigentlich immer Doppelpunkte:innen eingefügt?

Sabine: Jaaa, das ist das wirklich revolutionär Neue zumindest in der deutschen Übersetzung. Sie ist jetzt gegendert. Wir hatten im Übersetzungsteam eine Gender-Beauftragte und stehen geschlossen hinter diesem Ansatz. Am Anfang erschien es uns noch etwas aufgesetzt, aber mittlerweile haben wir uns komplett daran gewöhnt, und es ist mir, wie du merkst, bereits in Fleisch und Blut übergegangen. Ich hoffe, dass das für meine Kolleg:innen bald auch zur Selbstverständlichkeit wird :-).

Jens: Also gefühlt habe ich in meinen öffentlichen Trainings mittlerweile fast so viele Frauen, wie Männer. Auch da tut sich was.

Sabine: Dann besteht ja die Hoffnung, dass wir bald endlich eine weitere weibliche Certified Scrum Trainerin im deutschsprachigen Raum bekommen. (Ceterum Censeo…)

Es ist 0,5 Grad vor 12 – Mit Agilität gegen den Klimawandel

Sabine — Fri, 08 Jan 2021 13:47:08 +0000

Alle reden von Corona - der Klimawandel ist scheinbar in den Hintergrund gerückt. Auch wenn Corona dringlicher erscheint, dürfen wir das Klima nicht auf die lange Bank schieben: um die Ziele des Pariser Klimaabkommens zu erreichen, können wir uns nur noch 0,5 Grad Erwärmung leisten. Ich habe im letzten Jahr mein persönliches Klimaprojekt im privaten Bereich durchgeführt und mich dabei gefragt, welche Wirkung ich darüber hinaus erzielen kann. Wie kann ich meine Fähigkeiten als agile Coachin und meine Kontakte im Sinne des Klimas einsetzen? Wie kann ich mich weiter vernetzen, um zu beeinflussen und beeinflusst zu werden? Dieser Blog-Artikel ist ein erster Schritt dazu.

Langfristiges Denken und Agilität - ein Widerspruch?

Der agile Management-Vordenker Steve Denning bezeichnet in seinem Buch “The Age of Agile” die Ausrichtung eines Unternehmens weg von der internen Hierarchie hin zum Kund:innenennutzen, also von der Innensicht zur Außensicht, als Paradigmenwechsel. Die Bewältigung der Klimakrise und anderer Nachhaltigkeitsthemen erfordert aus meiner Sicht einen weiteren Paradigmenwechsel: die Außensicht muss von den Kunden auf ganze soziale, politische und ökologische Systeme erweitert werden, wodurch die Komplexität steigt.

Gleichzeitig müssen wir wieder langfristig denken. Bei der agilen Planung propagieren wir kurze Zyklen, damit wir möglichst bald ein Feedback von Kund:innen und Nutzer:innen zu Annahmen und Produktneuigkeiten bekommen. Sehr häufig beschränkt sich die Planung auf den kurzen Zeitraum eines Sprints von etwa zwei Wochen. Man hat vielleicht noch das nächste Release oder MVP (Minimum Viable Product) im Blick, das alle drei bis sechs Monate geplant ist. Bei den Zeiträumen, die für Klimaeffekte zu berücksichtigen sind, reden wir nicht von Wochen oder Monaten, sondern von Jahrzehnten und Jahrhunderten und Jahrtausenden, da Klimaänderungen vor allem durch träge Komponenten wie Ozeane und die Biosphäre bestimmt werden. Das sind Zeiträume, die nicht nur den Aktionsradius unserer demokratisch gewählten Politiker:innen deutlich überschreiten. Unser menschliches Gehirn, das auf das Erkennen kurzer Kausalketten optimiert ist, hat generell damit so seine Probleme.

Wenn wir heute unseren Stromverbrauch reduzieren, wird sich das relativ schnell auf den CO2-Gehalt in der Atmosphäre auswirken - aber erst sehr viel später auf die Höhe des Meeresspiegels. Zum Glück gibt es Modelle, die diese Zusammenhänge verlässlich vorhersagen können. Dadurch wird es möglich, Indikatoren für die Wirkung unseres Handelns in kurzen, agilen Zeiträumen zu finden. Wir haben kein Erkenntnis- sondern ein Umsetzungsproblem - und ein Verdrängungsproblem, gekoppelt mit Gefühlen der Überforderung und Ohnmacht. Der Ohnmacht kann man entgegentreten indem man Aktionen auf kleine, greifbare Schritte herunterbricht. Nachhaltige Agilität bedeutet für mich: langfristig denken - kurzfristig handeln.

Konkret können wir:

Als Führungspersönlichkeiten und Mitarbeitende in einer Firma eine nachhaltige Unternehmensstrategie entwickeln und Unternehmenskultur und Arbeitsweisen entsprechend anpassen.
Als Produktverantwortliche Klimaziele unserer Produkte genauso ernst nehmen wie Business-Ziele.
Als (agile) Coaches und Individuen den eigenen CO2-Fußabdruck reduzieren, informiert sein, Bewusstsein schaffen, Einfluss nehmen.

Die aktuelle Lage beim Klimawandel

Corona hat gezeigt, wie schnell sich Menschen als Experten fühlen und glauben, es an Kenntnis mit jedem Virologen aufnehmen zu können - oder aber auf Fake News und Behauptungen hereinfallen und Fakten verleugnen. Wir können dazu beitragen, Halbwissen, Bauchgefühl und dadurch verursachte Ängste durch Fakten zum Klimawandel zu ersetzen und in gangbare Schritte und Aktionen herunterzubrechen, die von einem großen Teil der Wissenschaft geteilt werden. Gute und verlässliche Quellen sind das Deutsche Klimakonsortium (DKK) oder der Intergovernmental Panel on Climate Change (IPCC).

Das DKK fasst die fünf Kerninfos zum Klimawandel so zusammen:

Er ist real.
Wir sind die Ursache.
Er ist gefährlich.
Die Fachleute sind sich einig.
Wir können noch etwas tun.

Die Konzentration von Kohlendioxid und Methan, die die Ursache für den schädlichen und menschengemachten Treibhauseffekt ist, hat seit Beginn der Industrialisierung dramatisch zugenommen durch Verbrennung der fossilen Energieträger Kohle, Erdöl und Erdgas (CO2) sowie durch die intensive Landwirtschaft (Methan).

Die Lufttemperatur hat sich seit der vorindustriellen Zeit bereits um 1 Grad Celsius erwärmt, in Deutschland sogar um 1,9 Grad. Das Tempo des Temperaturanstiegs nimmt zu. Das Meer- und Festlandeis schmilzt, der Meeresspiegel steigt, die Ozeane versauern, Wetterextreme wie Dürren, Stürme und Starkniederschläge nehmen zu, Ernteerträge sinken. Auch in Deutschland sind diese Effekte zu beobachten, z.B. durch Veränderungen in der Pflanzen- und Tierwelt und gestiegenes Waldbrandrisiko.

Mit Hilfe von Klimamodellen ist es möglich, die reale Klimaentwicklung zutreffend vorherzusagen. Bei ungebremsten Emissionen könnte bis Ende des Jahrhunderts die Erwärmung im weltweiten Durchschnitt mehr als vier Grad Celsius betragen. Auf dem UN-Klimagipfel von Paris im Jahr 2015 wurde beschlossen, dass der globale Temperaturanstieg auf „deutlich unter zwei Grad Celsius“ gegenüber dem vorindustriellen Niveau begrenzt werden soll, möglichst sogar auf 1,5 Grad. Das sind nur noch 0,5 Grad mehr als jetzt! Setzt sich der bisherige Erwärmungstrend fort, so könnte diese Grenze jedoch bereits in gut einem Jahrzehnt überschritten werden. Selbst alle Zusagen für Emissionsminderungen, die bisher von den Regierungen gemacht wurden, genügen lediglich für eine Begrenzung der Erwärmung auf rund 2,8 Grad. Daran ändern auch die kurzzeitigen Verringerungen der Treibhausgas-Emissionen während der Covid19-Pandemie nichts. Dennoch birgt die Pandemie Chancen: eine kohlenstoffarme Erholung könnte 25 % der Emissionen einsparen, die für 2030 erwartet werden (Emission Gap Report 2020).

Auch wenn es zweifellos eine große Herausforderung ist: Schnelle und drastische Minderungen der Treibhausgas-Emissionen sind möglich, das zeigen zahlreiche Studien und auch praktische Erfahrungen. Viele der dafür notwendigen Technologien existieren und sind teilweise bereits unter den heutigen politischen Rahmenbedinungen finanziell konkurrenzfähig.

Was wir tun können...

...als Unternehmen

Viele Unternehmen tragen aufgrund ihrer Geschäftspraktiken zu Umweltproblemen bei, sie besitzen jedoch auch die Macht und die haben Möglichkeiten, eine Wende in die Wege zu leiten. Der Druck zu derartigen Veränderungen wächst durch das gesteigerte Umweltbewusstsein von einzelnen Führungskräften, Kund:innen, Mitarbeitenden und der Gesellschaft, Investor:innen und verschärften Vorgaben. Es entstehen neue Chancen, die nach einer Umfrage der Londoner Non-Profit-Organisation Carbon Disclosure Project (CDP) mit 2,1 Billionen US-Dollar als doppelt so hoch beziffert werden wie die Risiken. Dennoch stellt Deloitte in einer Studie fest, “dass die meisten europäischen Unternehmen die absehbaren Auswirkungen des Klimawandels noch nicht ausreichend berücksichtigen und entsprechende Anpassungsmaßnahmen ergreifen”.

Wie eine agile Transition ist auch dieser Wandel vor allem eine Frage der Kultur und des Mindsets. John Elkington, Vordenker auf dem Gebiet der Unternehmensverantwortung und des nachhaltigen Kapitalismus, schreibt: “Grundsätzlich haben wir ein fest verdrahtetes kulturelles Problem in Wirtschaft, Finanzen und Märkten. Während CEOs, CFOs und andere Unternehmensführer Himmel und Erde in Bewegung setzen, um sicherzustellen, dass sie ihre Gewinnziele erreichen, gilt das Gleiche nur sehr selten für ihre Ziele in Bezug auf Menschen und Planeten.” Hier sind die Eigentümer und Führungskräfte gefragt. Wir brauchen einen Systemwandel, der nach agilen Prinzipien geführt und durchgeführt werden kann:

Den “Purpose” und die Vision des Unternehmens mit Nachhaltigkeit in Einklang bringen. Dies ist für viele Mitarbeitende ein wichtiger Faktor für die Identifikation mit ihrem Unternehmen und damit für ihre Motivation sich einzubringen.
Emissionsziele und die Strategie zu ihrer Erreichung definieren. Die Ziele werden aus einer Bewertung der klimabedingten Risiken (z.B. Unterbrechung von Lieferketten) und Chancen (z.B. Kostenreduktion durch verbesserte Energieeffizienz) hergeleitet.
Ein Backlog erstellen mit Maßnahmen, die nach ihrer Wirkung auf die CO2-Emissionen bewertet wird.
Eine Umgebung für die Motivation (materielle und nicht-materielle Anreize), Befähigung und Ermächtigung für funktionsübergreifende Teams schaffen, die an der Umsetzung des Backlogs arbeiten.
Kennzahlen zur Messung und Steuerung der Klimawirkung etablieren und transparent machen, z.B. in Form eines Nachhaltigkeitsberichts oder leichtgewichtiger (Gemeinwohl-Bilanz, ClimatePartner).
Aus Erfahrungen lernen. Unterschiedliche Vereinigungen helfen dabei, dass Unternehmen sich untereinander vernetzen und ihr Klimaengagement sichtbar machen können, wie z.B. Wirtschaft pro Klima, Stiftung 2 Grad.

Ein Beispiel ist das Berliner Unternehmen Ecosia, das den Deutschen Nachhaltigkeitspreis 2021 gewann. Ecosia ist eine ökologische Suchmaschine, die ihre Werbeeinnahmen nutzt, um Bäume zu pflanzen. Wie bei allen Suchmaschinen wird auch bei Ecosia durch die Suche nach bestimmten Begriffen Werbung angezeigt. Mit jedem Klick auf diese Werbung verdient das Unternehmen Geld, wodurch alle 0,8 Sekunden ein Baum gepflanzt werden kann. Den aktuellen Stand kann man jederzeit auf der Webseite nachsehen. Im Moment sind es gerade 117.319.214. Wenn ihr diesen Artikel lest, sind schon wieder etliche dazugekommen. "Wir sind ein normales Unternehmen, aber wir sind nicht dazu da, um Shareholder reich zu machen", sagt Christian Kroll, der Gründer von Ecosia. Kroll sagt auch, dass er nicht das höchste Gehalt in der Firma bekomme: "Ich bin nicht mal im oberen Drittel". Aber man versuche marktübliche Gehälter zu zahlen, auch wenn Google-Mitarbeiter in Berlin sicher das Dreifache bekommen. "Wir wolle gute Leute haben, die für das brennen, was Ecosia macht".

… als Produktverantwortliche

Apple, Facebook, Google und HP betreiben ihre Rechenzentren mindestens zur Hälfte mit klimafreundlichem Ökostrom. Hingegen setzen Amazon, Netflix, Pinterest und Spotify weiterhin auf Kohle- und Atomstrom.

Bei einer ethischen agilen Produktentwicklung werden nicht nur Ziele für Kundenzufriedenheit und Geschäftserfolg definiert, sondern auch für Nachhaltigkeit. Dabei wird der gesamte Lebenszyklus des Produktes einbezogen, also etwa reduzierter Stromverbrauch bei der Herstellung, Verpackung, Transport, Betrieb und Recycling.

Wer dabei vor allem an physikalische Produkte denkt, ist vielleicht von den folgenden Fakten genauso geplättet wie ich:

Die ICT (Information and Communications Technology)-Industrie könnte bis 2025 20% des gesamten Stroms verbrauchen und bis zu 5,5 % der weltweiten Kohlenstoffemissionen ausstoßen. Das wäre mehr als jedes Land außer den USA, China und Indien.
Die Internetnutzung in Deutschland produziert jedes Jahr so viel CO2 wie der gesamte Flugverkehr. Und die Menge könnte sich in den nächsten zehn Jahren verdoppeln. Weltweit produzieren IT-Geräte und -Anwendungen 800 Millionen Tonnen CO2 pro Jahr - das entspricht in etwa den gesamten Treibhausgas-Emissionen Deutschlands.
Das Abspielen von Youtube-Videos verbraucht jährlich ungefähr so viel Strom wie das schottische Glasgow, immerhin eine Stadt mit 600 000 Einwohnern.
Die 2008 versendeten 62 Billionen Spam-Mails haben nach einer Studie von MacAffee 33 Milliarden KWh Strom verbraucht. Das ist soviel, wie 2,4 Millionen Haushalte pro Jahr verbrauchen.
Das gesamte Bitcoin-Netzwerk verbraucht mittlerweile mehr Energie als Österreich oder Kolumbien.

Digitalisierung ist also nicht die Lösung des Klimaproblems, sondern kann es sogar verschlimmern. Da ein Großteil der agilen Produktentwicklungen mit Digitalisierung in Verbindung steht, besteht hier die Notwendigkeit und die Möglichkeit, Nachhaltigkeitsaspekte wie andere nichtfunktionale Anforderungen zu berücksichtigen (zum Beispiel über User Stories oder eine Definition of Done).

… als Agile Coach

Als Coaches haben wir Zugang zu Führungspersönlichkeiten und Produktverantwortlichen, Teams und Unternehmen und können Einfluss ausüben. Unser Selbstverständnis verbietet es, unseren Klient:innen ein Thema wie Klimawandel aufzudrängen, wenn sie es nicht selbst auf der Agenda haben - aber wir können es auf unserer Agenda haben und Möglichkeiten nutzen, es einzubringen, z.B. bei der Auftragsklärung, oder bei Gesprächen über Werte.

Der Klimawandel ist ein komplexes Problem. Agile Coaches können mit Komplexität und Unsicherheit umgehen und wissen, wie wir ihnen mit systemischem Denken, interdisziplinären Teams und adaptiver Planung zu Leibe rücken können. Agile Coaches sind bewandert in Methoden und Praktiken für Transitionen und Veränderungen - und können diese für einen klimafreundlichen Wandel einsetzen. Letztendlich können wir entscheiden, wie wir mit unseren Klient:innen zusammenarbeiten, und mit wem wir zusammenarbeiten.

Wenn wir andere authentisch zu einem Wandel bewegen wollen, müssen wir zuerst unser eigenes Bewusstsein schärfen und unser eigenes Verhalten verändern. Ein Vorbild für mich ist der Agile Coach und Certified Scrum Trainer Henrik Kniberg, den viele wahrscheinlich durch seine Videos (Spotify Engineering Culture, Product Owner in a Nutshell) kennen. Henrik ist aber auch Mitbegründer von GoClimateNeutral und hat dazu ebenfalls ein Video erstellt. Diese Organisation lässt Interessent:innen ihren aktuellen CO2-Fußabdruck ermitteln und auf Basis des Ergebnisses eine monatliche Gebühr zahlen. Dieses Geld wird in Klimaschutzmaßnahmen investiert, die von unabhängigen Organisationen verifiziert wurden. Also ein moderner Ablasshandel? Eine Studie belegt, dass Kompensationen den Ausgleich von schwer vermeidbaren Emissionen ermöglichen, was insgesamt zu mehr Klimaschutz führen sollte.

… als Individuum

Jeder Mensch trifft für sich eine Entscheidung, welche Werte er verfolgt und welchen Raum er welchen Themen in seinem Leben einräumt. Ich tendiere manchmal zu missionarischem Eifer, bin mir aber bewusst, dass ich nur einen einzigen Menschen verändern kann - mich selbst. Ich fühle mich verantwortlich als Mutter. Die “Fridays-for-Future”-Generation fragt zu Recht, wieso unsere Generation dabei zusieht, wie wir munter auf eine Katastrophe zusteuern. In Deutschland konnten wir bislang die durch das Klima verursachten Problem noch verdrängen, aber auf meinen (ökologisch unkorrekten) Reisen habe ich die vermüllten Strände in Vietnam gesehen, die verpestete Luft in chinesischen Großstädten eingeatmet und in Neuseeland den schmelzenden Gletschern nachgetrauert.

Ich beteilige mich seit 16 Monaten an GoClimateNeutral, und zusammen mit den 6500 anderen Mitgliedern haben wir so 472.000 t CO2-Emissionen ausgeglichen. Ich habe meine Heizung erneuert, meinen Gefrierschrank entsorgt, moderne Energiesparlampen installiert, Ecosia als Suchmaschine benutzt, Fleisch weitestgehend von meinem Speiseplan gestrichen und auch vor Corona schon keine Dienstreisen mehr per Flugzeug gemacht. Kleine, relativ leicht durchzuführende Schritte reduzieren Komplexität und sind der beste Weg zu neuen Gewohnheiten (s. BJ Foggs, Tiny Habits). Ich kann noch viel mehr tun. Daher ist mein Guter Vorsatz für 2021:

mehr über den Klimawandel lernen,
mich mit anderen vernetzen und austauschen, z.B. durch meine Mitgliedschaft bei der Climate Coaching Alliance,
das Thema Klima in mein Portfolio als Agile Coach aufzunehmen und meine Leidenschaft dafür weiterzutragen.

Danke an Kerstin Hofstetter, Peter Jetter, Felix Canditt und Lukas Canditt für Feedback und inspirierende Ideen. Danke, dass ihr meine Leidenschaft teilt und unterstützt.

Das 3x3 des Coachings – Teil 1: Praktiken für Individuen

Sabine — Mon, 22 Feb 2021 17:05:29 +0000

In diesem Artikel stelle ich exemplarisch drei Coaching-Praktiken für Individuen vor, die du als Führungspersönlichkeit oder Coach einsetzen kannst, um Selbstorganisation zu ermöglichen.

Der Führungsstil hat sich gewandelt: die Führungsrolle des 21. Jahrhunderts ist nicht mehr die des Experten oder Machers, sondern die des Coaches. So geben Leader Unterstützung auf eine Art und Weise, die neue Energie, Innovation und Engagement bei Mitarbeitenden, Teams und Organisationen freisetzt. Coaching wird immer mehr zu einem integralen Bestandteil einer Lernkultur - eine Fähigkeit, die gute Leader auf allen Ebenen entwickeln und einsetzen müssen.

Coaching ist zunächst einmal eine Frage der Haltung: Sie basiert auf der Überzeugung, dass die Coachees kompetent, kreativ und vollständig sind und nicht durch Coaches ‘repariert’ werden müssen. Zum anderen ist es aber auch sinnvoll, eine Reihe von Praktiken und Tools zu beherrschen, die man als Coach einsetzen kann. Solche Tools möchte ich vorstellen, und zwar für das Coaching von Individuen, Teams und Organisationen. Natürlich gibt es noch viel mehr tolle Praktiken, aber dieses 3x3 ist aus meiner Erfahrung ein guter Start.

Die Praktiken für Individuen und Teams bewegen sich ganz bewusst eher im Lösungsraum als im Problemraum. “Reden über Probleme lässt die Probleme wachsen. Reden über Lösungen lässt die Lösungen wachsen” (Steve de Shazer, dem Mitbegründer der Lösungsfokussierten Kurztherapie). Beim Coaching auf Organisationsebene ist es sinnvoll, das System zu analysieren und nach Problemen in Strukturen und Prozessen zu suchen, die ein Hindernis für die Menschen und Teams darstellen können, die in dem System arbeiten sollen.

Starke Fragen - Powerful Questions

Sinn und Zweck:

Fragen sind ein wichtiges Werkzeug für Coaches. Starke Fragen helfen der Coachee dabei, ihr Problem oder ihr Ziel aus einer anderen Perspektive zu betrachten. Dadurch kommen sie auf neue Gedanken und Einsichten. Fragen sind die Grundlage für viele weitere Coaching-Praktiken.

So geht’s:

Starke Fragen sind offen, können also nicht mit Ja/Nein beantwortet werden. Hier ist eine generelle Reihenfolge von Fragewörtern, mit denen man möglichst starke Fragen einleiten kann:

Warum / Wozu
Wie
Was
Wer, Wann, Wo
Ja/Nein-Fragen

Beispiele:

Was gefällt dir oder begeistert dich an diesem Vorhaben?
Warum ist das wichtig für dich?
Was ist das Ziel?
Wie ist es dazu gekommen?
Was hast du schon versucht?
Was brauchst du dazu? Wie kann ich dich unterstützen?
Welche anderen Ideen, Gedanken, Gefühle hast du dazu?
Was würde passieren, wenn du nichts tust?
Kannst du mir ein Beispiel dafür geben?
Kannst du mir mehr darüber sagen?
Was noch?
Was wirst du als nächstes tun?

Tipps und Stolperfallen:

Eine große Schwierigkeit für Coaches ist, dass sie oft schon eine Lösung für das Problem der Coachee im Sinn haben. Gerade für Führungskräfte, die es gewohnt sind, Probleme selbst zu lösen, ist es eine Herausforderung, sich zurückzuhalten und das Denken der Coachee zu befördern. Mit der eigenen Lösung im Kopf können Fragen dann suggestiv sein. Beispiel: “Was würde passieren, wenn du mit XY über dieses Thema sprichst?” Besser: “Wer könnte dir bei der Lösung dieses Problems helfen?”
Es geht nicht darum, dass du als Coach das Problem verstehst! Je mehr du dich in die Probleme der Coachee hineindenkst, desto eher wirst du in Versuchung sein, sie auch zu lösen. Daher stelle lieber Fragen, die auf die Zukunft ausgerichtet sind. Statt “Was genau ist passiert?” besser: “Was sollte deiner Meinung nach das nächste Mal passieren, wenn es zu einer ähnlichen Situation kommt?” Aus der Hirnforschung (s. z.B. David Rock, “Your Brain at Work”) ist bekannt, dass das Denken an Lösungen eher zu neuen Einsichten führt als das Wälzen von Problemen.
Formuliere die Frage einfach und direkt, und erkläre sie nicht. Wenn die Coachee sie nicht verstanden hat, wird sie schon nachfragen.
Stelle die Fragen in einem Tempo, das es der Coachee erlaubt, nachzudenken und zu reflektieren, und dann erst zu antworten. Halte die Stille aus, auch wenn es dich viel Selbstbeherrschung kostet. Je länger die Coachee nachdenkt, desto stärker war wahrscheinlich die Frage.
Sei dir bewusst über den Unterschied zwischen “Warum” und “Wozu”? Die Frage nach dem Warum zielt in die Vergangenheit, auf das Problem. Die Frage nach dem Wozu zielt in die Zukunft, auf die Lösung.

Referenz:

Powerful Questions (powerful-questions.com)

Zuhören

Sinn und Zweck:

Zuhören ist eine Kunst. Oft sind wir eher auf Reden eingestellt, oder wir sind mit unseren Gedanken bei uns und nicht beim Coachee.

So geht’s:

Die Beschreibung der folgenden drei Level hilft dabei, sich darüber bewusst zu werden und die Fähigkeit zu entwickeln, den richtigen Level für eine Situation einnehmen zu können.

Level 1: Der Fokus liegt auf dir selbst. Wenn du auf Stufe 1 zuhörst, achtest du eigentlich auf die Stimme in deinem Kopf - und nicht auf die Coachee. Du denkst zum Beispiel über die nächste brillante Frage, die du stellen könntest. Oder an deinen eigenen Lösungsvorschlag, den du der Coachee gern präsentieren würdest. Oder daran, wie du diesen Impuls zurückhalten kannst. Oder an das bevorstehende Gespräch mit deinem Chef…
Level 2: Der Fokus liegt auf der Coachee. Du bist neugierig und interessiert und zeigst dies durch deinen Gesichtsausdruck, Kopfnicken oder “kommunikatives Grundgrunzen” (“Aha”, “Hmmm”...). Du hörst auch auf das, was zwischen den Zeilen ausgedrückt wird. Du reagierst aus der Perspektive der Coachee, zum Beispiel indem du das, was du wahrgenommen hast, mit eigenen Worten wiedergibst. Diese Art des Zuhörens schafft Vertrauen. Die Coachee fühlt sich ernst genommen und verstanden.
Level 3: Der Fokus liegt auf der Energie. Du nutzt alle deine Sinne und nimmst mehr auf als die gesprochenen Worte. Du achtest auf Körpersprache, den Tonfall und die Atmosphäre im Raum. Du nutzt deine Intuition und traust ihr, dass du damit die richtigen Fragen zum Nutzen deiner Coachee finden wirst. Nicht ganz einfach, wenn das Coaching remote stattfindet...

Tipps und Stolperfallen:

Viele halten sich für gute Zuhörer, sind aber hauptsächlich auf Level 1 unterwegs. Mach dich darauf gefasst, dass das bewusste Achten auf die unterschiedlichen Level an diesem Selbstbild rüttelt ;-)
Zuhören auf Level 2 und 3 erfordert, dass du dich nicht von deinen eigenen Gedanken ablenken lässt. Nicht immer ist das möglich, zum Beispiel wenn du selber gerade in einer schwierigen Situation bist. Achte daher auf deine eigenen Gefühle.
Ein Trick, sich selbst dazu zu bringen, sich auf die Coachee zu konzentrieren: wiederhole innerlich wörtlich alles, was die Coachee sagt. Damit schützt du dich vor Ablenkung.
Du kannst auf unterschiedliche Weise auf deine Coachee reagieren:
- indem du das Gesagte wiederholst, mit deinen eigenen Worten (Paraphrasieren) oder den Worten der Coachee. Dadurch zeigst du, dass du den Inhalt verstanden hast, und vermeidest Missverständnisse. Eine einfache und sichere Methode, die allerdings auf der kognitiven Ebene bleibt.
- indem du in Worte fasst, welche Gefühle du bei deiner Coachee wahrnimmst, zum Beispiel “Diese Reaktion scheint dich sehr verärgert zu haben. Ist das so?” Oder: “Wenn du darüber sprichst, merke ich dir deinen Enthusiasmus richtig an!” Dadurch ermutigst du deine Coachee, sich weiter zu öffnen, und verhilfst ihr zu tiefergehenden Erkenntnissen.

Referenz:

Laura Withworth, Co-Active Coaching: New Skills for Coaching People Toward Success in Work and Life

Aktives Zuhören – Wikipedia

GROW

Sinn und Zweck:

GROW ist ein einfaches, eingängiges und leicht zu merkendes Modell, nach dem man Coaching-Sitzungen gestalten kann. Es hilft dabei, die richtigen Fragen in der richtigen Reihenfolge zu stellen, so das Gespräch besser zu strukturieren und am Ende zu Ergebnissen zu kommen.

So geht’s:

Die Fragen decken folgende Bereiche ab:

G für Goal setting: Definition der kurz- und langfristigen Ziele aus Sicht der Coachee.
Beispiele für Fragen:
1. Was soll langfristig erreicht werden?
2. Was bedeutet Erfolg, und wie könnten wir den messen?
3. Was ist das Ziel der heutigen Diskussion? Ist es realistisch in der verfügbaren Zeit?
4. Was muss passieren, dass du am Ende der Session ein gutes Gefühl hast?

R für Realität: Erfassen der derzeitigen Situation (möglichst objektiv, beschreibend, ohne Bewertung)
Beispiele für Fragen:
1. Was passiert gerade? (Was? Wo? Wann? Wer? Wie oft?)
2. Wie sicher bist du, dass das so ist?
3. Was hast du bisher getan?
4. Was hält dich zurück?

O für Option: Identifizieren und Evaluieren verschiedener Strategien
Beispiele für Fragen:
1. Was könntest du tun, um die Situation zu verbessern?
2. Was noch?
3. Wie würde XY in dieser Situation handeln?
4. Ich habe eine Idee… wollen wir die gemeinsam anschauen?
  Anmerkung: Im Sinne eines gemeinsamen Brainstormings kann der Coach seine Assoziationen, Gefühle, Intuitionen, Ideen… teilen. Er sollte es jedoch der Coachee überlassen zu entscheiden, was sie davon verwertet.
W für Wille: Was will man bis wann erreichen/umsetzen?

Beispiele für Fragen:

Welche Option erscheint dir am erfolgversprechendsten?
Was genau wirst du nun tun? Wann?
Welche Hindernisse könnten im Weg stehen, und wie könnten sie überwunden werden?
Wer sollte einbezogen werden? Wer könnte unterstützen?
Wie sicher bist du auf einer Skala von eins bis zehn, dass du die vereinbarten Handlungen auch ausführen wirst?

Tipps und Stolperfallen:

Als Coach lässt du deine Coachee das Ziel definieren. Als Führungspersönlichkeit kann es sinnvoll sein, das Ziel gemeinsam mit der Coachee zu definieren.
Es sollte immer erst das Ziel definiert werden, bevor die Situation geschildert wird. Das versetzt die Coachee in einen positiven emotionalen Zustand, was die Kreativität fördert.
Es ist völlig ok, eigene Vorschläge (in Form eines gemeinsamen Brainstormings) einzubringen. Es sollte jedoch der Coachee überlassen sein, eine Entscheidung über das weitere Vorgehen zu fällen (sonst ist es kein Coaching, sondern eine Auftragserteilung).

Referenz:

John Whitmore, Coaching für die Praxis - Wesentliches für jede Führungskraft

Sabine Canditt, CST, CEC, CAL Educator

sabine.canditt@improuv.com

Hier gehts zu Teil 2: Praktiken für Teams

Das 3×3 des Coachings – Teil 2: Praktiken für Teams

Sabine — Mon, 22 Feb 2021 17:12:57 +0000

In diesem Artikel stelle ich exemplarisch drei Coaching-Praktiken für Teams vor, die du als Führungspersönlichkeit oder Coach einsetzen kannst, um Selbstorganisation zu ermöglichen.

Falls du hier einsteigst, findest du hier Teil 1: Praktiken für Individuen

Werte-Rad und Verhaltensregeln (Working Agreements)

Sinn und Zweck:

Google hat herausgefunden, dass psychologische Sicherheit der entscheidende Faktor ist, der sich auf die Effektivität von Teams auswirkt. Eine Atmosphäre der Sicherheit ermöglicht es den Teammitgliedern, ihre Meinung frei zu äußern. Oft erarbeiten sich Team Verhaltensregeln (Working agreements), um diese Sicherheit zu schaffen. Wenn diese jedoch nicht auf gemeinsamen Werten basieren, greifen sie ins Leere. Z.B. ist eine Regel für “Pünktlichkeit” ein frommer Wunsch, wenn man den Zusammenhang zum Wert “Respekt” nicht thematisiert. Daher sollte der Coach mit dem Team gemeinsame Werte erarbeiten und die Verhaltensregeln daraus ableiten. Schon die Diskussion darüber kann zu Vertrauen und Sicherheit beitragen.

So geht’s:

Startpunkt ist eine Sammlung von Werten, die vom Team in einem Brainstorming erstellt und priorisiert wurden. Dabei können organisationsweite Werte und / oder agile bzw. Scrum-Werte (Kundenorientierung, Transparenz, Flexibilität, Mut, Respekt, Offenheit, Fokus, Commitment…, in Summe 4-8) als Input genutzt werden.
Der Coach legt die Werte in Form eines Kreises auf dem Boden aus, wie ein rundes Haus mit Räumen. Bei einem Remote-Workshop können sie auch auf ein Whiteboard aufgebracht werden. Wenn ein Raum unbeschriftet bleibt, ist das ok. Vielleicht taucht in der Diskussion noch ein “vergessener” Wert auf.

Der Coach bittet die Teammitglieder, einen “Rundgang” durch die Räume zu machen. Sich in jedem Raum eine Weile aufzuhalten und sich in den Wert, den dieser Raum repräsentiert, “hineinzuspüren”. Sich dann für einen Raum zu entscheiden, der im Moment am interessantesten für sie ist.
Ideal ist es, wenn sich in jedem Raum mindestens zwei Teammitglieder befinden, denn nun wird über die Werte in diesen Räumen gesprochen. Wenn sich nur eine Person oder gar keine in einem Raum befindet, ist der Wert vielleicht nicht so wichtig für das Team? Der Coach bittet die Teammitglieder, das bei der Aufteilung zu berücksichtigen.
Die Teammitglieder, die sich in einem Raum befinden, besprechen ein paar Fragen (remote geht das über Breakout-Sessions):
1. Warum hast du dich für diesen Raum entschieden?
2. Was läuft schon gut bei uns im Team in Bezug auf diesen Wert? Was könnte noch besser laufen? Welches konkrete Verhalten sollten wir aus diesem Wert für uns ableiten? -> Verhaltensregeln
3. Was kannst du persönlich dazu beitragen, dass wir diesen Wert noch besser im Team leben?
Um die Diskussion nicht zu “verkopft” und spielerischer zu gestalten, bittet der Coach jede der Gruppen, sich zu ihrem Wert eine Geste zu überlegen, die sie synchron vorführen sollen, z.B. eine erhobene Faust für “Mut”. Jede Gruppe führt ihre Geste vor, die anderen machen sie nach. Ihr werdet erleben, dass die gemeinsame Ausführung was mit euch macht! Dann stellen sie kurz ihre Arbeitsergebnisse vor.
Der Coach fasst die Werte und Verhaltensregeln (5b) zusammen und visualisiert sie gut sichtbar. Dann stellt er sicher, dass sie auch von allen geteilt werden (z.B. Abstimmung mit dem Daumen: hoch = ich bin dabei! quer = ich habe nichts dagegen, runter = nicht mit mir!).

Tipps und Stolpersteine:

Die Methode kann genutzt werden, um organisationsweite Werte in Teams zu verankern.
Werte sind häufig sehr subjektiv. Was bedeutet zum Beispiel “Offenheit”? Dass alle Informationen offengelegt werden? Dass wir jederzeit jedem unsere Meinung offen an den Kopf werfen? Ein anderes Beispiel: Was von dem einen als Fairness gesehen wird, ist für den anderen vielleicht eine Bevorzugung, oder Gleichmacherei. Es hilft, diese Diskussion anhand von konkreten Beispielen zu führen.
Es kommt häufig vor, dass die Teammitglieder keine Verantwortung für ihre Verhaltensregeln übernehmen und sich nicht gegenseitig dafür zur Verantwortung ziehen. Ein Grund dafür kann sein, dass die Verantwortung für die Regeln beim Leader oder Coach gesehen wird. Lass dich nicht in die Rolle der Regel-Polizei drängen. Ein anderer Grund kann sein, dass das Team noch nicht mit Konflikten umgehen kann. Das ist ein weiteres Thema für dich als Coach.
Du kannst eine Retrospektive nutzen, um mit dem Team eine Selbsteinschätzung durchzuführen, wie gut sie die Werte erfüllen.

Referenz:

Google Says The Best Teams Have These 5 Things (forbes.com)

Konsent-Entscheidung

Sinn und Zweck:

Selbstmanagement erfordert es, dass viele Entscheidungen im Team getroffen werden. Das ist für Teams, die es gewohnt sind, dass der Chef für sie entscheidet, oft sehr ungewohnt. Sam Kaners Buch (s. Referenz) bietet eine Fülle von Anregungen dafür. Eine weitere Methode aus dem Bereich der Soziokratie ist die Konsent-Entscheidung. Nicht zu verwechseln mit dem Konsens, bei dem für die Entscheidung die Zustimmung aller Teammitglieder erforderlich ist. Konsent-Entscheidungen gehen schneller und sind “gut genug für den Moment”, nach dem Motto “besser eine falsche Entscheidung als gar keine”.

So geht’s:

Vorschlag: eine vorher benannte Person (zum Beispiel die, die sich am besten auskennt und die Verantwortung für die Entscheidung übernimmt) schlägt eine Entscheidung vor.
Fragen: die Teammitglieder stellen Fragen, die der Vorschlagende beantwortet (oder auch nicht).
Reaktionen: die Teammitglieder bringen ihre Meinung und Reaktionen zu dem Vorschlag vor. Der Vorschlagende hört zu, muss jedoch nicht auf alles antworten.
Erneuerter Vorschlag: der Vorschlagende hat die Möglichkeit, den Vorschlag in überarbeiteter Form erneut vorzubringen.
Einwände: die Teammitglieder überlegen sich “schwerwiegende Einwände”. Das sind nur solche Einwände, die Schaden anrichten würden, oder das Team daran hindern würden, ihr Ziel zu erreichen. Ein Teammitglied mit einem schwerwiegenden Einwand bringt eine Alternative oder Verbesserung für den Vorschlag vor. Die Einwände werden der Reihe nach durchgegangen und in einen Vorschlag umgeformt, der “gut genug” ist.
Wenn alle schwerwiegenden Einwände so bearbeitet wurden, gilt der Vorschlag als akzeptiert.

Tipps und Stolpersteine:

Diese Fragen können helfen herauszufinden, ob ein Einwand wirklich “schwerwiegend” ist:
- Würde dadurch Schaden entstehen?
- Kannst du mit dem Vorschlag leben?
- Können wir die Entscheidung ausführen?
- Können wir die Entscheidung rückgängig machen, wenn sie sich als falsch herausstellt?
Die Konsent-Entscheidung ist auch geeignet, um Entscheidungen teamübergreifend zu fällen. Dann sorgt der Coach dafür, dass alle Betroffenen die Gelegenheit haben, ihre schwerwiegenden Einwände einzubringen.

Referenzen:

Sam Kaner, Facilitator's Guide to Participatory Decision-Making

KonsenT - (soziokratie.org)

ORID (Objective, Reflective, Interpretive, Decisional)

Sinn und Zweck:

Die ORID-Methode gibt eine Struktur für effektive Reflexion und Diskussion. Sie verbreitert die Perspektive und führt zu klaren Ideen, Schlussfolgerungen und Entscheidungen.

Jeder Mensch hat Emotionen und interne Filter, die sein Denken und seine Schlussfolgerungen beeinflussen. Normalerweise laufen sie unbewusst und unsichtbar für andere ab. Es wird (oft auch aus Zeitmangel) sehr schnell versucht, zu Ergebnissen zu kommen, die dann aber nicht von allen getragen und nicht umgesetzt werden. Bei der ORID-Methode werden objektive und subjektive gleichermaßen berücksichtigt.

So geht’s:

Der Coach / Facilitator führt die Gruppe durch vier Schritte und führt ein sichtbares Protokoll über die Antworten.

O (für Objective): Sammeln von Fakten, Informationen, Erfahrungen und Wahrnehmungen. In diesem Schritt sind Interpretationen und Meinungen erlaubt. Beispiele:
1. Was weißt du darüber?
2. Was ist passiert? In welcher Reihenfolge?
3. Was hast du beobachtet? Was gehört?

R (für Reflective): Sammeln von subjektiven, positiven und negativen Eindrücken, Gedanken und Emotionen. Hier sollen Bedenken und Ängste ihren Raum finden. Sie werden nicht analysiert.
1. Beschreibe deine Reaktion (positiv oder negativ).
2. Wie ging es dir damit? Wie geht es dir jetzt damit?
3. Welche Emotionen hast du bei anderen gesehen?

I (für Interpretativ): Erkunden, welchen Sinn oder welche Bedeutung die Teilnehmenden aus den Daten ziehen. Welche unterschiedlichen Perspektiven gibt es, und was können die Auswirkungen sein?
1. Was bedeutet das für dich, die anderen, die Organisation?
2. Wie erklärst du dir das?
3. Was waren die Gründe, was waren die Folgen?
4. Was muss sich ändern?
5. Was können wir daraus lernen?

D (für Decisional): Entscheidungen treffen.
1. Was werden wir nun tun? Wer, wann, wie?
2. Was ist realistisch?
3. Welche Ergebnisse wollen wir erzielen?

Tipps und Stolpersteine:

Triff mit der Gruppe Vereinbarungen, z.B. die eigene Meinung offen zu äußern, andere Perspektiven zu respektieren, Verantwortung für die gemeinsamen Ergebnisse zu übernehmen.
Eine bestimmte Zeitvorgabe gibt es nicht, aber alles unter einer Stunde ist wahrscheinlich zu knapp. Plane genügend Zeit ein, durch alle 4 Phasen durchzukommen.

Referenz:

Brian Stanfield, The Art of Focused Conversation

Sabine Canditt, CST, CEC, CAL Educator

sabine.canditt@improuv.com

Hier gehts zu Teil 3: Praktiken für Organisationen

Das 3x3 des Coachings – Teil 3: Praktiken für Organisationen

Sabine — Mon, 22 Feb 2021 17:17:45 +0000

In diesem Artikel stelle ich exemplarisch drei Coaching-Praktiken für Organisation vor, die du als Führungspersönlichkeit oder Coach einsetzen kannst, um Selbstorganisation zu ermöglichen.

Falls du hier einsteigst, findest du hier Teil 1: Praktiken für Individuen

Wertstromanalyse

Sinn und Zweck:

Eine Wertstromanalyse ist eine wichtige Methode aus dem Lean-Bereich. Sie dient zur Analyse und Verbesserung eines Prozesses, der zur Erstellung eines Ergebnisses (Produkt, Dienstleistung) notwendig ist. Die einzelnen Schritte werden end-to-end, also übergreifend über organisatorische Einheiten, vom Ursprung bis zur Auslieferung betrachtet. Das hilft, sich nicht in lokaler Optimierung zu verlieren, sondern den Blick auf das große Ganze zu bewahren. Damit ist die Methode auch ein wertvolles Kommunikationsmittel.

Bei der Analyse wird nach aus Kundensicht wertschöpfenden (Value Adding, kurz VA) und nicht wertschöpfenden (Non Value Adding, kurz NVA) Aktivitäten unterschieden. So kann Verschwendung gefunden und beseitigt und damit die Effizienz gesteigert werden.

So geht’s:

Zur Wertstromanalyse werden Expert:innen benötigt, die die Prozesse gut kennen und Auskunft bzw. Schätzungen über die Zeiten für die VA- und NVA-Aktivitäten abgeben können.

Anfang und Ende der Prozesskette festlegen
Prozessschritte definieren
Daten zu den Prozessschritten sammeln: geschätzte Durchlaufzeiten, Häufigkeit,...
Prozessschritte nach wertschöpfend und nicht-wertschöpfend bewerten
Stellen mit großem Verbesserungspotenzial identifizieren und deutlich markieren
Soll-Prozess erstellen
Implementierungsplan für Verbesserungen aufsetzen
Relevante Kennzahlen, allen voran die Verbesserung der End-to-End-Zeit, regelmäßig messen. So entsteht ein kontinuierlicher Verbesserungsprozess unter Einbindung der Mitarbeitenden

Tipps und Stolperfallen:

Die Prozesskette kann beliebig kompliziert werden. Die Analyse ist zeitaufwändig und lässt sich nicht einfach mal zwischen Tür und Angel einschieben. Fangt an mit einem schnellen Durchlauf des gesamten Prozesses, um einen Überblick zu schaffen. Später können Details ergänzt werden.
Wichtig ist die End-to-End-Betrachtung, weil die größten Verschwendungen in der Regel nicht innerhalb eines Teams oder einer Abteilung auftreten, sondern an den Schnittstellen.
Von hinten nach vorne: so wird eher klar, welche Prozessschritte relevant sind.
Beschriebene Prozesse sind ein guter Einstieg. Man sollte jedoch nicht blind darauf vertrauen, dass die tatsächlichen Prozesse der Beschreibung entsprechen.
Es gibt Tools für die Erfassung der Wertstromanalyse. Für den ersten Schritt reichen aber eine große Wand und Post-Its (bzw. ein digitales Pendant).
Auch wenn die Wertstromanalyse aus der Produktion (Toyota) stammt, kann sie in ganz anderen Bereichen (z.B. Software-Entwicklung) eingesetzt werden.
Die Analyse kann als Grundlage für die Einführung von Pull-Systemen (Kanban) dienen.

Referenz:

Mike Rother, Learning to See: Value Stream Mapping to Add Value and Eliminate Muda

Five Why

Sinn und Zweck:

Die Methode soll die Grundursachen (“Root Causes”) eines Problems zu Tage fördern. Das hilft dabei, die richtigen Maßnahmen zur Beseitigung der Ursache zu finden und nicht an den Symptomen zu kurieren. Die Zahl Fünf ist symbolisch als Ermutigung zu verstehen, sich nicht gleich mit der erstbesten Erklärung zufriedenzugeben; es kann auch öfter oder weniger oft gefragt werden.

So geht’s:

Das Problem wird beschrieben.
Durch wiederholtes Fragen von “Warum” wird die Grundursache analysiert.

Beispiel:

Tipps und Stolpersteine:

Die Methode wurde bei Toyota für Auto-Produktionssysteme erfunden und eingesetzt, also für technische Systeme, die linear, kausal und kompliziert sind. In komplexen Umgebungen sind Ursache und Wirkung nicht mehr eindeutig oder stehen sogar in einer Wechselwirkung. Daher solltest du unter diesen Voraussetzungen keine vorschnellen Rückschlüsse aus der Analyse ziehen. Oft hat ein Problem mehrere Ursachen, für die man jeweils durch die Warum-Fragen in die Tiefe gehen kann. Dann ergibt sich ein ganzer Ursachen-Baum. Es ist sinnvoll, die Analyse mit Experten durchzuführen, die gemeinsam entscheiden, welche Äste weiterverfolgt werden sollen. Die Gruppe kann auch entscheiden, welche Maßnahmen aus dem Ursachen-Baum abgeleitet werden können, und welche Maßnahmen die größten Erfolgsaussichten haben.
Es geht nicht darum, Menschen als Ursache von Problemen zu identifizieren und Schuld zuzuweisen! Sondern die Grundursache in einem Prozess oder Prozessschritt zu finden. Wenn man diesen Prozessschritt gefunden hat, ist die Analyse beendet. Weiteres Warum-Fragen führt oft zu Standardursachen wie “zu wenig Zeit”, “zu wenig Geld”, an denen man vielleicht gerade nichts ändern kann.
Die Methode kann auch in einer Team-Retro angewandt werden.

Referenz:

Five whys - Wikipedia

Open Space

Sinn und Zweck:

Open Space ist eine Methode der Gruppenmoderation, die häufig bei Konferenzen eingesetzt wird (20-2000 Teilnehmer:innen). Sie basiert auf Selbstorganisation: die Teilnehmenden schlagen Themen vor und bilden dazu Arbeitsgruppen, die sich nach Bedarf verändern können. Open Space kann auch innerhalb von Organisationen genutzt werden, um eine bestimmte Fragestellung zu adressieren, z.B. um Ideen für Produktinnovationen zu gewinnen oder um organisationsweites Lernen voranzubringen.

So geht’s:

Regeln: im Open Space gibt es vier Prinzipien
- Wer auch immer kommt, es sind die richtigen Leute
- Was auch immer geschieht, es ist das Einzige, was geschehen konnte
- Es beginnt, wenn die Zeit reif ist
- Vorbei ist vorbei

und das Gesetz der zwei Füße: Der Teilnehmende bleibt nur so lange in einer Gruppe, wie er es für sinnvoll erachtet, also solange er etwas lernen und/oder beitragen kann.

Vorbereitung und Einladung: Besonders bei großen Veranstaltungen musst du dich als Facilitator rechtzeitig um Räume und Termin kümmern. Aus der Einladung sollten das Thema und der Zweck des Open Spaces klar werden.
Den Raum öffnen: Der Facilitator erklärt die Regeln und bittet um Vorschläge für Themen. Jeder Teilnehmende kann ein auf einen Zettel schreiben, vorstellen und um Interesse werben (seine Idee pitchen). Die Zettel werden mit dem Namen des Vorschlagenden auf einer großen Wand gesammelt (das kann auch ein elektronisches Board sein).
Marktphase: Die Themen werden wie bei einem Stundenplan Zeiten zugeordnet, so dass möglichst viele Teilnehmende sich an Gruppen beteiligen können, die sie interessieren. Dabei können zum Beispiel auch Themen zusammengelegt werden.
Gruppenarbeitsphase: die Teilnehmenden arbeiten selbstorganisiert in den Gruppen, geleitet vom Gesetz der zwei Füße. Der Vorschlagende übernimmt als Einladender die Moderation für die Arbeitsgruppe.
Abschluss: je nach Anzahl der Teilnehmenden werden die Gruppenergebnisse visualisiert, oder von dem Einladenden der Gruppe kurz vorgestellt.

Tipps und Stolpersteine:

Oft ist die Aufbruchstimmung und der Energie, die man während eines Open Spaces spürt, vorbei, wenn der Space geschlossen wird. Als Facilitator solltest du bereits vor dem Open Space klären, welche Ergebnisse entstehen und wie diese Ergebnisse gesichert werden sollen. Wie wird entschieden, welche Ergebnisse umgesetzt werden sollen, und von wem? Wird es Arbeitsgruppen geben, die die Themen weiter verfolgen?
Es ist für die Teilnehmenden manchmal ungewohnt und erscheint ihnen “unhöflich”, eine Session vorzeitig zu verlassen. Als Facilitator solltest du klarmachen, dass dies Teil des Formats ist und es kein Ausdruck von mangelndem Respekt für den Moderator dieser Session ist.

Referenz:

Open Space – Wikipedia

Jutta Eckstein, Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy: Survive & Thrive on Disruption

Welcome to Open Space! - OpenSpaceWorld.ORG

Sabine Canditt, CST, CEC, CAL Educator

sabine.canditt@improuv.com

Warum brauchen wir Scrum Master?

jens — Wed, 10 Mar 2021 15:53:47 +0000

Eigentlich ist Scrum ganz einfach: Ein paar Events, ein paar Dinge, die ein Team erstellen oder machen muss und drei Verantwortlichkeiten. Auf diesem Level ist Scrum in fünf Minuten erklärt. Trotzdem - oder vielleicht gerade deshalb - tun sich viele schwer mit der Idee des Scrum Masters. Was tut ein Scrum Master eigentlich den ganzen Tag? Und brauchen wir die Rolle überhaupt?

Scrum Master:in ist das vielleicht ungewöhnlichste Konstrukt in Scrum und damit für viele Organisationen schwer verständlich: Ein:e Scrum Master:in ist ein "true Leader", aber ohne hierarchische Funktion oder "Weisungsbefugnis", wie man das im deutschen Arbeitsrecht nennt. Ein:e Scrum Master:in trägt die Verantwortung für die Effektivität des Teams, aber ohne es anzutreiben und in der Regel auch ohne die Arbeit inhaltlich beurteilen zu können. Ein:e Scrum Master:in ist "ergebnisverantwortlich für die Einführung von Scrum", aber ohne Entscheidungsbefugnis über die Organisation.

Aus Sicht eines traditionellen Führungsverständnisses klingt das alles reichlich schräg. Scrum liegt aber Selbstorganisation zugrunde, also die Idee, dass sich Organisationen wie Organismen aus dem Verhalten aller Mitarbeiter bilden. Das ist ein völlig anderes Verständnis, als das mechanistische, aus dem frühen 20. Jahrhundert stammende Bild, dass Organisationen vom Management durch die Definition von Prozessen und deren Überwachung geformt werden. Scrum gehört damit in das - reichlich schwammige - Universum des New Work. Und in diesem Universum bekommt ein:e Scrum Master:in plötzlich eine zentrale Rolle.

Um das Konzept eine:r Scrum Master:in zu verstehen, hilft es, die Rolle einer klassischen Produktmanagerin oder Projektleiterin zu zerlegen, wobei sie in drei Tätigkeitsbereiche zerfällt:

Was wollen wir eigentlich bauen? Für wen bauen wir es und warum? Warum wird es ein cooles Produkt werden? In Scrum fallen diese Fragen in die Verantwortung des:r Product Owner:in.
Wie bauen wir das Produkt? Welche Schritte sind dafür notwendig? Wer tut was? Für diese Fragen sind in Scrum diejenigen verantwortlich, die die Arbeit auch durchführen, in Scrum Terminologie die Developer:innen.
Wie arbeiten wir zusammen? Wie können wir besser werden? Und hier hat unser:e Scrum Master:in den Auftritt. Wie die Moderatorin eines Workshops oder ein guter Sporttrainer sorgt ein:e Scrum Master:in dafür, dass das Team gut zusammenarbeitet und gemeinsam zu Höchstform aufläuft.

Und damit wäre die Frage, ob wir eine:n Scrum Master:in brauchen auch schon beantwortet: Wenn es egal ist, wie gut das Team zusammen arbeitet und ob es seine Energie in Reibungsverluste oder in das Ergebnis investiert, braucht man auch keine:n Scrum Master:in. Schließlich braucht eine Amateur-Kickergruppe auch keinen Trainer, wenn sie sich einmal die Woche auf dem Bolzplatz trifft. Wenn man aber professionell arbeiten will, zahlt sich die Investition in eine:n Scrum Master:in schnell aus.

Wie passt Führung und Selbstorganisation zusammen?

Selbstorganisation ist ein grundlegendes Prinzip unserer Welt, sie findet immer statt. Allerdings muss sie nicht die Ziele des Teams unterstützen. Vielleicht dient sie dem Team auch nur dazu, über den Zeitpunkt des Mittagessens zu entscheiden. Scrum nutzt nun Selbstorganisation gezielt, damit das Team flexibel auf Veränderungen reagieren kann. Und das passiert nicht mehr von alleine. Scrum Master werden dafür gebraucht, dass das Team seine Selbstorganisation tatsächlich in die Verbesserung des Produkts und seiner Arbeitsweise investiert, statt sie wirkungslos verpuffen zu lassen oder schlimmstenfalls für Machtspiele zu vergeuden.

Was macht ein:e Scrum Master:in den ganzen Tag?

Das hängt sehr von der Reife des Teams ab. Ist Scrum neu für das Team, wird ein:e Scrum Master:in einen guten Teil der Zeit damit zubringen, das Team an die neue Arbeitsweise zu gewöhnen. Das umfasst organisatorische Aufgaben, Trainings, Einzelcoachings, aber auch die Vorbereitung von Meetings oder Werkzeugen. Dazu zählt aber auch die Arbeit mit anderen Personen, die mit dem Team zusammenarbeiten. Das können andere Teams sein, Linienmanager:innen, Nutzer:innen und Geldgeber:innen bis hin zu Betriebsrat und Personalabteilungen. In der Scrum Terminologie sprechen wir von Stakeholdern. Sie alle müssen verstehen, wie sich ihre Rolle gegenüber einem Scrum Team verändert. Und ein:e Scrum Master:in muss die Bedürfnisse der Stakeholder verstehen und dem Team helfen, auf diese Bedürfnisse zu reagieren.

Je mehr Erfahrung ein Team und eine Organisation haben, umso breiter wird auch das Aufgabenfeld eines:r Scrum Masters:in, so wie die Aufgabe eines Sporttrainers mit zunehmender Leistungsklasse der Sportler immer anspruchsvoller wird. Konflikte im Team müssen frühzeitig erkannt und möglichst konstruktiv aufgelöst werden. Probleme technischer, fachlicher und sozialer Natur müssen erkannt werden und das Team muss dabei unterstützt und geführt werden, diese Probleme zu lösen. Und sowohl Motivation als auch Disziplin im Team müssen aufrecht erhalten werden.

Die wichtigsten Werkzeuge eines:r Scrum Masters:in sind dabei Gespräche und Workshops. Immer wieder geht es darum, Entscheidungen in Gruppen herbeizuführen. Vor allem regelmäßige Retrospektiven dienen dazu, Probleme in der Zusammenarbeit zu adressieren und gemeinsam zu lösen. Das kann innerhalb des Teams sein oder auch mit Stakeholdern oder anderen Teams.

Was passiert ohne Scrum Master?

Scrum erfordert, wie alle agilen Verfahren, vom Team hohe Disziplin. Erfahrungsgemäß haben viele Teams Probleme die nötige Disziplin aufzubringen, um sich neben dem Fokus auf ihr Produkt und die Stakeholder auch noch stetig zu verbessern. Zudem neigen wir alle dazu, Probleme klein zu reden oder ihnen auszuweichen, wie der sprichwörtliche Frosch, der angeblich nicht mitbekommt, dass das Wasser immer heißer wird, bis er verkocht (Biologen bestreiten übrigens diese Geschichte). Die Teams arbeiten dann unterhalb ihres Potenzials. Häufig nehmen Konflikte mehr und mehr Raum ein, bis das Team zerbricht. Organisationen, die sich diese Verschwendung nicht leisten wollen, investieren in gute Scrum Master:innen.

Hier geht´s zu unserem Certified Scrum Master Training

Scrum VERdichtet

tina.rieger — Wed, 17 Mar 2021 13:57:16 +0000

Letztes Jahr wurde die neue Version des Scrum Guides ins Deutsche übersetzt. Mitgewirkt hat unsere liebe Kollegin Sabine Canditt. Das Ergebnis hat (incl. Glossar) 18 Seiten. Wer soll sich sowas merken? Ich sage, das geht kürzer. Und mit Verlaub, etwas geschmeidiger kann es auch noch klingen. Besonders gut merken können wir uns Dinge, die sich reimen. Das wissen wir schon, seit wir zu Schulzeiten "Der Erlkönig" von Johann Wolfgang von Goethe auswendig lernen durften.

Also hier ist er, der verdichtete Scrum Guide zum Auswendiglernen in Reimform:

Ken und Jeff die waren hell,
entwickelten das Scrum-Modell.
Sie packten Teams in neue Strukturen,
und schafften Events mit tickenden Uhren.
Denn schlägt hier mal die Timebox zu,
dann kommt der Fokus auch im Nu.

Das Team, das ist crossfunktional,
hat alles Wissen – Ist das nicht genial?
Es arbeitet an einem gemeinsamen Ziel,
limitiert wird dabei das externe Gastspiel.

Der Product Owner, das ist nicht verkehrt,
der kümmert sich um die Maximierung von Wert.
Ein Product Backlog wird aufgebaut,
mit geordneten Stories, das ist bald vertraut.

Doch wer macht daraus Realität?
Das Wichtigste ist, sei nicht zu spät!

In kurzen Sprints gehen die Developer es an,
im Sprint Planning erstellen sie sich einen Plan.
Sprint Backlog wird er genannt,
manchmal wird auch etwas angebrannt.
Doch können wir ganz schnell reagieren,
dadurch lernen und auch experimentieren.

Im Daily tauschen wir uns aus,
wo hakt es noch, was findet Applaus.
Wir brauchen Feedback, das ist klar,
doch wie stellt sich die Lösung dar?

Zwei Events geben Möglichkeiten,
sich auf den nächsten Sprint vorzubereiten.
Im Review geht es um die Stakeholder-Sicht,
die sagen, was gut für sie ist und was nicht.
Es geht um das vorgestellte Inkrement,
ein Produkt, das bisher noch niemand kennt.

Das Inkrement haben wir uns angeschaut,
doch wie haben wir den Sprint verdaut?
Schauen wir hier auf die Zusammenarbeit,
die Retrospektive ist keine Kleinigkeit.
Je besser wir zusammen agieren,
umso leichter können wir jubilieren.

Wir wollen uns stets weiter verbessern,
und nicht die agilen Prinzipien verwässern.
Mit diesem Event ist der Sprint vorbei,
dann beginnt das Ganze für 2-4 Wochen neu.

Das klingt erstmal leicht und ist doch oft schwer,
daher gehört unbedingt ein Scrum Master her.
Er hilft die Theorie in die Praxis zu bringen,
mit Geduld und Erfahrung – so wird es gelingen.
Er ist Coach, Mentor, Trainer und Mediator,
und zugleich ein guter Kommunikator.

Empirisch betrachtet und schlank gedacht,
so ist aus drei Säulen Scrum gemacht.
Der Reim ist rum ich bin gespannt:
Ist alles jetzt von Scrum bekannt?

Hier geht´s zu unserem Certified Scrum Master Training

Warum brauchen wir Scrum Master - Teil 2

jens — Wed, 24 Mar 2021 12:11:44 +0000

Mein Blogbeitrag "Warum brauchen wir Scrum Master?" wurde lebhaft auf LinkedIn diskutiert. Oliver Fischer von der LV1871 hat ihn zum Anlass genommen, seine Kolleginnen und Kollegen zu feiern, was mich sehr gefreut hat. Dankbar war ich auch Jenny Ley-Kumar für einen Kommentar, der mich sehr zum Nachdenken gebracht hat: "[...]Nur eine Frage bleibt:" schreibt sie, "braucht es unbedingt den Titel 'Scrum Master' - oder sollte nicht jede gute Projektleitung weitgehend so arbeiten?" Mit dieser Frage möchte ich mich in diesem zweiten Teil beschäftigen.

Die schnelle Antwort auf: Nein, es braucht nicht unbedingt den Titel „Scrum Master“, um gute Arbeit zu leisten. Ich habe zu viele gute Projektleiter:innen (und schlechte Scrum Master:innen) erlebt, um zu denken, dass der Titel entscheidend wäre. So weit, so oberflächlich.

Über Kontext

Bei genauerem Nachdenken über Jennys Frage komme ich allerdings zu dem Schluss, dass ich den Kontext meines Beitrags nicht sauber gesetzt habe. Das möchte ich nachholen. Auslöser für den Beitrag war ein Muster, das wir sowohl in Trainings als auch beim Coaching immer wieder beobachten.

Besonders nett manifestierte sich dieses Muster bei einem Product Owner Trainer für den „Innovation Hub“ eines DAX Konzerns. Im Vorgespräch hatten mir meine Ansprechpartner gesagt „Wir machen zwar Scrum, aber Scrum Master brauchen wir nicht“. Wie immer ließ ich den konkreten Problemen der Teilnehmenden viel Raum. Immer wieder musste ich die Fragen mit dem Nachsatz „Dafür gibt es übrigens den Scrum Master“ beantworten, sodass die Antwort zum Running Gag wurde. Gegen Ende leiteten die Teilnehmenden ihre Fragen mit „Wir wissen, dass das eigentlich der Scrum Master tun müsste, aber…“ ein. Zumindest in dieser Firma wird der Zweck von Scrum Mastern heute nicht mehr in Frage gestellt. Dafür wurden mehrere Stellen für Scrum Master geschaffen.

In meinem Beitrag ging es also um Organisationen, die Scrum einsetzen. Die volle Überschrift hätte damit lauten müssen „Warum brauchen wir Scrum Master, wenn wir Scrum einsetzen möchten?“ Darauf hätte die Antwort eindeutig „Ja“ lauten müssen. Nicht umsonst heißt es in der neuesten Fassung des Scrum Guides „Kurz gesagt fordert Scrum, dass ein:e Scrum Master:in ein [Scrum gemäßes] Umfeld fördert“. Allerdings hat mir der Kollege vom Marketing von so langen Titeln abgeraten; nicht ohne eine unvorteilhafte Verbindung zwischen meinem Alter und Cervantes‘ Buchtiteln herzustellen…

Über Projektleitung

Das korrigiert jetzt zwar eine Lücke in meinem Blog, geht aber immer noch an Jennys Frage vorbei. Man kann die Frage ja auch umformulieren zu „Warum brauchen wir Scrum Master, wenn wir eine gute Projektleitung haben?“ Jenny hat völlig recht: Gute Projektleiter achten auch auf die Zusammenarbeit im Team. Idealerweise fördern sie auch die Selbstorganisation des Teams. Ich stelle mir dann aber die Frage: Wie gut könnten diese Projektleiter:innen erst sein, wenn sie sich vollständig auf diese Aufgabe konzentrieren könnten? Wenn sich jemand anders um die inhaltliche Gestaltung kümmern würde? Und das Team den natürlichsten aller Wege ginge und aufgrund der eigenen Qualifikation sich selbst koordinieren würde?

Der Effekt ist ähnlich dem eines gut moderierten Meetings: Auch hier gibt es eine Person, die sich ausschließlich um die Zusammenarbeit und die Gruppendynamik kümmert – und sich inhaltlich raus hält. Gerade dadurch können Moderatoren die Neutralität wahren, die es braucht, um Gruppen zu guten Ergebnissen zu führen. Sicher, jeden Tag finden Millionen unmoderierter Meetings statt, viele von ihnen erfolgreich. Wenn der Einsatz aber hoch ist, weil viele Menschen beteiligt sind, oder schwierige Konflikte behandelt werden müssen, dann gehört die Begleitung durch Moderatoren oder sogar Mediatoren zum professionellen Handwerkszeug.

Man muss diese Rolle nicht „Scrum Master“ nennen. Sie zu haben hilft aber ungemein.

Man kann übrigens noch eine grundsätzlichere Frage aus Jennys Kommentar ableiten: Muss man unbedingt Scrum einsetzen? Aber diese Frage ist einen eigenen Blog-Eintrag wert. Kleiner Spoiler: Getreu meiner Argumentation oben, lautet auch hier die generische Antwort „Nein“ – schließlich enthält die Frage das Wort „unbedingt“. Aber ganz so einfach möchte ich es mir dann doch nicht machen.

Hier geht´s zu unserem Certified Scrum Master Training

Warum das Sprint Review das wichtigste Scrum Event ist

Sabine — Thu, 01 Apr 2021 11:45:27 +0000

Was würdet Ihr als das wichtigste Event ansehen? Die meisten plädieren hier für die Retrospektive. Oder das Daily Scrum. Klar, in der Retrospektive geht es um Verbesserung, im Daily Scrum um Selbstorganisation. Alles wichtig, gerade aus Sicht der Scrum Master:in. Bei diesen Events dreht es sich hauptsächlich um die Innensicht des Teams. Ein Scrum Team ist jedoch kein Selbstzweck, sondern seine Daseinsberechtigung ist es, ein Ergebnis zu liefern und Wert für Stakeholder erzeugen. Wie gut gelingt ihm das? Um diese Außensicht geht es im Sprint Review.

Im Sprint Review diskutieren das Scrum Team und die Stakeholder über das Produkt. Diese Stakeholder gehören nicht zu den im Scrum Guide beschriebenen Rollen bzw. Verantwortlichkeiten, und vielleicht wird ihre Bedeutung daher unterschätzt. Scrum macht (im Gegensatz zum "klassischen" Projektmanagement) keine expliziten Vorgaben zum Stakeholdermanagement. Es ist eine wichtige Verantwortung der Product Owner:in, die Stakeholder einzubeziehen. Wohl der, die (in einem früheren Leben als Projektleiterin, oder in einem Advanced Certified Scrum Product Owner Kurs) mal gelernt hat, wie das geht. Oder eine Scrum Master:in an ihrer Seite hat, die sich der Bedeutung bewusst ist. Denn ohne die Unterstützung der Stakeholder kann die Product Owner:in nicht wirksam werden. Zu den Stakeholdern gehören neben den Nutzern auch diejenigen, die den Geldhahn für das Produkt öffnen oder schließen.

Unzureichende Einbeziehung von Stakeholdern kann sich im Review unterschiedlich auswirken:

das Review findet ohne Stakeholder statt. Die Developper:innen stellen sich die Ergebnisse gegenseitig vor, oder der Product Owner:in. Das sollten sie während des Sprints machen. Wozu sind sie denn sonst ständig zusammen?

das Review findet mit Stakeholdern statt, aber die sagen nichts. Haben sie das Gefühl, dass ihre Meinung wirklich interessiert und eine Wirkung hat? Hat die Scrum Master:in mit geeigneten Facilitation-Methoden dafür gesorgt, dass ein sicherer Raum für Meinungsäußerung entsteht? Ist einfach die Zeit zu knapp?

das Review fand früher mal mit Stakeholdern statt, aber jetzt kommen sie nicht mehr. Vielleicht liegt das an der Sprache des Teams: zu technisch, nicht die richtige "Flughöhe" für Stakeholder? Stakeholder nicht "abgeholt"? Im Gegensatz zu dem Scrum Team ist es nicht ihre alleinige Aufgabe, sich um dieses Produkt zu kümmern, sondern sie haben in der Regel eine Fülle von anderen Aufgaben. Oder gibt es neben dem Sprint Review andere Meetings, Steering Board Committees zum Beispiel, in denen die Stakeholder besser Einfluss nehmen können?

Das Sprint Review ist das Event zum Stakeholder Management in Scrum. Es sollte die Grundlage für Stakeholder sein zu entscheiden, ob sie das Produkt unterstützen und es ggf. weiter finanzieren. Kommunikation mit Stakeholdern sollte auch außerhalb dieses Meetings stattfinden, aber die Zusammenarbeit im Review legt eine wichtige Grundlage dazu. Es entstehen persönliche Beziehungen: Stakeholder tauschen sich mit Scrum-Team-Mitgliedern und untereinander aus. Man lernt die Sprache "der anderen" zu verstehen: Stakeholder lernen "Tech-Sprech" und Developer:innen "Business-Sprech". Man erfährt die Perspektiven der anderen aus erster Hand und entwickelt Verständnis füreinander. So kann die Product Owner:in darauf einwirken, dass Stakeholder nicht gegeneinander arbeiten, um ihre eigenen Interessen durchzusetzen, sondern miteinander an einem gemeinsamen Ziel, das auch mal Kompromisse erfordert.

In einem guten Sprint Review wird nicht nur das Increment des letzten Sprints vorgestellt, sondern über die weitere Richtung der Produktentwicklung diskutiert. Hier ein paar Tipps, wie das gelingen kann:

Das Scrum Team sollte im Sprint Review keine Überraschungen erleben, die durch bessere interne Kommunikation hätten vermieden werden können. Es kann unangenehm sein, wenn die Product Owner:in erst im Review erfährt, dass eingeplante Product Backlog Items nicht fertig geworden sind. Oder wenn die Product Owner:in den Developper:innen ein negatives Feedback zum Nutzen des Increments gibt. Solche Dinge besser bereits im Sprint klären, damit sie so schnell wie möglich behoben werden.

Die Scrum Master:in sollte die Moderation des Meetings genauso gut vorbereiten wie die Retrospektive. Gerne mit ein paar ungewöhnlichen Methoden spielen: Ein Sprint Review darf Spaß machen! Aber dabei die Zielgruppe im Auge behalten, die wir nicht vergraulen wollen. Die fünf Schritte zum Ablauf einer Retro sind auch für ein Review sinnvoll:

Set the stage: Richtig zu starten ist für ein Review noch entscheidender als für die Retro! Da sich die Teilnehmenden seltener sehen und wahrscheinlich mehr Berührungsängste haben, ist es noch wichtiger, für eine offene und vertrauensvolle Atmosphäre zu sorgen. Umgang mit negativem Feedback fällt leichter, wenn auch im Review alle der Prime Directive für Retrospektiven folgen: "Unabhängig davon was wir entdecken werden, verstehen und glauben wir aufrichtig, dass in der gegebenen Situation, mit dem verfügbaren Wissen und Ressourcen und unseren individuellen Fähigkeiten, jeder sein bestes getan hat."

Gather Data: Das ist in erster Linie das Increment. Aber auch andere Daten sind relevant, zum Beispiel zur Qualität des Produktes, zum aktuellen Release-Plan oder zur Markt- und Mitbewerbersituation. Sowohl das Scrum Team als auch die Stakeholder können dazu beitragen, dass ein möglichst umfassendes Bild des Produktes entsteht.

Generate Insight: Das ist der oft vernachlässigte Kern des Reviews. Die Scrum Master:in kann die Diskussion durch spezifische Fragen befeuern. Zum Beispiel: "Auf einer Skala von 1-10, wie beurteilt ihr den Nutzen des Increment? Was wäre notwendig, damit ihr einen weiteren Punkt auf der Skala vergeben würdet?" Je nach Anzahl der Teilnehmenden kann es sehr sinnvoll sein, Kleingruppen für diesen Austausch zu bilden.

Decide what to do: Für das Produkt-Ziel und das Product Backlog Management ist die Product Owner:in verantwortlich. Je mehr sie Stakeholder und Developer:innen in diese Entscheidungen einbezieht, desto mehr werden sie von allen gemeinsam getragen werden. Vielleicht kann das Scrum Team bereits im Review entscheiden, dass eine neue Idee in den nächsten Sprint aufgenommen wird. Vielleicht ist es notwendig, zuvor noch ein Refinement durchzuführen. Oder es wird deutlich, dass die Umsetzung bis zum geplanten Release-Datum nicht mehr machbar ist. Oder es fehlen einfach noch Informationen, um hier und jetzt eine Entscheidung zu treffen. In jedem Fall entsteht Transparenz für alle Teilnehmenden.

Close the Review: Auch ein Review braucht einen Abschluss. Es kann auch aufschlussreich sein, eine kurze Retro des Reviews durchzuführen, damit das nächste Review noch besser wird.

Um die verschiedenen Aspekte des Reviews auf dem Schirm zu haben, kann die Scrum Master:in diese Punkte explizit ansprechen:

Welche neuen Anforderungen haben wir identifiziert?

Haben sich die Prioritäten geändert?

Gibt es neue Erkenntnisse, die sich auf die Schätzungen der Product Backlog Items oder den Release Plan auswirken?

Ergeben sich Änderungen für die Architektur oder das Design des Produktes?

Was könnte besser laufen in der Zusammenarbeit zwischen Stakeholdern und Scrum Team?

Zusammenarbeit mit Kunden. Maximierung des Werts, Erfolge sichtbar machen. Transparenz, Überprüfen und Anpassen. Wenn diese Elemente einer agilen Kultur bei euch im Sprint Review stattfinden, dann ist es richtig gut!

Beim Schreiben dieses Artikels habe ich mich an die Regeln und das Glossar der deutschen Scrum-Guide-Übersetzung gehalten.

Der Stakeholder - das unbekannte Wesen

Sabine — Fri, 16 Apr 2021 14:54:50 +0000

In Scrum gibt es bekanntlich drei Verantwortlichkeiten: Scrum Master:in (SM), Product Owner:in (PO) und Developer:in. Alle anderen werden in einen großen gemeinsamen Topf geworfen: den Stakeholder-Topf. Die Bedeutung der Stakeholder wird oft verkannt. Deswegen möchte ich ihnen diesen Blogartikel widmen.

Die Definition (wikipedia): Als Stakeholder wird eine Person oder Gruppe bezeichnet, die ein berechtigtes Interesse am Verlauf oder Ergebnis eines Prozesses oder Projektes hat.

Im Scrum-Kontext denken wir dabei zuerst an die Kunden und Nutzer, um die sich ja alles dreht. Auf den zweiten Blick wird die Liste deutlich länger: Mitarbeiter, andere Teams in der Entwicklung, andere Abteilungen im Unternehmen (Marketing, Sales...), das Management, Sponsoren, Investoren, Betriebsrat, alle möglichen Subject Matter Experts wie z.B. Experten für Datensicherheit oder rechtliche Fragen, Lieferanten... Bei einem Software-Produkt vielleicht nicht so relevant, aber entscheidend bei Hardware-Produkten: wir müssen den gesamten Lebenszyklus des Produktes im Auge haben, also auch Produktion, Betrieb, Wartung, Außerbetriebnahme. Menschen, die in diesen Lebensphasen mit dem Produkt arbeiten, haben ein berechtigtes Interesse daran und sind daher definitionsgemäß Stakeholder. All diese Personen im Blick zu haben und einzubeziehen, ist eine große Herausforderung, die man am besten als Team angeht.

Stakeholder-Mythen

Mythos #1: Scrum kommt ohne (explizites) Stakeholder-Management aus.

Richtig ist: Es gibt zwar kein Kapitel zum Stakeholder-Management im Scrum Guide, der Begriff Stakeholder kommt aber dort 13mal vor. Stakeholder geben dem Produkt einen Sinn. Sie beeinflussen die Entwicklung entscheidend. Manche von ihnen haben sogar so viel Macht, dass sie über das "Go/No Go" entscheiden können, indem sie einem Vorhaben kurzerhand den Geldhahn zudrehen.

Es gibt bewährte Praktiken aus dem Projektmanagement, die sich auch auf agile Produktentwicklungen anwenden lassen:

Stakeholder identifizieren: Checklisten für mögliche Stakeholder
Stakeholder analysieren und Priorisieren: Stakeholder Map zur Einschätzung von Interesse, Einfluss, Verfügbarkeit und Einstellung zum Produkt
Stakeholder kontinuierlich einbinden: Kommunikationsplan mit Häufigkeit und Art der Kommunikation, idealer Weise durch Integration in den Scrum-Ablauf, zusätzliche Meetings und Workshops

Noch wichtiger als Praktiken sind jedoch wieder mal die Werte und Prinzipien, nach denen wir unsere Zusammenarbeit gestalten wollen: Neugierde, Respekt, Vertrauen, psychologische Sicherheit, keine Schuldzuweisungen, Offenheit, Transparenz, Feedback. Die Scrum Master:in schafft eine Umgebung, in der die Scrum-Werte beherzigt, empirisches Vorgehen verstanden und agile Praktiken gelebt werden. Das gilt auch für die Zusammenarbeit mit Stakeholdern und kann durch spezielle Training oder Workshops initiiert werden. Dabei kann man die Rechte und Verantwortlichkeiten der Stakeholder festlegen.

Mythos #2: (Nur) die PO ist für Stakeholder zuständig.

Richtig ist: Die PO hat die Aufgabe, mit dem Produkt den maximalen Wert für Stakeholder zu erzeugen. Was Wert bedeutet, kann die PO nur mit Stakeholdern gemeinsam entscheiden. Daher ist eine Zusammenarbeit von Anfang an wichtig. Es ist ganz normal, dass Stakeholder ganz unterschiedliche Interessen haben. In einer Organisation, die agile Verantwortlichkeiten lebt, hat die PO die Verantwortung, bei Interessenskonflikten Entscheidungen über das Produkt zu treffen, damit die unterschiedlichen Interessen nicht zu einer Blockade führen. Die PO hat somit im Scrum Team eine besondere Rolle und muss "empowered" sein, also die Akzeptanz und Unterstützung der Stakeholder genießen. Das sollte jedoch nicht dazu führen, dass nur die PO mit Stakeholdern redet. Dann könnte sie leicht zum Bottleneck werden. Das Thema ist viel zu wichtig, als das man es einer einzelnen Person überlassen könnte. Je besser das gesamte Scrum Team die Bedürfnisse der Stakeholder versteht, desto besser ist es in der Lage, passende Lösungen zu entwickeln.

Mythos #3: Kontakt mit Stakeholdern findet (nur) im Sprint Review statt.

Richtig ist: Stakeholder-Zusammenarbeit ist von Anfang an und kontinuierlich wichtig. Es geht schon früh los bei der Erstellung von Produkt-Vision und -Zielen, mit Innovations-Workshops, bei der Modellierung von Use Cases oder der Erstellung von Story Maps. Gute Möglichkeiten für die SM, sich als Facilitator auszutoben. Am besten ist es, gleich mehrere Stakeholder zusammenbringen, damit sie sich gegenseitig kennenlernen und verstehen. Methoden wie Design Thinking oder "Buy a Feature" (Innovation Games) kombinieren divergentes und konvergentes Denken. So entstehen neue Ideen und ausführbare Aktionen. Über die Bedeutung des Sprint Reviews als regelmäßiger "Touch Point" mit Stakeholdern könnt ihr hier nachlesen. Darüber hinaus kann es sinnvoll sein, Stakeholder auch in das Backlog Refinement oder das Sprint Planning einzubeziehen, Das Product Backlog spielt eine wichtige Rolle als Artefakt, das (laut Scrum Guide) "transparent, sichtbar und verstanden" ist - auch und gerade für Stakeholder. Dafür sorgt die PO. Zum besseren Verständnis kann sie zum Beispiel Zuversichts-Intervalle im Backlog angeben: wie schätzen wir die Wahrscheinlichkeit, das bestimmte Items im aktuellen Release umgesetzt werden können?

Stakeholder Management ist Politik

Ob wir wollen oder nicht: Stakeholder sind häufig nicht vollständig in das agile Denken und Vorgehen einbezogen und ticken eher traditionell. Sie möchten (oder müssen aufgrund ihrer Aufgabenbeschreibung) ihre Interessen durchsetzen, wenn es sein muss auf Kosten anderer. Sie stellen Fragen, die sich in einer komplexen Umgebung nicht mit Sicherheit beantworten lassen: "Wann kommt Feature XY?", "Warum dauert das so lange?", "Könnt ihr Feature Y nicht noch mit ins Release aufnehmen? Das kann doch nicht so schwierig sein!" Sie üben Druck aus und sind sich oft nicht über die Folgen im Klaren (siehe dazu meinen Blog Mythbusting: Schätzungen werden überschätzt). Sie erkennen nicht, dass auch sie durch konstruktive Zusammenarbeit einen Beitrag zum Erfolg des Produktes leisten müssen. Um mit dieser Gemengelage fertig zu werden, bewährt sich die Aufgabenteilung zwischen PO und SM: die PO konzentriert sich auf die inhaltlichen Aspekte des Produktes und auf Informationen, die für Produktentscheidungen relevant sind. Die SM hat den Blick auf die Art der Zusammenarbeit und die Atmosphäre, wirkt als Facilitator, gibt Feedback und initiiert Verbesserungen.

Stakeholder-Management ist (über)lebenswichtig

Als ob das nicht schon anspruchsvoll genug wäre, möchte ich den Blick noch erweitern. Produkte können während ihres Lebenszyklus Schaden anrichten. Die Bewältigung der Klimakrise und anderer Nachhaltigkeitsthemen erfordert die Berücksichtigung sozialer, politischer und ökologischer Systeme. Ein Unternehmen und letztendlich die gesamte Menschheit kann nur überleben, wenn wir diese Aspekte bei Produktentwicklungen berücksichtigen. Dies erfordert einen systemischen Denkansatz beim Stakeholder-Management, über die Grenzen einzelner Funktionsgruppen hinaus. Wir können mit Stakeholdern gemeinsam überlegen, welche Nachhaltigkeitsthemen für die Produktentwicklung relevant sind, welche Auswirkungen sie haben, und wie wir damit umgehen wollen: Klimaschutz, Gesundheitsschutz, Digitalisierung, Unternehmenskommunikation... Zukunftsmusik? Ja, und wir können den Wandel, der sowieso stattfindet, dazu nutzen, uns neu zu positionieren.

Hier geht´s zu unserem Certified Scrum Master Training

Mythbusting: Schätzungen werden überschätzt

Sabine — Fri, 23 Apr 2021 14:37:22 +0000

"Wie kann ich mein Team davon überzeugen, mit Story Points zu schätzen anstatt mit Manntagen?" Abgesehen davon, dass der Begriff "Manntage" zum Aufrollen meiner Fußnägel führt: ich werde diese Frage in diesem Blog-Beitrag nicht beantworten. Anstatt mich damit auseinandersetzen, wie man schätzt, möchte ich meine Gedanken teilen, wozu man schätzen sollte. Die üblicherweise genannten Gründe entpuppen sich bei genauerem Hinsehen als Mythos.

Schätz-Mythen

Mythos 1: Ein Team braucht Schätzungen, um eine verlässliche Vorhersage abgeben zu können, was es in einem Sprint schafft.

Ob ein Team einen Product-Backlog-Eintrag in einem Sprint umsetzen kann, hängt von verschiedenen Dingen ab: Ist das Item inhaltlich verstanden? Hat das Team eine Idee, wie die Umsetzung erfolgen soll? Gibt es Abhängigkeiten nach außen? Dies zu diskutieren, ist Sinn des Product Backlog Refinements und des Sprint Plannings. Ein arithmetischer Vergleich von Schätzwert und Kapazität deckt nur einen Teil dieser Aspekte ab. Vielleicht kommt das Team zu dem Ergebnis: "Dieses Item ist zu groß für den Sprint." Dann muss das Item eben weiter verfeinert werden - so lange, bis das Team die Umsetzung für möglich hält. Eine gute Praktik ist, im Refinement etwa gleich große Items zu erzeugen. Dann kann das Team ein Gefühl dafür entwickeln, wie viele dieser Items es umsetzen kann. Dies ist aus meiner Sicht der wesentliche Mehrwert einer Schätzung: sie "zwingt" das Team, sich intensiv mit dem Item zu beschäftigen und ein gemeinsames Verständnis davon zu erzeugen.

Mythos 2: Die Product Owner:in braucht Schätzungen, damit sie einen Anhaltspunkt für die Ordnung des Backlogs hat.

Schätzungen spiegeln den Aufwand und damit die Kosten eines Product Backlog Items wieder (auch wenn immer wieder diskutiert wird, ob wir nun Komplexität oder Aufwand oder Größe oder oder oder ... schätzen). Eine Kosten-Nutzen-Abwägung hört sich sinnvoll an. Dazu braucht die Product Owner:in vor allem den Nutzen. Nach meiner Erfahrung tun sich die meisten Product Owner:innen schwer damit, diesen anzugeben. Für einzelne, heruntergebrochene Product-Backlog-Einträge ist dies kaum möglich und auch nicht sinnvoll, weil der Nutzen erst durch übergeordnete komplette Features oder Epics entsteht. Wie sinnvoll ist es, Kosten-Nutzen-Abwägungen zu treffen, wenn sowohl der Nutzen als auch die Kosten reine Vermutungen sind? Vielleicht statt dessen über den Schaden nachdenken, der entsteht, wenn das Item gar nicht oder spät kommt (Cost of Delay). Oft gibt es wenige Features mit hohem Cost of Delay und viele mit geringem. Für die Product Owner:in ein klarer Hinweis, in welcher Reihenfolge Features umgesetzt werden sollten.

Mythos 3: Die Product Owner:in braucht Schätzungen, um damit einen Release Plan zu erstellen.

Ich bin der Überzeugung, dass ein Sprint-Inkrement oft zu klein ist, um wirklich Nutzen für Kunden und Stakeholder zu erzeugen. Daher bin ich ein Fan von Planungen, die über einen Sprint hinausgehen. Es gibt bewährte Möglichkeiten wie Story Mapping und Lean-Startup-Zyklen mit einem Minimum Viable Product (MVP), die darauf ausgerichtet sind, so schnell wie möglich auszuliefern. Dann erst entsteht outcome statt output und somit Kenntnis über den Nutzen. Eine auf Schätzungen basierende Release-Planung kann dagegen dazu führen, dass eine Illusion der Planbarkeit und damit der Sicherheit entsteht, die die Notwendigkeit einer schnellen Auslieferung übertüncht.

Der (verständliche) Wunsch nach Planbarkeit führt leider oft zu Machtspielchen zwischen dem (internen oder externen) Auftraggeber und der Entwicklungsabteilung. Ich habe manchmal den Eindruck, dass Termine nicht aus Notwendigkeit oder Dringlichkeit entstehen, sondern aus dem Glaubenssatz: "Ohne Druck arbeiten die Leute nicht produktiv." Das hört sich für mich verdächtig nach Theorie X an: "Der Mensch ist von Natur aus faul." Die Entwicklungsabteilung bekommt einen Release-Plan vorgesetzt oder wird genötigt, sehr frühzeitig Schätzwerte abzugeben. Sie weiß aus Erfahrung, dass realistische Schätzungen nicht akzeptiert und heftig zusammengestrichen werden. Daher baut sie verdeckte Puffer ein. Reiner Selbstschutz - aber nicht gerade eine gute Grundlage für Transparenz und vertrauensvolle Zusammenarbeit. Je mehr Politik im Spiel ist, desto schwieriger ist es, eine realitätsfernen Planung über Bord zu werfen und eine Kurskorrektur vorzunehmen. Das würde ja bedeuten zuzugeben, dass man Fehler zugeben muss! Statt dessen setzt man lieber die Entwicklung unter Druck, sich an den "vereinbarten" Termin zu halten. Die Entwickler:innen - nicht dumm - greifen in ihre Trickkiste und produzieren schnelle, aber qualitativ schlechte Lösungen. So entstehen technische Schulden, die das Problem der mangelnden Planbarkeit langfristig vergrößern. Schlimmer noch: der durch Zeitdruck entstehende Stress verhindert Kreativität und Lernen, führt zu Frustration und manchmal sogar zu gesundheitlichen Problemen.

Merke: Schätzungen sind kein Commitment! Ein aus Schätzungen erstellter Release-Plan ist ein Schnappschuss, der aufgrund der aktuell vorliegenden Erkenntnisse die Zukunft antizipiert - und der so schnell wie möglich auf Basis von realen Daten und neuen Erkenntnissen angepasst werden sollte. Das Agile Manifest lehrt uns: Es ist nicht das primäre Ziel, einen Plan einzuhalten, sondern Wert für Kunden und Stakeholder zu erzeugen. Dieser Wert hat manchmal mit dem ursprünglichen Plan herzlich wenig zu tun.

Mythos 4: Stakeholder brauchen Schätzungen, um zu entscheiden, ob und wieviel sie in eine Produktentwicklung investieren.

Oftmals sind frühe Schätzungen Voraussetzung für eine "Go/No Go"-Entscheidung und eine Budgetfreigabe. Sie werden zu einem Zeitpunkt erstellt (von einer PO, oder einem Projektleiter, oder einer anderen Management-Rolle), wo es noch gar kein Team gibt, das Expertenwissen einbringen könnte. Die Komplexität und Unsicherheit werden dabei geflissentlich ignoriert. Das ist kein agiles Vorgehen, sondern klassisches Projektmanagement und Wasserfall? Genau. Und genau so läuft es in vielen Unternehmen, in denen einzelne Teams nach Scrum arbeiten, aber die Randbedingungen alles andere als agil sind. Dazu gehören die Prozesse zur Budgetplanung, zu der es agile Alternativen gibt (s. Beyond Budgeting). Die Trennung von Planung und Ausführung ist die klassische Management-Arbeitsweise der Industrialisierung, die wir mit agilem Vorgehen eigentlich hinter uns lassen wollen. Eine sinnvollere Frage als die nach einem Schätzwert ist: "Wieviel Geld sind wir bereit zu investieren, bevor wir wirklich wissen, ob dieses Produkt nützlich ist?"

Echte Investoren für Startups agieren tatsächlich anders: Sie entscheiden, wie viel sie bereit sind, auf eine Idee zu wetten. Schafft es das Startup innerhalb eines angemessenen Anteils dieses Betrag (z.B. ein Viertel) nicht, dass Vertrauen der Investoren zu festigen, wird die Investition gestoppt - was normalerweise das Ende des Startups ist. Kann es aber aufgrund harter Daten und Fakten überzeugen, dass das Risiko geringer oder der zu erwartende Gewinn höher ist als ursprünglich gedacht, steht auch mehr Geld zur Verfügung. Und idealerweise trägt sich das Startup nach ein oder spätestens zwei Runden selbst. Die Frage lautet also nicht "Was kostet es?", sondern "Wie viel bin ich auf der aktuellen Datenbasis bereit, zu riskieren? Und reicht das aus, um höhere Sicherheit zu gewinnen?".

Schätzungen sind Verschwendung

Eine Schätzung ist eine Schätzung ist eine Schätzung... alle Schätzungen sind falsch, da sie - rein statistisch - mit 50%iger Wahrscheinlichkeit über- oder unterschritten werden. Die Erfahrung lehrt uns jedoch diese beiden Gesetze:

Parkinson'sches Gesetz: „Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht.“
Hofstadters Gesetz: "Es dauert immer länger, als man erwartet, selbst wenn man Hofstadters Gesetz berücksichtigt."

Schätzungen können also dazu führen, dass die geschätzten Tätigkeiten sich künstlich aufblähen. Und noch schlimmer: Die Schätzungen selbst - und erst recht die Planungen mit all den beschriebenen Nebeneffekten - tragen nicht zur Wertschöpfung bei und sind daher im Lean-Sinne Verschwendung. Vor gefühlten 100 Jahren, als ich noch als Prozessverbesserin in einem Großunternehmen tätig war, gab es etliche Versuche, mit Hilfe von ausgefeilten Methoden wie "Function Points" Schätzungen zu verbessern, oder "Historischen Daten" so zu erfassen, dass man zukünftige Vorhaben mit vergangenen vergleichen konnte. All das war sehr aufwändig und letztendlich um so weniger erfolgreich, je innovativer die Produkte waren.

Was also tun?

Können wir komplett auf Schätzungen verzichten und damit auch auf eine Beantwortung der Fragen: "Was kostet uns das" und "Bis wann ist Funktion X fertig"? Wir sollten uns darüber klarwerden, ob Schätzungen wirklich das geeignete Mittel sind, diese Fragen zu beantworten. Vielleicht haben wir genug Sicherheit für einigermaßen verlässliche Schätzungen. Wenn wir jedoch keine Ahnung haben, sollten wir dazu stehen. Anstatt uns gegenseitig in die Tasche zu lügen, sollten wir die Scrum-Werte "Offenheit" und "Mut" beherzigen. Und gemeinsam überlegen, wie wir die Unsicherheit in den Griff bekommen können. Die agile Antwort darauf ist:

Transparenz durch Experimente und möglichst schnelles Feedback, Inspizieren und Anpassen. Oder in der Lean-Startup-Sprache: Build-Measure-Learn.
An einer agilen Vision arbeiten, in der tolle Produkte mehr zählen als Planungen und wir der Realität mehr vertrauen als Schätzwerten.

Wenn ihr nach diesen Überlegungen immer noch der Überzeugung seid, dass Schätzungen sinnvoll für euch sind, können wir uns gern darüber unterhalten, wie man das (mit möglichst wenig Aufwand) macht .

Hier geht´s zu unserem Certified Scrum Product Owner Training

Team meint Team - Scrum Teams sind schon 300.000 Jahre alt

tina.rieger — Fri, 30 Apr 2021 12:50:40 +0000

Was haben wir eigentlich vor 300.000 Jahren gemacht? Wir sind auf Mammutjagd gegangen, um uns und unsere Familien ernähren zu können.

Um ein Mammut zu jagen, brauchte es ein gut eingespieltes Team mit Mitgliedern, die verschiedene Fähigkeiten mitbringen. Da ist der beste Fährtenleser, der beste Läufer, der beste Bogenschütze und der beste Speerwerfer. Es braucht mehr als eine Person, um ein Mammut besiegen zu können. Ein zu großes Jagd-Team kannst du nicht gebrauchen, denn dann wird es unübersichtlich. Und noch viel schlimmer: ein einziges Mammut reicht nicht aus, um alle gut zu ernähren. Dann ist es vielleicht sinnvoller, sich in zwei Gruppen zu teilen und damit die Erfolgschancen zu erhöhen.

Wir haben hier eine hochfunktionale kleine Einheit von Menschen mit demselben Ziel. Sie nutzen ihre Erfahrung, ihr Wissen, ihr Talent, ihre menschlichen Instinkte und die Kraft der Gruppe, um in der Situation erfolgreich zu sein. Und am Abend nach der Jagd sitzen alle gemeinsam am Feuer, reden darüber, lernen und legen Konflikte bei, vielleicht moderiert durch ihren Schamanen. Haben wir hier etwa eine Retrospektive mit „Scrum Master“?

Warum sollten sie das tun? Es hängt das Leben davon ab, dass die Gruppe auch in der kommenden Jagdzeit erfolgreich ist.

Ist das denn heute anders? Ok, damals war es unmittelbarer. Mammut tot = Familie satt. Heute ist es mittelbarer. Das Ziel, auf das sich ein Team committet, ergibt sich im Zusammenspiel mit den Stakeholdern, denn die sind in der heutigen Zeit die Werttreiber. Aber letztlich ist es auch heute noch Wert für das Unternehmen und natürlich für sich selbst.

Ob es Scrum Teams schon in der Steinzeit gab, weiß ich nicht, ganz sicher hießen sie nicht so. Fakt ist: in jeder Epoche, in der Menschen agieren, gab und gibt es Teams, die ein gemeinsames Ziel verfolgen. Je nach Umfeld und Situation ist eine andere Art und Weise der Zusammenarbeit hilfreich. Mal braucht es eine Einheit mit direktiver Führung und mal ein flexibles Team ohne Hierarchien. Wichtig ist zu wissen, in welchem Umfeld ihr euch bewegt und welche Anforderungen ihr meistern wollt.

Was macht Scrum Teams aus?

Scrum ist ein leichtgewichtiges Rahmenwerk für komplexe Probleme, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen zu generieren. Ein wichtiger Erfolgsfaktor ist dabei die Teamstruktur. Die Teams werden so aufgestellt, dass sie in einem komplexen Umfeld wirklich etwas bewegen können.

Was bedeutet es, ein Team im Scrum-Umfeld zu sein?

Das Scrum Team besteht aus einem Product Owner, Scrum Master und Developern. Gemeinsam sind sie üblicherweise 10 oder weniger Personen. Denn wie wir anfangs schon bei der Mammutjagd festgestellt haben: bei mehr wird es irgendwann unübersichtlich und die Zusammenarbeit verliert an Effizienz. Ist das Team größer, bilden sich automatisch kleine Untergruppen - und das wollen wir nicht.

Jeder dieser Verantwortlichkeiten hat im Team ihre eigene Wichtigkeit.

Der Scrum Master trägt dazu bei, dass die Mitglieder des Scrum Teams schrittweise in die Art der Zusammenarbeit, wie sie mit Scrum gedacht ist, hineinwachsen.

Der Product Owner ist ergebnisverantwortlich für die Wertmaximierung eines Produktes und damit für ein effektives Product Backlog Management.

Und die Developer sind die im Team, die sich zur Aufgabe gemacht haben, in jeden Sprint ein nutzbares Inkrement zu schaffen.

Was alle drei vereint, ist das gemeinsame Ziel. Zusammen sind sie für alle produktbezogenen Aktivitäten umsetzungsverantwortlich. Vom Verstehen und Erfassen der Kundenbedürfnisse bis zur Auslieferung und Betreuung des Produktes. Dazu gehört auch die Gestaltung eines geeigneten Arbeitsumfeldes. Wir gestalten alles mit, was es braucht, um gute Ergebnisse liefern zu können. Und das beginnt damit, wie wir miteinander umgehen und unsere gemeinsamen Prozesse gestalten und leben.

Wir sehen, der Fokus geht weg von der Leistung eines Einzelnen. Wenn Wert geschaffen wird, dann ist das ein gemeinsamer Erfolg. Wenn wir etwas nicht schaffen, dann ist nicht der Product Owner schuld, der falsche Anforderungen zur Verfügung gestellt hat und auch nicht das Teammitglied, das letzte Woche Urlaub hatte. Im WIR geht es darum, dass wir uns als TEAM committen, gemeinsam Wert zu schaffen. Im Scrum Team sieht und gestaltet jeder einzelne seinen Beitrag zum großen Ganzen. Deswegen ist es auch wichtig, sich dafür zu interessieren, wo die anderen im Arbeitsprozess stehen und welche Hürden zu nehmen sind. Auch ist es notwendig, selbst Lösungen zu bringen und Lösungen von anderen anzunehmen. Jeder ist gefragt, mitzudenken, proaktiv zu handeln und für das gemeinsame Team-Ziel sein Bestes zu geben.

Damit ein Scrum Team seiner gemeinschaftlichen Ergebnisverantwortung sinnvoll nachkommen kann, ist es eine hochfunktionale, geschlossene, kleine Einheit von Fachleuten ohne Hierarchien im Team. Es ist befähigt, seine Arbeit selbst zu steuern. Zudem hat es alles Wissen im Team, das benötigt wird, um in jedem Sprint Wert zu schaffen. Indem es unabhängig und interdisziplinär aufgestellt ist, muss weniger auf externe Personen zugegriffen werden, was die Wartezeit sowie Arbeitszeit reduziert und dem Team mehr Reaktionsfähigkeit verschafft.

Ich glaube, jeder von uns hat das schon erlebt: Ich stecke in einem Projekt und brauche Zuarbeit von einem Kollegen. Dieser jedoch ist gerade mit etwas anderem beschäftigt und kommt nicht sofort dazu, mir das zu liefern, was ich brauche, um weitermachen zu können. Das Projekt steht an dieser Stelle still. Vielleicht muss ich sogar mein Thema und die Dringlichkeit immer wieder bei dem Kollegen in Erinnerung bringen. Und wenn ich die Zuarbeit habe, muss ich mich selbst wieder eindenken. Genau solche Effekte sollen vermieden werden.

Ein weiterer Vorteil von interdisziplinären Teams ist die Kraft der vielen Köpfe, denn hier wird eng zusammengearbeitet und sich abgestimmt.

Jeder, der schon einmal in einem Team gearbeitet hat, kennt diesen Effekt: da steckt in einem eine Idee, die erst reift durch die ergänzenden Ansätze der Kollegen. Darüber hinaus können wir in dieser Struktur viel intensiver voneinander lernen, was für alle - vom Stakeholder bis zum einzelnen Teammitglied - gewinnbringend ist.

Um die Bedürfnisse der Kunden möglichst schnell und passend umzusetzen, arbeiten beispielsweise Product Owner und Developer ständig zusammen. Der Product Owner hat die engste Verbindung zu den Stakeholdern und kennt deren Wünsche in der Regel am besten. Die Developer können von Anfang an und am besten die Umsetzbarkeit der Wünsche beurteilen. Durch diese intensive Zusammenarbeiten kann der Product Owner sich viel präziser mit den Stakeholdern abstimmen. Auch können die Stakeholder direkt mit den Developern zusammenkommen. Egal wie, durch die intensive Zusammenarbeit aller, wird ein viel klareres Gesamtbild über das gewünschte Produkt geschaffen. Und das hilft allen Beteiligten. Dem Scrum Team bei der Umsetzung und den Stakeholdern, weil sie das bekommen, was sie wollen und vor allem oftmals deutlich schneller.

Jetzt haben wir eine kleine Reise gewagt. Lasst uns kurz nochmal zusammenfassen, was ein Team im Sinne von Scrum bedeutet:

Das Scrum Team
- ist eine geschlossene Einheit von Fachleuten, ohne Hierarchien und Untergruppen, die sich auf ein Produkt-Ziel konzentrieren
- verfügt über alle Fähigkeiten, die zur Erreichung des Produkt-Ziels benötigt werden (interdisziplinär, crossfunktional)
- besteht aus den Verantwortlichkeiten: Scrum Master, Product Owner und Developer
- ist üblicherweise 10 oder weniger Personen groß
- hat keine Teilteams und Hierarchien
- ist gemeinsam umsetzungsverantwortlich für alle produktbezogenen Aktivitäten, inklusive der Zusammenarbeit mit Stakeholdern
- verantwortet es, in jedem Sprint ein nützliches Increment zu schaffen (ergebnisverantwortlich)
- steuert seine Arbeit selbst und arbeitet eng zusammen
- unterstützt sich gegenseitig, um das Beste aus sich herauszuholen
- nutzt die Synergie vieler Köpfe und kann dadurch voneinander lernen und gemeinsam wachsen

Es klingt ganz leicht und ist doch oft schwer, denn es kommen oftmals unsere alten Muster daher.

Wie nehmt ihr euer Teamgefüge wahr?

Seit ihr informiert über die aktuellen Themen in eurem Team?

Geht ihr immer proaktiv auf andere zu, um so wenig Zeit wie möglich zu verlieren? Oder wartet ihr manchmal, mit dem Gedanken im Hinterkopf: „Das ist nicht in meiner Verantwortung“?

Wenn dieses Teamgefüge Erfolg haben soll, ist es immer wieder notwendig, dass jeder Einzelne für sich und das Team gemeinsam sein Handeln reflektiert. Das muss nicht nur in der Retrospektive passieren. Das zu fördern ist unter anderem Aufgabe des Scrum Masters. Doch letztlich bleibt es bei dem Grundsatz: Verantwortlich seid - wie immer - ihr als Team.

Was ist ein Sprint Ziel?

jens — Fri, 28 May 2021 07:53:22 +0000

"Arbeitet jemand von Euch mit Sprint-Zielen?" Wenn ich diese Frage in den Trainings stelle, melden sich selten mehr als ein oder zwei Teilnehmende. Dabei ist das Sprint-Ziel meiner Meinung nach einer der mächtigsten Hebel in Scrum.

Mit dem letzten Scrum Guide wurde es nun sogar in die völlig neue Kategorie der "Commitments" befördert. Eine solche tiefgreifende strukturelle Änderung hat es an Scrum bisher noch nie gegeben. Es wird also Zeit, sich mit dem Sprint-Ziel etwas näher zu beschäftigen.

Das Sprint-Ziel erklärt, warum ein Sprint wertvoll ist. Es geht beim Sprintziel also nicht darum, was am Ende geliefert werden soll – das steht ja schon im Sprint Backlog. Sondern es geht darum, warum dieses Ergebnis den Anwendern oder den Geldgebern gefallen sollte. Bei einer Smartphone-App würde das Sprint-Ziel zum Beispiel verwendet, um im Store anzuzeigen, was neu ist in dieser Version. Freuen sich die Anwender dann auf die neue Version und laden sie gerne herunter, war das Sprint-Ziel gut.

Aber Vorsicht: Das Sprint-Ziel ist etwas anderes, als Release Notes. Im Sprint-Ziel beschreibt das Scrum Team, was es sich vornimmt, zu erreichen. In den Release Notes, was es tatsächlich getan hat.

Über gute und schlechte Sprint-Ziele

Anhand der Version 2.0.3 der Corona WarnApp kann man das schön sehen (siehe Abb 1): Ziel dieser Version waren Check-Ins für Events per QR-Code. Der Wert eines solchen Sprints ist unmittelbar einsichtig. Man darf auch ohne Insider-Wissen vermuten, dass die Entwickler stolz darauf waren, als sie dieses zusätzlichen Puzzlestück zur Freiheit fertig gestellt hatten. Wir haben hier also einige wichtige Eigenschaften eines guten Sprint-Ziels zusammen:

Das Sprint-Ziel leistet eine klare Aussage, warum der Sprint wertvoll ist und für wen. Es ist also für die Stakeholder unmittelbar verständlich, nachvollziehbar und bewertbar.
Es bleibt wage genug, um noch auf unvorhergesehenes reagieren zu können. Welche Sonderfälle werden abgedeckt, was passt nicht mehr in den Sprint? Solange das Sprint-Ziel nicht gefährdet ist, bleibt hier durchaus noch Entscheidungsspielraum, den das Scrum Team auch während des Sprints noch nutzen kann und sollte.
Das Spint-Ziel setzt ein nutzbares Ergebnis voraus, es kann also nicht auf Kosten der Qualität erzwungen werden.

Was uns motiviert

Diese drei Kriterien entsprechen „Purpose“, „Autonomy“ und „Mastery“, laut Dan Pink den drei wichtigsten Voraussetzungen für Motivation. Das Sprint-Ziel spielt also eine wichtige Rolle dabei, das Team nicht nur zu fokussieren, sondern erzeugt intrinsische Motivation. Zumindest wenn es gut ist.

Ein Beispiel für ein wenig motivierendes Sprint-Ziel findet man ebenfalls bei der Corona-WarnApp nur wenige Wochen später: Für die Version 2.1.3 heißt es lapidar „Mit diesem Update beheben wir einen Fehler“. Als Stakeholder würde mich hier zumindest interessieren, was verändert wurde, damit dieser Fehler in Zukunft gar nicht mehr ausgeliefert würde. Und welcher Fehler überhaupt? „Testautomatisierung erweitern, um Fehlerklasse XY zuverlässig zu erkennen“ wäre da schon ein besseres Sprint-Ziel, zumindest für interne Stakeholder.

Heben Sprint-Ziele häufig nur auf die innere Qualität ab, würde ich als Scrum Master einmal eine Retrospektive zum Thema Produktqualität ansetzen. Das Scrum Team kann dann diskutieren, warum solche Sprint-Ziele notwendig sind. Wie könnte man wieder mehr Zeit auf Ziele verwenden, die dem Anwender tatsächlich einen neuen Wert schaffen? Sprint-Ziele, die sich nur mit Fehlern beschäftigen, sind für alle Beteiligten frustrierend. Sie bedeuten, dass man nun das auch wirklich liefert, was man schon vor ein paar Sprints behauptet hatte, man hätte es geliefert.

Das Sprint-Ziel im Fokus behalten

Damit das Sprint-Ziel wirklich nützlich wird, sollte es sich durch den ganzen Sprint ziehen. Es wird während der Sprint Planung erarbeitet und vereinbart, wenn das ganze Scrum Team es für realistisch hält.

Im Daily Scrum wird der Fortschritt gegen das Sprint-Ziel gemessen, also „Was müssen wir noch tun, um das Sprint-Ziel zu erreichen“. Während des Sprints setzt es die Leitplanken. Welche sind Entscheidungen unkritisch, weil sie das Sprint-Ziel nicht gefährden? Welche Enstscheidungen müssen noch mit dem Product Owner diskutiert werden, weil sie das Sprint-Ziel gefährden könnten? Wenn sich herausstellt, dass doch mehr Arbeit notwendig ist, als man in der Planung dachte, versuchen alle gemeinsam, den Umfang zu reduzieren, ohne das Sprint-Ziel zu gefährden. Das setzt natürlich voraus, dass man gut verstanden hat, was an dem Sprint-Ziel für die Stakeholder wichtig ist. Damit kann man das Essenzielle unterscheiden von dem, was zwar schön aber doch verzichtbar ist.

Im Sprint Review nutzt das Scrum Team das Sprint-Ziel schließlich als Überschrift und Kontext: Warum haben wir diesen Sprint überhaupt gemacht? Warum ist es für Euch, liebe Stakeholder, interessant, sich mit dem Ergebnis zu beschäftigen? Und wie findet Ihr unsere Umsetzung?

Gute Sprint-Ziele finden

Ein gutes Sprint-Ziel zu finden braucht sowohl ein gutes Verständnis für die Bedürfnisse der Stakeholder als auch einige Erfahrung beim Schneiden von Sprints. Deshalb machen erfahrene Product Owner das gemeinsam mit dem Scrum Team und möglicherweise auch im Austausch mit einzelnen Stakeholdern. Ein hervorragendes Werkzeug dafür ist Story Mapping. Dabei zerlegt das Team ein komplexes Problem sehr systematisch in kleine, in sich wertvolle Teile, die auf sehr natürliche Weise zu Sprint-Zielen führen. Ein schönes Beispiel für Story Mapping zeigt der leider viel zu früh verstorbene David Hussman in diesem Video.

In der Sprint Planung unterzieht das Scrum Team das Sprint Ziel nochmal einem Realitätscheck: Es überlegt, welche Backlog Items auf das Sprint-Ziel einzahlen, und ob es realistisch ist. Falls nicht, muss das Team entweder auf eine Idee kommen, wie sich das Ziel auch mit weniger Aufwand erreichen lässt, oder das Sprint-Ziel entsprechend reduzieren. Erst wenn alle einverstanden sind, gilt das Sprint-Ziel als vereinbart.

Übrigens muss das Sprint-Ziel nicht unbedingt eine für die Anwender wertvolle Funktionalität sein. Ich erinnere mich ein Team, das ein völlig neues Consumer-Gerät bauen sollte. Am Anfang mussten sie erst einmal die zukünftigen Kunden verstehen und Ideen entwickeln, was man bauen könnte. Dafür verplanten sie einen kompletten Sprint für Haushaltsbesuche und einen Design-Thinking Workshop. Das Sprint-Ziel lautete „Ideen für die Verprobung generieren“, das Ziel für den Sprint davor war schlicht „Haushaltsbesuche ermöglichen“. Es ging also darum, zu lernen – nicht das schlechteste Sprint-Ziel, wenn spätere Sprints sich dann auch um das Liefern kümmern.

Tipps & Tricks

Was wichtig ist: Das Sprint Ziel wird nicht von irgendjemandem außerhalb des Scrum Teams dem Team aufoktroyiert. Es entsteht durch eine gemeinsame Sicht des gesamten Scrum Teams. Andere dürfen zwar Wünsche äußern, oder auch ihre Vorstellungen von Wert („Wenn dieser Button nicht rosa eingefärbt wird, steht die ganze Firma auf dem Spiel!...“). Entschieden wird es aber vom Scrum Team in Sprint Planung.

Ein Tipp noch aus der Praxis: Erfahrene Teams wählen ihre Sprint Ziele so, dass noch ein paar Backlog Items extra in den Sprint passen. Das erhöht das nicht nur die Chance, das Sprint-Ziel auch tatsächlich zu erreichen. Es bietet zudem auch noch Raum, den ein oder anderen Fehler zu beheben, oder technische Schulden abzubauen. Das reduziert die Notwendigkeit für öde Sprint-Ziele á la „Mit diesem Update beheben wir einen Fehler“, auch wenn man doch hin und wieder auch diesen Kelch leeren muss.

Willst Du mehr über Sprint-Ziele erfahren? Dann besuche doch einen CSPO oder A-CSPO Kurs bei uns.

Anmerkung: Meine Überlegungen zur Corona-WarnApp erfolgen aus reiner Anwenderperspektive. Ich verfüge über keinerlei Insider-Informationen über Organisation oder Überlegungen des Entwicklungsteams. Ich bin den Entwicklerinnen und Entwicklern der App sehr dankbar für das, was sie für geleistet haben und weiterhin leisten. Dass ich sie hier als Beispiel verwendet habe, ist Zeichen meiner Anerkennung, nicht Kritik.

Abb 1: Beispiel für ein gutes Sprintziel – zumindest aus meiner Sicht: Endlich liefert die Corona WarnApp eine Alternative zur Zettelwirtschaft in Restaurants und liefert damit einen Vorgeschmack auf zukünftige Lockerungen. Als Sprint-Ziel würde der PO hier vielleicht „Check-In per QR Code ermöglichen“ vorschlagen.

Abb 2: Beispiel für ein eher ödes Sprintziel. Als Anwender freue ich mich über automatische Updates, die mir die Beschäftigung mit solchen Sprint-Zielen ersparen. Als Scrum Master wird es Zeit, einmal ein paar Fragen zu stellen.

Agile Tuesday Juni: Organisationsgestaltung im 21. Jahrhundert

christian-braun — Tue, 01 Jun 2021 08:05:00 +0000

Aufgrund der aktuellen Situation findet der Agile Tuesday nicht im Hofbräuhaus statt, sondern als Zoom Meeting.

Wir schicken euch die Einwahldaten am 8.6. via Xing-Benachrichtigung gegen 17:00 Uhr direkt zu. Bitte beachtet, dass Ihr diese Benachrichtigung bei einer Anmeldung am 8.6. nach 17:00 Uhr nicht mehr erhaltet. Auf Anfragen bzgl. der Zugangsdaten während des Events können wir leider nicht eingehen.
Wichtiger Hinweis: Ihr erhaltet die Xing-Benachrichtigung als Email, also checkt bitte auch eure Spamordner, falls Ihr die Mail auf den ersten Blick nicht finden könnt. Schaut ggf. auch in die Einstellungen eures Xing-Profils ob die Option zum Erhalt von Benachrichtigungen durch Xing nicht deaktiviert ist.

Hier geht´s direkt zum Xing-Event

Organisationssteuerung im 21. Jahrhundert – Neues disruptives Know-how ist für Führungskräfte und Organisationslenker notwendig

Wir alle kennen Begriffe wie Strategieplanung, Budgetierung, Marketing, Buchhaltung und Controlling ebenso wie Hierarchie und Command-and-Control. Aber, diese Begriffe stammen aus einer vergangenen Zeit. Es stellt sich also die Frage, wie hilfreich sie heute noch sind.

Bereits Einstein hat festgestellt: „Probleme kann man niemals mit derselben Denkweise lösen, durch die sie entstanden sind.“ Wenn wir also effizientere und resilientere Organisationen haben wollen, benötigen wir neue Denkweisen. Aber welche könnten das sein?

Diese möchten wir am heutigen Agile Tuesday mit Euch diskutieren. Dabei werden wir unter anderem das Thema Beyond GDP beleuchten und welche Konsequenzen sich daraus für das Management und die Führung einer Organisation ergeben.

Jürgen Mohr wird den Abend mit einem Impulsvortrag starten. Im Anschluss daran werden wir unser aller Wissen, Erfahrungen und Meinungen dazu auszutauschen.Wir freuen uns schon sehr auf euch!
Euer Agile Tuesday Team und Jürgen

Remote und interaktiv. Bring Your Own Beer ;-)

Agile Tuesday Mai: Agile Coaches und der Klimawandel

christian-braun — Sat, 01 May 2021 08:08:00 +0000

Aufgrund der aktuellen Situation findet der Agile Tuesday nicht im Hofbräuhaus statt, sondern als Zoom Meeting.
Wir schicken euch die Einwahldaten am 11.5. via Xing-Benachrichtigung gegen 17:00 Uhr direkt zu. Bitte beachtet, dass Ihr diese Benachrichtigung bei einer Anmeldung am 11.5. nach 17:00 Uhr nicht mehr erhaltet. Auf Anfragen bzgl. der Zugangsdaten während des Events können wir leider nicht eingehen.
Wichtiger Hinweis: Ihr erhaltet die Xing-Benachrichtigung als Email, also checkt bitte auch eure Spamordner, falls Ihr die Mail auf den ersten Blick nicht finden könnt. Schaut ggf. auch in die Einstellungen eures Xing-Profils ob die Option zum Erhalt von Benachrichtigungen durch Xing nicht deaktiviert ist.

Unser Thema: Vom Bewusstsein ins Handeln kommen - wie Agile Coaches Verantwortung im Klimawandel übernehmen können

Hier geht´s direkt zum Xing Event

Die Fachleute sind sich einig: Der Klimawandel ist real. Er ist gefährlich. Wir Menschen sind die Ursache. Und wir können noch etwas tun.

Wir, Peter und Sabine, sprechen über das, was sie bereits getan haben und noch tun wollen - als Privatpersonen und auch im beruflichen Umfeld. Ein Vorbild ist für uns Henrik Kniberg. Wenn ihr seine Videos über Spotify und Product Ownership in a Nutshell mögt, dann schaut euch doch mal seinen „Friendly Guide to Climate Change“ an: https://youtu.be/3CM_KkDuzGQ.

Gemeinsam sind wir stärker - deswegen möchten wir euch in diese Diskussion mit einbeziehen. Wir sind neugierig auf eure Ideen! Und für die beste Idee gibt es sogar eine klimafreundliche Überraschung.
Wir freuen uns schon sehr auf euch!
Euer Agile Tuesday Team, Sabine und Peter

Remote und interaktiv. Bring Your Own Beer ;-)

Agile Tuesday April: Agile Lernreisen für Erfahrene

christian-braun — Thu, 01 Apr 2021 08:10:00 +0000

Aufgrund der aktuellen Situation findet der Agile Tuesday nicht im Hofbräuhaus statt, sondern als Zoom Meeting.
Wir schicken euch die Einwahldaten am 13.4. via Xing-Benachrichtigung gegen 17:00 Uhr direkt zu. Bitte beachtet, dass Ihr diese Benachrichtigung bei einer Anmeldung am 13.4. nach 17:00 Uhr nicht mehr erhaltet. Auf Anfragen bzgl. der Zugangsdaten während des Events können wir leider nicht eingehen.
Wichtiger Hinweis: Ihr erhaltet die Xing-Benachrichtigung als Email, also checkt bitte auch eure Spamordner, falls Ihr die Mail auf den ersten Blick nicht finden könnt. Schaut ggf. auch in die Einstellungen eures Xing-Profils ob die Option zum Erhalt von Benachrichtigungen durch Xing nicht deaktiviert ist.

Hier geht´s direkt zum Xing Event

Unser Thema: Agile Lernreisen für Fortgeschrittene

Der Start als Agiler Coach ist seit vielen Jahren recht einheitlich: Zwei Tage Kurs als Scrum Master und dann geht es ab in die Praxis - wenn man Glück hat, an der Hand eines erfahrenen Coaches. Seit fast ebenso langer Zeit ist aber auch klar, dass das bei weitem nicht ausreicht. Alle Zertifizierungsprogramme bieten mittlerweile auch Level für Fortgeschrittene an und keine Transition vergeht ohne dass Ausbildungspfade für Coaches, Product Owner und andere Rollen definiert würden. Dabei kann man sich mittlerweile aus so vielen Ansätzen und Vorgaben bedienen, dass alleine die Auswahl kaum weniger Arbeit verspricht, als würde man die Konzepte gleich selbst entwickeln.
An diesem Agile Tuesday sammeln wir gemeinsam Bedürfnisse, Lösungen und Angebote. Wie sieht Eure "perfekte Lernreise" aus? Welche Teile davon waren leicht und vor welchen Problemen standet Ihr? Was davon können gängige Qualifizierungsprogramme abdecken? Und was was waren Deine ganz persönlichen "Gamechanger", als Trainings, Bücher oder andere Erlebnisse, die Euer Denken verändert haben? Viel Interaktion ist garantiert.

Wir freuen uns schon sehr auf euch!
Euer Agile Tuesday Team und Jens

Remote und interaktiv. Bring Your Own Beer ;-)

Agile Tuesday März Special: Open Space

christian-braun — Mon, 01 Mar 2021 09:13:00 +0000

Aufgrund der aktuellen Situation findet der Agile Tuesday nicht im Hofbräuhaus statt, sondern als Zoom Meeting.
Wir schicken euch die Einwahldaten am 09.03. via Xing-Benachrichtigung gegen 17:00 Uhr direkt zu. Bitte beachtet, dass Ihr diese Benachrichtigung bei einer Anmeldung am 09.03. nach 17:00 Uhr nicht mehr erhaltet. Auf Anfragen bzgl. der Zugangsdaten während des Events können wir leider nicht eingehen.
Wichtiger Hinweis: Ihr erhaltet die Xing-Benachrichtigung als Email, also checkt bitte auch eure Spamordner, falls Ihr die Mail auf den ersten Blick nicht finden könnt. Schaut ggf. auch in die Einstellungen eures Xing-Profils ob die Option zum Erhalt von Benachrichtigungen durch Xing nicht deaktiviert ist.

Dieses Mal haben wir uns etwas besonders für euch einfallen lassen: Wir tun uns mit der Community des Scrumstammtischs Bonn zusammen und veranstalten den nächsten Agile Tuesday als Open Space. Bringt Themen mit, die euch interessieren, inspirieren oder die Ihr teilen wollt. Frei nach dem Motto: Alles, was mit Agilität, Wandel oder ähnlichen Gebieten zu tun hat, ist willkommen!

Auch bzgl. des Zeitplans läuft es dieses Mal anders als gewohnt:

- ab 18:30 Uhr Einlass in das Meeting zum Austauschen, Quatschen und einfach Beisammen sein

- um 19 Uhr beginnt der Open Space

- wir haben mehrere Zeitslots und die Veranstaltung kann bis ca. 22 Uhr gehenWir freuen uns schon sehr auf euch!
Euer Agile Tuesday Team und die Jungs vom Scrumstammtisch Bonn

Remote und interaktiv. Bring Your Own Beer ;-)

Agile Tuesday Februar am 09.02. – Das neurotische Pferd

christian-braun — Mon, 01 Feb 2021 09:15:00 +0000

Aufgrund der aktuellen Situation findet der Agile Tuesday nicht im Hofbräuhaus statt, sondern als Zoom Meeting.
Wir schicken euch die Einwahldaten am 09.02. via Xing-Benachrichtigung gegen 17:00 Uhr direkt zu. Bitte beachtet, dass Ihr diese Benachrichtigung bei einer Anmeldung am 09.02. nach 17:00 Uhr nicht mehr erhaltet. Auf Anfragen bzgl. der Zugangsdaten während des Events können wir leider nicht eingehen.

Hier geht´s direkt zum Xing-Event

Das neurotische Pferd.

Wie wir verhindern können, dass Lösungen zu Problemen werden.

Wie schnell kann es gehen: Eine anfangs sinnvolle und kluge Lösung für ein spezifisches Problem entwickelt ihr Eigenleben, sie wird zum Dogma, zur Lösung für alle Situationen, zum Identitätsstifter und möglicherweise zu einer Ideologie. Sie wird selbst zum Problem.

Kann uns das in der "Agilen Welt" auch passieren? Besteht hier auch die Gefahr, dass wir anfangen, ein sinnvolles Handeln zu einer Lehre zu machen, die durch Hinterfragen nicht mehr gefährdet werden darf? Und falls ja, wie ließe sich das vermeiden?Viele Grüße
Jens und euer Agile Tuesday Team

Remote und interaktiv. Bring Your Own Beer ;-)

Agile Tuesday am 12.05. -Agilität und Leidenschaft

christian-braun — Sat, 01 May 2021 08:24:00 +0000

Aufgrund der aktuellen Situation findet der Agile Tuesday nicht im Hofbräuhaus statt, sondern als Zoom Meeting. Um eine größtmögliche Sicherheit zu gewährleisten, meldet Euch dieses Mal bitte per Email an: kontakt@improuv.com. Am Dienstag schicken wir Euch dann den Link mit den Einwahldaten zu.

"Nichts geht ohne Leidenschaft" mit Marc Löffler

Stell Dir vor, es ist Freitag Nachmittag, 16.00Uhr und Du läufst durch Deine Abteilung. Erst vor zwei Stunden hast Du eine kleine Rede gehalten und den Ernst der Lage geschildert. Du hattest eigentlich das Gefühl, dass Deine Mitarbeiter verstanden haben, um was es geht. Doch das Büro ist nahezu leer, fast alle sind bereits zu Hause und ins Wochenende gestartet. Vor ein paar Monaten habt ihr damit begonnen in Richtung Agilität zu starten. Doch nach anfänglicher Euphorie, ist mittlerweile totale Ernüchterung eingetreten. Keine der Versprechungen, die mit agilem Vorgehen verbunden werden, sind bis heute eingetreten. Der Druck durch den Markt steigt stetig weiter und Dein Chef wird immer ungeduldiger. Wenn Du nicht bald etwas änderst, fährt Dein Unternehmen an die Wand. So langsam bist Du mit Deinem Latein am Ende.

In Marcs Vortrag erfährst Du, wie Du Deine Mitarbeiter emotional berühren und mitreissen kannst. Du lernst, wie Du die Voraussetzungen für passionierte Agilität schaffen kannst und ein Umfeld schaffst, in dem Deine Mitarbeiter ihr volles Potential entfalten können. Und das Geniale daran: Ihr werdet dabei alle eine Menge Spaß haben. Lerne, warum Leidenschaft so wichtig ist, denn nichts geht ohne Leidenschaft.

Und darum gehts in dieser Session. Remote und interaktiv. Bring Your Own Beer ;-)

Selbstorganisation ermöglichen und ausrichten: So geht agile Führung

Sabine — Mon, 21 Jun 2021 10:44:29 +0000

Braucht man in einer agilen Welt, in der alle von Selbstorganisation sprechen, überhaupt noch Führung? Unsere Meinung: mehr denn je, aber eine andere Art der Führung als im letzten Jahrhundert. Eine Führung, die es Menschen und Organisationen ermöglicht, in einer unsicheren und sich ständig verändernden Welt zu agieren, zu überleben und immer weiter zu lernen.

Diese Führung kann an eine hierarchische Position gekoppelt sein, muss es aber nicht sein. De facto findet sogar die meiste Führung unabhängig von definierten Strukturen statt. Unterschiedliche Menschen können sie in unterschiedlichen Momenten einnehmen. Was man dazu braucht: innere Agilität, also die Bereitschaft und Fähigkeit, sich selbst weiterzuentwickeln. Und äußere Agilität, die auf andere, Teams und ganze Organisationen Einfluss ausübt und Wirkung erzielt.

Elemente agiler Führung

Die wesentliche Aufgabe agiler Führung ist es, Selbstorganisation mit Fokus auf Ergebnisse entstehen zu lassen:

Fokus: Gerade in selbstorganisierten Systemen ist eine klare Ausrichtung notwendig, um zu verhindern, dass man sich verzettelt. Führungspersönlichkeiten sorgen für eine gemeinsame Vision, Zielsetzung, Strategie und Richtung: welche Initiativen und Themen angegangen werden, welche nicht, und wie die vorhandenen Mittel eingesetzt werden. Für alle ist klar, warum diese Entscheidungen getroffen werden und welchen übergeordneten Leitlinien das Unternehmen folgt.
Alignment und Inspiration. Der Fokus ist eine Einladung, an einem großen Vorhaben mitzuwirken. Selbstorganisierende Systeme lassen sich nicht direkt steuern. Selbstorganisation funktioniert nur freiwillig. Die Mitarbeiter und Teams „müssen es wollen“, und zwar gemeinsam. Führungspersönlichkeiten kommunizieren ihre Absicht, also Sinn und Zweck und das erwartete Ergebnis. Sie beeinflussen das Engagement der Mitarbeitenden, indem sie agiles Verhalten vorleben. Sie schaffen einen sicheren Raum, in dem zuerst unterschiedliche Meinungen gehört und gefördert werden, dann aber auch der Übergang von divergentem zu konvergentem Denken und Handeln entsteht.
Enablement. „Wollen“ allein reicht nicht, man muss auch können. Die Teams und Mitarbeiter brauchen das Wissen, die Informationen und die Fähigkeiten, komplexe Probleme eigenständig zu lösen. Führungskräfte fördern das selbständige Denken der Menschen, das die Voraussetzung für eigenverantwortliches Handeln ist. Sie schaffen einen Raum zum Experimentieren, in dem Irrtümer als Möglichkeit zum gemeinsamen Lernen genutzt werden. Sie wirken als Coach und Mentor bei der Weiterentwicklung von Individuen und Teams.
Empowerment. Selbstorganisation ist nicht Laissez-faire. Ein „plötzliches“ Loslassen und Übertragen jeglicher Verantwortung hinterlässt ein Führungsvakuum und könnte ins Chaos münden. Führungspersönlichkeiten setzen Richtlinien und „Delegation Levels“, wer was mit wem entscheiden darf und wie Verantwortlichkeiten verteilt sind. Sie vereinbaren realistische Ziele und unterstützen bei der Umsetzung. Oftmals werden klassische Strukturen und Prozesse zum Hindernis. Eine silo-artige, hierarchische Organisation führt zum Beispiel dazu, dass Mitarbeitende ihren Beitrag zum „Großen Ganzen“ nicht erkennen und ein lokales Optimum erzeugen. Anpassungen der „Leitplanken“ ist notwendig, um Teams mehr Freiräume zur Verbesserung ihrer Leistung einzuräumen. Dazu gehört auch, dass ich als Führungspersönlichkeit einschreite, wenn ich ernsthaften Schaden für das Unternehmen befürchte.

Was bedeutet agile Führung für mich persönlich?

„Nur wer sich selbst führen kann, kann auch andere führen“ (Anselm Grün).

Agile Führung fängt bei der eigenen Haltung an. Als Führungspersönlichkeit vertraue ich den Mitarbeitenden, dass sie willens und fähig sind, selbstorganisiert zu handeln und Ergebnisse zu erzielen bzw. sich in diese Richtung weiterzuentwickeln. Meine Aufgabe ist es nicht, heroisch Probleme selbst zu lösen, sondern Menschen zu beflügeln, darin besser zu werden als ich selbst. Durch diese innere Überzeugung kann ich authentisch als Vorbild handeln, Feedback geben, Einfluss ausüben und die Mitarbeitenden bei ihrem persönlichen Wachstum unterstützen.

Als agile Führungspersönlichkeit entwickle ich mich selbst ständig weiter. Ich kenne meine eigenen Werte und Antriebe und orientiere mich daran. Ich bin mir über meine eigenen Gefühle bewusst und kann mein Verhalten auch in emotional schwierigen Situationen steuern. Meine Mitmenschen behandle ich mit Respekt und Empathie. Ich erkenne mit Hilfe von Feedback, welche Wirkung ich auf andere habe, und kann mein Verhalten und damit die Beziehungen zu anderen entsprechend beeinflussen. Ich entwickle unterschiedliche Führungsstile, die ich je nach Situation anwenden kann.

Führung eines agilen Unternehmens

Agilität ist eine Kulturfrage. Unternehmenskultur ist geprägt von Überzeugungen und Glaubenssätzen, die sich nicht direkt und schnell verändern lassen, aber wesentlich durch die Erfahrungen mit dem Führungsverhalten geprägt werden. Solche Glaubenssätze können sein: „Ober sticht Unter“, „Wer die Wahrheit sagt, braucht ein verdammt schnelles Pferd“, oder aber „Ich kann mit meiner Meinung etwas verändern“.

Die traditionelle Führung ist formal bzw. legitimiert, d.h. bestimmte Befugnisse (Erteilung und Kontrolle von Aufträgen, Belohnung, Bestrafung) sind an die Rolle oder die Stellung in der Unternehmenshierarchie gebunden. In einer agilen Organisation ist Führung verteilt. Im Idealfall werden Entscheidungen von denjenigen getroffen, die dazu am besten in der Lage sind. Zum Beispiel ist jede der drei Scrum-Rollen eine Führungsrolle, die in Form einer „Gewaltenteilung“ bestimmte Aspekte abdeckt. Der Umstieg von traditioneller zu agiler Führung bedeutet also einen anderen Umgang mit Macht. Wenn ich formale Macht habe, sollte ich diese nicht verleugnen (das führt zu Verwirrung).

Als Systemdenker:in nutze ich legitimierte Macht, um die Randbedingungen (Strukturen, Prozesse, Ziel-, Controlling- und Beurteilungssysteme) zu ändern, die sich auf das Denken und Verhalten von Menschen auswirken. Zur direkten Steuerung setze ich sie nur in Ausnahmefällen ein (z.B. bei Regelverletzung, unbefriedigender Leistung).

Bei aller Agilität darf ich nicht vernachlässigen, dass eine langfristig erfolgreiche Organisation unterschiedliche Modi parallel fahren muss:

Innovation, Resilienz: die Fähigkeit, den Status Quo zu stören, um neue Produkte und Services zu schaffen und schnell auf den Markt zu bringen, und Krisen als Anlass für Entwicklung zu nutzen. Dazu brauchen wir den Umgang mit Variabilität, sprich Agilität!
Operational Excellence, Effizienz: die Fähigkeit, sicher, schnell und kostengünstig zu liefern und das auch über die Lebenszeit von Produkten und Services aufrecht zu erhalten. Dazu brauchen wir Standards und Wiederholbarkeit und eine möglichst geringe Variabilität – Agilität ist da manchmal vielleicht sogar hinderlich.
Evolving / Learning Organisation: die Fähigkeit, individuelle Kenntnisse und Erfahrungen für die gesamte Organisation verfügbar zu machen. Auf Basis dieses Wissens muss sich die Organisation an die sich verändernde Lage anpassen. Auch das ist agil, aber eine Erweiterung des Blickwinkels über Kunden und Märkte hinaus.

Als Führungskraft verstehe ich die Notwendigkeit und den möglichen Nutzen von Agilität in meinem Unternehmen. Ich kenne die Bedeutung von selbstorganisierten, funktionsübergreifenden Teams und weiß, wann ich sie sinnvoll einsetzen und wie ich sie fördern kann. Ich denke systemisch und arbeite mit den Wechselwirkungen in einem komplexen Organisationssystem, das aus mehreren Teams, anderen Einheiten, Netzwerken und informellen Strukturen besteht.

Hast Du Lust auf mehr Informationen dazu? Die unterschiedlichen Aspekte sind in unserem CAL-Trainingsprogramm abgedeckt:

CAL-Essentials: Sich selbst und andere Menschen führen
CAL-Teams: Teams führen
CAL-Organsation: Organisationen führen

Hier geht´s zu unseren Agile Leadership Trainings.

Wer zu spät kommt, den bestraft der Markt - eine ökonomische Sicht auf das Product Backlog

Sabine — Mon, 05 Jul 2021 14:26:12 +0000

Nach welchen Kriterien ordnet ihr euer Product Backlog? Nach Abhängigkeiten zwischen Produkt-Komponenten oder Teams? Nach Verfügbarkeit von bestimmten Experten? Nach der Lautstärke von Stakeholder-Stimmen? Oder lasst ihr wirtschaftliche Erwägungen in die Ordnung einfließen?

Als Product Owner:in seid ihr - laut Scrum Guide - nicht nur für ein effektives Backlog Management zuständig, sondern auch für die Maximierung des Werts des Produkts. Das bedeutet aus ökonomischer Sicht: die Maximierung des Profits, den ihr mit dem Produkt generieren könnt. Dazu hat sich Don Reinertsen in seinem Buch "The Principles of Product Development Flow" viele Gedanken gemacht. Ich möchte ein paar wesentliche Gesichtspunkte daraus extrahieren, die beim Product Backlog Management helfen, gute ökonomische Entscheidungen zu treffen. Genauer gesagt soll es darum gehen, das Product Backlog nach ökonomischen Kriterien zu ordnen, seine Größe und den Anteil für Releases festzulegen.

Entscheidungen nach ökonomischen Auswirkungen treffen

In der Praxis werden ganz unterschiedliche Ziele für die Produktentwicklung angegeben: Innovation erzeugen, Qualität verbessern, einen Plan einhalten, Verschwendung reduzieren... Sehr häufig hat die Product Owner:in sich mit Zielkonflikten herumzuschlagen, zum Beispiel: ist es besser, das Produkt jetzt zu releasen, oder sollten erst die bekannten Fehler beseitigt werden? Die einhellige Meinung in der agilen Community ist: Technische Schulden sind des Teufels und sollten auf jeden Fall vermieden werden. Aber ist diese Meinung immer ökonomisch gerechtfertigt? Ein weiteres Beispiel: Sollte das Produkt mit einem Minimum an Features auf den Markt, um frühes Feedback zu bekommen, oder sollten lieber noch ein paar weitere Features eingebaut werden, um die Chance auf begeisterte Kunden zu erhöhen? Wäre es nicht großartig, wenn wir diese Möglichkeiten anhand einer Größe vergleichen könnten, die den Einfluss auf den Profit während des gesamten Produkt-Lebenszyklus ausdrückt? Schauen wir uns das an dem ersten Beispiel von oben an:

Option A: Wieviel kostet es, das Release zu verschieben, bis alle Fehler beseitigt sind? Die CoD ist der in der Verzögerungszeit entgangene Gewinn. Sie ist in der Regel nicht konstant über die Zeit. Die Konkurrenz schläft nicht... vielleicht verpassen wir durch die Verschiebung ein wichtiges Marktfenster, und die Gewinnerwartung geht auf Null. Währenddessen steigen die Entwicklungskosten weiter an. Die folgende Abbildung aus dem Kanban Maturity Model der Kanban University zeigt verschiedene mögliche Zeitverläufe.

Die Verzögerung hat noch einen weiteren Nachteil: Da wir ein späteres Feedback vom Markt erhalten, leben wir länger mit der Unsicherheit, dass unser Produkt nicht gekauft wird.

Option B: Wieviel kostet es, die Fehlerbeseitigung zu verschieben, bis das Produkt am Markt ist? Wir erzeugen technische Schulden. Die Beseitigung eines Fehlers wird um so teurer, je weiter wir sie in die Zukunft verschieben, da es im Produkt Seiteneffekte gibt und der Testaufwand steigt. Außerdem besteht das Risiko, Kunden durch schlechte Qualität zu verärgern und dadurch einen Imageverlust zu erleiden.

Diese beiden Optionen mit konkreten Zahlen zu versehen, ist schwierig und abhängig vom jeweiligen Kontext, aber allein die Überlegungen dahinter sind sehr aufschlussreich. Sie helfen, Entscheidungen rational abzusichern und sich nicht (nur) auf sein Bauchgefühl zu verlassen. Solche Entscheidungen sind in der Regel stabiler und lassen sich besser begründen - auch wenn der Stakeholder mit der lauten Stimme anruft. Also: Quantifizieren wenn möglich, aber nicht um jeden Preis.

Verzögerungen kosten also Geld. Sie führen zu

erhöhtem Risiko durch veränderte Markt-/Kundensituation
verspätetem Feedback und dadurch erhöhten Kosten für "falsche" Entwicklungen und verminderter Qualität
erhöhten Prozesskosten und Overhead
abnehmender Motivation bei den Entwicklungsteams

Das Product Backlog als Warteschlange

Wie kommen diese Verzögerungen überhaupt zu Stande? Die Antwort ist: durch Wartezeiten. Wie bitte? Wir sind doch alle ständig am Rotieren und füllen Wartezeiten sofort mit neuen Aktivitäten. Genau da liegt das Problem: wir betrachten den einzelnen Menschen, oder das einzelne Team (allgemein: einen Service), und sehen deren Auslastung. Was wir nicht im Blick haben, ist die Arbeit, die von einem Service zum anderen weitergereicht wird. Vor ausgelasteten Services entstehen Warteschlangen, die das Weiterreichen zur nächsten Station verzögern. Am einfachsten können wir uns das an einer Schlange im Supermarkt veranschaulichen. Sobald der Service (in diesem Fall die Kassierer:in) nicht mehr nachkommt mit Kassieren, bildet sich eine Schlange. Wenn wir erst an der Wursttheke, dann an der Brottheke und dann noch einmal an der Kasse in der Schlange stehen müssen, verzögert sich die Gesamtdurchlaufzeit um so mehr.

Warteschlangen sind die Hauptursache für Verzögerungen und damit für Verschwendung in der Produktentwicklung. Um das zu verstehen, helfen zwei Erkenntnisse aus der Warteschlangentheorie:

Die Länge von Warteschlangen steigt massiv mit der Auslastung. Unsere intuitive Annahme, dass hohe Auslastung zu schneller Abarbeitung führt, ist verkehrt. Das Gegenteil ist der Fall. Dies zeigt die folgende Abbildung.
Im langfristigen Durchschnitt gilt: Wartezeit = Länge der Warteschlange / Abarbeitungszeit, wenn das System stabil ist, also genauso viel neu rein kommt, wie hinten abgearbeitet wird (Little's Gesetz).
Warteschlangen entstehen schneller als sie sich wieder abbauen. Das weiß jeder aus Erfahrung, der schon einmal einen Verkehrsstau erlebt hat, lässt sich aber auch mathematisch zeigen.

Das Product Backlog ist eine Warteschlange, in dem Product Backlog Items (PBIs) auf ihre Abarbeitung warten. Jeder Service, der in der Produktentwicklung eine Rolle spielt, hat eine eigene Warteschlange. Das können unterschiedliche Teams sein, die gemeinsam an einem Produkt arbeiten, aber auch Einheiten außerhalb der Entwicklung, wie z.B. Marketing oder die Rechtsabteilung. Wir sollten also unsere Aufmerksamkeit weg von der Auslastung der einzelnen Services hin zu den Arbeitsaufträgen lenken. Solche gekoppelten Warteschlangensysteme sind, wenn es auch Rückkopplungen gibt, chaotische Systeme im mathematischen Sinne, die nicht vorhersehbares Verhalten zeigen - und sich mit traditionellen Planungen nicht in den Griff bekommen lassen.

Product Backlog Items ökonomisch ordnen

Na prima, nachdem wir dieses Problem verstanden haben, finden wir eine Lösung: wir verringern die Auslastung der Services bzw. erhöhen deren Kapazität. Das macht der Supermarkt ja auch, wenn bei langen Schlangen zusätzliche Kassen geöffnet werden. Leider ist das nicht umsonst zu haben: wir brauchen zusätzliches Personal oder Schulungen, durch die das Personal an unterschiedlichen Stellen eingesetzt werden kann. Ist das ökonomisch gerechtfertigt? Dazu sollten wir statt der Größe die Kosten der Warteschlangen betrachten. Diese können wir durch die Reihenfolge der Einträge in der Warteschlange beeinflussen. Product Backlog Items (PBIs) mit großer CoD kommen ganz nach oben. Als weitere Regel kommt hinzu: kurze Aufträge vor langen Aufträgen. Kurze Aufträge blockieren den Service weniger lang und führen schneller dazu, dass die Warteschlange sich wieder abbaut. Die Abbildung veranschaulicht zwei Fälle: im ersten Fall ist der erste Job der mit hoher CoD und niedriger Dauer. Im zweiten Fall ist es umgekehrt. Der Unterschied ist deutlich zu erkennen: die hohen CoDs akkumulieren sich im zweiten Fall über einen längeren Zeitraum.

Arbeiten in kleinen Stapeln

Eine weitere Möglichkeit, Wartezeiten zu reduzieren, ist die Verwendung von geringen Stapelgrößen (Batch Size). Damit ist die Anzahl von zusammengehörigen Arbeitseinheiten gemeint, also z.B. die Tasks in einem Sprint, oder die Features (und deren Tasks) in einem Release. Die bisherigen Betrachtungen gingen davon aus, dass Arbeit vereinzelt und zeitlich gleichmäßig verteilt beim Service ankommt. Das entspricht z.B. einem Team, dass eine bestimmte Zahl von kleineren Bugs mit mittlerer Auslastung erledigen kann. Die Realität ist aber nicht so. Arbeitsaufträge kommen zufällig, mit variablen Zeitabständen und variabler Größe und in Stapeln. Wie bei einem Restaurant, wenn ein Bus mit 40 hungrigen Touristen vorfährt. Plötzlich steigt die Warteschlange und damit die Wartezeit rapide an. Das Personal gerät in Stress, arbeitet an der Auslastungsgrenze, wodurch sich der Effekt noch verstärkt. Die Stapelgrößen sind oft nicht offensichtlich und eine Frage der "Flughöhe": Für ein Produktentwicklungs-Team versteckt sich hinter einem großen Requirement oder Feature ein Stapel von kleineren Arbeitsaufträgen.

Eine Möglichkeit, Stapelgrößen und die Länge von Warteschlangen zu begrenzen, sind Work In Progress (WIP) Limits. WIP ist die Anzahl der Arbeitseinheiten, die noch nicht fertiggestellt sind. zum Beispiel durch ungetesteter Code oder halb-umgesetzte Anforderungen. Wir können WIP kontrollieren, indem wir die Annahme von weiteren Aufträgen verweigern, wenn das WIP-Limit erreicht ist. Ein extremer Ansatz ist, die neuen Aufträge komplett zu verwerfen. Eine andere Möglichkeit ist, sie zu blockieren. Sie bleiben dann "weiter oben" in der Prozesskette hängen, wo sie weniger Kosten verursachen. Zum Beispiel ist es oft besser, neue Opportunities in einer Warteschlange zu halten und nicht in die Produktentwicklung eintreten zu lassen. Denn dort erhöhen sie die Auslastung, verursachen Kosten und Overhead.

Don Reinertsen zeigt an einem Beispiel, dass bereits moderate WIP-Begrenzungen einen großen ökonomischen Effekt haben können: bei einem WIP-Limit, das doppelt so groß ist wie der durchschnittliche WIP ohne Limit, entstehen Kosteneinsparungen durch die verminderte CoD, die fast 10mal so groß sind wie die zusätzlichen Kosten durch zurückgewiesene Aufträge. Natürlich sollten bei hohem WIP besonders solche Aufträge abgewiesen werden, die eine geringe Werterzeugung bieten.

In einer iterativ-inkrementellen Entwicklung helfen die Sprints, Stapelgrößen klein zu halten. Kanban-Systeme, die den Namen verdienen, sind per Definition WIP-limitiert. Es geht aber auch um Releases - in Sinne von kleinen Stapelgrößen und schnellem Feedback - möglichst häufig erfolgen sollten. Bei unserer ökonomischen Betrachtung stehen diesem Vorteil die Transaktions- oder Overhead-Kosten gegenüber, die mit einem Release verbunden sind, z.B. Systemtests, manuelle Tests, Dokumentation, Freigabe, Auslieferung. Eine Investition in gute Infrastruktur zur Verringerung der Transaktionskosten, zum Beispiel durch Automatisierung, kann sich dann schnell auszahlen .

Product Backlogs sind überall

Wie oben schon erwähnt, besteht eine Produktentwicklung nicht nur aus einem Product Backlog bzw. einer Warteschlange, sondern aus ganz vielen. Das klassische Projektmanagement, die Kritische-Pfad-Analyse und die Wertstromanalyse gehen davon aus, dass die Produktentwicklung eine lineare Sequenz von Schritten ist. Das muss aber nicht so sein. Bei manchen Aufträgen wird mehrfach die Unterstützung des Marketing-Teams benötigt. Bei anderen ist vor allem ein Backend-Team involviert. Bei wieder anderen liegt der Engpass bei den Nutzern, die den Akzeptanztest durchführen sollen. Statt einer linearen Abfolge haben wir ein Netzwerk von Funktionen und können von der Funktionsweise des Internets lernen: Das Produkt wird in Pakete heruntergebrochen, die durch dieses Netzwerk wandern, so wie es für das jeweilige Paket sinnvoll ist, und wie es der jeweilige Belastungs- und Warteschlangenzustand der Stationen erlaubt.

Noch eine Erweiterung der bisherigen Erkenntnisse. Wir können sie auf ein einzelnes Product Backlog anwenden, aber auch auf einer höheren Ebene auf ein ganzes Programm oder Portfolio von Projekten. Ein Riesen-Problem ist häufig, dass Mitarbeiter oder ganze Teams nicht nur in einem Projekt mitarbeiten, sondern in mehreren gleichzeitig. Es gibt keine WIP-Limits. Kein Wunder, dass die Fertigstellung von Projekten oft so lange dauert. Leider gibt es oft Hemmungen, einmal gestartete Projekte einzustellen. Statt dessen werden ihnen die Mitarbeiter:innen entzogen, so dass sie weder tot noch lebendig sind - Zombie-Projekte.

Die folgende Darstellung veranschaulicht dies für vier Projekte. Im ersten Fall laufen alle parallel. Im zweiten Fall werden zunächst Projekt 1 und 2 fertiggestellt, bevor 3 und 4 gestartet werden. Davon profitieren nicht nur Projekt 1 und 2 (geringere CoD), sondern auch 3 und 4: sie können von den Ergebnissen von 1 und 2 lernen, und sie vermeiden Overhead durch die geringere Laufzeit.

Zum Abschluss noch zwei persönliche Bemerkungen zu den Arbeiten von Don Reinertsen: ich finde den ökonimischen Blickwinkel wichtig und notwendig für eine wirtschaftlich denkenden Product:Ownerin. Das Buch ist jedoch nicht gerade leichte Kost, und mir fällt es schwer, seine quantitativen und statistischen Analysen nachzuvollziehen und auf eigene Beispiele zu übertragen. Weiterhin vermisse ich Aspekte, die über die Ökonomie der Produktentwicklung hinausgehen, zum Beispiel Nachhaltigkeitsaspekte. Es ist wichtig zu erkennen, dass Überlastung von Mitarbeitern zu CoD führt, aber noch wichtiger ist es sich zu überlegen, was das für ihre Gesundheit bedeutet. Folgekosten für Umwelt oder Gesellschaft sollten auch in eine ökonomische Betrachtung einbezogen werden. Die Cost of Delay einer solchen Maßnahme ist jetzt schon riesig und wird immer größer.

Hier geht´s zu unserem Product Owner Training

Agile Leadership - was ist es und wenn ja, wie viele?

hedi.buchner — Tue, 05 Oct 2021 08:48:59 +0000

Cross-funktionale Teams - Allheilmittel oder überschätztes Dogma?

Sabine — Wed, 13 Oct 2021 14:38:45 +0000

"Scrum Teams sind interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen." (Scrum Guide).

Historischer Rückblick

Die Vorteile liegen auf der Hand:

Für das Team lässt sich leicht ein gemeinsames Ziel formulieren: ein Produkt mit Wert für Kunden zu erzeugen. Entwickler:innen, Tester:innen und die anderen Funktionen ziehen an einem Strang und arbeiten eng zusammen. Das steigert die Identifikation mit dem Team, die Motivation und damit auch die Leistungsbereitschaft.
Mit ihren unterschiedlichen Skills und Sichtweisen findet das Team innovative Lösungen für komplexe Probleme.
Übergabeformalitäten, zum Beispiel in Form von Meilensteinen wie "Ready for System Test", können eingespart werden. So ist der Weg geebnet für ein iterativ-inkrementelles Vorgehen anstelle eines Wasserfallprozesses. Das Team ist in der Lage, schnell und agil zu agieren und seinen eigenen Prozess ständig weiterzuentwickeln.
Um das gemeinsame Ziel zu erreichen, werden starre Rollenbeschreibungen aufgelöst. Jedes Teammitglied trägt Verantwortung zur Erreichung des Ziels. Statt der Elfenbeinturm-Architekt:innen gibt es nun Team-Mitglieder, die sich besonders gut mit Architektur von Systemen auskannten, aber auch andere Tätigkeiten übernehmen können. Team-Mitglieder lernen voneinander und entwickeln sich weiter. Das Know-How wird verbreitert, nicht nur vertieft.
Durch die Unterschiedlichkeiten im Team entstehen Herausforderungen wie Umgang mit Konflikten und gemeinsame Entscheidungsfindung. Was auf den ersten Blick als Nachteil erscheint, ist tatsächlich ein Vorteil, wenn das Team lernt, derartige Herausforderungen gemeinsam bewältigen.

Feature Teams - ein weiterer Schritt zur Business Agility

Einsatzmöglichkeiten für cross-funktionale Teams

Inter- und extra-dependent Teams

Sind die cross-funktionalen Teams - zumindest als Grundbaustein - also ein Allheilmittel, wenn es um die effektive Lösung von komplexen Problemen geht?

The market punishes those who come too late - an economic view of the product backlog

Sabine — Mon, 01 Nov 2021 13:32:11 +0000

Entscheidungen nach ökonomischen Auswirkungen treffen

Die Verzögerung hat noch einen weiteren Nachteil: Da wir ein späteres Feedback vom Markt erhalten, leben wir länger mit der Unsicherheit, dass unser Produkt nicht gekauft wird.

Verzögerungen kosten also Geld. Sie führen zu

erhöhtem Risiko durch veränderte Markt-/Kundensituation
verspätetem Feedback und dadurch erhöhten Kosten für "falsche" Entwicklungen und verminderter Qualität
erhöhten Prozesskosten und Overhead
abnehmender Motivation bei den Entwicklungsteams

Das Product Backlog als Warteschlange

Warteschlangen sind die Hauptursache für Verzögerungen und damit für Verschwendung in der Produktentwicklung. Um das zu verstehen, helfen zwei Erkenntnisse aus der Warteschlangentheorie:

Die Länge von Warteschlangen steigt massiv mit der Auslastung. Unsere intuitive Annahme, dass hohe Auslastung zu schneller Abarbeitung führt, ist verkehrt. Das Gegenteil ist der Fall. Dies zeigt die folgende Abbildung.
Im langfristigen Durchschnitt gilt: Wartezeit = Länge der Warteschlange / Abarbeitungszeit, wenn das System stabil ist, also genauso viel neu rein kommt, wie hinten abgearbeitet wird (Little's Gesetz).
Warteschlangen entstehen schneller als sie sich wieder abbauen. Das weiß jeder aus Erfahrung, der schon einmal einen Verkehrsstau erlebt hat, lässt sich aber auch mathematisch zeigen.

Product Backlog Items ökonomisch ordnen

Arbeiten in kleinen Stapeln

Product Backlogs sind überall

Hier geht´s zu unserem Product Owner Training

Agile Tuesday November: Agile beyond IT

christian-braun — Mon, 01 Nov 2021 14:40:00 +0000

Der Agile Tuesday findet immer noch als Online Meeting statt. Sobald wir wieder in eine Präsenzveranstaltung wechseln, erhaltet Ihr einen Post in der Gruppe.

Hier geht´s direkt zu Anmeldung.

"Agile beyond IT: Controlling und Corporate Finance" mit Marie-Luise Lehmann und Constantin Tornow

In der heutigen VUCA-Welt stößt die Rolle des Controllings an ihre Grenzen. Erst recht, wenn Organisationen unternehmensweit agile Ansätze einführen. Im Vortrag erzählen wir von unserer persönlichen Erfahrung mit der Etablierung von agilen Methoden und Mindset im Corporate Finance. Das Ziel ist, den Teilnehmenden eine Idee davon zu vermitteln, wie "Agile" in der Controlling-Praxis gelingen kann. Mit allen Highs und Lows. Der Vortrag enthält ausreichend Zeit für Q&A´s.

Wir freuen uns schon sehr auf euch!
Euer Agile Tuesday Team

Remote und interaktiv. Bring Your Own Beer ;-)

Agile Tuesday Oktober: 20 Jahre Agiles Manifest - Wären wir doch erfolgreich gewesen

christian-braun — Fri, 01 Oct 2021 13:43:00 +0000

Der Agile Tuesday findet immer noch als Online Meeting statt. Sobald wir wieder in eine Präsenzveranstaltung wechseln, erhaltet Ihr einen Post in der Gruppe.

Hier geht´s zur Anmeldung.

"20 Jahre Agiles Manifest - Wären wir doch erfolgreich gewesen" mit Jens Coldewey

Ist zum 20. Jahrestag des Agilen Manifests eigentlich schon alles gesagt worden? In diesem Talk schaue ich mich ein wenig in der Realität um und komme zu dem Schluss: Wenn ja, dann nicht oft genug und nicht laut genug. Im Rückblick auf die Vision, die hinter dem Agilen Manifest stand, hat die Reise erst begonnen und ein Ende ist noch lange nicht abzusehen. Ein provokanter Rückblick mit viel Raum für anschließende Diskussion"

Wir freuen uns schon sehr auf euch!
Euer Agile Tuesday Team und Jens

Remote und interaktiv. Bring Your Own Beer ;-)

Agile Führung in 60 Minuten vermitteln - geht das? (kostenlos)

christian-braun — Thu, 01 Jul 2021 13:59:00 +0000

Agile Führung in 60 Minuten vermitteln - geht das?

Hier geht´s zur Anmeldung.

Wir stellen uns dieser Herausforderung.

Zugegeben, wir decken nicht alle Aspekte ab, aber unsere Essenz nimmst du mit. Und das nicht als Druckbetankung und Folienschlacht, sondern als vollwertiges, interaktives Trainingsmodul. Wir bieten sogar den Raum, andere kennenzulernen und sich mit ihnen auszutauschen. Und das coolste: Du zahlst nur mit deiner Zeit.

Wenn deine Neugierde auf mehr geweckt ist, beantworten wir anschließend noch 30 Minuten Fragen zur Weiterentwicklung für Agile Führungspersönlichkeiten.

Mehr Gedanken zu Agile Leadership findest du hier.

Agile Führung in 60 Minuten vermitteln - geht das? (kostenlos)

christian-braun — Fri, 01 Oct 2021 14:00:00 +0000

Agile Führung in 60 Minuten vermitteln - geht das?

Hier geht´s zur Anmeldung.

Wir stellen uns dieser Herausforderung.

Wenn deine Neugierde auf mehr geweckt ist, beantworten wir anschließend noch 30 Minuten Fragen zur Weiterentwicklung für Agile Führungspersönlichkeiten.

Mehr Gedanken zu Agile Leadership findest du hier.

2. Februar: Jens Coldewey auf der OOP

christian-braun — Mon, 06 Dec 2021 15:58:13 +0000

Im Februar wird es für unseren Jens Coldewey nicht langweilig. Direkt am 2. Februar spricht er auf der OOP über "Warum Teams ohne gemeinsames Ziel nicht dysfunktional sein müssen".

Dabei sein lohnt sich! ; )

Hier geht´s zur Konferenzpage

22. Februar Jens Coldewey bei den kanban Days

christian-braun — Mon, 06 Dec 2021 15:50:13 +0000

Jens Coldewey ist am 22. Februar bei den @kanban Days 2022 als Speaker zu Gast. Sein Thema: "Flow in der Strategiefindung"

Wir freuen uns schon!

Hier geht´s zur Konferenzpage

14. Dezember: Agile Tuesday "Die adaptive Organisation"

christian-braun — Mon, 06 Dec 2021 15:40:13 +0000

"Die adaptive Organisation" mit Christoph Mathis

Fast unbemerkt hat sich neben der uns vertrauten Agilität ein Ökosystem entwickelt, das von einem ganz anderen Ansatz kommt: die Struktur und die Kultur eines Unternehmens als Ganzes neu zu denken.
Wir reden von Weiterentwicklungen von Holokratie, Soziokratie und so weiter.. Das Interesse an den Firmen die sich so ein Modell ausgesucht haben, ist dramatisch gestiegen und es sind auch viele Neue dazugekommen: waren es vor einiger Zeit vor allem kleinere Unternehmen von bis zu 250 Mitarbeitern, so gibt es jetzt große Firmen, die sich komplett als verteilte Organisation von autonomen Teams organisiert haben. Ich zeige einige Beispiele, und versuche nachzuvollziehen was die gemeinsamen Merkmale dieser Unternehmen sind, warum sie für uns als Agilisten interessant sind und versuche eine Prognose über ihre Erfolgsfaktoren.

Wir freuen uns schon sehr auf euch!
Euer Krishan und das Agile Tuesday Team

Remote und interaktiv. Bring Your Own Beer ;-)

Hier geht´s zur Anmeldung

Agiles Tuesday Januar "Agiles MINDSET - Neurowissenschaftlich betrachtet"

christian-braun — Thu, 16 Dec 2021 14:00:44 +0000

"Agiles MINDSET – Neurowissenschaftlich betrachtet – mit Übungen zu Agilen Werten auf der Basis von Achtsamkeit" mit Anita Frey

Sehr oft ist von Begriffen die Rede wie:

A Winners Mindset
High-Performance Mindset
Agiles Mindset
…

Was genau ist ein MINDSET, was sagt der aktuelle Forschungsstand der Neurowissenschaft dazu und wie kann man es mit einfachen Übungen aus der Achtsamkeitslehre verändern?

Das erzählt Euch Anita Frey an diesem Agile Tuesday.

Zu allen agilen Werten (Respect, Courage, Focus, Openness, Commitment und Trust) erfahrt Ihr die neurowissenschaftlichen Zusammenhänge und warum es nicht funktioniert sich „vorzunehmen“ das Mindset zu verändern. Zusätzlich praktizieren wir gemeinsam kurze Auszüge aus möglichen Übungen. Seht selbst, was es mit Euch macht.

Wir freuen uns schon sehr auf euch!
Euer Agile Tuesday Team und Anita

Remote und interaktiv. Bring Your Own Beer ;-)

Hier geht´s zur Anmeldung

Die Glasdecke - Wenn Agilität auf Budgets trifft

jens — Wed, 02 Feb 2022 11:29:37 +0000

Wer in größeren Organisationen Agilität einführt, kennt das Problem: Mit viel Mühe hat man sich geeinigt, ein bestimmtes Feature zu bauen und plötzlich meldet sich einer der beteiligten Manager fragt "Und aus welchem Budget sollen wir das jetzt bezahlen?"

Was vielen als lästige Formalie scheint, ist in Wirklichkeit Ausdruck einer fundamentalen Inkompatibilität Agilen Arbeitens mit traditionellen Budgetierungsprozessen, argumentiert Bjarte Bogsnes in seinem lesenswerten Artikel "Agile Transformation and the Elephant in the Room". Stammgäste unserer Agile World kennen Bjarte als Keynote Speaker, ich arbeite mit ihm seit einigen Jahren im Rahmen der Supporting Agile Adoption Initiative der Agile Alliance zusammen.

Die Techniken der Budgetierung, die James McKinsey vor fast hundert Jahren entwickelt hat, so Bogsnes, sind schlichtweg nicht mehr flexibel genug, um in der heutigen Zeit bestehen zu können. Als Alternative fasst er in dem Blogbeitrag die Grundideen von Beyond Budgeting zusammen.

Das Problem der Budgetierung

Um Unternehmen mit der notwendigen "Business Agility" steuern zu können, empfiehlt Bogsnes, die drei Zwecke der Budgetierung zu entwirren und in drei getrennte Prozesse aufzuspalten:

Zielsetzung: Sich Ziele zu setzen, ist ein wichtiges Mittel, um gemeinsam an einem Strang zu ziehen. Das dürfen gerne auch ambitionierte Ziele sein, solange sich alle einig sind.
Vorhersagen: Um mittel- und langfristige Verpflichtungen eingehen zu können, kommt man um einen realistischen Blick auf die Zukunft nicht drum rum. Sollen wir neue Kolleginnen und Kollegen einstellen? Werden wir ausreichend Inhalt zur Messe fertig haben, um eine Kampagne zu starten? Werden wir ausreichend Produkte verkaufen, um in die neue Fabrik zu investieren? Bei solchen Fragen führen ambitionierte Ziele selten zu den besten Entscheidungen, sondern nur ein nüchterner Blick auf die Realitäten.
Ressourcenallokation: Sollen wir noch fünf zusätzliche Teams aufbauen? Welche Prioritäten müssen wir in den nächsten Monaten setzen? Und wofür steht nicht genug Kapazität zur Verfügung und muss deshalb verworfen werden? Oft genug wird darüber gejammert, "dass das Business nicht bereit ist, Entscheidungen zu treffen". In Wirklichkeit führt die Vermischung der drei unternehmerischen Aufgaben dazu, dass niemand die zur Verfügung stehenden Kapazitäten und Ressourcen wirklich gut einsetzen kann.

Als Agilist ist man versucht, sofort "wir kümmern uns doch genau darum!" zu rufen. Damit verkennt man aber, dass Bogsnes hier auf einer anderen Flughöhe argumentiert. Es geht ihm nicht um Sprintziele oder empirische Planung, sondern um Unternehmensplanung, also Portfoliomanagement, Finanzplanung und Strategieumsetzung.

Das zeigt aber auch, dass Beyond Budgeting und Agilität nicht nur irgendwie ähnliche Geschwister eines gleichen Mindsets sind, sondern jede ernsthafte Agile Transition irgendwann auch die Frage nach der Unternehmenssteuerung aufwirft. Und hier liefert Beyond Budgeting Ansätze, die entstanden sind, "indem wir es selbst getan haben und anderen dabei geholfen haben", um das Agile Manifest (nicht ganz korrekt) zu zitieren.

Agilität und Beyond Budgeting

Agiles Arbeiten auf der operativen Ebene liefert die perfekte Grundlage für informierte Entscheidungen. Mit empirischer Planung können wir aus gemessenen Daten szenariobasierte Vorhersagen ableiten und - mit ein wenig "statistischem Voodoo" sogar deren Eintrittswahrscheinlichkeiten abschätzen. Durch stabile Teams und Flowprinzipien können wir sicherstellen, dass zugewiesene Kapazitäten auch tatsächlich zur Verfügung stehen und Allokationen sich nicht in der Komplexität der Organisation verlieren. Hypothesen-getriebene Produktentwicklung und validiertes Lernen ermöglichen uns schließlich, lohnenswerte Ziele zu entwickeln und auf sie hin zu arbeiten.

Beyond Budgeting erlaubt es, diese Fähigkeiten auch zur Unternehmenssteuerung zu nutzen. Umgekehrt erlaubt es Beyond Budgeting auch, das Unternehmen so flexibel zu steuern, dass man die Möglichkeiten Agiler Umsetzung tatsächlich auch am Markt ausnutzen kann. Echte Business Agility entsteht, wenn man die zuverlässige und schnelle Reaktionsfähigkeit agiler Lieferung mit flexibler Unternehmenssteuerung kombiniert. Beyond Budgeting entfernt die Glasdecke, an die Agile Transformationen früher oder später stoßen.

Bjarte Bognes' Artikel ist ein guter Start, um sich mit dem Thema zu beschäftigen. Sprechen Sie mich an, wenn Sie sich für mehr Details interessieren.

Agile Tuesday Februar: "Darf man noch Lean sagen?"

christian-braun — Tue, 25 Jan 2022 11:58:15 +0000

Als Agile anfing war Lean noch eng damit verwoben – mittlerweile liest man kaum noch davon.

Sollten wir jetzt nicht mehr auf Lean gucken? Wir meinen: Doch, gerade… und gucken uns das am Beispiel Kanban konkret an.

Die Wurzeln der Kanban Methode mit ihrem starken Fokus auf Change-Management und Empowerment liegen in der Arbeit von W. Edwards Deming und Tahichi Ohno – vielfach bekannt als TPS (Toyota Produktion System) oder ‚Lean‘.

Will man die Kanban Methode wirklich für mehr benutzen, als nur Zettel über die Wand zu schieben, ist ein Blick auf auf Lean nicht nur hilfreich, sondern eigentlich unvermeidlich. Gerade aus ‚dem Lean‘ kommen viele der Ansätze wie

das Visual Management (als Ansatz zum Empowerment ),
die Improvement Kata (als Führungsmethode),
das Jidoka Konzept (als Ansatz zum Umgang mit Automatisierung),
und viele andere Ideen für Change und Organisation, die wir in diesem Talk vorstellen und in den Kontext aktueller Change Ansätze (wie der Kanban-Methode, Scrum, SAFe, etc :-p ) bringen.

Wir freuen uns schon auf euch!

Euer Agile Tuesday Team

Hier geht´s direkt zur Anmeldung

Nachtrag zu "Die Glasdecke - Wenn Agilität auf Budgets trifft"

jens — Thu, 24 Feb 2022 15:06:04 +0000

In meinem letzten Blogbeitrag "Die Glasdecke - Wenn Agilität auf Budgets trifft" hatte ich mich mit den Problemen beschäftigt, die auftreten, wenn klassisch geführte Organisationen Agil werden wollen, aber an ihren alten Finanzstrukturen festhalten. Ich habe einige Reaktionen auf den Beitrag erhalten, vielen Dank dafür. Eine davon möchte ich Teilen: Constantin Tornow hat mich auf einen Beitrag von Franz Wirnsperger und Klaus Moeller in der Zeitschrift Strategic Finance aufmerksam gemacht: "The Guided Self-Control Management Model".

Wirnsperger und Moeller analysieren das Problem mit ähnlichen Schlüssen wie ich sie auch wiedergegeben hatte und geben zusätzlich noch praktische Tipps und Hinweise vor allem zur Zielsetzung und Incentivierung. Ein lesenswerter Beitrag aus der Praxis moderner Unternehmensführung. Danke, Constantin für den Tipp.

Agile Tuesday März: "Extradependent Teams" mit Jens Coldewey

christian-braun — Thu, 17 Feb 2022 15:54:46 +0000

"Extra-Dependent Teams: Warum Teams ohne gemeinsames Ziel nicht dysfunktional sein müssen"

Teams sollten interdisziplinär sein und möglichst fokussiert auf ein gemeinsames Ziel hinarbeiten. So lehrt es uns sowohl die klassische Management-Literatur als auch agile Methoden wie Scrum. Nur leider gibt es in der Praxis immer wieder sehr erfolgreiche Teams, auf die keines dieser Kriterien zutrifft.
Wenn man genauer hinsieht, entdeckt man, dass es verschiedene Arten von Teams gibt, die unterschiedlich organisiert und geführt werden sollten. Gemeinsam werden wir die verschiedenen Spielarten erkunden.

Die Session basiert auf dem Konzept von "Extradependent Teams" von David Kesby. Diese Teams, die nach außen wirksam sind, kommen in praktisch jeder Organisation vor und werden vom klassischen Teamgedanken außen vor gelassen. Dabei bilden sie - richtig geführt - einen Pfeiler der Organisation. Wer sie von "normalen", sogenannten "Intredependent Teams" unterscheiden kann, stellt sicher, dass funktionsfähige Teams nicht durch ein unpassendes Paradigma in dysfunktiopnale Gruppen zerlegt werden.
Wir werden die wesentlichen Elemente des Konzepts interaktiv erarbeiten.

Hier geht´s zur Anmeldung

Wir freuen uns schon auf euch!

Euer Agile Tuesday Team

Update: Hier findet Ihr die Slides zum Event:

2022.03.08.ExtradependentTeams.AgileTuesday.JC Download

Keine Angst vor Konflikten - wenn die Scrum Master:in die Gegengifte kennt

Sabine — Fri, 18 Feb 2022 09:52:46 +0000

Martina ist mit Sicherheit die erfahrenste Entwicklerin im Team. Sie kennt sich gut aus mit dem System und hat Ahnung davon, wie man eine gute Architektur erstellt. Das ist aber kein Grund, die anderen Teammitglieder herumzukommandieren, finden diese. Sie fangen an, hinter Martinas Rücken über sie zu reden. "Sie tut so als wäre sie unsere Chefin, das ist sie aber nicht! Immer von oben herab, das geht mir auf den Senkel." Beim letzten Product Backlog Refinement lag Martinas Schätzung für eine Story deutlich über den anderen. Diesmal schlossen die Teammitglieder sich aber nicht, wie so oft, Martinas Meinung an. Nach einer hitzigen Diskussion über den "richtigen" Schätzwert schimpft Martina gereizt: "Meine Güte, dann macht doch was ihr wollt! Klar, wenn ihr wieder nur diesen Quick and Dirty Code schreibt, geht es natürlich schneller, und das fliegt uns dann um die Ohren". Wenn dies kein Online-Meeting wäre, würde sie sicher den Raum verlassen und die Tür hinter sich zuknallen.

Tim steht nicht gerade im Ruf, der fleißigste zu sein. Er achtet penibel auf die Einhaltung seiner Arbeitszeiten, ist bei der Auslegung seiner Pausenzeiten aber großzügig. Selbst vor dem Release-Datum, wenn alle anderen noch mal so richtig reinklotzen, hält Tim sich vornehm zurück. Beim Daily Scrum sind Spannungen selbst über die Zoom-Fenster spürbar. Gestern bemerkte Elisa schnippisch: "Na, ist der Herr diesmal mit seinen Aufgaben fertig geworden? Ansonsten wäre ich natürlich liebend gern bereit, sie noch mit zu erledigen, denn ich habe ja sonst nichts zu tun." Tim sah sehr eingeschüchtert aus, berichtete aber sachlich über seine Tätigkeiten, als ob nichts wäre.

Klaus, der Product Owner, und Manuela, das Teammitglied, sind unterschiedlicher Meinung. "Wir müssen unbedingt dieses Feature mit ins nächste Release nehmen, sonst steigt uns unser Stakeholder aufs Dach, und ich bekomme Riesenärger", sagt Klaus. Manuela entgegnet: "Aber du weißt doch, wir haben uns am Ende vom letzten Sprint geeinigt, dass wir auf jeden Fall dieses Reenngineering machen müssen, sonst häufen wir weiter technische Schulden an."

Was tun als Scrum Master:in?

Zunächst mal: ruhig Blut und Nachdenken: Handelt es sich hier überhaupt um einen Konflikt, und wenn ja, um was für einen?

Viele Menschen haben Angst vor Konflikten. Sie befürchten Verletzungen. Die meisten von uns tragen schlimme Erfahrungen aus Konfliktsituationen mit sich herum. Als Scrum Master:in bist du verantwortlich, dich um den Konflikt zu kümmern, aber am liebsten würdest du ihn unter den Teppich kehren, aber das ist der falsche Weg. Mit diesem Blog-Artikel möchte ich dir Mut machen, konstruktiv mit Konflikten umzugehen.

Heiße Konflikte kann man nicht übersehen oder überhören. Sie werden leidenschaftlich ausgetragen. Die Konfliktparteien kämpfen für ihre Ziele und darum, sich durchzusetzen. Emotionen haben die Herrschaft über die vernünftigen Teile des Gehirns übernommen, so dass man den Argumenten der Gegenseite gegenüber nicht mehr zugänglich ist. Die Situation mit Martina im Product Backlog Refinement ist so ein Konflikt. Heiße Konflikte kündigen sich oft an durch Vorboten wie verdrehte Augen oder genervtes Stöhnen. Du hast dann die Chance einzugreifen und eine Eskalation zu vermeiden. Dann besteht eine gute Chance zur Klärung, zum Beispiel indem du die gemeinsamen Ziele herausarbeitet. Wichtige Sofortmaßnahme, um eine Eskalation zu verhindern: Sich nicht selbst in den Konflikt reinziehen lassen, sondern einen klaren und kühlen Kopf bewahren. Pause einläuten, damit sich die erhitzten Gemüter beruhigen können.

Ein kalter Konflikt ist weniger leicht zu erkennen. Es findet wenig direkte Kommunikation statt, man spürt Frustration und Enttäuschung. Die Konfliktpartner gehen sich aus dem Weg, beschränken sich auf Dienst nach Vorschrift, und die Qualität der Zusammenarbeit nimmt ab. Das macht kalte Konflikte schwieriger zu bearbeiten. Tim und seine Teammitglieder zeigen Anzeichen eines kalten Konflikts. Vielleicht ist etwas in der Vergangenheit passiert, was dazu geführt hat. Deine Aufgabe ist hier, den unter den Teppich gekehrten Konflikt wieder hervorzuholen. Das erfordert Mut und Fingerspitzengefühl. Es könnte nämlich sein, dass der glimmende Konflikt wieder richtig auflodert. Wichtig ist es, für eine sichere Umgebung zu sorgen und dafür, dass die Konfliktpartner respektvoll miteinander umgehen.

Und manchmal liegt auch gar kein Konflikt vor, sondern einfach eine Meinungsverschiedenheit, wie bei Klaus und Manuela. Sie tauschen sich leidenschaftlich, aber sachlich aus und schlagen nicht unter die Gürtellinie. Dann kannst du dich "ganz normal" als Facilitator betätigen und dafür sorgen, dass die Argumente gehört und verstanden werden.

Konflikte gehören zum Alltag in Teams, die gemeinsam Verantwortung übernehmen und Entscheidungen treffen sollen. Gerade in der Team-Building oder Forming-Phase treten sie häufig auf. Konflikte sind notwendig, damit Teams aus Fehlern der Vergangenheit lernen, entscheidende Maßnahmen ergreifen und das gesamte Talent und die Erfahrung des Teams nutzen können. Wir wollen "psychologische Sicherheit" erreichen: jede:r soll seine Meinung frei äußern können, über Schwierigkeiten und Fehler sprechen können. Das funktioniert nicht, wenn die Menschen Angst vor Konflikten haben.

Patrick Lencioni hat sich in seinem Buch "The Five Dysfunctions of a Team" mit Konflikten beschäftigt. Dort beschreibt er fünf Ebenen, die aufeinander aufbauen.

Die Angst vor Konflikten ist eine direkte Folge der ersten Dysfunktion, dem fehlenden Vertrauen. Ohne die Leitplanken, die das Vertrauen bietet, fürchten die Teammitglieder, dass jeder Konflikt in persönliche Sticheleien und unproduktive Streitereien ausartet, so dass sie Konflikte ganz vermeiden. Folge davon sind die drei oberen Ebenen: fehlendes Commitment, Vermeidung von Verantwortung und damit auch schlechte Ergebnisse.

Beim Umgang mit Konflikten musst Du zunächst unterscheiden zwischen inhaltlichen Konflikten, die (noch) nicht eskaliert sind und eskalierten Konflikten, bei denen die inhaltliche Meinungsverschiedenheit längst keine Rolle mehr spielt. Zu letzteren hat sich das Eskalationsmodell von Johann Glasl als hilfreiches Werkzeug etabliert [ Konflikteskalation nach Friedrich Glasl – Wikipedia. ] Als Scrum Masterin solltest Du aber das Team dabei unterstützen, Konflikte gar nicht erst eskalieren zu lassen. Hier ist das Wissen um die 4 Giftstoffe in Beziehungen - Schuldzuweisung, Verachtung, Verteidigung und Abschottung - und ihre Gegenmittel hilfreich. Es handelt sich um die häufigsten Fehlverhaltensweisen in Teams, die sich direkt negativ auf die Teamarbeit und vertrauensvolle Beziehungen auswirken. Die vier Gifte zu kennen und zu teilen trägt dazu bei, Verständnis füreinander zu wickeln und Konflikteskalation zu verhindern. Dies ist besonders wichtig, da jeder Mensch - bis zu einem gewissen Grad - von Zeit zu Zeit eines oder mehrere von ihnen anwendet. Es liegt einfach in unserer DNA.

Das Konzept der vier Gifte - auch die vier Reiter der Apokalypse genannt - wurde von John Gottman, entwickelt, der vor allem zu Beziehungsanalyse und Ehestabilität geforscht hat. Er behauptet, eine Methode entwickelt zu haben, mit der mit 90 % Wahrscheinlichkeit vorausgesagt werden kann, welche neu verheirateten Paare verheiratet bleiben und welche nach 4 bis 6 Jahren geschieden sein werden. Und diese Methode basiert auf dem Konfliktverhalten der Partner:innen. Es sind grundlegende Verhaltensmuster, die du vielleicht in dir selbst und deiner Partner:in erkennst - und die auch Teammitglieder in sich tragen. Mehr zu dem Thema findest du hier: Teamwork: 4 toxins that make teams derail, and how to avoid them (shinecoachingbarcelona.com).

Hier ist eine Übersicht über die vier Gifte und ihre Gegengifte:

Gift	Beispiele für Gegengifte
Schuldzuweisung	Kritisiere - wenn überhaupt - das Verhalten und nicht die Person. Besser sind konkrete Verbesserungsvorschläge. Wenn du selbst kritisiert wirst, versuche es nicht persönlich zu nehmen. Hör gut zu und versuche, die Notlage deines Gegenübers zu erkennen. Vielleicht ist eine Entschuldigung angebracht?
Verachtung	Sprich über deine Beobachtung und deine Wahrnehmung der Verachtung. Welche Wirkung hat diese Verachtung auf dich? Äußere deinen Wunsch, wie die Situation anders zu lösen sei.
Verteidigung	Überlege dir: "Was wäre wenn... 2% von dem, was ich da höre, wahr wären?" Wenn du merkst, dass jemand anfängt, sich zu verteidigen, äußere Respekt und Anerkennung. Hör gut zu, was die Person sagen will, vielleicht fühlt sie sich nicht ausreichend gehört.
Abschottung	Die Abschottung ist normalerweise eine Reaktion auf Angst oder Gefahr. Versuche einen sicheren Raum ohne Angst zu schaffen.

Du kannst dieses Konzept in Form eines Workshops mit deinem Team erforschen. In vorpandemischen Zeiten, als wir noch gemeinsam in Räumen gearbeitet haben, sah das so aus: die vier Gifte wurden auf PostIts geschrieben und auf dem Boden in vier Quadranten ausgelegt. Die Teammitglieder wurden gebeten, sich zu dem PostIt zu stellen, das ihr typisches Konfliktverhalten am ehesten beschreibt. Jede:r darf etwas dazu sagen Das geht ganz spielerisch, gibt oft Grund zum Lachen und bringt die Leute einander näher. Sie erkennen Muster, die erklären, warum es im Team zu Konflikten kommt, und entwickeln Verständnis füreinander. Dann überlegt das Team gemeinsam, welche Gegengifte sie anwenden können. Vielleicht kann man daraus direkt Teamregeln ableiten. Den Workshop kann man auch remote mit Miro-Boards machen, es ist aber nicht so wirkungsvoll.

Voraussetzung für so einen Workshop ist, dass die Teammitglieder bereit dazu sind. Dies solltest du durch Einzelgespräche vorbereiten. Du erkennst nun die Vergiftungen der Teammitglieder: Tim hat sich abgeschottet, als Reaktion auf eine Schuldzuweisung. Martina hat mit Schuldzuweisungen reagiert. Als Gegengift könntest du Tim beiseite nehmen und ein Gespräch unter vier Augen mit ihm führen. Vielleicht hat er gute Gründe dafür, warum er immer pünktlich nach Hause will und seinen Arbeitseinsatz auf das Notwendige reduziert. Ihn vor allen Leuten mit seinem Verhalten zu konfrontieren, würde ich nicht empfehlen. Danach könntest du eine Diskussion im Team führen mit dem Ziel, Vereinbarungen zum Arbeitseinsatz zu treffen. Vielleicht sind die 2% Wahrheit in Tims Arbeitsweise, dass er sich vor Überlastung schützen will, und vielleicht würde das den anderen auch ganz gut tun.

Auch im Fall von Martina würde ich mit einem persönlichen Gespräch beginnen. Vielleicht fühlt sie sich in ihrer Rolle als Expertin nicht ausreichend gewürdigt. Vielleicht kann sie eine neue Verantwortung darin finden, eher als Coach zu agieren.

Fazit: du bist als Scrum Master:in gefragt, bei Konflikten einzugreifen und zu verhindern, dass sie eskalieren und das Team schädigen. Damit du nicht auf Dauer den Hut des Konfliktlösers tragen musst, arbeite mit deinem Team daran, dass sie Konflikte selbst erkennen und lernen, sie konstruktiv zu nutzen. Das ist ein Schritt auf ihrem Weg zum effektiven Team. Deine Aufgabe ist es, für die psychologische Sicherheit zu sorgen, dass dies möglich werden kann. Und noch etwas: wenn du dich dem Konflikt nicht gewachsen fühlst, suche dir Hilfe bei Menschen, die den Umgang mit Konflikten gelernt haben - und nicht nur einen Blog-Artikel darüber gelesen haben. Oder besuche unser Training zum Advanced Certified Scrum Master Advanced Certified Scrum Master - vor Ort oder Live-Online (improuv.com). Die Inhalte dieses Blog-Artikels besprechen wir dort ausführlich.

Agiles On-Boarding

zoi — Tue, 08 Mar 2022 13:53:18 +0000

Von Martin Krensing und Zoi Natsiopoulou

Vor einiger Zeit haben uns die Scrum Master:innen in unserem Projekt mit folgender Frage beglückt: Wir bekommen bald neue Kolleg:innen in die Teams. Das ist ja ganz toll, aber wie kriegen wir die jetzt gut eingearbeitet? Wie schaffen wir den Know-How-Transfer?

Das Schöne an solchen Fragen ist, dass sie universell sind. Wir begegnen ihnen immer wieder in unseren Projekten. Deswegen möchten wir unsere Perspektive auf das On-Boarding und unsere Erfahrungen damit teilen. Der Blog kann auch sehr gut als Leitfaden für einen Workshop verwendet werden. Zumindest haben wir damals genau das getan und uns das Thema gemeinsam mit den Scrum Master:innen erarbeitet.

Dabei haben wir zu Beginn erstmal ein gemeinsames Verständnis über Begrifflichkeiten geschaffen, die einem beim Thema On-Boarding über den Weg laufen.
Darauf aufbauend konnten wir ein Modell zur Begleitung des On-Boardings vorstellen. Die Teilnehmer:innen haben das Modell mit Leben gefüllt, indem sie ein auf ihre neuen Teammitglieder zugeschnittenes initales Onboarding-Backlog mit Themen und Lernmethoden erstellt haben.

Die Grundlagen

Das Thema On-Boarding ist aus unserer Sicht primär ein Thema von Lernen und Kennenlernen, Wissensaufbau, Kompetenzerwerb und das Eingehen sozialer Verbindungen. In agilen Software-Projekten findet die Entwicklung vorzugsweise in selbstorganisierten, cross-funktionalen und lernenden Teams statt. Dafür braucht es zusätzlich soziale Kompetenzen wie z.B. Kommunikationsfähigkeit, aber auch Wissen darüber, wie agiles Arbeiten funktioniert und was es bedeutet.

Als Einstieg haben wir daher mit den Teilnehmenden gemeinsam die Grundlagen/Begrifflichkeiten erarbeitet.

Wissensgebiete

Wir haben das Ganze mit der Annahme gestartet, dass wir uns in einem komplexen Umfeld befinden. Die Entwicklung von Software ist komplex. Sie ist eine wissensintensive Tätigkeit, die sowohl allgemeines technisches Wissen als auch Expertise in spezifischen Domänen erfordert.
Wir haben die folgenden Wissensgebiete mit jeweiligen Lernfeldern gefunden.

Neue Mitarbeiter:innen stehen vor der Herausforderung, sich gut in die Organisation und in die Teams zu integrieren und dadurch vollwertige und produktive Mitglieder zu werden. Dazu müssen sie sich Wissen aus unterschiedlichen Gebieten aneignen. Wir haben drei Wissensgebiete definiert: Fachlich, Technisch und Organisation. Die Neuen müssen sich Wissen über die Produkte oder Dienstleistungen des Unternehmens, das technische Umfeld und die Organisationsstrukturen erarbeiten. Gleichzeitig brauchen sie Informationen darüber, wie das Team arbeitet und wie es "tickt". Die Abbildung zeigt für jeden der Lernbereiche Beispiele. Diese sind geordnet von übergreifend, also organisationsweit hin zu indiviudell. Die Sortierung ist nützlich, da sich die Lernmethoden hier unterscheiden. Wir haben diese Darstellung der Lernbereiche verwendet, weil sie einen guten Rahmen und gleichzeitig Flexibilität bietet, um an die realen Anforderungen des Kunden angepasst zu werden.

Wissens- und Lernarten

Nachdem wir die Wissensgebiete beschrieben haben stellen wir uns die Frage, ob es ausreicht einen supi-dupi Plan auszuarbeiten und den neuen Kolleg:innen ein 250-seitiges Pamphlet auf den Tisch zu legen?! So nach dem Motto "Macht mal". Die Teilnehmenden unseres Workshops waren sich recht schnell einig: Nein, es reicht definitiv nicht aus. Dazu ist Lernen zu komplex und individuell.

Über eine kurze Diskussion konnten wir zwei Wissensarten herausarbeiten: Explizites und implizites Wissen.
Die Basis für unsere Überlegungen bildet das SECI-Modell (Nonaka & Takeuchi, 1995), das wir für uns und unsere Zielgruppe adaptiert und visualisiert haben.

Expliztes Wissen kann beispielsweise in einem organisationsinternen Wiki dokumentiert werden. Implizites Wissen ist Erfahrungswissen der Organisationsmitglieder, also etwas "können, ohne genau sagen zu können wie".
Wenn wir das Lernen als die Aneigung von explizitem und impliziten Wissen verstehen, lassen sich zwei Lernarten unterscheiden:
Das Erlernen von explizitem Wissen bezeichnen wir als Wissensaufbau.
Das Aneigenen von implizitem Wissen nennen wir hingegen Kompetenzerwerb.

Lernmethoden

Für die zwei Lernarten gibt es unterschiedliche Lernmethoden. Als Lernmethode verstehen wir ein konkretes Vorgehen das beschreibt, wie man sich Wissen bzwl. Kompetenzen aneignet. In unserem Workshop wollten wir von den Teilnehmer:innen wissen, welche Lernmethoden sie bereits kennen.
Die Ergebnisse eines kurzen Brainstormings können sich sehen lassen. Von Checklisten, Pair-Programming, Socializing, einen Mentor zur Verfügung stellen und kleine Lernvideos von Kolleg:innen für Kolleg:innen aufzunehmen, bis hin zu persönlichem Coaching - es wurden viele tolle und praxistaugliche Ideen vorgestellt und diskutiert.
Wir haben einige davon in Verbindung zu den zwei Lernarten Wissensaufbau und Kompetenzerwerb gebracht. Nicht jede Lernmethode passt zu jedem Lernfeld. Wie soll beispielsweise ein Handbuch oder Video etwas vermitteln, das die Kolleg:innen rein intuitiv machen, weil sie das System über Jahre kennen?

Lernumgebung und individuelle Lernstile

Wir können also festhalten, dass es zwei unterschiedliche Arten von Wissen (Explizit, Implizit) und dazu passende Lernarten (Wissensaufbau, Kompetenzaufbau) gibt. Zu den Lernarten gibt es jeweils passende Lernmethoden. Dazu gesellen sich jetzt noch Lernumgebungen und individuelle Lernstile.

Wissensaufbau und Kompetenzerwerb haben unterschiedliche Anforderungen an die Lernumgebung. Eine für den Wissensaufbau lernfördernde Umgebung sollte beispielsweise Zeit und Rückzugsmöglichkeit bieten. Kann ich in einem Teamraum in Ruhe ein Einführungsvideo ansehen? Darüberhinaus fordert der Kompetenzerwerb eine sichere Lernumgebung. Das Wort "sicher" bezieht sich hier auf die soziale Umgebung. Es geht also um die psychologische Sicherheit als Rahmenbedingung. Sieht die Organisation das Lernen aus Fehlern als eine Lernchance und fördert sie es? Hier spricht man häufig von Fehlerkultur. Aus unserer Sicht passt der Begriff Lernkultur besser, da das Lernen aus Fehlern nur eine Voraussetzung für eine gute Lernumgebung für den Kompetenzerwerb darstellt .

Jeder lernt individuell. Manche Menschen mögen die Herausforderung, gleich mit echten Aufgaben zu starten, andere brauchen mehr Sicherheit und möchten sich lieber langsam herantasten. Manche brauchen Theorie vor Erfahrung, manche umgekehrt (Kolb, 1984).
Wir sehen individuelles Lernen als eine Kombination aus Lernmethoden und passender Lernumgebung an. So können wir unterschiedliche Lernstile beachten.

Damit haben wir ein gemeinsames Domainenmodell des Lernens erarbeitet . Nun können wir unsere On-Boarding Reise antreten.

Die On-Boarding Reise

Nachdem ein gemeinsames Verständnis für den Kontext und die Rahmenbedingungen für gutes On-Boarding geschaffen wurden, haben wir das Modell von Talya N. Bauer (2010) als Grundlage für eine Gruppenübung genommen. Für alle, die gerne Theorie studieren und sich wundern, warum es ganz anders als im Buch ist: Auch dieses Modell haben wir an unsere Zielgruppe und den agilen Kontext angepasst.

Das Tolle an diesem Modell aus unserer Sicht ist, dass der Recruiting-Prozess bereits Teil des On-Boardings ist. Schließlich geht es darum, auf Seiten der Bewerber:innen realistische Erwartungen des Unternehmens und der Rolle zu formen. Hier ist ein agiler Recruiting-Prozess besonders wichtig, in dem die Teammitglieder idealerweise von der Bewerbung bis zur Entscheidung einbezogen werden. Das hilft später bei der Integration der/des Neuen in das Team und erzeugt weniger Widerstände. Am besten lernen sich Kandidat:in und Team in einer echten Situation wie bspw. dem Daily kennen, mit anschließender Arbeitsprobe und gemeinsamem Mittagessen. So kann die Stimmung im Team genauso wahrgenommen werden wie die Arbeitsweise und die Art bzw. der Anspruch der Aufgaben. Besonders wertvoll wird es, wenn sich das Team gemeinsam um dieses Kennenlernen kümmert und das Ganze plant und durchführt. HR sehen wir hier eher in einer Beratungs- und Unterstützungsfunktion.

In der Orientierungsphase geht es darum, Informationen zu liefern. Hier können Anleitungen, Checklisten, Handbücher, Videos und andere formalisierte Dokumente erste Anhaltspunkte liefern. Idealerweise stellt man in dieser Phase eine Mentor:in zur Seite, um Informationen zur Kultur, Umgangston und Historie des Unternehmens bzw. des Teams zu vermitteln. So ist es gut zu wissen, wo man sein Büromaterial bekommt, aber vielleicht sollte man nicht vor 12 Uhr in den Raum, weil der Kollege dort ein Morgenmuffel ist?

Die nächsten beiden Bereiche, Coaching & Training sowie Feedback-Tools, gehören für uns zusammen und sind als wiederkehrender Kreislauf zu sehen, der hoffentlich auch nach dem On-Boarding weitergeht. Schließlich sind wir nach Scrum organisiert, und Lernen gehört zum Framework einfach dazu. Hier können wir viel von Scrum adaptieren, um den Prozess gut zu gestalten. Es hat sich bewährt, dass Teams Einarbeitungsstories zusammen mit den neuen Kollegen erarbeiten und sie in das Team-Board integrieren. Die Stories durchlaufen den ganz normalen Flow, sind Teil des Reviews und werden in der Retrospektive reflektiert. Bilaterales Feedback ist hier sehr wichtig. So können die Stories für den nächsten Sprint an den Bedürfnissen der neuen Kollegen, also deren individuellen Lernstil, angepasst werden. Während des Doings können Methoden wie Pair-Programming und Coaching, aber auch Trainings und Workshops den Lernprozess unterstützen. Bei den fachlichen Inhalten sollte aber immer der Fokus auf der Umsetzung liegen: Ergebnisse in kurzen Zyklen, auch wenn sie noch so klein oder fehlerhaft sind, zählen mehr als umfangreiche und perfekt umgesetze Aufgaben. Schließlich sollen sich die Neuen an schnelle Feedbackzyklen und Lernen gewöhnen.

Das Ziel der On-Boarding Reise ist erreicht, wenn die "Neuen" vollwertige und produktive Mitglieder der Organisation sind. Wie erwähnt darf hier das individuelle Lernen nicht enden. Das ganze Leben ist bekanntlich ein Quiz und damit eine nicht endende Lernreise.

Wir haben im Anschluss an diesen kurzen Theorie-Input die Teilnehmenden in zwei Gruppen aufgeteilt und ihnen die Aufgabe gegeben, mit dem bis hierher erworbenen Wissen und Erkenntnissen und unter Berücksichtigung ihrer Arbeitsweise sowie den vorhandenen organisatorischen Bedingungen ein initiales On-Boarding Backlog zu erarbeiten. Welche Themen seht ihr bei euren Teams, wie würdet ihr das On-Boarding methodisch begleiten? Wir haben uns sehr über die Ergebnisse gefreut. Alle waren hochmotiviert, das eine oder andere auszuprobieren, in der Scrum Master CoP ihre Erfahrungen zu teilen und an dem Thema weiter zu arbeiten.

Definition On-Boarding

On-Boarding = Organizational Socialization

"Onboarding refers to a process that helps new employees learn the knowledge, skills & behaviors they need to succeed in their new organisation" (S. 21, Bauer, T.N., Erdogan, B.: Organizational socialization: The effective onboarding of new employees. In: Zedeck, S. (ed.) APA Handbook of Industrial and Organizational Psychology, vol. 3, pp. 51–64. American Psychological Association, Washington, DC (2011)

Noch mehr zu diesem Themencluster findest du in einer dreiteiligen Blogbeitrags-Serie über HR und Agile Transformationen

Quellen

Bauer Talya N.; Onboarding New Employees: Maximizing Success; 2010

Nonaka I. & Takeuchi H., The knowledge creating company: How Japanese Companies create the dynamics of innovation, 1995

Kolb D., Experiental Learning: Experience as the Source of Learning and Development, 1984

Kostenloses Event zu Agile Leadership mit Sabine Canditt

Sabine — Wed, 09 Mar 2022 10:54:10 +0000

Psychologie der Veränderung – wie man Menschen durch unsichere Zeiten führt

Wir leben in unsicheren Zeiten – das wird uns durch den Krieg in der Ukraine und die Corona-Krise schmerzhaft bewusst. Aber auch unabhängig von diesen äußeren Kräften gerät in unseren Unternehmen einiges in Bewegung durch Klimakrise, Globalisierung, Digitalisierung. Veränderungsprozesse in einem komplexen System wie einem Unternehmen laufen selbstorganisiert ab. Das bedeutet, dass sie nicht planbar und von außen steuerbar sind – jedes selbstorganisierte menschliche Gehirn entscheidet selbst, was es annimmt und was nicht. Führung von Selbstorganisation bedeutet, einen Rahmen zu bieten für die inneren Veränderungen der Menschen. Dabei beginnen wir am besten bei uns selbst, denn: „Nur wer sich selbst führen kann, kann andere führen“ (Pater Anselm Grün). Wir möchten mit euch einen Blick in das menschliche Gehirn werfen, das zwei große Ziele kennt: Bedrohungen zu vermeiden und Belohnungen zu maximieren. Wenn Veränderungen als Bedrohung wahrgenommen werden, funktionieren Teile unseres Gehirns nicht mehr, die wir aber die Bewältigung von Herausforderungen brauchen. Wenn wir uns über diese Vorgänge bei uns selbst bewusst werden, können wir lernen, sie zu steuern. Das ist die Grundlage dafür, dass wir Empathie für andere in ähnlichen Situationen aufbauen und unsere Beziehung zu ihnen vertrauensvoll gestalten können. So entsteht ein Arbeitsklima, in dem sich Mitarbeitende ernst genommen und wertgeschätzt fühlen. ,

Hier könnt Ihr euch anmelden

Psychologie-der-Veransaltung Download

Flight Levels - Mit unterschiedlichen Flughöhen auf den Fluss der gesamten Organisation schauen

tina.rieger — Fri, 01 Apr 2022 11:25:56 +0000

Von Tina Rieger und Zoi Natsiopoulou

Flight Levels sind aktuell in aller Munde und entwickeln sich zu einem bekannten Modell für den Weg zu Business Agility. Das schöne an Flight Levels: Denken ist ausdrücklich erlaubt. Das ist das, was wir bei improuv leidenschaftlich gerne und gut tun. Denn wir sind davon überzeugt, dass individuelle Ansätze die auf das Ziel des Kunden eingehen, erfolgreiche Lösungen schaffen.

Was sind Flight Levels und was macht sie besonders?

Flight Levels sind ein Gedankenmodell, eine Art und Weise wie wir gemeinsam auf die gesamte Organisation blicken. Es hilft uns dabei, zu erkennen wo wir ansetzen müssen, um die Ergebnisse zu erzielen, die wir uns wünschen. Ziel ist es den größtmöglichen Verbesserungseffekt mit der kleinsten Veränderung zu erreichen. Das Grundgerüst von Flight Levels sind 5 Aktivitäten auf 3 Ebenen. Es ist ein wenig wie auf einem Hochstand. Man sieht andere Dinge als unten am Boden. Und gehen wir noch höher, vielleicht auf Vogelperspektive, dann wird der Blick noch weiter. Tauchen wir einmal in die 3 Ebenen der Flight Levels ein.

Fangen wir bodennah an. Die erste Ebene, das Flight Level 1, befasst sich mit der operativen Arbeit. Also mit dem Bereich, in dem Teams an der Umsetzung von Services, Lösungen und Produkten arbeiten. Wie die Teams dabei vorgehen ist nicht relevant, denn Flight Levels sind methodendenagnostisch. Das Vorgehen kann Scrum sein, Kanban oder traditionell. Wichtig ist, dass sich das Team gut organisieren kann und das Vorgehen zu ihrem Bedarf passt. Der Zeithorizont ist eher kurz und der Detailgrad hoch. Hier will das Team Wert für den Kunden liefern. Idealerweise kann es das alleine.

Die Realität zeigt jedoch, dass es oft mehrere Teams braucht, um ein Produkt zu entwickeln, das Wert für den Kunden bringt. Um hier Suboptimierungen zu vermeiden, hilft der Blick über die Teaminseln hinaus. Mit der zweiten Flughöhe verlassen wir die Teamsichtweise und schauen auf den Ende-zu-Ende Wertstrom. Flight Level 2 ist eine koordinative Ebene in der wir alle Produkte, Initiativen und Business Ideen in den Blick setzen können. Diese Ebene hilft uns, Abhängigkeiten zu erkennen und die Arbeit der Teams zu koordinieren. Die Aktivitäten im Flight Level 2 bringen die Teams zusammen, die es braucht um Wert zu schaffen und Produkte zu entwickeln, an denen der Kunde eine Freude hat und für die er bereit ist zu zahlen. Gibt es mehrere Wertströme in der Organisation, kann es auch mehrere Flight Level 2 Systeme geben.

Die dritte Ebene von Flight Levels richtet die Arbeit an den strategischen Zielen des Unternehmen aus. Vertreter der einzelnen Produkte bauen auf dieser Ebene gemeinsam die strategische Sicht auf. Wichtig ist, dass auch im Flight Level 3 Vertreter aus den anderen Ebenen dabei sind, um die Verbindung zwischen Strategie und Umsetzung herzustellen.

Die Flight Levels Ebenen sind nicht hierarchisch zu sehen, sondern in alle Richtungen durchlässig. Das heißt die strategische Ebene speist sich aus den Ebenen 1 und 2 und liefert gleichzeitig den richtigen Rahmen für diese. Sie ergänzen sich und schaffen dort Transparenz und Abstimmung wo diese gebraucht werden.

Wir haben uns in diesem Blog die Ebenen der Flight Levels angeschaut. Im nächsten Blogbeitrag widmen wir uns den 5 Aktivitäten.

Zitationen:

Leopold K., Agilität neu denken. Mit Flight Levels zu echter Business-Agilität. 2. Aufl., dpunkt.verlag, 2022.

Kaltenecker S. & Leopold K., Flight Levels - Eine kurze Einführung, dpunkt.verlag, 2022

Agile Tuesday April: "Agile on an organizational level with an expert on Beyond Budgeting" mit Steve Morlidge

christian-braun — Tue, 05 Apr 2022 11:30:25 +0000

Wichtig: Dieses Mal wird der Impuls auf Englisch vorgetragen:

’Scaling Agile' is a hot topic at the moment. But it begs two questions. What does ‘Agile’ or ‘agile’ mean at the level of an entire organisation? And what does ‘scaling' involve? In this talk Steve Morlidge will give his perspective on these questions, informed by his work in Beyond Budgeting and with the Agile Business Consortium. The aim is not to provide answers but to provoke debate that might help Agile practitioners deep their understanding of the challenges.’

Hier geht´s zur Anmeldung

Update: Hier stehen die Slides zum Agile Tuesday zur Verfügung

Scaling-Agile-Talk Download

Wir freuen uns schon auf euch!

Euer Agile Tuesday Team

Flight Levels - Wirkungsvolle Verbesserungen und Erfolge durch die passenden Aktivitäten

tina.rieger — Fri, 08 Apr 2022 08:13:52 +0000

Von Tina Rieger und Zoi Natsiopoulou

Wirkungsvolle Verbesserungen und Erfolge durch die passenden Aktivitäten.

Flight Levels bringen fünf Aktivitäten mit auf die sich ein Blick lohnt, denn sie haben sich als hilfreiche Hebel bei der Produktentwicklung herauskristallisiert. Schauen wir uns alle einmal an.

Die Situation sichtbar machen

Die erste Aktivität besteht darin, die Situation sichtbar zu machen. Das Ergebnis kann ein Board sein, das den aktuellen Wertstrom abbildet - von der Ideengenerierung bis zur Umsetzung und Messung. Dieses Board ist somit auf unser Ziel ausgerichtet, Kundenwert zu schaffen. Die Visualisierung hilft uns, Transparenz und ein gemeinsames Verständnis der Ausgangssituation zu entwickeln. Es ist ein Kommunikationstool. Nicht das Ergebnis zählt, sondern der Weg dahin. Wichtig ist, dass alle beteiligten Personen das Board gemeinsam bauen. Grundsätzlich gilt: es gibt kein richtig oder falsch und es soll zum Ziel passen. Es gibt natürlich auch andere Möglichkeiten der Visualisierung - erlaubt ist, was uns unterstützt, die aktuelle Situation zu erfassen.

Fokus herstellen

Die Visualisierung macht sichtbar, wie viel Arbeit im System ist, wie sie umgesetzt wird und wie lange es dauert bis sie fertig ist. In der Regel gibt es immer mehr Anforderungen und Ideen als das, was wir umsetzen können. Und deswegen ist Fokus entscheidend. Fokus ist das, was wir brauchen um ergebnisorientiert und erfolgreich unterwegs zu sein. Es macht Sinn Fokus dort zu schaffen, wo wir die größte Wirkung im Hinblick auf unsere Ziele erwarten. Damit etwas möglichst zügig fertig wird, ist es sinnvoll sich darauf zu fokussieren und Schritt für Schritt umzusetzen. Möglichkeiten für Fokus zu sorgen sind: WIP Limits, die wir aus Kanban kennen, Pull System, Konzentration auf eine Aufgabe, Timeboxing, Sequenzieren und Policies. Das ist eine Auswahl von Lösungen die sich bewährt haben. Vielleicht kennt ihr weitere gute Ansätze aus dem beruflichen und auch privaten Umfeld? Erlaubt ist was funktioniert.

Agile Interaktionen etablieren

Unter agilen Interaktionen verstehen wir alle Aktivitäten, die wir brauchen um unsere Arbeit zu erfassen, zu koordinieren, umzusetzen und Feedback darüber zu bekommen. Die Bandbreite kann von einem Team Slack Kanal zur Koordination der täglichen Aufgaben bis hin zu einem größeren Planning Event reichen. Die Tools und Formate, die wir einsetzen, sollten unserem Zweck dienen. Das Ziel ist echte Kommunikation zu fördern, bei der verschiedene Perspektiven eingebracht werden, ein gemeinsames Verständnis entsteht sowie Entscheidungen getroffen und Maßnahmen abgeleitet werden können. Erfahrungsgemäß erreichen wir die besten Ergebnisse, indem wir die richtigen Leute zur richtigen Zeit zusammenbringen und sie über ihre Arbeit und Herausforderungen reden lassen.

Auch bei agilen Interaktionen und dem Aufbau geeigneter Meetingstrukturen gilt "mitdenken ausdrücklich erlaubt". Wo brauchen wir Kommunikationswege innerhalb und zwischen den Flight Levels und warum? Wer muss wie involviert werden? Wie können wir unsere Arbeit koordinieren? Haben wir vielleicht schon was ähnliches? Das sind Leitfragen, die uns helfen, ein erstes Set an Meetings zu definieren. Das können gemeinsame Planungs Meetings sein oder auch Stand-ups. Wichtig ist, dass alle Beteiligten das richtige Verständnis von dem Ziel der Meetings haben und dies visualisiert ist. Es ist ratsam, regelmäßig zu reflektieren welche der Meetings noch gebraucht werden. Frei nach dem Motto: "Ist das Kunst oder kann das weg?"

Fortschritt messen

In der Regel versprechen wir uns von Agilität irgendeine Art von Verbesserung. Wir wollen schneller liefern - die richtigen Produkte, in der richtigen Qualität. Vielleicht verfolgen wir auch interne Ziele, wie die Zusammenarbeit zwischen Abteilungen zu verbessern, Vertrauen auf- und Silos abzubauen. Aber woran merken wir, dass Agilität uns dabei hilft, unsere Ziele zu erreichen? Bei diesen Fragen kommen wir schnell auf das Thema Fortschritt messen. Stellen wir die Frage, welche Kennzahlen und Messgrößen wir Agilen Coaches kennen, dann kommt ein ganzes Potpourri dabei heraus. Da sind z.B. Durchlaufzeiten, Velocity, Time-to-Market, Little's Law, Time in State und Cost of delay. Egal welche Kennzahl wir für wichtig erachten, auch dabei gilt "Context is King". Die Frage nach dem Messen ist eine Einladung zu einem Gespräch darüber was wir messen wollen und warum es wichtig ist. Und vielleicht auch darüber, was passiert, wenn wir uns auf die falsche(n) Kennzahl(en) fokussieren oder zu einseitig messen. Maßgebend ist eine gute Balance von Kennzahlen, abgestimmt auf die gewünschten Ziele.

Mehr zum Thema Kennzahlen und Messen könnt ihr hier nachlesen: https://www.flightlevels.io/blog/six-dimensions-of-performance/

Verbessern

Bei dieser Aktivität fragen wir uns: Was funktioniert? Was funktioniert noch nicht? Was müssen wir in der Zusammenarbeit, an der Darstellung oder am Produkt ändern? Ob das durch Retrospektiven oder sonstige Formate passiert ist hierbei irrelevant. Essentiell ist, dass wir immer wieder auf unsere Aktivitäten schauen, aus dem was wir umgesetzt haben lernen und neue Optionen herleiten. Das ist auf Teamebene genauso wichtig, wie auf den anderen Ebenen. Ziel ist, blinde Flecken zu erkennen und mit neuen Wissen immer weiter zu wachsen. Wir kennen es auch unter der Bezeichnung Inspect & Adapt.

Die fünf Aktivitäten auf den drei Ebenen sind die Kernelemente der Flight Levels. Sie haben sich in der Praxis bewährt und können uns auf dem Weg zu unseren Zielen unterstützen.

Referenzen:

Leopold K., Agilität neu denken. Mit Flight Levels zu echter Business-Agilität. 2. Aufl., dpunkt.verlag, 2022.

Kaltenecker S. & Leopold K., Flight Levels – Eine kurze Einführung, dpunkt.verlag, 2022

https://circle.flightlevels.io/c/knowledge-base/the-5-activities

https://www.flightlevels.io/blog/six-dimensions-of-performance/

Agile Tuesday Juni: Obeya - visuelles Cockpit für den Flug durch die VUCA-Welt mit Tobias Windbrake

christian-braun — Wed, 01 Jun 2022 10:29:43 +0000

Die Welt um uns herum scheint sich immer schneller zu drehen, die verfügbaren Informationen wachsen exponentiell. Wie kann man da den Überblick, geschweige denn den Durchblick behalten?

Neue Erkenntnisse aus der Hirnforschung, zusammen mit Lean-Methoden wie „Obeya“, können Deinem Team das Leben und die Zusammenarbeit vereinfachen.

Anhand von konkreten Beispielen werden wir uns ansehen, wie visuelle Werkzeuge Teams dabei helfen können, bessere Entscheidungen schneller zu treffen.

Tobias ist ein Experte im Bereich Team-Collaboration und hat 15+ Jahre Erfahrung mit digitalen visuellen Werkzeugen.

Wir freuen uns schon auf euch!

Viele Grüße

Euer Agile Tuesday Team und Tobias

Hier geht´s zur Anmeldung

Agile World 2022: Inspect. Adapt. Sustain.

christian-braun — Wed, 01 Jun 2022 10:33:34 +0000

Die Agile World (4. und 5. Juli 2022, Online Konferenz) feiert ihren 10. Geburtstag: am Montag, 04. Juli, ab 18 Uhr vor Ort in München.

Seit inzwischen zehn Jahren treffen wir uns einmal im Jahr mit der agilen Community, um das zu tun, was uns am meisten Spaß macht: voneinander lernen, netzwerken, neue Perspektiven und Ideen bekommen. Wir können es kaum erwarten, das mit euch zu feiern.

Uns interessiert die Zukunft von Agilität. Wie hat sich Agilität im letzten Jahr weiterentwickelt? Welche Rolle spielt das neue hybride Setting für Führung und agile Organisationen? Wir wollen mit euch gemeinsam während der Konferenz die Möglichkeiten und Chancen ausloten, die sich ergeben, wenn Nachhaltigkeit ein neuer Unternehmenswert wird: Inspect. Adapt. Sustain.

Auch dieses Jahr findet die Agile World wieder als Online Konferenz mit vielen Möglichkeiten für Erfahrungsaustausch statt.

Wir wollen kreative und inspirierende Ideen und Perspektiven, wie Unternehmen Business Agility leben. Wir wollen neue Trends beleuchten, Zukunftsideen spinnen und versorgen euch mit spannenden Erfahrungsberichten und, wie gewohnt, mit mitreißenden Keynotes.

Hier gibt es mehr Infos und die Möglichkeit zur Anmeldung

Agilität trifft Kultur - Erfolg oder Desaster?

markus.kling — Wed, 01 Jun 2022 11:29:08 +0000

Von Zoi Natsiopoulou und Markus Kling

Agilität ist heute in aller Munde. Lasst uns eine kleine Reise in die Vergangenheit unternehmen und uns ansehen, wie und wo alles begann. Im Winter 2001 trafen sich 17 Menschen in den Bergen von Utah um gut zu essen, Ski zu fahren und um über Software Entwicklung zu reden. Dabei kam das Agile Manifest [1] heraus. Eine Sammlung von Ideen, wie man Software entwickeln kann ohne die dokumentenbasierten und schwerfälligen Ansätze der damaligen Zeit. Aber es war nicht nur eine Ideensammlung: das Agile Manifest war auch Ausdruck eines geteilten Wertesystems, das auf Vertrauen und Respekt aufbaut und Menschen und ihre Zusammenarbeit konsequent in den Mittelpunkt stellt. Dieser Kodex spiegelt sich in den Werten und Prinzipien des Agilen Manifestes wider.

Warum erzählen wir diese Geschichte, die doch jeder Agilist kennt? Weil wir wie Jim Highsmith glauben und betonen möchten, dass es “letzten Endes bei dem kometenhaften Anstieg - und manchmal auch der heftigen Kritik - an agilen Methoden es am Ende doch um das “mushy stuff” geht” - also um Werte und Kultur.

“Agilität ist kein Prozess - sie definiert vielmehr eine Kultur” [2] und wir reden in ersten Linie von Kultur, wenn wir von Agilität reden.

Unternehmenskultur ist eine der größten Herausforderungen bei Agilen Transformationen

Bei unserer Arbeit erleben wir immer wieder, dass Unternehmen ihre Agile Transformation damit beginnen, ein Framework auszuwählen. Im Anschluss wird es eingeführt mit Trainings, Rollen, Meetings und allem was dazu gehören könnte. Nach einer Weile stellt man dann fest, dass es irgendwie nicht funktioniert mit der Agilität. Die gewünschten Ergebnisse bleiben aus und manches ist sogar schlimmer als vorher… es knirscht im Getriebe. Aus unsere Sicht liegen die Gründe dafür nicht auf der Prozessebene sondern in einem regelrechten “culture clash”.

Verschiedene Unternehmen haben unterschiedliche Kulturen, die mal mehr und mal weniger mit agilen Werten und Prinzipien zusammenpassen. Diese Kulturen sind nicht per se gut oder schlecht, sondern sie sind einfach da. Je weiter weg die - mitunter über Jahrzehnte kultivierten - Werte und Prinzipien eines Unternehmens von den agilen Werten und Prinzipien liegen, umso mehr kommt es bei Agilen Transformationen zu Hindernissen, die wiederum den Veränderungsprozess erschweren.

Diese Erfahrung deckt sich mit den Ergebnissen aus dem State of Agile Report (2021) [3]. Der Widerspruch zwischen der aktuellen Kultur in der Organisation und den agilen Werten wird dort als das zweithäufigste Hindernis bei der Einführung von Agilität genannt.

Was läuft da schief?

Aus unserer Sicht ist es wichtig die bestehende Organisationskultur zu berücksichtigen, bevor man sich für eine agile Transformation oder ein Framework entscheidet. Eine Standortbestimmung der Kultur und damit eine Klarheit darüber, wo wir als Unternehmen starten und wo wir hinwollen, unterstützt dabei sinnvolle Entscheidungen zu treffen. Wird dieser Schritt ausgelassen, läuft es oft mühsam. Wenn wir beispielsweise bis jetzt als Unternehmen auf Experten gesetzt haben, dann wird es uns schwerfallen ein kollaborativ- und teambasiertes Framework wie Scrum einzuführen. Entscheiden wir uns trotzdem dafür, müssen wir bereit sein, am Anfang Produktivitätsverluste und Lernkosten [4] zu akzeptieren. Kommen harte Liefertermine hinzu, ist der Stress vorprogrammiert.

Das muss nicht sein - und es muss auch nicht immer Scrum oder SAFe sein. Viele Wege führen nach Rom, und welcher am Besten zu uns passt können wir entscheiden, wenn wir wissen wer wir sind und wie wir ticken.

Modelle helfen bei der Lösung

Nichts ist so praktisch wie eine gute Theorie [5]. Um zu verstehen wie wir als Unternehmen “ticken”, können wir uns verschiedener Modelle bedienen. Welche wir dabei genau verwenden, ist im Prinzip nicht ausschlaggebend - solange uns bewusst ist, dass es sich um ein Modell handelt, das lediglich versucht sich einer komplexen Realität zu nähern. Es ist eine Vereinfachung der Realität die wir bewusst hinnehmen, damit wir praktisch damit arbeiten können.

Wir haben in diesem Zusammenhang gute Erfahrungen mit dem Kultur-Kompatibilitäts-Modell von William E. Schneider gemacht, weil es eingängig und handlungsorientiert ist.

Das Kultur-Kompatibilitäts-Modell

William Schneider entwickelt In seinem Buch [6] ein Modell zur Bestimmung der Kultur eines Unternehmens. Da es sehr viele unterschiedliche Vorstellungen von den Begriffen Kultur bzw. Unternehmenskultur gibt, liefert er eine Definition von Kultur im Zusammenhang mit seinem Modell mit:

Culture is: How we do things around here in order to succeed

Frei übersetzt in etwa: Kultur ist die Art und Weise, wie wir in unserem Unternehmen agieren, um erfolgreich zu sein.

Dies geschieht im Schneider Modell in zwei Dimensionen, die er Inhalt (content), bzw. Prozess (process) nennt.

Inhalt ist das, worauf eine Organisation ihr Augenmerk legt, also was für die Organisation wichtig ist. Laut Schneider gibt es Organisationen, die mehr Fokus auf die Gegenwart (actuality) legen und andere, die sich mehr mit den Möglichkeiten beschäftigen, die ihnen die Zukunft bieten könnte (possibility).

Prozess dagegen ist die Art und Weise, wie die Organisation zu Entscheidungen kommt. Diese Dimension spannt sich zwischen den Extremen persönlich (personal), also mit den Mitgliedern der Organisation im Mittelpunkt und unpersönlich (impersonal) mit der Organisation selbst im Mittelpunkt.

Legt man diese Dimensionen orthogonal zueinander, bekommt man ein Koordinatensystem, das vier Quadranten bildet. In diesen Quadranten verortet Schneider vier Kernkulturen.

Je nachdem, welche Inhalte und Prozesse in einer Organisation dominanter sind, lässt sich sagen, welcher Kernkultur sie am ehesten zugeordnet werden kann. Dabei betont Schneider, dass mit dieser Zuordnung keine Wertung verbunden ist. Eine Kultur ist per se nicht gut oder schlecht. Es gibt immer Gründe, warum eine Kultur so ist wie sie ist. Die Definition “How we do things around here to succeed” beinhaltet ja auch den Erfolg am Markt - eine erfolgreiche Organisation kann nicht alles falsch gemacht haben.

Es lohnt sich, diesen Punkt nochmal explizit zu betonen:

Keine Kultur ist per se gut oder schlecht

Genauso lohnt es sich zu betonen, dass die Kernkulturen theoretische Reinformen sind, die in der Realität nicht in dieser Einseitigkeit existieren. Vielmehr beinhalten bestehende Organisationen in der Regel Elemente aus mehreren benachbarten Kulturen. Es sind die vorherrschenden Merkmale, die die Kernkultur definieren.

In seinem Buch stellt Schneider auch einen Fragebogen mit 20 Fragen vor, anhand derer man die Kernkultur einer Organisation ermitteln kann. Diesen Fragebogen gibt es hier auch online.

Was verbirgt sich nun hinter den einzelnen Kernkulturen?

Kollaborativ

Persönlich und auf die Gegenwart ausgerichtet. Zusammenarbeit ist alles. Sehr häufig in Teams oder Teams of Teams strukturiert. Generalisten fühlen sich hier wohl, Diversität wird großgeschrieben. Die Kommunikation ist offen, frei und direkt. Sehr oft fühlen die Mitglieder eine starke Verbundenheit mit der Organisation wie auch untereinander.

In einem Umfeld mit Konkurrenten, die mit harten Bandagen kämpfen, tut sich eine kollaborative Organisation schwer - sie sucht die Harmonie. Talentierte Einzelkämpfer finden hier keine Bestätigung und bleiben in der Regel nicht lange. Sie hält nicht viel von Plänen und wird durch ihre Anpassungswilligkeit mitunter zum Spielball ihrer Umgebung. Auch läuft sie Gefahr, zu lange für Entscheidungen zu brauchen.

Kultivierung

Persönlich und in die Zukunft schauend. Werte sind wichtig, der Zweck der Organisation und der Beitrag ihrer Mitglieder und ihre Weiterentwicklung stehen im Mittelpunkt. Kontinuierliche Verbesserung, Vertrauen und Selbstverpflichtung sind grundlegend in einer auf Kultivierung ausgelegten Organisation. Idealisten finden hier eine Heimat.

Auch die kultivierende Organisation tut sich schwer mit Konkurrenten, die nicht fair spielen. Sie läuft Gefahr, die Richtung zu verlieren, weil sie sich zu sehr in den Möglichkeiten der Zukunft verstrickt und dabei die Gegenwart außer Acht lässt. Manche Mitglieder gehen so in ihrer Teilnahme auf, dass sie ausbrennen.

Kompetenz

Unpersönlich und in die Zukunft gerichtet. Wissen, Können und Expertise sind zentral für den Erfolg. Sie strebt nach Perfektion und Überlegenheit. Dabei geht sie logisch, analytisch, technokratisch, ziel- und ergebnisorientiert vor.

Emotionen und Werte werden nur gering geachtet. Das konstante Streben nach Perfektion kann zu Unzufriedenheit mit dem Erreichten führen. Zusammenarbeit und Teams sind nicht sehr im Mittelpunkt, da nicht nur die Organisation sondern auch ihre Mitglieder die Besten sein wollen. All das kann für ihre Mitglieder zu Stress und einem Gefühl der Unzulänglichkeit führen.

Kontrolle

Unpersönlich und in der Gegenwart beheimatet. Steht für Stärke, Stabilität, Planung, Ordnung und Vorhersagbarkeit. Leute fühlen sich in einer Kontrollkultur sicher, da Erwartungen, Rollen und Stellenbeschreibungen klar und abgegrenzt sind.

Dagegen sind Innovationen eher schwierig. Konflikte sind unerwünscht, werden nicht offen ausgetragen. In der Folge kann Misstrauen um sich greifen, offene Kommunikation leidet, (vor allem negative) Informationen werden nicht weitergetragen. Bürokratisierung ist ein häufiges Problem in einer von Kontrolle dominierten Umgebung.

Das Schneider Modell in (Agilen) Transformationen

Betrachtet man Kultur als eine wichtige Determinante für den Erfolg von Veränderungsprozessen, helfen uns die Kernkulturen zu entscheiden wie wir diese Prozesse gestalten können. Die Kernaussage aus dem Modell ist logisch und einfach: Kernkulturen die diagonal zueinander liegen, bilden totale Gegensätze. Der Weg von Kontrolle zu Kultivierung oder der Weg von Kompetenz zu Kollaboration ist am schwierigsten, da es sowohl auf der Inhalts- als auch auf der Prozessebene starke Unterschiede gibt.

Agile Frameworks bauen beispielsweise sehr stark auf Zusammenarbeit und Kultivierung. Expertise ist wichtig, aber der Mensch und der Sinn hinter der Arbeit stehen im Vordergrund. Wir finden sie im linken Bereich des Koordinatensystems wieder. Eine Organisationskultur, die auf Experten setzt und/oder starke hierarchische Strukturen hat, wird sich daher mit der Agilität sehr schwer tun. Der Schritt ist zu groß und nicht alle können ihn mitgehen. Ist einem das bewusst, sollte man überlegen ob vielleicht Kanban besser passen könnte. Oder ein Modell wie die Flight Levels, das eher wenige Voraussetzungen benötigt. Alternativ bedient man sich ganz pragmatisch aus verschiedenen Töpfen und schafft sein eigenes passendes Framework. So startet man die Transformation mit den eigenen Stärken im Gepäck, macht positive Erfahrungen und mehr Türen gehen auf.

Wir wenden das Modell von Schneider gern in Workshops an. Es entsteht dadurch ein gemeinsames Verständnis und eine Standortbestimmung der aktuellen Unternehmenskultur. Wenn man erkennt, dass man sich auf der rechten Seite des Koordinatensystems befindet und man Agil werden möchte, muss man auch sehr viele Elemente einer gegensätzlichen Kultur aufnehmen. Das ist eine gefährliche Strategie, weil man dann mit der Transformation in Teilen gegen seine eigene Kultur arbeitet. Wie Edgar H. Schein schon 1985 gesagt hat: “Culture constrains strategy” [7].

Schneider bringt in seinem Buch ein sehr greifbares Beispiel, wie der Zusammenschluss zweier Unternehmen mit gegensätzlichen Kulturen zu großen Problemen geführt hat:

“The world´s views of the two firms…were radically different. Rockwell´s company culture looked at the world as a rough-and-tumble place where profit margins dominate decision making. North American’s environment was more noble. Some 60 well-paid PhD´s…spent only 20 percent of their time on company business and were free to devote the rest of their time as they chose to basic research. This was not compatible with Rockwell’s obsession about controlling costs and margins. Thirteen years later, executives are still trying to improve the cultural fit of the two firms.” (S.14f)

Fazit

Viele Unternehmen empfinden ihre aktuelle Kultur als ein großes Hindernis für ihre agile Transformation. Deswegen halten wir es für absolut wichtig, die bestehende Unternehmenskultur zu bestimmen, bevor man eine Entscheidung für eine Richtung und damit eventuell für ein Framework trifft. Agile kann das Richtige sein - oder aber in ein Desaster führen. Egal wohin es für Sie und Ihre Organisation gehen soll: Lassen Sie sich von jemandem unterstützen, der sich damit auskennt.

Referenzen:

[1] https://agilemanifesto.org/

[2] Sahota M., An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture, 2012

[3] https://digital.ai/resource-center/analyst-reports/state-of-agile-report

[4] https://markus-kling.de/herangehensweise/

[5] Kurt Lewin, Problems of Research in Social Psychology, in: Field Theory in Social Science, 1951

[6] Schneider William E., The Reengineering Alternative - A Plan for Making Your Current Culture Work, 1994

[7] Schein Edgar H., Organizational Culture and Leadership, 1985

Flight levels for Whom and Where or Everyone?

mats.olof.winroth — Tue, 19 Jul 2022 09:42:11 +0000

Flight Levels is one of the newer agile concepts around, but it is on a rise in popularity since it helps you to understand and reach business agility, regardless of which situation you happen to be in right now. The first time I came in deeper contact with the concept was just before I joined improuv GmbH. One of my future, good colleagues hung a black improuv bag, with the text “ask the team”, on the doorknob at my home... all-in-all very corona conform. In the bag I found the book “Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility", by Klaus Leopold. The blue and quite thin book explains the concept of business agility in an impressively clear and simple way, based on a real-life use case. In short, it explains that business agility cannot be reached by great agile teams alone, but that it is an “organization sport” where business, end-to-end coordination, and various teams need to be tightly tied together. There are three organizational flight levels and we need to define and manage agile interactions between them. In the end, we get a coherent concept for how a measurable outcome can be achieved over the complete product chain, starting with a vision, via strategies, actions, implementation, and finally via the actual product.
The Flight Levels concept gave me a new and extended view of business agility. Nowadays I often find myself thinking about agile scenarios in terms of flight levels, where I earlier had less clear concepts.

The three levels

The Flight levels idea is based on a Kanban-like concept, where you may start a transition from where your organization happens to be right now and evolve from there in steps, rather than via a reorganization; You make the current situation transparent, define agile interactions, create focus, measure progress and then gradually identify areas to improve and adapt. The basic concept can easily be explained via a drawing and 15 minutes, but you will be allowed to (and need to) figure out how to implement it in your situation.

5 activities of Flight Levels - for each level

For whom and where are the flight levels a good approach?

In our work for various projects and clients, we have found the flight levels model to be useful as a thought model but also useful in places you would first not assume. Whereas the flight levels can be applied as a transition method in itself we have seen it useful as a model also within other frameworks like SAFe. Below you find two examples where ideas from the Flightlevels could be used to reach better co-ordination and focus within SAFe implementations.

Use case - production quality SW, within a large SAFe organization:

A set of teams are responsible for defining, developing, testing, and deploying production quality SW solutions, for factories in a large organization. They had issues achieving reasonable lead times, had problems with focus and prioritization but also had a lack of a clear vision and strategy for the future steps.
The development was shared between some teams within a SAFe Agile Release Train, (ART) but the definition of new features, testing and deployment was handled by experts in quality management communities and by teams in the actual factories. Lack of sufficient coordination of dependencies led to delays, frustration and very long lead times.
The vision and strategy would need to be handled by a group of worldwide distributed quality managers, with the goal to initiate innovative solutions to keep the company on the edge.

How can we use the Flight levels in the setup:
On flight level three, the strategy level, the group of managers got the responsibility to define clear and common visions for the products and a corresponding strategy to reach the goal. The strategy covers the few next years but to be actionable it is broken down into measurable objectives for one year and a quarter of a year. For the quarterly and measurable goals, we can define concrete actions, in terms of e.g. items that need to be implemented. The idea is to arrange a tight feedback loop on the strategy level, that allows the organization to learn and adapt in short time steps. The measurable goal may be formulated as a testable hypothesis that can be checked in next iteration. The breakdown into actionable strategy and into concrete activities are all visualized on a virtual whiteboard, which is accessible and transparent to the whole organization. It can be linked with Jira items.

On flight level two, the end-to-end coordination level, we define an end-to-end workflow, which describes the process of a new feature, from the idea until the final deployment. In order to handle this work flow we have representatives from the distributed teams within and outside of the ART, that meet and coordinate dependencies and blockers. This led to considerably shortened lead times since the various teams have regular interactions and can share expectations, instead of sending emails and hoping for the best effort execution. The items in the backlog are also better aligned with the vision and strategy, since the features and work items are based on the quarterly objectives. These are brought into the ART program backlog for the next Program Increment. On the coordination level, we define meetings to regularly align the activities between the teams; system engineering, development, test and deployment in factories. To improve the process, we run a retrospective between the teams to discuss what could be done better in the next iteration.
In this SAFe setup the level 2 quality management co-ordination is implemented as a Jira end to end workflow, which is running as a sub system/workflow to the SAFe Level 2 system, the ART. The teams that are part of the actual ART still perform regular PI planning together with the ART, in parallel to the coordination for the "quality management" value stream.

On level one, the operational level, we have scrum or Kanban teams that visualize their progress in scrum or Kanban boards. Members from the teams on level one align with other teams on the coordination level.

In this use case we make sure to visualize and make transparent the process on every level. This gives all involved parties a coherent picture of where we are heading, what we do now, and where we may have issues in the flow, that can be improved.

Use case for a SAFe Essential Agile Release Train (ART) in a Product line in Automotive area:

A new ART is set up for a product division, covering complex embedded SW/HW products in the automotive area. How can we create a coherent view of the whole process from a great vision to a product, that our customers love?

In the "SAFe Essential" setup (i.e. a setup of a single ART, with 50 to 125 members in teams) there is no clear proposal on how to connect the product visions and strategies with the development. Here the Flight levels offer a great idea of how to visualize and achieve a clear path from the company vision to the actual implemented product. In the same way as described in the earlier use case we introduce and visualize the strategy level on a separate virtual whiteboard. It provides transparency for visions, actionable strategies, measurable objectives and actual work items for the whole organization. The work items, "Features" in Jira, are linked and visualized on the board. In addition to the information on the whiteboard, strategic details and business cases are kept in a Jira issue type "Business epic", which is also linked and made available on the whiteboard. The flight level 3, strategy level, generates the inputs for the ART to work on, but is also forms a means to check if new and creative ideas from the ART comply with the agreed strategy. This is very important to allow us to keep focus on the most promising opportunities (and to make sure we "stop starting and start finishing").

The measurable outcomes can be defined as concrete business goals, e.g. "we get good feedback and a request for a quotation from a customer, via a successful demo". It can also be defined as a test of a product hypothesis, for instance, "90% of potential customers will regard the new user interface experience as better than the current product and would be prepared to pay 10 euro more for it."

Flight level two, the coordination level, is in this case formed by the SAFe ART and the corresponding end-to-end program kanban board. The agile interactions are formed by the PI planning and other SAFe ceremonies for coordination between teams.

and ... for whom and where is the flight levels actually useful?

Within improuv, we see great benefits with the Flight Levels concept and use it frequently. Not only as an alternative to traditional transition frameworks but also as a think-model, that helps us to understand and optimize situations where other frameworks may be applied; SAFe, various flavors of Scrum, etc...

The concept allows an emerging and iterative transition, where we start our journey by making the flow in our current organization transparent and adapting from there, rather than via a costly and risky re-organization. This allows us to identify opportunities for improvement, where we via hypotheses and experiments can change our organization.

Vom Global Scrum Gathering 2022, Denver

jens — Mon, 25 Jul 2022 10:05:54 +0000

Nach zwei Jahren Zwangspause hat heuer das erste Post-Corona Global Scrum Gathering in Denver stattgefunden. Noch hat die ScrumAlliance keine Teilnehmerzahlen bekannt gegeben, aber geschätzt haben etwa 400-500 Menschen den Weg zu den Rockies gefunden. Angeblich haben sich nochmal eine ähnliche Anzahl von Teilnehmenden virtuell hinzugeschaltet. Für ein amerikanisches Gathering waren auffallend viele Menschen aus anderen Teilen der Welt angereist. Fast die Hälfte kam aus Europa, Asien, Südamerika und Asien - nur aus Australien und der Antarktis konnte ich niemanden finden. Was im Fall der Antarktis auch verständlich ist. Allen Beteiligten merkte man an, wie sehr sie danach lechzten, mal wieder "echte Menschen" kennenzulernen, sich nicht nur per Zoom-Kachel auszutauschen. Und so waren die Pausen und "Social Events" fast wichtiger als das Konferenzprogramm.

Besonders stachen die drei Keynotes aus dem Programm hervor. Bereits im "Vorprogramm", dem "Guides Retreat" hielt Mike Cohn einen launigen Rückblick auf die Gründung der Scrum Alliance vor 20 Jahren, als er gemeinsam mit Ken Schwaber das erste Certified Scrum Master Training gegeben hatte: "We gave that training and the participants asked for a certification, so Ken invented the Certified Scrum Master." Eine Entscheidung aus der mittlerweile über eine Millionen Zertifikate hervorgegangen sind. Freundlicherweise überging Mike Cohn die Konflikte innerhalb der Agilen Community, die diese Entscheidung zur Folge hatte, aber das wäre dem Anlass wohl auch nicht angemessen gewesen.

Die Konferenz selbst wurde von Chris Gardners Keynote eröffnet, dessen Aufstieg aus schwierigsten Verhältnissen zum Multimillionär 2006 unter dem Titel "Das Streben nach Glück" mit Will Smith in der Hauptrolle verfilmt worden war. Gardner betreibt heute Programme zur Förderung von Schülern an Brennpunktschulen.

Als dritte Keynote hielt Seth Godin der Community den Spiegel vor: "Ihr kümmert Euch zu sehr um Terminologie und Worte. Geht raus und verändert die Welt!" Und weiter "Do things that matter for people who care".

Jens hält seinen Vortrag 'The Scrum Master's Immersion Camp'

Das weitere Programm war vor allem auf individuelle Entwicklung fokussiert. Vorträge und Workshops für Scrum Master und Product Owner zum einen, aber auch ein umfangreiches Programm zum Thema Führung. Das Konferenzprogramm schien sich da am Zertifizierungsprogramm der Scrum Alliance mit dem "Path to CSP" und dem CAL Programm zu orientieren.

Spanned fand ich vor allem, welche Themen nicht oder kaum vorkamen. Insbesondere das Thema Skalierung wurde so gut wie gar nicht angesprochen. Das mag zum einen daran liegen, dass die Kooperationen der Scrum Alliance mit Bas Vodde (LeSS) und Jeff Sutherland (Scrum@Scale) jeweils unter keinem guten Stern standen. Die Kooperation mit Sutherland endete sogar vor Gericht. Es könnte aber auch eine beginnende Strömung in der Agilen Community widerspiegeln, die in großen Skalierungsansätzen eher eine Bürokratisierung als eine Agilisierung sieht (siehe dazu auch den Beitrag "How not to Scale", den ich gemeinsam mit Hendrik Esser, Darja Smite und Marcin Floryan im "emergence" Magazin veröffentlicht habe).

Sehr viele Agile Transformationen scheitern tatsächlich nicht an fehlenden Strukturen, sondern nicht angemessenen Führungsansätzen. Hier hilft Ausbildung der Führungskräfte mehr, als spezifische Skalierungsframeworks. Wenn sich die Scrum Alliance strategisch auf diesen Bereich fokussiert, könnte das ein gutes Alleinstellungsmerkmal im agilen Bereich werden. Zwanzig Jahre nach dem ersten Scrum Master Training könnte sie damit ihren neuen Existenzgrund gefunden haben. Ob bewusst, oder eher aus Versehen, ist dabei weniger wichtig, als die Frage, ob sie diese Richtung nun konsequent weiter verfolgt. Vielleicht gibt das Global Scrum Gathering im Oktober in Lissabon schon erste Antworten darauf. Unabhängig von Strategie und Politik war es einfach mal wieder schön, echte Menschen zu treffen und neue Kontakte aufzubauen. Das hat nicht nur der Agilen Community die letzten zwei Jahre gefehlt.

Eine kurze Einführung in das Flight Levels Modell

alisa — Wed, 17 Aug 2022 10:16:33 +0000

Ein Gespräch zwischen Hedi Buchner, Transformation Coach, und Alisa Ströbele, Flight Levels Coach und Trainerin.

Hedi: Alisa, du hast dieses Jahr deine Ausbildung zum Flight Levels Coach gemacht. Im Herbst bieten wir unser erstes Training mit dir und Klaus Leopold als Trainer zu Flight Levels an. Kannst du kurz erklären, was Flight Levels sind?

Alisa: Flight Levels sind ein Denkmodell, um Organisationen zu betrachten. Wenn es darum geht, Business Agilität in einer Organisation zu ermöglichen, reicht es nicht aus, sich mit den einzelnen Teams zu beschäftigen. Business Agilität ist mehr als die Summe von Teams, die sich z.B. nach Scrum oder Kanban organisiert haben. Denn in den wenigsten Organisationen können Teams völlig autonom voneinander liefern. Häufiger gibt es Abhängigkeiten zwischen den Teams, die zu Verzögerungen bei der Lieferung führen, obwohl die einzelnen Teams womöglich schnell sind. Und dann noch die Frage - womit sind die Teams schnell? Wie hängt das, woran gearbeitet wird, mit den strategischen Themen zusammen?

Dem Flight Levels Modell liegt die Metapher vom Fliegen zugrunde: je nach Flughöhe nimmt der Betrachter eine andere Perspektive ein.

Flight Level 1 - die Ebene der operativen Arbeit und der einzelnen Teams.
Flight Level 2 - hier liegt der Fokus auf der Koordination zwischen Teams oder Produkten
Flight Level 3 - hier liegt der Fokus auf der Strategie.

Um Business Agilität zu erreichen, braucht es das “Fliegen” auf allen drei Ebenen. Das “Fliegen” wird in 5 Aktivitäten übersetzt: Visualisiere die Situation, schaffe Fokus, etabliere agile Interaktionen, Fortschritt messen und verbessern.

Wie hängen Flight Levels mit anderen agilen Modellen und Frameworks zusammen?

Der Erfinder von Flight Levels, Klaus Leopold, hat jahrzehntelange Erfahrung als Kanban Trainer, Berater und Buchautor. Das Flight Levels Modell basiert auf der Kanban Philosophie: nicht die formalen Strukturen und Hierarchien stehen im Vordergrund, sondern die Wertströme und die Frage, wer zu welchem Zeitpunkt mit wem reden sollte, um möglichst effektiv Kundenwert zu liefern. Dabei spielt das Kanban-Konzept von Flow eine zentrale Rolle, das auf die Gesamtorganisation skaliert wird.

Jetzt hast du das Stichwort “Skalierung”genannt. Es gibt ein paar andere Frameworks wie SAFe, Less, das Spotify Modell. Wie kann ich die Flight Levels in diese Sammlung einordnen?

Die genannten Skalierungsframeworks definieren neue Strukturen, Rollen und Zuständigkeiten. Diese erstmal umzusetzen kann richtig teuer werden und bedeutet sehr häufig eine Reorganisation. So eine große Veränderung triggert häufig große Verunsicherung und sogar Widerstand, was absolut kontraproduktiv ist.

Weil Flight Levels auf Kanban Philosophie basieren, geht es in Bezug auf Skalierung und auch Change darum, sich in evolutionären Schritten zu verändern und die Menschen von Anfang an mitzunehmen. Das verursacht weniger Stress und Unsicherheit und ermöglicht eine größere Bereitschaft der Beteiligten. Das "Upfront"-Investment hält sich dadurch auch in Grenzen. Jede Flight Levels Implementierung ist "maßgeschneidert". Flight Levels sind ein pragmatischer Skalierungsansatz, der immer im Kontext zu sehen ist.

Du sprichst ganz oft von der Organisation. Wenn Unternehmen SAFe oder das Spotify Modell einführen, starten Transformationen immer noch häufig im IT Bereich. Was sind die Erfahrungswerte bei Flight Levels?

Bei Flight Levels geht es um die Team-, Produkte- bzw. abteilungsübergreifende Wertgenerierung. Das bedeutet, es geht gar nicht um IT im Sinne der Funktion, sondern um die größeren Zusammenhänge in der Organisation. Während meiner Flight Level Coaching Ausbildung durfte ich in die Kontexte von anderen Kollegen eintauchen, die aus sehr unterschiedlichen und teilweise sehr großen Organisationen kommen. Es wurden verschiedene Wege diskutiert, wie so eine Flight Levels Initiative an Fahrwind gewinnt. Die häufigsten Szenarien waren:

Die Notwendigkeit, die einzelnen agilen Teams oder Produkte im Rahmen eines Portfolios zu koordinieren, führt zu einem Start mit den Flight Level 2 Systemen
die Notwendigkeit, die Strategie sichtbar, verständlich und umsetzbar zu machen - mit einem Start auf Flight Level 3. Dem folgt die “Übersetzung” der Strategie in die Umsetzung über die weiteren Flight Levels

Wenn es um die Strategie geht, wird oft im agilen Umfeld mit OKRs gearbeitet. Wie passen OKRs und Flight Levels zusammen?

Bei der “Übersetzungsarbeit” zwischen den strategischen Themen und der operativen Umsetzung könnten OKRs behilflich sein, um von Zielen zu umsetzbaren Paketen und Ergebnissen zu kommen und in kürzeren Zyklen die Ergebnisse zu evaluieren. Ob das mit OKRs oder anders geschieht - das ist Geschmackssache.

Dann komme ich jetzt zu meiner letzten Frage: In unserer Arbeit als Coaches und Berater gehen wir davon aus, dass es keine one-size-fits-all Lösungen für mehr Business Agilität gibt. Vielmehr ist es kontext- und kulturabhängig, welche Pattern eine Organisation weiterbringen. In welchen Situationen kann das Flight Levels Modell hilfreich sein und in welchen eher nicht?

Die Flight Levels sind eben kein Framework, sondern ein Denkmodell. Es gibt keine vordefinierten Strukturen und Regeln. Das Modell kann helfen, eine gemeinsame Sprache und ein gemeinsames Verständnis in der Organisation zu entwickeln:

wie entsteht Wert?
was hat Fokus und Priorität?
wie beeinflussen die verschiedenen Teile in dem komplexen System das Unternehmen einander?

Was genau das bedeutet, welche Art der Visualisierung, welche Absprachen oder Metriken sind nötig - das ist alles höchst individuell und sollte in der Organisation mit den Beteiligten erarbeitet werden. Wenn du mich fragst - wenn man nach solchen Prinzipien arbeitet, dann passt es überall, wo man eine Weiterentwicklung anstrebt.

Agile Tuesday: "Agile Leadership – vom klassischen Manager zur agilen Führungskraft" mit Holger Neumann und Celina Kostmann

christian-braun — Mon, 08 Aug 2022 14:31:01 +0000

Ein selbstorganisiertes Team braucht Führung, um Höchstleistungen zu erbringen. Ähnlich braucht eine Organisation Leadership, damit die agilen Teams auch ihre Interaktionen untereinander agil gestalten. Doch was bedeutet agile Führung eigentlich für die Vorgesetzten und Teammitglieder? Welche Herausforderungen verbergen sich dahinter? Und was ist überhaupt der Unterschied zwischen klassischer und agiler Führung?

Unser interaktiver Impulsvortrag bietet dir die Möglichkeit, einen Einblick in das Thema „Agile Leadership“ zu erhalten.

Dieses Event bietet dir die Chance in Breakoutsessions, deine bisherigen Erfahrungen in agile Leadership gezielt zu hinterfragen und zu reflektieren. Als Ergebnis nimmst du konkrete erste Schritte für deine Entwicklung zur agilen Führungskraft mit.

Am Ende der Veranstaltung weißt du, wie du Agile Leadership in deinem Unternehmen fördern kannst. Des Weiteren wird der Austausch und das Kennenlernen der Teilnehmer untereinander gefördert

Vorstellung von Holger Neumann und Celina Kostmann:

Holger Neumann leitete über viele Jahre hinweg ein globales Team mit rund 150 Personen aus aller Welt. Seine Leidenschaft gilt den „Agilen Methoden“ – dafür ist er heute bei Infineon in zentraler Funktion verantwortlich (Agile Center of Excellence). Er ist nicht nur Certified Product Owner (CSPO) sowie Scrum Master und Agile Coach sondern auch ein gefragter Referent zu den Themen „Einführung agiler Methoden im Unternehmen“.

Celina Kostmann ist Scrum Masterin bei M-net Telekommunikations GmbH. Celina war mehr als zwei Jahren bei Infineon Technologies AG beschäftigt und hat in Kooperation mit Infineon ihre Masterarbeit geschrieben. Außerdem ist Celina ebenfalls zertifizierte Scrum Masterin (PSM II).

Wir freuen uns schon auf euch!

Viele Grüße

Euer Agile Tuesday Team mit Celina und Holger

Hier geht´s zur Anmeldung

Flight Levels - Der fehlende Link zur Business Agility

hedi.buchner — Thu, 11 Aug 2022 11:47:08 +0000

Auf unserer alljährlichen Konferenz 'Agile World 2021' war Klaus Leopold einer unserer Keynote-Speaker - natürlich zu seinem Denkmodell "Flight Levels". Die Idee dazu hat er aus einem Phänomen heraus entwickelt, das er im Rahmen agiler Transformatione immer wieder beobachtet hat: Zwar werden Teams „agilisiert“, aber diese lokalen Optimierungen ergeben in Summe kein agiles Business, obwohl das ein erklärtes Ziel war.

Obwohl die Keynote inzwischen auch schon ihren 1. Geburtstag gefeiert hat, ist sie nach wie vor hochaktuell, spannend und sehr inspirierend.

https://youtu.be/Z2607_P40iY

Kleiner Tipp: wenn Du Interesse hast, tiefer in das Thema einzusteigen, komm doch zu unserem Flight Level 2 Design Workshop am 17./18. Oktober 2022 in München. Wir freuen uns schon sehr auf den Workshop mit Klaus und Alisa.

Jens Coldewey auf der Manage Agile in Berlin

christian-braun — Mon, 29 Aug 2022 14:15:39 +0000

Jens hat am 12. Oktober um 12:30 Uhr auf der Konferenz Manage Agile einen Vortrag mit dem Titel "Vom Kopf auf die Füße gestellt - Was Agile Organisationen anders machen".

https://www.youtube.com/watch?v=UIbuLRl-ebo

Wer gute Erfahrungen mit Agilen Teams gemacht hat, möchte die schnelle und sichere Lieferfähigkeit seiner Teams irgendwann auch für die ganze Organisation nutzen können. Dann wird monatelang über neue Aufbauorganisationen, Skalierungsframeworks und "Target Operation Models" gebrütet, die unter großen Kosten ausgerollt werden - nur um dann festzustellen, dass sich die Situation eher noch verschlimmert hat.

Um zu verstehen, warum viele Agile Transitionen selbst unter größten Mühen nicht zum Erfolg führen, während andere Unternehmen ihre Agilität fast spielerisch erreichen, hilft es, sich die jeweiligen Entscheidungsstrukturen anzusehen. Wo werden welche Entscheidungen getroffen und welche Rolle spielen dabei Prozesse?

In diesem Vortrag benutzen wir verschiedene, etablierte Organisationsmodelle von Autoren wie Nonaka, Mintzberg und Cameron, um die wesentlichen Unterschiede zwischen wirklich Agilen Organisationen und traditionellen Organisationen herauszuarbeiten. Welche Elemente sind unverzichtbar, welche sind unverträglich und was bedeutet das für die Führungskräfte?

Dieser Vortrag stützt sich auf Konzepte, die im Rahmen der Supporting Agile Adoption Initiative der Agile Alliance erarbeitet wurden.

Was lernen die Zuhörenden in dem Vortrag?

Du wirst ein besseres Verständnis bekommen, warum es für Business Agility nicht ausreicht, einfach ein Skalierungsframework Deiner Wahl auszurollen, sondern wie sich Entscheidungsstrukturen, Prozessparadigmen und Führungskultur verändern müssen.

Hier geht´s zur Konferenzpage

Alisa Ströbele auf dem Flight Levels Day

christian-braun — Mon, 29 Aug 2022 14:38:03 +0000

Am 10. Oktober diskutiert Alisa um 15:15 Uhr beim Expertenpanel des Flight Levels Days mit Siegfried Kaltenecker, Nagesh Sharma und John Coleman.

Hast du Lust habt mit dabei zu sein? -Mit dem Code FLD2020 erhältst du 10% Rabatt auf dein Einzelticket.

Konferenztipp: Agile meets Architecture

christian-braun — Mon, 29 Aug 2022 14:59:51 +0000

Wie wäre es direkt nach der Urlaubszeit mit neuen Impulsen in den September zu starten?

Am 6. und 7. September findet in Berlin die Agile meets Architecture statt und wir sind als Sponsor mit dabei. Jens Coldewey kannst du auf der Konferenz persönlich treffen.

improuv Coaches auf dem Scrum Gathering 2022 in Lissabon

hedi.buchner — Fri, 16 Sep 2022 17:01:17 +0000

Endlich findet das Scrum Gathering in Lissabon statt! Nach 2 langen Jahren Pause ist es vom 17.-19. Oktober wieder so weit. Und improuv ist mit einigen Vorträgen, Sessions und dem Panel am Mittwoch dabei:

Jens Coldewey hält zusammen mit Hendrik Esser den Vortrag "Before You Learn to Scale, First Learn to Descale" Mon Oct 17, 2:00 PM - 3:15 PM

This workshop results from the work of the “Supporting Agile Adoption” initiative of the Agile Alliance. We follow the ideas laid out in our article “How not to Scale” in the “Emergence” magazine to demonstrate the attendees that sustaining agility, team performance and overall organizational success is challenging when the company grows. Similarly, implementing agility in a large-scale organization is a challenge. In this workshop for Scrum Masters, Coaches and Organizational Leaders we explore options to grow beyond more structure, more planning and more bureaucracy by instead focusing on growth of competences and capabilities. Based on many years of experience at Ericsson, Spotify, consulting and academic research we challenge the conventional perceptions and ideas about scaling giving practical advice for how to avoid the common pitfalls on the path of organizational growth.

Zum Thema "Strategy in a Flow - Where Business Agility Begins" hält Jens am Mittwoch 19. Okt., 3:15 PM - 4:00 PM einen Vortrag

Strategy is a big thing for successful businesses: Every five years you start a large strategy project, call in your favorite strategy consulting firms, and generate the next big Five-Year Plan. Then you break this down to yearly budgets and strategic projects.

Unfortunately, the world is complex and the only thing you know for sure is that it won’t keep stable for the next five years. And yearly budgeting has become one of the major impediments to Business Agility.

Sabine Canditt und Paul Marshall sprechen zum Thema "Sustainable Development: How to Include Agile Manifesto Principle #8 in Agile Training" Mon Oct 17, 3:30 PM - 4:00 PM

The Scrum Alliance is “on a mission to create agile workplaces that are joyful, prosperous and sustainable”. As a worldwide provider of certifications, we could use our trainings as a lever to encourage students to take a stand for sustainability. In this talk, I share my experience how this can be done, in trainings for Scrum Masters, Product Owners and Agile Leaders. Participants will have the opportunity to practice one of the examples themselves.

Sabine diskutiert mit Joanne Stone, Kubair Shirazee, Steve Holyer, Ana-Laura Juvino und Lyssa Adkins: Panel: Agile and Our Global Challenges Wed Oct 19, 10:00 AM - 11:45 AM

If Agile is no "accident" and has emerged at exactly the right time, then what is its purpose in meeting today's significant challenges and paradigm shifts? This is the question our panelists brought together by industry thought leader, Lyssa Adkins, will help you explore as they share how they are applying agility to address planetary-level issues such as climate change, poverty, responsible economic growth and more.

Schaut gerne vorbei - wir freuen uns :)

Veränderungen in überlasteten Systemen

zoi — Mon, 24 Oct 2022 15:12:57 +0000

von Zoi Natsiopoulou und Markus Kling

Wir sind Zoi und Markus. Wir sind Agile Coaches. Wir arbeiten bei verschiedenen, immer neuen Kunden und in der Regel werden wir gerufen, wenn es Probleme gibt. Natürlich hat dabei jeder Kunde für sich gesehen seine ganz besondere und einzigartige Situation. Wir beobachten jedoch auch oft Dinge, die nahezu überall gleich sind, und “pair-bloggen” darüber. In der heutigen Folge: Veränderungen in überlasteten Systemen.

Überlastetes System - Versuch einer Definition

Für unsere Zwecke interpretieren wir System als eine (Teil-)Organisation, die der Lösung eines komplexen Problems gewidmet ist, wie z.B. eine Abteilung, die eine Webanwendung entwickelt.

Auf der Suche nach einer Definition für den Begriff überlastet, sind wir zunächst im Duden fündig geworden: “[etwas] über die gegebenen Möglichkeiten hinaus beanspruchen und dadurch in seiner Funktionsfähigkeit beeinträchtigen”[1].

Für unseren Systembegriff verstehen wir unter “gegebenen Möglichkeiten” die vorhandene Leistungsfähigkeit oder Kapazität des Systems. Wird diese Leistungsfähigkeit überschritten, indem wir sie zu sehr beanspruchen, kommt es zu einer Überlastung, worunter die Funktionsfähigkeit des Systems leidet.

Ein einfaches Beispiel für ein System aus der wirklichen Welt ist die Autobahn. Sind zu viele Autos gleichzeitig auf der Straße, die von A nach B wollen, kommt es zum Stau. Das passiert oft an neuralgischen Stellen, wie z.B. bei Ausfahrten oder Baustellen. Wer schon einmal gehofft hatte, zu Ferienbeginn schnell durch den Gotthard-Tunnel zu kommen, hat sicher schon die ein oder andere böse Überraschung erlebt. Zu den ganzen Pendlern und LKWs, die tagtäglich durch den Tunnel wollen, kommen ganz viele Urlaubsautos dazu und sorgen für eine Überlastung. Das Ergebnis: alle brauchen länger, um an ihrem Zielort anzukommen.

Ein Beispiel aus der Projektwelt für Überlastung haben wir im Kanban Maturity Model [2] gefunden: Durch die forcierte Projektarbeit bei gleichbleibender Belastung durch das Tagesgeschäft kam es zu einer erheblichen Überbeanspruchung besonders bei fachkompetenten Mitarbeitern, was zu unvorhergesehenen Verzögerungen in den betroffenen Projekten und Services führte.

Überlastete Systeme erkennen

Wenn wir als Agile Coaches zu Kunden gerufen werden, um bei der Agilen Transformation zu unterstützen, versuchen wir zunächst, uns mit Hilfe der bisher Beteiligten ein Bild der Lage zu machen. Dabei sehen wir ziemlich schnell das erste Symptom für ein überlastetes System:

Die Kalender sind voll, alle stecken bis zum Hals in Arbeit und es dauert Tage bis Wochen, um ein paar Termine zu bekommen.

Schauen wir dann zweitens auf die Dinge, mit denen die Leute sich beschäftigen, sehen wir, dass es mehr Dinge gibt, die herumliegen und warten, als in Arbeit sind. Es dauert meist sehr lange, bis etwas fertig wird, selbst wenn es nur eine Kleinigkeit ist.

Das dritte Symptom ist die Anzahl der nicht abgeschlossenen Projekte. In beinahe jeder (Teil-)Organisation sehen wir, dass zu viele Projekte am Laufen sind. Oder besser: am Bummeln oder Warten. Teils sehen wir ein Verhältnis von 1:1. In einem Bereich mit beispielsweise 100 Leuten gibt es dann um die 100 Projekte, mit denen sich die Leute beschäftigen (müssen).

Tut sich darüber hinaus die Organisation schwer damit, Lieferzusagen zu treffen bzw. einzuhalten, könnte das ein weiterer Hinweis auf Überlastung sein. Und damit meinen wir nicht die inhärente Unsicherheit durch die Varianz in der Entwicklungsdomäne, sondern eine ungleich höhere Unsicherheit, die durch die Überlast in das System kommt.

Große Veränderungen kosten Zeit und erzeugen Widerstand

Ironischerweise ergibt sich aus diesen Schmerzpunkten sehr oft die Motivation für eine Agile Transformation. Die Kunden wünschen sich eine Verbesserung und glauben, dass Agil der richtige Ansatz ist. Genau an diesem Punkt gilt es für uns als Coaches, aufmerksam zu sein und die Kunden gut zu beraten. Denn auf der einen Seite ist der “Sense of Urgency” [3] vorhanden und somit auch die Energie, die es für eine Transformation braucht. Auf der anderen Seite müssen wir im Blick behalten, dass Agile Transformationen eine erhebliche Veränderung darstellen und mit Unsicherheit und Mehrarbeit einhergehen. Neue Rollen, Aktivitäten und Methoden müssen etabliert und gelernt werden. Auf der eh schon überfüllten Autobahn machen wir zum Ferienbeginn noch eine Baustelle auf. Und siehe da: alles braucht länger. Schlimmstenfalls bricht der Verkehr kurzzeitig zusammen. Widerstände steigen und die Akzeptanz für die Agile Transformation sinkt. Wir laufen Gefahr, in einen Teufelskreis aus zu viel Arbeit, steigender Unzufriedenheit und Widerstand zu kommen. Oft spiegelt sich das in der Aussage: “Wir haben es versucht, aber bei uns funktioniert Agil nicht. Ganz im Gegenteil, es wurde schlimmer und wir haben seitdem nichts mehr ausgeliefert.”

Ein Beispiel aus der Praxis:

Die betreffende Organisation hatte sich für ein fertiges Agiles Framework entschieden, um ähnliche Schmerzpunkte wie oben beschrieben anzugehen. Leider war das System schon vorher überlastet. Wenn wir uns den Release Burndown in Abbildung 1 anschauen, dann sehen wir die aktuelle Burndown Kurve in blau, die bis zur gestrichelten Linie “Today” verläuft. Die daraus als dünne blaue Gerade abgeleitete Prognose zeigt an, dass zum anvisierten Liefertermin noch Arbeiten offen sein würden (“Current Delta”), d.h. wir haben schon mehr Arbeit im System, als bis zum feststehenden Termin erledigt werden kann.

Abbildung 1: Das Release Burndown Diagramm

Dabei geht die Prognose davon aus, dass die Arbeiten weiterhin in einer vergleichbaren Geschwindigkeit ablaufen, d.h. dass mit etwa gleichbleibender Produktivität gearbeitet wird.

Leider ist es aber so, dass bei jeder Veränderung die Produktivität zunächst zurückgeht, bevor sie (hoffentlich) wieder ansteigt und sich letztendlich auf einem höheren Niveau wieder einpendelt. Das gilt für jede Veränderung - nicht nur, aber eben auch für eine Agile Transformation. Neue Rollen, Aktivitäten und Regeln werden eingeführt. Sie müssen erst mal erlernt und Altes entlernt werden. Verwirrung und Desorientierung entstehen. Dies alles drückt die Produktivität erstmal nach unten. Bekannt ist dieses Phänomen als J-Kurve, wie sie in Abbildung 2 zu sehen ist.

Abbildung 2: Die J-Kurve des Lernens

Da die Produktivität aber entscheidend für das Gefälle des Release Burndowns ist, wird dieses Gefälle bei sinkender Produktivität auch zurückgehen. Mitunter kann die Kurve sogar kurzzeitig ansteigen, da durch die Veränderung plötzlich neue Arbeiten im Release Backlog erscheinen oder bestehende Aufgaben größer werden. Dies sehen wir in Abbildung 1 in der grünen Kurve dargestellt. Diese nähert sich zwar nach einiger Zeit wieder an die ursprüngliche Prognose der blauen Kurve an, was auf die bis dahin angestiegene Produktivität zurückzuführen ist. Aber - abhängig von der Größe der Veränderung und dem Zeitpunkt des Release Termins - kann es passieren, dass diese Veränderung die Lage nicht verbessert, sondern verschlimmert. Es kommt dann zu dem schon bestehenden Delta noch ein größeres dazu. Genau das ist im vorliegenden Fall passiert. Genauer gesagt, es wäre passiert, wenn man nicht im letzten Moment auf Kosten der Agilität gegengesteuert hätte.

Am Ende hat es der Kunde geschafft, den Liefertermin einzuhalten. Alle waren glücklich und stolz auf Ihre Arbeit. Gleichzeitig hat es viel Energie gekostet, das Projekt zu stemmen. Der Versuch, das eigentliche Problem durch die Agile Transformation zu lösen, wurde nach hinten verschoben. Die anderen Anforderungen waren während der heißen Phase auf Eis gelegt. Sobald der Release-Termin geschafft war, poppten die Anforderungen wieder hoch, neue Projekte wurden initiiert, weil vermeintlich wieder mehr Kappa da war und es ging wieder von vorne los. Viele Anforderungen und Projekte kamen auf zu wenige Entwickler, die versprochenen Liefertermine waren nicht mit der Kapazität zu schaffen.

Die Politik der kleinen Schritte

Nichts zu tun ist auch keine Lösung. Aber wie können wir in überlasteten Systemen mit weniger Risiko Verbesserungen bewirken? Als David Anderson die Kanban-Methode erstmals einführte, bezeichnete er sie als Wandel in kleinen Schritten (Evolutionary Change) [2].

Im Zusammenhang mit Agilen Transformationen verstehen wir unter Politik der kleinen Schritte eine Vorgehensweise, die dort beginnt, wo der Kunde steht und durch viele kleine Veränderungen versucht, Verbesserungen zu erzielen. Da spielen die Problemstellung und die daraus abgeleiteten Ziele genauso eine Rolle wie kulturelle Überlegungen und die allgemeine Auslastung des Systems. Ausgehend davon ist es ratsam, den Blueprint für die Transformation selbst zu gestalten. Dazu kann man sich verschiedener Praktiken und Vorgehensweisen bedienen.

Um auf unser Thema zurückzukommen: wir würden bei einem überlasteten System unseren Kunden nicht empfehlen, ein fertiges Framework zu implementieren, sondern eher die Politik der kleinen Schritte zu verfolgen. Am Anfang sollte eine kurze Analyse stehen, um das System zu verstehen. Dazu können Daten wie Durchlaufzeiten oder Ähnliches herangezogen werden. Aber auch Beobachtungen hinsichtlich Meetings, Zusammenarbeit, oder Artefakten. Es gilt, einen ersten Eindruck vom System zu bekommen. Gibt es die typischen Anzeichen für eine Überlastung, müssen wir die Gründe dafür suchen. Sind sie eher auf der Umsetzungs- oder auf der Koordinations-Ebene zu sehen? Oder in deren Zusammenspiel?

Aus dem Verständnis der Problemlage entstehen Hypothesen und daraus dann passende Verbesserungsschritte. Das kann in einem Fall die Visualisierung und Verbesserung von Prozessschritten in der Wertschöpfungskette sein oder in einem anderen die Entlastung von Teams und Experten durch die Einführung von WiP Limits. Das erfordert keinen Umbau der Organisation und ist weniger aufwändig als die Zusammenstellung neuer Teams oder die Einführung neuer Rollen. Wir bewegen das System, indem wir etwas ändern, überfordern es jedoch nicht so, dass die Produktivität zu sehr darunter leidet. Zudem sind solche kleineren Veränderungen wieder schneller zurückzudrehen. Wenn wir bspw. merken, dass die WiP Limits nicht wirklich den erwünschten Effekt haben, können wir sie anpassen. Durch die kleinen Schritte entsteht auch weniger Widerstand bei den Beteiligten.

Die Verbesserungen mit ihren anfänglichen Produktivitätsverlusten haben wir in der Abbildung 3 in der gelben Kurve visualisiert. Es gibt mehrere kleinere J-Kurven. Wir vermeiden den großen Dip und sind schneller auf der bisherigen als auch auf der angestrebten Produktivität.

Abbildung 3: Lernen in einem großen Schritt (grün) – oder in vielen kleinen Schritten (gelb)

Fazit

Veränderungen fügen sich keinem Plan - auch keinem Beraterplan [4]. Oft kann man im Vorfeld nicht sagen, ob eine Veränderung auch die erhofften Verbesserungen bringt. Manchmal kann es sogar zu gegenteiligen Effekten kommen. Deswegen ist man gut beraten, auf den jeweiligen Kontext zu achten und diesen bei Veränderungs-Entscheidungen einzubeziehen. Die Politik der kleinen Schritte kann eine sinnvolle Alternative zu SAFe oder Scrum sein, um bspw. eine Entlastung und dadurch den Boden für eine Reorganisation vorzubereiten. Und wenn die Organisation bewusst disruptiv vorgehen möchte, dann sollte sie sich zumindest des Risikos bewusst und bereit sein, durch das Tal der Tränen zu gehen. Das gilt für jede Veränderung, aber vor allem für Veränderungen in überlasteten Systemen.

Referenzen:

[1] Duden, Handbuch der deutschen Rechtschreibung, Onlineversion, https://www.duden.de/rechtschreibung/ueberlasten, abgerufen am 05.10.2022

[2] Anderson, David J. / Bozheva, Teodora, Kanban Maturity Model, Handbuch für Agilität, Resilienz und Neuausrichtung in Organisationen (2021), dpunkt.verlag GmbH

[3] Kotter, John P., Leading Change, 2011, Vahlen

[4] Eidenschink, Klaus, Metatheorie der Veränderung, Podcast, https://audioportal.metatheorie-der-veraenderung.info/das-thema-beratung-darf-keine-zielversprechen-machen/, abgerufen am 05.10.2022

Was bedeutet "bessere" Lead Times?!

sacha.storz — Tue, 25 Oct 2022 09:50:04 +0000

Mit zunehmender Reife nutzen agile Teams Metriken, um ihren kontinuierlichen Verbesserungsprozess zu gestalten. Gerade für Kanban-Teams ist die Lead Time, also die Durchlaufzeit von Arbeitspaketen, dabei ein wichtiger Kandidat.

Letztes fragte eine Entwicklerin bei einem Kunden in die Runde: "Ok, unsere Lead Time ist 18 Tage... ist das jetzt gut? Oder schlecht?" Sie wünschte sich Hilfe bei der Interpretation der Metriken. Der Agile Coach gibt natürlich nicht einfach eine Antwort, sondern stellt eine Gegenfrage: "Du meinst den Durchschnitt, schätze ich. Was ist besser? Ein Lead-Time-Durchschnitt von 18 Tagen oder von 14 Tagen?"

Die richtige (oder zumindest bessere) Antwort ist nun leider nicht: Natürlich 14 Tage! Es ist wichtig, zu verstehen, dass Lead-Time-Angaben ohne Streumaß wenig aussagekräftig sin. Also: 14 Tage im Schnitt, ok, aber was ist bei euch der minimale und maximale Wert? Wie verteilen sich die Lead Times um den Durchschnitt herum?

Lead Times: Die Streuung machts

Bevor wir ins mathematisch-philosophische abgleiten, fragen wir zuerst noch mal: Was ist uns eigentlich wichtig? Ist es wichtig, dass wir manchmal extrem schnell liefern, aber manchmal auch extrem lange brauchen? Dann wäre ein niedrigerer Durchschnittswert der Lead Time wünschenswert, ohne Rücksicht auf Verluste (i.e. Ausreißer, die ewig dauern).

Meistens ist das aber nicht das, worum es uns geht. Meistens geht es darum, dass wir zuverlässig liefern. Dass wir also vielleicht nicht ganz so schnell liefern, aber dafür mit hoher Vorhersagbarkeit schnell genug liefern. Schauen wir ein konkretes Beispiel an.

Die beiden Lead-Time-Verteilungen A und B sehen relativ ähnlich aus. Der Durchschnitt der beiden Datenmengen ist auch ähnlich, 10.04 bei A und 9.69 bei B. Die Einheit ist für unsere Zwecke hier egal, es könnten Tage sein, Wochen, Monate, es geht ja nur um den Vergleich.

Welche Lead Times sind besser, A oder B?

Welche Lead Times sind nun besser, A oder B? Wie gesagt, das kommt darauf an, was man mit besser meint. Ein zentrales Ziel von Kanban ist verbesserte Vorhersagegüte. Wenn der Kunde fragt "Wann ist es fertig?" hilft es ja wenig, wenn man sagen kann "In 10 Tagen", dabei aber in circa 50% der Fälle falsch liegt, länger braucht und sein Lieferversprechen somit bricht. Besser bedeutet also nicht, dass der Durchschnitt niedriger ist, sondern dass die Streuung schmaler ist, also die "Breite" der Verteilung. Get rid of the tail ist deshalb eine wichtige Devise der Kanbanistas. Was ist der Tail? Die vielen Issues rechts in der Verteilung. Hier zwei Verteilungen, eine mit fat tail, eine mit thin tail.

Mittelwert bringt nichts, benutzt Perzentile!

Schauen wir uns unter diesem Gesichtspunkt jetzt noch mal die o.g. Lead-Time-Verteilungen A und B an. Es ist klar geworden, dass allein der Durchschnitt keine gute Aussage ist. Wir müssen irgendwie auch was darüber sagen, wie weit nach rechts unsere Verteilung ragt. In industriellen Settings wie z.B. Fertigung wird dafür gern die sog. Standardabweichung genutzt, ein statistisches Maß, auch genannt Sigma (daher hat Six Sigma seinen Namen). Darauf wollen wir hier gar nicht eingehen, weil die Standardabweichung bei Lead-Time-Verteilungen von Arbeitspaket-Durchlaufzeiten keine gute Aussagekraft hat. Sie funktioniert optimal nur für symmetrische Verteilungen.

Wir verwenden hier besser sog. Perzentile. Sie teilen die Verteilung in zwei Teile, das 50. Perzentil zum beispiel Hälfte-Hälfte: Die eine Hälfte der Werte ist unter dem Median-Wert, die andere Hälfte über dem Median-Wert. Wenn der Median z.B. 7 ist, und ich sage "In 7 Tagen ist es fertig", dann bin ich in der Hälfte der Fälle schneller, in der anderen langsam. Eine Fifty-Fifty-Chance ist, wie gesagt, kein guter Forecast, den ich an Kunden kommunizieren will.

Das 80. Perzentil sagt: In 80% der Fälle brauch ich so lang oder kürzer. Das ist schon besser! Wenn das 80. Perzentil meiner Verteilung bei 15 Tage liegt, und ich sage dem Kunden "In 15 Tagen ist das Arbeitspaket fertig", dann liege ich in 4 von 5 Fällen (80%) richtig. Wenn es heikel ist, die Abgabefrist zu überschreiten, gehe ich auf Nummer sicher und wähle das 90. Perzentil — jetzt werde ich in 9 von 10 Fällen rechtzeitig abgeben. Eine weiterführende Besprechung der Charakteristika von Lead-Time-Verteilungen findet man in den hervorragenden Artikeln auf Alexei Zheglovs Blog. Aber jetzt noch mal zu A versus B!

Noch mal: Welche Lead Times sind besser, A oder B?

Die entsprechenden Werte für die o.g. Verteilungen A und B sind:

Mittelwert 10.04
Median 7.5
80. Perzentil 17
90. Perzentil 20.6

Bei B sieht es so aus:

Mittelwert 9.69
Median 8
80. Perzentil 14
90. Perzentil 17.6

Wenn wir also sagen, Schnelligkeit im Schnitt ist nicht alles, Vorhersagegüte ist wichtig, dann ist Verteilung B besser für mich, weil die Lead Time, die ich mit sehr hoher (80% bzw. 90%) Wahrscheinlichkeit vorhersagen/versprechen kann, um drei Tage kürzer ist als bei A. Der ähnliche Mittelwert täuscht darüber hinweg, dass die Verteilung der Werte bei B kompakter und damit für die Vorhersagegüte besser ist.

Fazit: Wenn man Lead-Time-Verteilungen anschaut, ist der wichtigste Ansatz: Get rid of the tail!

Achtung: Die aus den Daten abgeleiteten Perzentilwerte sind nur Annäherungen an das, was wir statistisch erwarten können. Wir müssen eigentlich eine Monte-Carlo-Simulation über unsere Daten machen. Warum das so ist, ist z.B. in diesem Artikel beschrieben.

Agile Tuesday: "Mit Liberating Structures gemeinsam Ergebnisse erzielen" mit Paul Marshall

christian-braun — Tue, 08 Nov 2022 09:14:38 +0000

Wer kennt das Dilemma nicht?
Auf der einen Seite werden Meetings und Workshops zur Bühne von wenigen. Entscheidungen finden statt, der Elan der anderen bleibt aber mäßig.
Auf der anderen Seite drohen endlose Diskussionen und Chaos, sollte die Gruppe einmal versuchen, gemeinsam zu entscheiden und handeln.Liberating Structures können zumindest helfen, uns aus den Fängen misslingender Meetings zu befreien. Alle Teilnehmer:innen kommen mit LS zu Wort und dennoch stehen die Chancen gut, in vertretbarer Zeit Ergebnisse zu erzielen.An diesem Agile Tuesday will euch Paul Marshall - langjähriges Mitglied der Münchner LS-Community und neuerdings Agiler Coach bei improuv - in die Welt der Liberating Structures einführen. Dabei steht das Erlebnis im Vordergrund . Sprich wir werden ein LS-Meeting simulieren.
Ihr sollt aber auch etwas aus der Perspektive einer Moderator:in mitnehmen können und wissen wie ihr mit LS weitermachen könnt.

Wir freuen uns schon auf euch!

Wichtig: Zum Jahreswechsel wird die Planung des Agile Tuesday nur noch auf meetup.com stattfinden, da Xing die Gruppenfunktion abschalten wird.

Wir freuen uns schon auf euch!

Viele Grüße

Euer Agile Tuesday Team mit Paul

Hier geht´s zur Anmeldung

Kanban skalieren: Flight Levels und Schnittstellenoptimierung

sacha.storz — Thu, 10 Nov 2022 15:18:16 +0000

Gehen wir für diesen Artikel davon aus, dass es unser Ziel ist, zuverlässig Wert zu liefern. Zuverlässig, weil das Versprechen "Du kriegst irgendwann Wert, aber keiner weiß, wann" im Business Context meistens nicht fliegt. Und Wert, weil hocheffizient das Falsche tun, langfristig zum Untergang der Organisation führt. Dazu ein wunderschönes Zitat von Altmeister Russell Ackoff: The more efficient you are at doing the wrong thing, the wronger you become.

Es gibt nun verschiedene gute Gründe, anzunehmen, dass derselbe Denk- und Arbeitsansatz nicht für alle Sachlagen gleich gut geeignet ist. Das sagen uns z.B. Cynefin, Wardley Maps, die Stacey Matrix und viele Org-Modelle. Sparen wir uns die Details, klar ist: Wie man es auch dreht und wendet, immer standardisieren mit Effizienz und Uhrwerk-Metapher ist nicht das Richtige. Und immer Agile mit zusammen drüber reden und gemeinsam nachdenken und rumprobieren ist auch nicht immer das Richtige.

Ein Beispiel: Wenn auf dem Fließband eine Tür zum Reinmontieren ins Auto ranfährt, dann müssen wir nicht immer wieder neu überlegen "Ja, Mensch, was machen wir denn jetzt mit der Tür?!" Wenn wir aber neue Produkte oder Services anbieten wollen, sollten wir von den Fließband- und Kochrezept-Ansätzen Abstand nehmen und: Gemeinsam denken, experimentieren, liefern und lernen.

Dass immer beide dieser Seiten eine Rolle spielen, sieht man auch schon im Agilen Manifest. Es heißt da ja "People and interactions over processes and tools" und nicht "People and interactions instead of processes and tools". Im Komplexen brauchen wir einfach ein bisschen mehr von "people and interactions" und ein bisschen weniger von "processes and tools".

Zusammenarbeit — komplex vs. kompliziert

Wenn wir den gerade besprochenen Denkansatz auf die Skalierung von Kanban anwenden, also das Vernetzen von mehreren (Kanban) Teams/Services, dann kommen wir zu dem Schluss:

für komplexe Aufgaben brauchen wir Interaktion (Agile)
für komplizierte Aufgaben brauchen wir Standards (good practices, Schnittstellen etc.)

Ein Beispiel: Wenn ich einen Demand an eine andere Abteilung (oder Team oder Service) habe, z.B. "Gib uns eine Schulung zum Thema Flight Level 2 Design", dann schicke ich manchmal eine Mail, manchmal mache ich ein JIRA-Ticket, manchmal chatte ich sie an und manchmal schick ich eine Brieftaube. Die Kollegen dort teilen mir mit: Das ist echt unpraktisch! Kannst du nicht immer Weg X gehen? Das würde uns das Leben vereinfachen. Na klar, kann ich.

Diese Vereinbarung, für meinen Demand immer Weg X zu gehen, ist eine ganz primitive Standardisierung und Vereinfachung. Sie hat nichts mit Agile oder innovativer Kollaboration zu tun — weil Agile und innovative Kollaboration hier einfach überflüssig sind. Dieser Ansatz ist der Kern von tayloristischer "Professionalisierung" und Effizienz, wie er im 20. Jahrhundert gepflegt und vervollkommnet wurde.

Wenn wir aber folgende Anfrage haben: Mach mal eine Schulung zum Thema Flight Levels in SAFe Release Trains — Freunde fürs Leben… Aber die Teilnehmer sind noch nicht ganz klar, da muss ich erst mal fragen, sollen wir da alle rein tun oder nur das Business? Und sind das dann eher zwei Tage oder (Business hat nie Zeit) geht es auch an einem Tag? Und brauchen wir die Design-Abteilung? Und sollte man da Grundwissen voraussetzen, wenn ja, welches? Dann hab ich eine Fragestellung, die in meinen Standardweg X nicht reinpasst. Wir kennen das, der Sachbearbeiter sagt uns: Das kann ich in meiner Maske nicht eingeben.

Aber selbst, wenn wir es eingeben könnten, wäre es nicht sinnvoll, denn was wir hier brauchen, ist: Austausch, Ping Pong, Kollaboration, zusammen nachdenken und Pläne schmieden. Klaus Leopold, Begründer des Flight-Level-Ansatzes, nennt das agile Interaktionen. Über einen standardisierten Ansatz mit einem anderen Service zu sprechen, könnte nicht alle nötigen Fragen, Ideen, Rahmenbedingungen und Seiteneffekte anmelden, die der Service wissen müsste, damit wir zusammen (!) das beste Ergebnis generieren. Das ist es u.a., was ein Flight Level System leistet.

Kanban Skalierung: Agile Interaktionen vs. Service Canvas

Wir haben also zwei Fälle, den komplizierten, den man standardisieren kann, und den komplexen, wo man agile Interaktion braucht. Kunden-Beispiel: Für die gemeinsame Arbeit an der Wertschöpfung nutzen wir ein "klassisches" Flight-Level-2-Board, auf dem Arbeitspakete (Epics, User Stories) abgebildet sind, bei denen es Abhängigkeiten zwischen mehreren Teams gibt. Diese Pakete durchlaufen auf dem FL2-Board den ganzen Ende-zu-Ende-Wertstrom. Einmal in der Woche besprechen alle relevanten Personen aus allen Services/Teams den Stand, wie bei einem Kanban-Daily-Standup auch. Denn genau das geschieht in einem FL2-Standup: Die Abhängigkeiten werden visualisiert und Blocker, Bottlenecks und auftauchende Probleme gemeinsam thematisiert. Ziel ist: Gemeinsame zuverlässige Lieferung von Wert.

So sieht ein solches Flight Level System schematisch z.B. aus:

Aber nicht alles, was zwischen zwei Teams bzw. Services passiert, muss andauernd besprochen werden, wie schon gesagt. Für alles Standardisierbare haben wir einen einfachen Service Canvas gebaut, der pro Service folgende Dinge offenlegt:

Welche Arten von Anfragen (Demand) nimmst du an?
Hast du Definitions of Ready für diese Demands?
Welche Dependencies hast du unter Umständen bei diesen Demands?
In welcher Form lieferst du und hast du Definitions of Done für die Lieferung?
Welche Serviceklassen bietest du an und wie sehen deine Lead-Time-Verteilungen aus? (vgl. hierzu Was bedeutet „bessere“ Lead Times?! in unserem Blog)

All diese Dinge will ich nämlich nicht immer wieder besprechen müssen, so a la "Hey Joe, wie lange brauchst du für X" oder "Hey Joe, kann ich das Ticket hier auch bissl schneller haben?" oder "Hey Joe, wenn ich X von dir brauche, brauchst du dann den Y dafür?!" usw. Diese Dinge müssen geklärt und definiert sein. So bietet jeder Service den anderen eine definierte Schnittstelle zur Verfügung, so wie es Services in der Softwareentwicklung über APIs tun.

Hier die Spreadsheet-Version des Service Canvas (Lizenz CC-2.0-BY-SA-NC):

Nach einer Base-Line-Messung, die gerade läuft, versprechen wir uns dadurch für die Zukunft spürbare Verbesserungen bei Durchlaufzeiten, Lieferzuverlässigkeit, Alignment und nicht zuletzt Zustand der Nervenkostüme. Weiteres werde ich hier berichten, ich bin selber schon gespannt.
Die Zusammenarbeit in einem Netzwerk aus Teams mit Flight Levels und Schnittstellenoptimierung zu verbessern ist auf alle Fälle eine spannende und lohnenswerte Aufgabe.

Hier geht´s zu unserem Flight Level 2 Design Workshop

Wie aus "meine Arbeit" und "deine Arbeit" im Team "unsere Arbeit" mit Kanban wird

sacha.storz — Wed, 23 Nov 2022 14:19:29 +0000

In cross-funktionalen agilen Teams gilt joint ownership, also die gemeinsame Verantwortung für Arbeitsergebnisse, als wichtiges Grundprinzip. Bekommt man stattdessen zu hören "Dass Arbeit X nicht fertig wurde, da kann ich nichts dafür, das war Toms Ticket", dann weiß man: Wir sind noch nicht bei joint ownership. Aber wie kommen wir dorthin?

Mit der Marketing-Bereichsleiterin bei einem Kunden hatte ich kürzlich ein interessantes Gespräch. Nachdem sie das Kanban-Management-Professional-Training mitgemacht hatte, führte sie mit ihrem Marketing-Team Kanban ein. Zuvor gab es schon ein Board in JIRA, aber ohne WIP-Limits, und leider ist es so: Keine WIP-Limits — oder ein anderes eindeutiges Pull-Signal — heißt, kein Kanban.

Mit drei Zutaten kam das Team über ein bis zwei Monate hinweg zu einem gemeinsam verantwortlichen Ownership der Arbeit, wo zuvor sehr stark die Mentalität "meine Arbeit" versus "deine Arbeit" vorgeherrscht hatte. Die drei Zutaten waren:

eine beinharte Pull Policy
ein kollaboratives Spice Girls Meeting
eine geheime überraschende Zutat, Aufklärung am Schluss des Artikels

Schauen wir uns das Ganze etwas genauer an.

Pull statt Grabsch-Assignment!

Im Team herrschte lange schon die Regel "Grabsch-Assignment". Grabsch-Assignment ist ein Kanban-Fachbegriff, den ich gerade erfunden habe. Er beschreibt ein Verhalten, bei dem sich jedes Teammitglied möglichst früh auf die Tickets assigned, die es gerne macht. Damit sind die coolen Aufgaben besetzt — man kennt das von Liegestühlen am Hotel-Pool und territorialen Handtüchern.

Grabsch-Assignment hat aber mehrere Nachteile:

Die weniger coolen Tickets bleiben (eher) auf der Strecke.
Es gibt eine Mentalität von "mein" Ticket versus "dein" Ticket. Das Gegenteil von joint ownership.
Dadurch, dass Tickets "besetzt" sind durch das frühe Assignment, kann man sie nicht mehr pullen, also sich ziehen, wenn man Zeit hätte, das ist schlecht für die Lead Times und den Flow.

Vor allem um das Wir-Gefühl und die gemeinsame Team-Verantwortlichkeit zu fördern, wurde deshalb eine einfache, sehr starre (beinharte) Pull-Regel eingeführt: Rechts vor links und von oben nach unten.

Generell gilt in Flow-Systemen, also auf Kanban-Boards, oft die Regel "rechts vor links", weil man ja eher Dinge fertig machen will, als neue Dinge zu starten. Und von oben nach unten, das vermeidet Cherry Picking, also dass sich Team-Mitglieder die Tickets ziehen, auf die sie Lust haben, obwohl andere eine höhere Priorität haben, aber weniger spaßig sind (= Grabsch-Assignment).

Diese Pull Policy, also die Regelung, wann und wie Tickets gezogen und assigned werden, war einer der drei wichtigen Faktoren, die zum Team-Gefühl "unsere Arbeit" statt "meine versus deine Arbeit" führte, berichtete die Marketing-Leiterin.

Der nächste Faktor war das Vorgehen im sog. "Spice Girls Meeting."

Das Spice Girls Meeting: Tell me what you want

Wer kennt nicht den Spice Girls Hit Wannabe von 1996. Wie heißt es dort so schön: Tell me what you want, what you really, really want. In der Kanban-Community hat sich deshalb für das sog. Replenishment Meeting der Spitzname Spice Girls Meeting eingebürgert.

So nennt es auch das Marketing-Team bei besagtem Kunden. Im Replenishment Meeting wird das Kanban Board wieder "aufgefüllt", sprich, es wird priorisiert, welche Aufgaben als nächstes anstehen und dann gepullt werden können. Die Frage an die Stakeholder ist dabei sozusagen: Was willst du als nächstes? Tell me what you really, really want!

In diesem wöchentlichen Kanban-Meeting priorisiert das beschriebene Marketing-Team einmal pro Woche die Tickets ein, die als nächstes gezogen werden können — man nennt diesen Status oft Selected. Alle im Team haben Mitsprache, was auf Selected kommt, es ist also ein kollaborativer Prozess, in dem alle aufgefordert sind, sich zu äußern, in dem alle Prios und Argumente gehört werden. Dadurch ist der Buy-In viel größer, als wenn ein Product Owner die Selected-Spalte einfach per "Order by Mufti" füllt.

Dieses gemeinsame Einigen auf die nächsten wichtigsten Arbeiten brachte mehr Gemeinschaftsgefühl in die Teamarbeit, berichtet die Bereichsleiterin. Dieses Vorgehen erfordert natürlich gute Moderation und einen partizipativen Führungsstil. Diejenigen, die kein Vertrauen in ihr Team haben, gemeinsam sinnvoll zu priorisieren, würde ich aber ganz frech fragen: Wieso hast du diese Leute eingestellt, wenn du sie nicht für intelligent und kooperationsfähig hältst?

Die dritte, geheime Zutat: Beharrliche Fragen vom "Neuen"

Eine Zutat, mit der ich nicht gerechnet hatte, war ein neuer Kollege im Team. Der wiederum fragte, wenn jemand die Pull-Regel verletzte und sich — wie früher — ein attraktives Ticket pullte statt dem nächsten regulären: "Aber haben wir nicht ausgemacht, dass...?" Mit dem unverbrauchten Spirit eines Neuankömmlings stellte diese Person das Team bei Fehlverhalten ganz naiv in Frage, nicht mit erhobenem Zeigefinger, sondern mit ehrlicher Fragestellung.

Die Aufgabe, diese Art von Fragen zu stellen, liegt als Fallback beim Agile Team Coach, im Notfall bei der Führungskraft, aber es ist natürlich hundertmal besser, wenn sie aus dem Team kommen.

Über den Bericht der Marketing-Leiterin habe ich mich sehr gefreut. Ohne großes Bohei wurden die Kanban-Prinzipien für Service Delivery "Manage die Arbeit, lass die Leute darum herum organisieren" und "Entwickle Policies, um die Outcomes zu verbessern" umgesetzt. Dadurch wurde interessanterweise ein kultureller Change angestoßen, nicht nur einfach eine Prozessverbesserung oder Flow-Optimierung, nämlich das Wahrnehmen gemeinschaftlicher Verantwortung für die Team-Arbeitsergebnisse und das sich offen gegenseitig Challengen bei Unterlaufen der beschlossenen Policies.

Interessieren Sie sich für Kanban und wie Sie, Ihr Team oder Ihre Abteilung davon profitieren können? Vielleicht sind unsere Kanban-Trainings etwas für Sie. Hier können Sie sich informieren und für Fragen stehen wir jederzeit gern zur Verfügung.

Hier geht´s zu unserem Kanban System Design Training

Agile Tuesday „Die Skalierungsfrage: Ein Allround-Coachingtool“ mit Heidi Reimer

christian-braun — Tue, 29 Nov 2022 16:03:56 +0000

Wir verbringen viel Zeit damit über Probleme und deren Entstehungsgeschichte zu sprechen. Und verlieren dabei häufig Motivation und Energie. Sprechen wir stattdessen über Lösungen und vorhandene Ressourcen, entstehen hingegen Zuversicht und Tatendrang. Die Toolbox des lösungsfokussierten Coachings hält wirksame Fragetechniken bereit, die uns helfen, den Blick nach vorne zu richten. In Einzelgesprächen und in Team-Settings.

Heidi Reimer, Coach-Ausbilderin und Inhaberin der HR Akademie München, nimmt Euch mit in das lösungsfokussierte Mindset. Ihr lernt die Skalierungsfrage kennen und erlebt, wie sich mit einer einzigen Frage Unterschiede, Ressourcen, Fortschritte und konkrete nächste Schritte auf dem Weg zur Lösung transparent machen lassen.
Gemeinsam testen wir die Anwendung in kleinen Gruppen und reflektieren anschließend darüber, in welche Situationen in Eurem agilen Alltag sich dieses Coachingtool gut nutzen lässt.

Wir freuen uns auf Euch!

Wichtig: Zum Jahreswechsel wird die Planung des Agile Tuesday nur noch auf meetup.com stattfinden, da Xing die Gruppenfunktion abschalten wird.

Wir freuen uns schon auf euch!

Viele Grüße

Euer Agile Tuesday Team mit Heidi

Hier geht´s zur Anmeldung

"10x your product outcome with the Value Engine" with Sandra Hinz

christian-braun — Wed, 14 Dec 2022 17:33:14 +0000

Are you also struggling to create a real impact with your product teams? Features are prioritized top-down and you fail to generate measurable value. When you were only 3 teams, it was still easy to coordinate, but since you are more than 5 teams you lost the overview. We all want to ensure we're working on the right thing and generating outcomes quickly. It's difficult, but not impossible.
This talk is about the Value Engine, a product management framework that helps you to organize the discovery & delivery of your product teams to create a permanent culture of experimentation and achieve 10x more outcomes with 10x less effort.

Get a sneak peek in this video:
https://www.youtube.com/watch?v=RltPSEo1dWg

About Sandra:
Sandra is a passionate product professional and Co-Founder of the Value Rebels, a product consultancy founded in 2020. She worked as Product Manager and Product Lead for 10+ years in companies such as zooplus and Justeattakeaway, where she majorly influenced the product success and shaped the product organization.
Together with the Value Rebels she is on a mission to shake up the digital product world in Europe and ensure that the next generation of companies uses the role of Product Management to generate more value faster instead of defining feature roadmaps that miss the mark.

We´re looking forward to seeing you!

Wichtig: Zum Jahreswechsel wird die Planung des Agile Tuesday nur noch auf meetup.com stattfinden, da Xing die Gruppenfunktion abschalten wird.

Viele Grüße

Euer Agile Tuesday Team mit Sandra

Hier geht´s zur Anmeldung

Agilität nur ein Hype – Echt jetzt?

jens — Mon, 23 Jan 2023 14:54:59 +0000

Eine Replik an Stefan Kühl zu “Der sinnlose Hype um Agilität”, Harvard Business manager 1/2023

Wenn Stefan Kühl, vielen vielleicht bekannt aus seinem hörenswerten Podcast “Der ganz formale Wahnsinn” mit der Reichweite des Harvard Business managers eine “Wutrede” gegen Agilität veröffentlicht, lässt das aufhorchen. Bei seiner Expertise würden wir es uns etwas zu leicht machen, das als das übliche “Einer hat immer etwas dagegen” abzutun, das das Thema Agilität seit nunmehr 25 Jahren begleitet. Hier muss man etwas genauer hinsehen.

In gewissem Sinne spricht Stefan Kühl mir ja aus dem Herzen, wenn er anprangert, bei Beratern sei “das Wort ‘agil’ ohnehin omnipräsent”. Es gibt tatsächlich kaum ein Beratungsunternehmen, das nicht “irgendwas mit agil” auf der Webseite hat und die Menge frei erfundener Zertifikate scheint exponentiell zu steigen. Mein Liebling: Der “Agile Coach nach ISO / IEC 17024” – wobei die Norm im Wesentlichen besagt, dass man nach dem Training noch irgendwas testet. So etwas ist tatsächlich “An Banalität kaum zu überbieten”, um Stefan Kühls Worte zu verwenden.

Mit seinem Test auf Banalität macht er es sich aber zu einfach. Stefan Kühl argumentiert entlang der folgenden Linie: Banal ist alles, dessen “Negation eine nicht in Betracht kommende Alternative ergibt” – eine Definition für “Banalität”, die sich zumindest mir aus der des Dudens nicht unmittelbar erschließt. Bei Agilität handele es sich nun um “die Fähigkeit einer Organisation, sich kontinuierlich an ihre komplexe, turbulente und unsichere Umgebung anzupassen” und das Gegenteil dessen kann ja kaum wünschenswert sein. Also sei Agilität banal.

Diese Argumentation ist wenig überzeugend. Wenn wirklich alles banal wäre, dessen Gegenteil nicht in Betracht kommt, müssten wir kaum um den sozialen Frieden oder gegen Krieg und Hunger auf der Welt kämpfen.

Der eigentliche Argumentationsfehler liegt aber in der impliziten Schlussfolgerung, dass ein banales Ziel immer auch über einen offensichtlichen Weg erreichbar wäre, also nicht bedenkenswert sei und damit im eigentlichen Sinne banal. Nachdem viele Managerinnen und Manager Flexibilität als ein wünschenswertes, aber eben nicht erreichtes Ziel ansehen, scheint Agilität eben doch nicht so selbstverständlich zu sein, wie Stefan Kühl behauptet.

Tatsächlich gibt es einen Zielkonflikt zwischen Flexibilität auf der einen Seite und anderen wünschenswerten Eigenschaften eines Unternehmens, wie Vorhersagbarkeit und Effizienzoptimierung auf der anderen Seite. Management kann man sehen als die Navigation eines Unternehmens durch Zielkonflikte. Die richtige Balance kann sich dabei durchaus im Laufe der Zeit verschieben. Zielkonflikte zu ignorieren ist aber ein Zeichen denkfaulen und damit schlechten Managements. Das kann zum Untergang des Unternehmens führen oder zumindest dessen Marktposition gefährden. Namen wie Xerox, Kodak oder Nokia sind immer wieder genannte Beispiele.

“Beim Hype um Agilität können sich Manager entspannt zurücklehnen. Das Wissen ist [...] in der Organisation bereits vorhanden,” schreibt Stefan Kühl. Das ist ein denkbar schlechter Rat. Korrekt ist, dass oft einzelne Mitarbeiterinnen und Mitarbeitern des Unternehmens viel über Agilität wissen. In der Praxis verlassen aber auch viele dieser Menschen die Organisation bald frustriert, weil ihnen die Strukturen und die Manager den notwendigen Spielraum verwehren. Die dafür verantwortlichen Mechanismen sind alles andere als banal und die Sichtweise eines Organisationssoziologen darauf wäre bestimmt bereichernd.

Genau darum geht es auch bei agilen Transformationen: Das vorhandene Wissen organisatorisch wirksam werden zu lassen. Das sei alles “kalter Kaffee", merkt Stefan Kühl an und sei bereits seit den 1960er Jahren bekannt. Und ja, der Zielkonflikt, über den ich oben geschrieben habe, ist bereits in den 1980ern von Henry Mintzberg beschrieben worden. Die systemischen Ansätze gehen auf Niklas Luhmanns Arbeiten aus den 1960ern zurück. Aber ist ein moderner Computer wirklich kalter Kaffee, nur weil Konrad Zuse bereits 1941 Relais in ähnlicher Weise verschaltet hat?

Einem Wissenschaftler sollte es eigentlich Freude bereiten, wenn man auf existierendem Wissen aufbaut und es in der Anwendung weiterentwickelt. Den Vorwurf, es dabei mit der Quellenarbeit nicht immer allzu genau zu nehmen, müssten sich viele Agilisten gefallen lassen und gelegentlich wäre da auch ein gewisser Furor der Wissenschaft heilsam. Aber dieser berechtigte Vorwurf findet sich in Stefan Kühls Wutrede ja gar nicht.

Es ist sicherlich sinnvoll, “das Konzept [der Agilen Organisation] von den nach Zustimmung heischenden Wohlfühlformeln [zu ] entkleiden”, wie Stefan Kühl formuliert, um dann “drei zentrale Ideen” zu identifizieren:

Auflösung der strikten Grenzen zwischen den Silos
Rückbildung der hierarchischen Struktur bis hin zu deren kompletten Abschaffung
Verzicht auf die Formalisierung der Organisation

Zwar gibt es anders als bei der “Agilen Software Entwicklung” keine allgemein anerkannte Definition einer “Agilen Organisation”, wenn aber Aspekte wie Betrachtung der Wertschöpfungskette und organisatorisches Lernen bei der Abstraktion auf der Strecke bleiben, hat man wesentliche Teile organisatorischer Agilität aus den Augen verloren. Zudem ist die Rückbildung von Hierarchie die Konsequenz davon, dass man Entscheidungen dorthin verschiebt, wo sie am besten und schnellsten getroffen werden können und weder Selbstzweck noch zentrale Idee.

Die Kritik an oberflächlichen Beratern, die nicht mehr zu bieten haben als “abstrakte Prinzipien wie ‘Mut’, ‘Respekt’ und ‘Offenheit’, ergänzt um wolkige Maxime wie ‘Vertrauen’, ‘Selbstverantwortung’ und 'Kollaboration,'" ist absolut gerechtfertigt. Leider existieren solche Berater. Sie richten massive Schäden in den Unternehmen an, die ihnen vertrauen. Und sie ruinieren den Begriff der Agilität. Was sie anbieten, hat tatsächlich mehr mit Cargo-Kult zu tun, als mit seriöser Beratung.

Stefan Kühl beschreibt in seinem Beitrag die Karikatur denkfauler Manager und oberflächlicher, geldgieriger Berater. Das ist legitim und kann durchaus amüsant sein. Daraus aber Schlussfolgerungen zu ziehen ist zumindest gefährlich, weil ich aus einer Karikatur getreu dem Motto “Ex falso quodlibet" jedes beliebige Argument ableiten kann. Das ist dann aber kein Debattenbeitrag, sondern höchstens dessen Simulation.

Gegen Banalität, Denkfaulheit und Oberflächlichkeit helfen Tiefgang und Präzision. Zumindest in seinem Podcast beweist Stefan Kühl immer wieder, dass er auch diese Tugenden beherrscht.

The EMU team - a tale of a Scrum team trying Kanban

mats.olof.winroth — Tue, 07 Feb 2023 15:15:46 +0000

This is a story about the path for a scrum team who started to use Kanban and the results of
the transition, which brought considerable improvements in performance but also improved
the situation for the development team.

The EMU team is working within the product line Human Vision, in the Continental ADAS
business line. The products provide a wide range of visualizations to support parking or
giving a better view around the car. Right now, the team works in the end phase of a
customer project for a good but demanding customer. The project is running in SAFe.
Why did the EMUs want to try out Kanban, it is a mature Scrum team that actually loves
Scrum? On the other hand, as most of us have experienced, in project “end phases” things
are not always running 100% smooth.
The customer felt the bug tickets were not prioritized high enough and that things generally
took too long. The customer was also unhappy with lack of flexibility for the frequent
unplanned “must have” tasks and had limited understanding for the team’s preference to
work on planned items.
The team on the other hand was annoyed with the, already mentioned, unplanned
customer items and the need to allocate time for unplanned review for external
contributions. They were disturbed that people often ran out of planned work in the end of
the sprint and that sometimes some items took very long time to get done. The team was
also, and still is quite large, in the project end phase with some 15 members. This resulted in
long and sometimes inefficient Scrum meetings. So far, the Emu’s did not want to split up in
two, more Scrum sized teams. One reason was it would be hard to make the teams
independent.
This was the situation when Felix, the EMU Scrum master and Martin, the PO searched for a
new way of working. We had already earlier had some lose chats about Kanban but now
they had gotten a buy-in from the EMU development team and asked if we together could try out if Kanban could improve the situation. It needs to be said, the EMU team is very
open for change and were encouraging the experiment.

How did we setup Kanban?

We planned two workshops; one to run a flow simulation with the team. It was an online
version of Klaus Leopold’s “the Ship building simulation – improving and scaling Kanban”
(please find on YouTube). It is a great visualization about the difference of flow for a push
system and a pull system, with WIP limits. When running in pull mode the throughput
improves a bit but the changes in lead-time and predictability are enormous. Such a
simulation is a very good start to understand the ideas of pull and flow from Kanban.

The second meeting was a STATIK workshop, which is a “Systems Thinking Approach To
Introduce Kanban”. It is a systematic approach to investigate the situation from a holistic
point of view, where the whole team takes active part to define the way of working. When
is the service fit for purpose? What are sources for dissatisfaction? What kind of
requirements do we have? What is the performance? Thereafter you agree on a workflow
model, agree on how to handle different classes of services, and finally design a Kanban
system. The STATIK process helps to ensure we consider many facets of the situation, helps
us to get a common understanding and provides an agreement for the setup and next steps.

Finally, the still engaged team discussed and agreed on explicit rules for handling of the
process and the Kanban board. A stringent and “lived” set of rules is key for a successful
Kanban implementation. They agreed on WIP Limits for of the various workflow states and
on rules to always pick the highest prioritized item from the Selected items, even if it does
not fit to your expertise, to not move items backwards in the flow, that impediments are not
counted in the WIP but are discussed every day and that they have at maximum one blocker
in an expedite lane, that is allowed to break the WIP limit and order of execution.

The EMUs agreed to keep many of the processes from their Scrum that worked well, like
standups, review meetings, retrospectives and backlog refinement. These are also explicit
cadences in Kanban. The general cadence for e.g., review and retrospective is still two
weeks.
However they stopped estimation of items after a while, since the value of estimation is
lower in Kanban and to save time. Even if items are not mapped to sprints the team focuses
more on breaking down items as much as sensible, but in all cases shorter than two weeks.
They also have more focus on getting items “really done”, by including unit test and
documentation in the items.
For the replenishment of selected items, the active backlog for the team, they introduced a
rule to fill up when the number of selected items goes below a defined level (right now 5
items).

Was there an outcome?

The new way of working had several positive effects. The customer got a considerably
higher throughput and some improvement in lead time but also experienced better
flexibility for ad hoc requests. The customer could also be confronted with direct impact on
putting urgent tasks in the backlog. This helped the stakeholders to reduce the number of
items with highest priority to get better focus.
For the team the new process has improved many things in addition to the feedback “more
pleasant / Less painful”. The team has got more flexibility and has less overhead, for
instance with leaving out estimation and having less discussions. “We have better focus on
the right things”, “we always have something important to work on” and “unpopular items
do not hang around for long time anymore”. In fact, even quality improved, since there is no
temptation to take a shortcut to get an item ready for the sprint end, now you can spend an
extra day or two to get something “really done”.
Other effects were better co-operation and a more active inspect and adapt process, with
more improvement proposals from the team. This may be the result after any change.
On the other hand, the team misses the end of a sprint when you can slow down, think a bit
and then start up again. In their Kanban setup the process still runs in a more continuous
mode, with less time for calm downs and re-thinkings.

What about the performance for the new setup?

Interesting enough the major change in delivery after introducing Kanban was in terms of
throughput, where the team delivered around 40% more during the 6 months after the
transition, compared to the 6 months before.
Also the lead time improved but not as significant, with a 15% reduction for the 85%
percentile (the lead time at which 85% of the items are closed).
The limited change in lead time is probably based on that the mature EMUs already had
focus on closing items in the scrum setup, but also due to the complicated long items that
turn up in every project end phase, when the simple things have already been fixed.
The increase in throughput is not fully clear, the team claimed in a presentation based on
early results “We do not know why we close more items (too good to be true?)”. However
also after 6 months there is a significant improvement. The reason is probably based on better cooperation between team members, where the WIP limits could lead to more pair
work, together with even more focus on finishing items. Further there was less down time
for developers, that earlier sometimes happened in the end of the sprints.
The improvement may also be related to other factors like item size and improved learning
and experience of developers.

Learnings and conclusions

For the EMU team the Kanban process improved the general performance in terms of
throughput and lead time, but it also improved the flexibility and focus to work and close
the most critical items. This has helped the team to provide a better service to the
customer.
The customer can be confronted with direct impact on putting urgent tasks in the backlog.
This helps the stakeholders to not put in too many items with highest priority.
The team experienced the new way of working as “more pleasant / Less painful”, within a
process that they had defined themself. The benefits are for instance less overhead in the
process, the urgent customer requests that earlier destroyed the planning are now business
as usual and there are always most important items to work on, earlier team members were
often without work in the end of the sprint. The team also owns the process better; when
the customer and/or PO now comes with a tricky request to be taken up “now” the team
asks “Is it a blocker? … well if it is not, please put it in the “selected” column, we’ll work on it
next”.
The initial workshops with flow simulation and STATIC helped to explain the benefits with
Kanban but also to get a buy in from the team. It is their process.
The Scrum master and Product Owners are obviously happy with the way Kanban turned
out but what would they do if they had to start from scratch:
Martin, the PO, “If I started up a new project I would probably start with Scrum and then
consider applying Kanban when team and project get more mature. In the early phase the
Scrum process seems to provide better structure to encounter too much flexibility from the
stakeholders.“
Felix, the SM, “the next thing to try out is to split the big team in two or three teams.”

And what happened to the EMUs in the last months?

For the last three months the project has an even higher demand on resolving items fast. At
this point the simple bugs were already fixed, what remains are complicated issues and
performance problems that require maximal focus. To encounter the situation the team,
still open for experimentation, decided to temporarily split up in four focus/topic sub teams,
which maintained own specialized backlogs. To further gain momentum, the whole
worldwide team co-located in Ulm for a week, it was a required and very appreciated move
to align on the last activities and tasks within the project before code freeze.

In the new setup the standup meetings were held per topic team, with a second common
standup with representatives for each topic team to align the whole team. The positive
effects were improved co-operation and communication in the small teams, including very
fast review and further improved throughput. A minor downside was the reduced
transparency for focus on the right things, since not all team members participated and
aligned in the common daily standup.
In the last weeks the sub teams joined into the normal EMU team again, since the most
critical specific work were closed into a more general bug fixing phase.

Felix Paffrath Conti, Martin Bürker Conti and Mats Olof Winroth improuv.

Agile Tuesday „Agile Transformation: was kommt nach den Flitterwochen?" mit Ugur Akin

christian-braun — Fri, 10 Feb 2023 08:52:48 +0000

Aka: ein Problem kommt selten allein

Agile Transformationen sind ein spannender und manchmal auch überraschender Prozess, der viele Herausforderungen mit sich bringt. Kein Kontext, keine Transformation ist gleich, und doch kann man aus den Erfahrungen anderer viel lernen. Ugur hat über den Tellerrand hinausgeschaut und in acht verschiedenen Unternehmen Experteninterviews geführt, um mehr über die Herausforderungen zu erfahren, denen sie begegnet sind und wie sie diese gelöst haben.

Zu Ugur Akin:

Seine Erfahrung ist, dass Menschen zuerst miteinander reden müssen, damit sie erfolgreich zusammenarbeiten. Agile Werte wie Offenheit, Mut sowie Arbeiten auf Augenhöhe mit motivierten Kollegen machen das möglich.

Ugur ist mit 3 Jahren aus dem Orient in den Okzident gezogen, kennt die unterschiedlichsten Kulturen und verbindet diese. Dafür nutzt er vor allem drei Dinge: seinen systemischen Blick, seine Lust am Lernen und seine Fähigkeit, die Weiterentwicklung von Teams und Produkten durch kontinuierliches Feedback zu fördern.
Für ihn trägt jede Stimme zum Erfolg bei – von den einzelnen Teammitgliedern bis zum Vorstand. Denn Kommunikation ist für ihn die Basis von Agilität.

Wir freuen uns schon auf euch!

Viele Grüße

Euer Agile Tuesday Team mit Ugur

Hier geht´s zur Anmeldung

Business Agility: Unsere liebsten Bücher

sacha.storz — Wed, 15 Feb 2023 15:07:28 +0000

"A room without books is like a body without a soul."

— Cicero

Mit Anfang 2023 starten wir eine Reihe von regelmäßigen Postings über unsere Lieblingsbücher. Wir stellen dabei — unserer Meinung nach — wichtige Bücher zu Agilität, Lean, Führung, Management und Strategie vor, brandaktuell ebenso wie zeitlos klassisch.

Ganz gleich, ob du Führungskraft, Agile Coach, Scrum Master:in oder einfach jemand bist, der seine Fähigkeiten und sein Wissen verbessern möchte, unsere Beiträge sollen dir wertvolle Informationen und Impulse geben. Mit Büchern aus den Kerngebieten von Lean und Agile, aber auch Titeln, die man über den Tellerrand hinaus erspäht. Und vielleicht hast auch du ein Werk, das uns unbedingt empfehlen willst? Dann sag uns gern unter kontakt@improuv.com Bescheid, wir würden uns freuen.

Wir sind davon überzeugt, dass die Bücher, die wir besprechen werden, etwas Wertvolles zu bieten haben. Erforsche mit uns Ideen, Konzepte und Praktiken. Begleite uns auf unserer Reise durch das beinahe unendlich große Universum interessanter Literatur.

Heute starten wir mit einem ganz und gar nicht neuen, aber um so aktuelleren Buch von Henry Mintzberg, das uns Jens Coldewey vorstellt.

Mintzberg on Management

Viele Menschen glauben ja, um neue Ideen zu bekommen, müsse man neue Bücher lesen. Aber nicht alle neuen Bücher enthalten wirklich neue Ideen. Und dann gibt es noch alte Bücher, deren Ideen erst heute ihre ganze Größe entfalten. “Mintzberg on Management” ist für mich ein solches Buch. Nachdem es auch (viel zu) wenig bekannt ist, nehme ich es in diese Liste auf.

Henry Mintzberg hat in den späten Siebzigern über die Tätigkeiten von Managern promoviert. Das Neue an seinem Ansatz war, dass er dabei nicht versucht hat, bestehende Management Theorien zu validieren, sondern eher wie ein Anthropologe dokumentiert hat, was Manager wirklich tun. Das Ergebnis in Kürze: Die von ihm beobachtete Praxis hatte wenig mit Theorien zur Unternehmensführung zu tun. Damit hatte er sein Forschungsfeld für die nächsten Dekaden gefunden.

In diesem Buch hat er versucht, seine Beobachtungen zu einer Theorie über Management und Organisationen zu verdichten. Einer Theorie, die auch eine Generation später noch erstaunlich gut funktioniert, auch wenn sich in der Zwischenzeit der ein oder andere Aspekt ein wenig verschoben hat.

Ein Goldnugget dieses Buchs sind für mich die sechs “Unternehmenskonfigurationen”, in denen Mintzberg völlig wertfrei sechs Muster beschreibt, nach denen Organisationen funktionieren. Dabei konzentriert er sich auf (real existierende) Macht- und Entscheidungsstrukturen und Kommunikationswege. Der Weg von dahin zu modernen Ansätzen wie Glenda Eoyangs “CDE Modell” ist extrem kurz.

Aus Agiler Sicht macht Mintzberg schon in diesem Buch sehr deutlich, warum es nicht ausreicht, ein paar Rollen neu zu definieren und “den Scrum Prozess auszurollen”. Die Einführung von Agilität bedeutet in Mintzbergs Modellen die Konfiguration des Unternehmens zu verändern. Und das ist ein Eingriff in die DNA, vor dem man Respekt haben sollte.

Wer Verantwortung für Organisationen hat, oder anderen dabei hilft, sie zu verändern, sollte dieses Buch gelesen haben.

Henry Mintzberg, Mintzberg on Management, 1989 (!)

empfohlen von Jens

ABIT Konferenz: Nachhaltige Entwicklung braucht innere Entwicklung

hedi.buchner — Thu, 02 Mar 2023 13:00:41 +0000

Als ausgebildete 'Consultants for Global Change' freuen sich Sabine und Hedi schon sehr auf ihren Workshop auf der diesjährigen 'Agile Beyond IT' Konferenz, am 27. April, in Hannover.

Nachhaltige Entwicklung braucht innere Entwicklung: agile Schritte in eine lebensbejahende Zukunft

Agilität bedeutet vor allem Flexibilität und Schnelligkeit. Sie sorgt für Wachstum und hält das Unternehmen am Laufen. Aber seien wir ehrlich: genau dieses System ist die Ursache für die Klimakrise und andere damit verbundene Nachhaltigkeitsprobleme. Können wir Agilität als “Beschleuniger” nutzen, um die UN Sustainable Development Goals (SDGs) zu erreichen? Welche inneren Fähigkeiten brauchen wir, um mit diesen zunehmend komplexen Herausforderungen umzugehen? Mit welchen kleinen Schritten können wir starten, um damit eine nachhaltige Wirkung zu erzielen?

Unser Workshop soll ein Bewusstsein für diese Herausforderung schaffen – und für die Verantwortung, die damit einhergeht. Als Inspiration zeigen wir konkrete Beispiele von Agilist:innen, die sich bereits auf einen nachhaltigen Weg begeben haben. Gemeinsam erforschen wir die SDGs und entwickeln Ideen, wie wir dazu beitragen können: in der Produktentwicklung, mit unseren Teams und Organisationen, aber auch in unserem Privatleben. Wir werfen einen Blick auf die Inner Development Goals (IDGs), die uns helfen sollen, ein zielgerichtetes, nachhaltiges und produktives Leben zu führen.

Key Takeaways

Wie passen Agilität und Nachhaltigkeit zusammen?
Was sind Sustainable Development Goals?
Was sind Inner Development Goals?
Praktische Ansätze und Methoden zur Umsetzung von Agilität und Nachhaltigkeit in Unternehmen und im privaten Kontext

An wen richtet sich dem Workshop?

alle, denen Nachhaltigkeit ein Herzensanliegen ist. Egal ob sie bereits agil arbeiten oder damit beginnen wollen

#Agilität #Nachhaltigkeit #SustainableDevelopmentGoals #InnerDevelopmentGoals

Bist du dabei?

Disruptive Technologies Konferenz: Woran Marktführer sterben – und was dagegen hilft

hedi.buchner — Thu, 02 Mar 2023 13:10:45 +0000

Unser Transformation Coach und Berater Sacha ist nächste Woche in Berlin auf der Disruptive Technologies Konferenz. Schaut doch vorbei und hört euch seinen Vortrag zu Innovationsfähigkeit von Marktführer an.

Woran Marktführer sterben – und was dagegen hilft

Ihr seid Marktführer und baut die besten Produkte in Eurem Bereich? An Euer Know-how kommt niemand heran? Dann kann es sein, dass genau das, was Euch derzeit stark macht, Euch in wenigen Jahren vom Markt fegt. Die Wirtschaftsgeschichte ist voll mit Marktführern, die eine vermeintlich kleine Veränderung im Markt ins Verderben gestürzt hat.

In dieser Session schauen wir uns gemeinsam an, was dabei passiert, warum Know-how einen sogar anfällig machen kann für Disruption. Anhand von Beispielen können wir sehen, dass eine neue Art der Vernetzung bereits vorhandener Expertise erfolgsentscheidend sein kann. Wir schauen gemeinsam darauf, welche Veränderungen notwendig sind, und wie man den Agilen Baukasten einsetzen kann, um Eure Expertise in nachhaltige Innovationsfähigkeit umzusetzen.

Agile Tuesday "Playful Agile Coaching" mit Dennis Wagner und Marc Bleß

Wed, 08 Mar 2023 12:34:44 +0000

Wie Du spielerisch alle Herausforderungen mit Teams, Organisationen und Führungspersonen überwindest.

Agile Spiele und Simulationen sind das Silver-Bullet für Agile Coaches und Scrum Master. Mit spielerischen Ansätzen lassen sich so gut wie alle Herausforderungen mit Teams, Organisationen und Führungspersonen überwinden. Die beiden Autoren Dennis Wagner und Marc Bleß haben ihr aktuelles Buch zum Thema im Gepäck. In einer Art Lean Coffee werden wir viele Spiele und Simulationen vorstellen. Tipps und Tricks zu Moderation, Workshop-Aufbau mit Spielen, Umgang mit Störungen und weitere Themen aus unserem Buch runden das Ganze ab. Es bleibt genug Zeit zum Austausch und für Fragen und Antworten.

Auf LinkedIn könnt ihr euch für das Event anmelden & am besten auch gleich dem Agile Tuesday folgen, damit ihr auch in Zukunft kein Treffen verpasst :-)

Welche Probleme löst Kanban eigentlich?

sacha.storz — Wed, 22 Mar 2023 15:51:56 +0000

Kanban ist ein beliebter Ansatz für die Optimierung von Flow, Auslastung und Lieferfähigkeit. Manchmal habe ich jedoch den Eindruck, dass Teams und Organisationen Kanban einfach benutzen, weil es modern ist und weil es gut klingt, und belassen es dann dabei, Post-its über ein Whiteboard zu ziehen. Immerhin stellt dieser Ansatz Transparenz her, aber das ist noch kein Kanban.

Kanban basiert auf der Idee, die Arbeit zu visualisieren, ja, aber vor allem auch die im System befindliche Arbeit zu begrenzen — mit sogenannten Work In Progress Limits, WIP Limits. Und dann mit expliziten Regeln zu arbeiten (Policies), z.B. “Zieh immer das älteste Item aus der Selected-Spalte, nicht irgendeines”. Und dann diese Regeln langsam so zu optimieren, dass das optimale Ergebnis entsteht: Flow und Zuverlässigkeit. Erst so entfaltet Kanban seine Wirkung und löst so manches Problem, unter denen fast alle Organisationen notorisch leiden.

Kanban vermeidet Überlastung

Eines der häufigsten Probleme, mit denen Unternehmen konfrontiert sind, ist die Überlastung von Menschen, Teams, ja eigentlich der ganzen Organisation. Wenn zu viel Arbeit zu erledigen ist, sind die Mitarbeiter überfordert und überlastet, Priorisierung ist schwierig, und alles dauert ewig, bis es fertig wird. Kanban reguliert die Arbeitsmenge und zielt darauf ab, Leerlauf zu verhindern und Überlastung ebenso. Flow entsteht nur, wenn die Arbeitslast und die Leistungsfähigkeit (Capability) des Systems zusammenpassen.

Kanban verbessert Lieferfähigkeit und Zuverlässigkeit

Ein weiteres Problem, mit dem Unternehmen häufig konfrontiert sind, ist ein Mangel an sogenannter Predictability, also der Güte von Forecasts und Lieferversprechen. Wenn das Team sagt “Das Arbeitspaket ist in 14 Tagen fertig”, was heißt das dann? 14 Tage? Zwischen 10 und 40 Tagen? Zwischen 20 und 60 Tagen? Oder: Keiner weiß es?

Ohne eine klare Vorstellung davon, wie Durchlaufzeiten und Durchsatz von Teams, Services und Abteilungen sind, ist es schwierig, vernünftig zu planen und pünktlich zu liefern. Kanban hilft, dieses Problem zu lösen, indem es erstens Transparenz über den Status der Arbeit schafft und mit den WIP Limits dafür sorgt, dass ein balanciertes System entsteht: Ein System, in dem Flow herrscht und bei dem ich weiß, wie viel Arbeitspakete in welcher Zeit abgearbeitet werden. Und zwar nicht auf Basis von Bauchgefühl, Würfeln oder Fantasie-Gantt-Charts, sondern auf Basis von einfacher, robuster Statistik.

Kanban stellt Fokus her

Ein weiteres Problem, mit dem Unternehmen häufig konfrontiert sind, ist ein Mangel an Fokus. Wenn der Chef fragt “Was ist mit Arbeitspaket X?”, ist es am besten, man kann antworten: “Klar, Chef, X ist schon in Arbeit.” Die implizite Aussage, dass mit X zusammen noch circa 50 andere Arbeitspakete in Arbeit sind, unterschlägt man besser. Denn das hat zur Folge, dass niemand weiß, wann Arbeitspaket X jemals abgeschlossen wird. Die Kanban-Devise ist deshalb: Stop starting, start finishing! Ohne Fokus kann kein Flow entstehen.

Ein WIP Limit auf dem Pool an Arbeit, die man als nächstes angeht — ganz einfach à la “Was sind die nächsten 5 wichtigen Dinge?!” — führt dazu, dass man viel genauer überlegen muss: Was ist jetzt wichtig? Dieser Fokus ist oft schmerzhaft, aber immer hilfreich. Im Beispiel des Kanban Boards unten sorgt das WIP Limit der Spalte Selected für diesen Fokus.

Was dazu kommt: Durch die Begrenzung der laufenden Arbeiten und die Konzentration auf die Erledigung von wenigen Aufgaben können sich die Leute auf die derzeit wichtigsten Aspekte und Ziele konzentrieren, es gibt weniger Kontextwechsel, das kommt der natürlichen Arbeitsweise des Gehirns entgegen.

Kanban unterstützt die team-übergreifende Zusammenarbeit

Dass Kanban Transparenz herstellt über die Arbeit, haben wir schon gesehen. Sobald aber mehrere Teams mit Kanban arbeiten, kann etwas Magisches passieren: Teamübergreifendes Kanban hilft uns, indem es uns auf die nächste Flughöhe hebt und die Perspektive auf den Flow erweitert. In diesem Fall spricht man von Skalierung oder skaliertem Kanban.

Die Ergebnisse der einzelnen Teams, also Kanban-Systemen auf Flight Level 1, fließen dann auf Flight Level 2 zusammen zu einem übergreifenden Kanban-System. Auf diesem “Über-Kanban-Board” sieht man das Zusammenspiel aller einzelnen Teams und Services und kann Abhängigkeiten, Priorisierung und Probleme wirkungsvoll behandeln.

Fazit: Kanban ist kein Allheilmittel — heilt aber ziemlich viel!

Das hier gezeigte Kanban Board stellt exemplarisch dar:

WIP Limits (in rot) pro Workflow-Status
- um Pull zu implementieren und
- um Überlastung des Systems zu vermeiden und
- um hohe Predictability herzustellen: Wir arbeiten immer nur an 10 Work Items gleichzeitig, dafür wissen wir bei denen dann recht genau, bis wann sie fertig sind
eine spezielle Service-Klasse
- oft als sogenannte “Fast Lane” oben auf dem Board implementiert
- mit der sehr dringende Arbeiten bevorzugt behandelt werden
- mit einem WIP Limit von 1, weil wenn es zu viele “Silver Bullets” gibt, verlieren sie ihre Wirkung
sogenannte Kapazitätsallokation (Capacity Allocation)
- die dafür sorgt, dass wir zu jedem Zeitpunkt mit 70% unserer Kapazität auf dem “gelben Projekt” arbeiten, mit 20% auf dem blauen und mit 10% auf dem grünen.

Mit ein paar simplen Regeln/Policies und augenfälliger Visualisierung haben wir sehr viel Liefer-Güte in unser Arbeitssystem eingebaut.

Zusammenfassend lässt sich sagen: Kanban ist ein effektiver Ansatz, der viele der üblichen Probleme von Unternehmen lösen kann. Durch die Visualisierung der Arbeit, die Begrenzung der laufenden Arbeit (WIP Limits) und die Optimierung des Arbeitsflusses auf allen Ebenen hilft Kanban Organisationen, ihre Effizienz, Liefergeschwindigkeit und Termintreue zu steigern und gleichzeitig die Transparenz und Zusammenarbeit zu verbessern.

–

Wenn Sie Kanban effektiv einsetzen wollen, sind vielleicht die Trainings Kanban System Design und Kanban Systems Improvement für Sie interessant. Werden Sie zertifizierter Kanban Management Professional!

Und wenn Sie mehr darüber erfahren möchten, wie Sie die Lieferfähigkeit und Zusammenarbeit mehrerer Teams oder Services effektiver koordinieren können — nehmen Sie an unserem Flight Levels 2 Design Workshop teil.

Flight Levels und das Kanban Maturity Model

sacha.storz — Thu, 23 Mar 2023 15:21:42 +0000

Wir hatten beim letzten improuv Coach2Coach Open Space eine hochinteressante Session zum Brückenschlag zwischen dem Flight-Levels-Ansatz und dem Kanban Maturity Model (KMM).

Flight Levels setzt oben an, Kanban unten?

Zunächst setzte Alisa Ströbele das Flight-Levels-Konzept in Beziehung zum Kanban Maturity Model (KMM). Ein extrem spannender Teil der Diskussion war: Flight Levels (FLs) steigen eher auf einer höheren Org-Ebene ein, also dem Ende-zu-Ende-Value-Stream oder sogar der Strategie. Wie die einzelnen Teams/Services arbeiten, also mit Scrum, Kanban, X oder Y, ist dabei erst mal unerheblich, denn die E2E-Betrachtung auf FL2 bringt zwangsläufig Flow-Probleme ans Licht und ist dabei pragmatisch und lösungsorientiert: Probleme lösen, statt über Scrum philosophieren. Das heißt: Denken “von oben nach unten”.

Kanban geht, vom KMM und vom Service-Gedanken her, erst mal von den einzelnen Teams aus. Einer Organisation, die auf Maturity-Level 0 (Kultur-Wert: Achievement) lebt, mit einer Werte-Aspiration von Maturity-Level 3 zu kommen (z.B. Fit for Purpose) ist nicht sinnvoll, weil das für die Organisation bzgl. der Lieferfähigkeit, Agilität und den umsetzbaren Praktiken ein viel zu großer Sprung wäre — sie ist noch nicht reif dafür. Sprich: Im Grundkurs Mathe macht man keinen Stoff aus dem LK Mathe. Die Skalierung von Kanban in die gesamte Org hinein über das KMM erfolgt also über die Reifung zunächst der Teams hin zu systemischen Zusammenhängen. Das heißt: Denken “von unten nach oben”.

Was ist wichtiger? Reifung Bottom up oder Top Down?

Die spannende Gretchenfrage in unserer Diskussion war nun: Soll ich das eine vor/nach dem anderen machen? Und was mache ich zuerst?

In einem Fallbeispiel von EOS, das ich mit Bastian Hassloch dargestellt habe, war mein Learning in diesem Zusammenhang: Wir hätten Lieferfähigkeit, Predictability und Flow auf FL1, also der Team-Ebene, früher angehen sollen in unserer Flight-Level-Initiative. Denn die Erkenntnis auf FL2 "Hier ist kein Flow" löst ja nicht automatisch die Probleme, die Teams auf FL1 mit dem Flow nun mal hin und wieder haben. Sonst würden Scrum Teams ja Sprints, in denen sie keine externen Abhängigkeiten haben, immer abschließen. Tun sie aber nicht. Mangelnder Flow auf FL2 ist also nicht immer und nur ein Problem des Zusammenspiels einzelner Services — es ist m.E. auch die Frage, wie gut diese einzelnen Services gemanaged sind (oder sich selber managen), wie zuverlässig ihre Prädiktion (Forecast) ist usw.

Andererseits wäre es doch auch merkwürdig, wenn man sagt: Wir können uns jetzt noch nicht mit unserer Fit-for-Purpose-Strategie beschäftigen, mit den Business-Risiken, die wir haben, und mit dem Problem Solution Fit unserer Produkte und Services. Nein, nein, bevor wir irgendwas davon machen, müssen erst alle unsere Services/Teams optimalen Flow lernen, super Predictability und Just-In-Time-Replenishment. Zurecht würde die Organisation auf so einen Rat hin sagen: Du spinnst.

**Kein “entweder oder”, sondern ein “*und auch”***

Wie so oft im Leben gilt auch für die beiden skizzierten Ansätze kein erst eins, dann zwei und auch kein entweder oder — sondern ein und auch. Bei einer evolutionären Verbesserung der Organisationsreife müssen wir auf allen Ebenen anfassen: Auf der Ebene der Services und Teams (FL1), der Ende-zu-Ende-Value-Streams und übergreifenden Koordination (FL2) und der Ebene von Portfoliomanagement und Strategie (FL3).

Hier kann das KMM als Analyse und Coaching Tool helfen, angemessene Schritte der evolutionären Verbesserung zu planen und umzusetzen. Und das ergänzend zu den Aktivitäten der Flight Levels.

Das klingt vermutlich trivial, wird aber m.E. in Transformationen gern vernachlässigt. Der Ansatz "Wir rollen jetzt erst mal Agilität in die Teams aus" ohne über Portfolio nachzudenken, ist nur die halbe Miete — genauso wie eine geniale perfekte Strategie, die an der Execution scheitert, weil auf FL2 und FL1 totales Chaos herrschen.

Das Flight Level Modell als Change-Perspektive

Es braucht also folglich ein Change Team, das alle drei Flight-Levels-Ebenen betrachtet, Zusammenhänge versteht und die Wirksamkeit der einzelnen Change-Interventionen für das Gesamtsystem evaluiert.

Somit sind Flight Levels auch ein leichtgewichtiges Instrument für die systemische Betrachtung der Organisation: Auf allen drei Ebenen muss Verbesserung und Veränderung ansetzen, und nur im Kontext miteinander werden diese Veränderungen zu Business Agility führen.

–
Wenn Sie sich für Flight Levels und Kanban interessieren, haben wir evtl. spannende Schulungen und Workshops für Sie.

Reihe "Lieblingsbücher": The Book of Beautiful Questions

sacha.storz — Tue, 28 Mar 2023 09:28:27 +0000

The book of beautiful questions von Warren Berger ist ein Leitfaden für alle, die in ihrem persönlichen und beruflichen Leben neugieriger, kreativer und effektiver werden wollen. Waren Berger bezeichnet sich als “questionologist”, als “Fragenwissenschaftler”, und man möchte nicht glauben, dass man ein ganzes — hervorragendes — Buch über Fragen schreiben kann, aber: das Buch lohnt sich ganz unbedingt!

Im ersten Teil des Buches werden die Vorteile des Fragenstellens erörtert und Berger legt dar, warum das Fragenstellen in der heutigen komplexen Welt eine so wichtige Fähigkeit ist. Der zweite Teil des Buches bietet eine Art Rahmenwerk, um die Gewohnheit des Fragestellens zu entwickeln und bessere Fragen zu stellen, einschließlich Tipps, wie man Fragen effektiv formuliert und wie man generell eine fragende Haltung und Lebenseinstellung einnimmt.

Der dritte Teil des Buches konzentriert sich auf bestimmte Arten und Kategorien von Fragen, die zur Lösung von Problemen, zur Förderung der Kreativität und zur Vertiefung von Beziehungen hilfreich sind. Der vierte Teil des Buches schließlich bietet praktische Ratschläge, wie man die Kunst des Fragens im Alltag umsetzen und pflegen kann.

Im gesamten Buch greift Berger auf Erkenntnisse aus einer Vielzahl von Quellen zurück, darunter Interviews mit führenden Denkern und Innovatoren, Fallstudien über erfolgreiche “Fragesteller” und wissenschaftliche Untersuchungen über die Wirkung und Vorteile des Fragens.

Hier ein paar schöne Fragen-Beispiele aus dem Buch:

Was wäre, wenn das Gegenteil wahr wäre? Diese Frage kann verwendet werden, um Annahmen zu hinterfragen und innovatives Denken zu fördern.
Was ist das einzige, das wir mit Sicherheit wissen? Diese Frage kann uns dabei helfen, zentrale Werte und Überzeugungen zu erkennen, was ein nützlicher Ausgangspunkt für die Entscheidungsfindung sein kann.
Was, wenn wir die Denkweise eines absoluten Anfängers einnehmen würden? Diese Frage ermutigt uns, Probleme und Herausforderungen mit Offenheit und Neugierde anzugehen, anstatt mit vorgefassten Meinungen oder (oft impliziten) Annahmen.
Was ist die Frage hinter der Frage? Diese Frage ermutigt uns, tiefer zu graben und die zugrunde liegenden “eigentlichen” Fragen und Probleme aufzudecken. Wir kennen das z.B. als 5 Why aus dem Lean.
Was, wenn wir der Empathie Vorrang geben würden? Diese Frage kann uns helfen, Perspektiven und Bedürfnisse anderer zu erkennen, zu verstehen und zu berücksichtigen (was nicht selten Vorteile hat ;).
Was sind unbeabsichtigte Folgen dieser Entscheidung? Diese Frage regt dazu an, die möglichen langfristigen Auswirkungen des Handelns zu bedenken.
Was ist das Schlimmste, was passieren könnte? Diese Frage kann uns dabei helfen, die Scheu vor Risiken zu überwinden bzw. sie realistisch einzuordnen.

Insgesamt ist das book of beautiful questions ein zum Reflektieren anregender, praktischer Leitfaden für die Wirkungskraft des Fragenstellens, den man nur rundherum empfehlen kann.

Warren Berger, The Book of Beautiful Questions: The Powerful Questions That Will Help You Decide, Create, Connect, and Lead, 2019

empfohlen von Sacha

Reihe "Lieblingsbücher": "This is Lean"

paul.marshall — Fri, 14 Apr 2023 09:00:03 +0000

"This is Lean" ist ein wunderbares kleines Buch über die Gedankenwelt des Lean, das von zwei schwedischen Wissenschaftlern geschrieben ist, die sich auf Lean spezialisiert haben.

Ich liebe dieses Buch, weil es wirklich unglaublich klar geschrieben ist und den Begriff Lean ohne Rückgriff auf 14 Prinzipien oder 5 Schritte oder ähnlich mühsame Bullet-Listen auf eine sehr einfache Formel bringt. Ich werde es mir so definitiv merken und die darin enthaltenen Gedanken langfristig vertreten können.

Dabei bleibt es im Buch nicht nur bei Gedanken. Zu jedem Punkt gibt es immer spannendes Storytelling, so dass sich die teilweise durchaus abstrakte Materie sehr spannend liest. Man merkt einfach, dass es sich für die Autoren um viel mehr als ein trockenes Thema der Organisationstheorie handelt. Stattdessen steht viel Leidenschaft für wirklich bessere Organisationen und letztendlich bessere Leben der Beteiligten dahinter.

Gleich zum Einstieg werden mit viel Empathie die Geschichten zweier Patientinnen erzählt. Beide begeben sich auf Grund eines Verdachts auf Brustkrebs in die Hände je einer Gesundheitsorganisation, um Gewissheit über ihren Zustand zu erlangen.

Die erste Frau durchleidet nach einer Reihe von Arztbesuchen, Untersuchungen und Laboranalysen, für die jeweils neue Termine nötig sind, ganze 42 Tage Ungewissheit, bis sie zu ihrer Diagnose kommt.

Die zweite Frau geht dagegen zu einer Spezialklinik, die sich genau auf diese Fälle eingerichtet hat und voll auf die Erfahrung der Patientinnen ausgerichtet ist. Hier erhält sie die komplette Serie an Untersuchungen und Analysen fast ohne Wartezeiten und hat ihre Diagnose bereits nach 2 Stunden.

An Hand der beiden Fälle entwickeln die Autoren die beiden zentralen Begriffe des Buches:

"Resource Efficiency" und "Flow Efficiency".

Resource Efficiency ist das, was man gemeinhin als Effizienz kennt. Es ist ein Maß für die Auslastung einer potenziell teuren Ressource (Ärzte, MRT-Scanner, Laborkapazitäten etc.). Der Arzt spricht z.B. im Akkord mit jeweils wechselnden Patientinnen, oder der MRT - Scanner läuft von 8:00-19:00 durch. Schließlich sind beide teuer. Ganz ohne Lücken bei der Auslastung läge die Resource Efficiency bei 100% .

Flow Efficiency, worauf offenbar die Spezialklinik optimiert ist, fokussiert dagegen auf den Fluss, mit dem in der Organisation echte Kundenbedürfnisse befriedigt werden. Die Kennzahl setzt diejenige Zeit, in der aktiv an einem Kundenbedürfnis gearbeitet wird, mit der gesamten Durchlaufzeit für die jeweilige Kundin ins Verhältnis. Ganz ohne Wartezeiten für alle Patientinnen wäre die Flow Efficiency der Organisation bei 100%.

Im Buch wird ein Verbesserungsansatz dann als "Lean" definiert, wenn es sich um eine langfristig angelegte, kontinuierliche Verbesserung handelt, die sowohl Flow Efficiency als auch Resource Efficiency steigert, dabei aber immer bei der Flow Efficiency anfängt und diese höher priorisiert.

Relativ bald zeigen die Autoren, dass die meisten Organisationen heutzutage freie Potenziale haben, beide Formen der Effizienz noch sehr weit zu steigern. Dennoch kommt es ab einem gewissen Punkt zu einer notwendigen Abwägung zwischen den beiden Effizienzen. Irgendwann wird man Puffer lassen und auf maximale Auslastung verzichten müssen, wenn man die Wartezeiten für Kunden immer weiter reduzieren will.

Hier kommt meiner Erfahrung nach der wichtigste Einwand gegen Lean-Ansätze ins Spiel, der bei Entscheidern schnell im Hinterkopf auftaucht und dort seine Wirkung entfaltet:

"Das mit Respekt und Kundenorientierung ist schön und gut. Wenn wir aber zu sehr auf Flow Efficiency achten, verlieren wir letztendlich Geld, sobald wir auf Resource Efficiency in Teilen verzichten müssen. Wir müssen unsere teuren Ressourcen einfach maximal auslasten, weil wir es uns sonst nicht leisten können."

Im Umgang mit diesem Einwand glänzt das Buch. Die Autoren zeigen anhand vieler Beispiele und Case Studies, wie die typische Fixierung auf Resource Efficiency in aller Regel nur scheinbar zu echter Kosteneffizienz führt, weil durch die steigenden Wartezeiten und unbefriedigten Bedürfnisse der Kunden zusätzliche Aufwände notwendig werden, die bei höherer Flow Efficiency (also kürzeren Wartezeiten) überhaupt nicht nötig wären. In vielen Fällen ist es also doch möglich, mit konsequentem Fokus auf Flow Efficiency und moderatem Verzicht auf Resource Efficiency paradoxerweise sogar mehr fürs gleiche Geld zu schaffen!

Für mich war diese Behandlung des sogenannten Efficiency Paradox das Highlight in dem Buch. Ich bin überzeugt, dass ich diesen Gedanken als Agiler Coach noch oft vertreten werde.

Daher empfehle ich das Buch allen Führungskräften und Coaches wärmstens, die sich mit einer Lean/Agile Transformation beschäftigen oder sich dafür interessieren.

empfohlen von Paul

Wenn Sie sich für Efficieny und Flow Optimierung interessieren, ist Kanban ein wirkungsvoller Ansatz für Ihre Organisation. Unsere speziellen Schulungen und Workshops und unsere Beratung helfen Ihnen bei der Implementierung.

Warum das unFIX Model nützlich ist

sacha.storz — Wed, 26 Apr 2023 13:16:24 +0000

Vor kurzem hatte ich die Chance, Jürgen Appelos unFIX-Modell in einem zweitägigen Workshop intensiver kennenzulernen. Appelo, der durch Management 3.0 bekannt wurde, hat mit unFIX eine Musterbibliothek (pattern library) entwickelt, die darauf abzielt, Organisationsdesign flexibler zu gestalten.

Frameworks sind Schnee von gestern...

Im Vergleich zu bekannten Frameworks wie SAFe, LeSS, Scrum@Scale, die ebenfalls alle auf Business Agility abzielen, aber auch Soziokratie und Holokratie, bietet unFIX eine Alternative. Anstatt starre Ansätze zu verfolgen, möchte Appelo einen Baukasten anbieten, mit dem jede Organisation ihre eigene, individuelle und spezifische Struktur und Methodik entwickeln kann. Er vergleicht es mit Lego-Bausteinen: Was man damit baut, ist offen.

Es ist kein Geheimnis, dass (agile) Frameworks häufig nur oberflächlich implementiert werden, Blaupausen-Charakter und meist wenig mit echter Businessagilität und sinnvollem Organisationsdesign zu tun haben.

UnFixen und neu kombinieren

Der Ansatz von unFIX besteht darin, Organisationen als Sammlungen und Interaktionen vieler Muster zu betrachten. Anstatt einer starren Blaupause zu folgen, sollten Organisationen aus verschiedenen Mustern genau die Struktur, Methode und Vorgehensweise entwickeln, die am besten zu ihnen und ihrer Situation passt.

Typische Muster aus unFIX

Ein grundlegendes Muster in unFIX sind die verschiedenen Arten von Teams, die als Crews bezeichnet werden. Appelo verwendet die Crew-Typen aus den Team Topologies — Value Stream Crew, Facilitation Crew, Platform Crew, Capability Crew, und fügt noch weitere hinzu, etwa Experience Crew und Governance Crew.

Beispiele aus unFIX für Entscheidungsfindungsmuster sind:

Einstimmigkeit
Konsens
Konsent
Score-Bildung
Multi-Voting
Mehrheit (einfache etc.)
Delegation
Autorität

In vielen Workshops frage ich "Wie werden bei euch Entscheidungen getroffen?" — und die traurige Wahrheit ist, oft ist die Antwort "Man weiß es nicht genau" oder "Mal so, mal so".

Zusammen mit den Delegation Levels, die Appelo schon in Management 3.0 entwickelt hat, bietet unFIX eine nützliche Bibliothek, um Entscheidungsprozesse in der Organisation zu designen.

Organisationsdesign für alle!

Mit unFIX können bereits viele praktische Organisationsdesigns umgesetzt werden. In den Übungen zeigte sich, dass jede Gruppe unterschiedliche Aspekte betonte und Herausforderungen auf verschiedene Weise löste.

Indem man die verschiedenen Umsetzungsoptionen diskutiert und die entsprechenden Herausforderungen klar definiert, entsteht ein gemeinsamer und bewusster Entscheidungsprozess. Das ermöglicht es, die Organisation gezielt von Grund auf zu designen.

Auch wenn eine bestehende Organisation nicht überstürzt umgebaut werden sollte, sind die Aha-Erlebnisse darüber, warum eigentlich bestimmte Dinge so und nicht anders sind, Gold wert. Es bedeutet, dass das Wissen aller Beteiligten in das Organisationsdesign einfließt, wo es ansonsten im Elfenbeinturm des sogenannten Leaderships stattfindet.

Was unFIX noch fehlt...

Appelo und sein Team sind sich bewusst, dass es noch viel zu tun gibt. Zum Beispiel könnten Interaktionsmuster zwischen strukturellen Einheiten wie Crews noch weiter ausgebaut werden. Aktuell arbeitet das Team unter anderem an den folgenden Punkten:

Ein Set von Prinzipien, die der Anwendung des Modells zugrunde liegen sollen.
Beispiel: Manage the work, lead the people.
Überlegungen zum Zielsetzungssystem OKR: Müssen OKR iterativ sein oder geht auch continuous flow?
Ansätze für Gewohnheitsbildung (Habit Building) in Teams, basierend auf Gamification

unFIX bietet derzeit Muster für Crews, Entscheidungsfindung, Investitionshorizonte, Life-Cycle-Phasen, Abhängigkeitsmanagement, größere Gruppenzusammenhänge (Turf, Base, Forum), Teamrollen und einiges mehr.

unFIX: eine vielversprechende Musterbibliothek

Es lohnt sich m.E., unFIX weiter zu verfolgen und auch schon in der aktuellen Form auszuprobieren. Die Übungen im Basis-Workshop dauern höchstens 30 Minuten, so dass man schnell einen ersten Eindruck gewinnen kann.

PS: Jurgen Appelo wird im Juli auf unserer Konferenz Agile World in München als Gastredner zugegen sein, allein deshalb lohnt sich der Konferenzbesuch schon. Tickets gibt es hier.

Boost a learning organization by using these 5 Flight Levels activities

mats.olof.winroth — Thu, 20 Apr 2023 14:44:24 +0000

During a recent Zoom meeting with a client, the discussion turned to Flight Levels and its potential benefits for the current situation. One of the customer's colleagues suddenly reached over his shoulder and brought a printed piece of paper from the wall behind him. It was a printout of the 5 Flight Levels activities, and he told us that he used it as a daily work guideline. I liked the idea and realized I do not have one myself, perhaps I should… I've personally found the 5 Flight Levels activities to be incredibly helpful.

In case you are not familiar with the Flight Levels model, it claims it can help you to find out where in your organization you need to do what to achieve the results you want to achieve. You do this with 5 activities on three levels”.

The three levels are the following:

Flight level 1: the operational level, where teams are working on products or services.
Flight level 2: provides end-to-end coordination between (and by) the teams. This level is necessary when multiple teams must contribute to provide customer value.
Flight level 3 represents the strategic view, sets priorities and provides a link between the strategic decisions, the coordination and the development.

The Flight Levels model offers pragmatic ideas on achieving transparency, alignment around the goals and how to bring value to flow between different parts of the organization.

The 5 activities

To achieve business agility, we need to execute the following activities on every flight level in the system:

Visualize the situation: Only when we see what is going on can we act. Therefore, we need to make our situation visible. What are we working on and why? What are the work steps? Are there delays? Is work in progress piling up somewhere?
Create focus: We need to shift from starting work to finishing work. We need to focus on the work items where we want to see improvement. It is not enough to limit the stories per iteration on which we are working if we are interested in shorter Lead Time for initiatives or projects. We also should perhaps bring the 50 parallel projects down to 20 and deliver.
Establish agile interactions: The right people have the right conversations at the right time. Change happens only when people talk to each other. We want to define interactions and meetings with clear purpose and clear outcome.
Measure progress: We need to see where we are and if our experiments achieve positive effects. We want to measure things we want or need to change. Only when we know how things are developing can we act.
Operate and Improve: Continuous improvement on all levels in your organization. (via use of the 5 activities).

How do you use the 5 activities in your daily life? on all flight levels in your organization or at least on the level you work on yourself? In my daily coach life I have used 5 activities to trigger my curiosity about how it could (or should) be. Do we see what we need, do we have enough focus, are the interactions and meetings we have meaningful, what do we need to change and how can we measure it and how can we continuously improve, in small steps in all areas. In principle this is what we should do every day as agilists, with or without the 5 activities, still they help me to get a structure and to keep the focus on improving. There are some examples from a late project below.

Visualize the situation

Does everyone have a common view on the goals and purposes for the items we work on? Here we introduced a strategy board where vision and strategy were broken down in shorter term steps of outcomes: what do we hope to achieve in the next three months and how can we measure it? We called these outcomes “initiatives” and defined activities required to reach the goals in the form of features, epics and stories. The link from strategy down to story gave a very clear picture for all of us about the goals for the next three months, and the activities needed to reach them.
Do we have a good flow? by visualization on all levels we could see we had too many strategic initiatives running in parallel. Also on coordination level we could see we had too many work items running in parallel. A lot of work STARTED but only a little FINISHED. This helped us to focus more on closing items and focus on limiting started work.

Create focus

Do we start more work than we finish? Via regular strategy meetings we were able to strictly prioritize and limit strategic areas and initiative for the next cycle. On level 2 we prioritized features and created strong end-to-end ownership for teams. Every end-to-end feature is owned by one team, even if multiple teams had to contribute. This improved the probability to finish.
On the team level we initiated a scrum master community of practice. First we reviewed how things were running in all the teams and then we shared good ideas and ran experiments for how to improve the focus of finishing in time.

Establish agile interactions

Are the meetings and interactions we have as useful as they could be? We defined purpose, outcome and decisions for the interactions and made sure to get review and input from the teams and leadership. This helped us a lot, every now and then we ran mini retros in our meetings to find areas for improvement. It helped us to get better meetings and to avoid making the same mistakes repeatedly.

Measure progress

Is there something we want to change? Can we measure it to find out if our experiments move the situation in the right direction? Based on workshops for vision and goals for the transformation we identified areas needing change or improvement and how to measure it. We defined the goals, clarified the goals with questions and then found metrics that could answer the questions. For instance we wanted to reduce the time to finish a new feature, so we started to measure lead time and work in progress for features. We wanted to improve satisfaction in teams, so we regularly requested feedback from the teams. We wanted to improve the way we work, so we regularly triggered assessments to learn which areas to focus on and measure our progress.

Operate and improve

Do we learn on all flight levels and do we build in learning loops. If you have “operate&improve” on your daily agenda, you may more often ask “Did this meeting meet your expectations, how can we do it better?”.
On initiative level we experimented to focus more measurable outcomes and hypotheses instead of only a number of features. This triggers another level of consideration on how to create true customer value.

What is then the final conclusion for pinning the 5 activities at your home office wall? Well, It can for sure help in your daily work and may save you from getting too self-satisfied, where you risk slowing down on improvements.
It is good to remember that the Flight Levels model can be seen rather as a thinking model than an agile framework. It provides a toolkit to handle and improve your current situation, regardless of the framework or no framework you happen to use. The project from which I took the examples was a SAFe transformation.

Therefore, you may better print the 5 activities and pin them to your wall. Then you can start turning up with new creative ideas for improvements in your organization and no-one will know you are “just doing Flight Levels”.

By the way, I’ve just pinned the 5 activities to my own wall. Let’s see how this will change my life : ).

Want to learn more about Flight Levels? Join our Flight Levels 2 Design Workshop!

Neu in SAFe 6.0; Spoiler-Alarm: Flow (SAFe®)

ugurakin — Tue, 02 May 2023 12:31:45 +0000

SAFe® 6.0 eine U-Bahn-Linie

In dem Artikel beschreibe ich, aus meiner Sicht, die wichtigste Neuerung in SAFe 6.0. Das Thema ist bereits in der Kanban Community ein heißes Thema und hat nun auch den Weg in SAFe 6.0 gefunden. SAFe ist ein umstrittenes Framework. Da ich als SPC (SAFe Practice Consultant, vorher SAFe Program Consultant) in mehreren Projekten unterwegs bin, habe ich mir ein fundiertes Wissen dazu aufgebaut und möchte das gerne teilen. Der Artikel beschreibt den SAFe Flow aus meiner Sicht. Für mich ist SAFe eine U-Bahn-Linie, die von einem Startpunkt zu einem Ziel fährt. Mit Zwischenstopp und Anbindungen zu anderen Modellen/Frameworks. Reicht diese U-Bahn-Linie für dich, um deine Ziele zu erreichen? Das darf sich jeder selbst fragen, entscheiden oder entdecken! 😄

Flow und SAFe 6.0

Bereits in früheren SAFe Versionen war Flow ein Thema. So war es bereits Teil von den Trainings und im Zusammenhang mit Kanban und Lean immer da. Das Thema konnte jedoch schnell überlesen und ignoriert werden.

Nun ist es im SAFe 6.0 Big Picture auf allen Ebene integriert. Das heißt, es spielt eine Rolle auf der Team-Ebene, ART/Programm Ebene, Solutions Ebene und auch Portfolio Ebene. Zusätzlich ist es in den neuen Rollenbeschreibungen enthalten. Doch was genau bedeute Flow im Zusammenhang mit SAFe 6.0? Es gibt auch andere Definitionen und Vorgehen, auf diese werde ich in diesem Artikel jedoch nicht eingehen. So viel sollte jedoch gesagt sein: Egal, mit welchem Vorgehen man startet, die Unterscheidungen sind nicht mehr groß.

@scaled agile, Inc

SAFe House of Lean - Flow

Das SAFe House of Lean ist Teil der Lean-Agile Leadership Kompetenz (einer der 7 Kompetenzen) und ist insbesondere ein wichtiger Bestandteil des Trainings "Leading Agile". Hier war das Thema vorher enthalten. Das House of Lean ist nicht mehr Bestandteil von SAFe 6.0. Wir gehen deshalb nur kurz drauf ein.

Ein wichtiges Zitat ist hier von Don Reinertsen aus dem Buch Flow (auf Don Reinertsen und sein Buch ist sehr viel in Zusammenhang mit Flow und SAFe zurückzuführen)

EN: "Operating a product development process near full utilization is an economic disaster."

DE: Der Betrieb eines Produktentwicklungsprozesses nahe der Vollauslastung ist eine wirtschaftliche Katastrophe

Wie man hier erkennen kann, stellt Flow eine wichtige Säule da, um Wert zu generieren. In Flow geht es also um die folgenden Punkte.

Optimierung, kontinuierlicher und nachhaltiger Durchsatz von Wert.
Qualität bereits in der Entwicklung berücksichtigen, dies beeinflusst den Flow positiv.
Vermeiden von Pausierung der Projekte und Entwicklungen, da die Wiederaufnahme den Flow negativ beeinflusst
Entscheidungen dort treffen, wo sie benötigt wird, dies beschleunigt den Flow

Das Zitat und die Aussagen sind selbstverständlich immer noch gültig Nur tauchen diese viel konkreter und präsenter auf.

SAFe 6.0 Prinzip Nr. #6

Nun ist Flow in einem der 10 Prinzipien explizit gemacht worden.

Aus "Visualize and limit WIP, reduce batch size, and manage queue lengths"

Wurde: Make value flow without interruptions

In dem Zusammenhang beschreibt sich SAFe selbst als Flow basiertes System. Ziel ist es, Unterbrechungen und Abhängigkeiten im System zu identifizieren und zu Lösungen und Verbesserungen zu adressieren.

Dabei sieht SAFe "kürzeste nachhaltige Durchlaufzeit" finden, als wichtigstes Thema des Frameworks. Um das zu erreichen, werden folgende Punkte hervorgehoben.

Genaue Angabe des Wertes nach Produkten
Identifizierung der Value Streams (Wertströme) jedes Produktes
Der Kunde pulled (zieht) den Wert des Produktes

Die SAFe Prinzipien sind den wenigsten bekannt. Jedoch verweist auch SAFe häufig darauf und viele Praktiken sind auf die 10 SAFe Prinzipien zurückzuführen.

Die 8 Beschleuniger für Flow

Um Flow zu erreichen, hat SAFe 6.0 8 konkrete Vorschläge. SAFe nennt:

Visualisierung der Arbeit und den WIP (Work in Progress) limitieren. In dem Zusammenhang erstellen wir ein Kanban oder Scrum Board, das den Prozess widerspiegelt.
Bottlenecks (Engpässe) identifizieren und angehen. Egal, ob ein Team, eine Person oder auch ein ganzer ART dafür zuständig ist, dass eine Aufgabe lang dauert, über Bottlenecks müssen wir uns Gedanken machen im System. Das kann unter anderem ein externer Lieferant sein, der uns zuliefert oder ein Entwickler:in.
Übergaben und Abhängigkeiten reduzieren. Im Zusammenhang mit Wertströmen können wir identifizieren, welche Übergaben und Abhängigkeiten wir haben und somit diese angehen.
Schnelles Feedback ermöglichen und fordern/fördern. Der Gedanken von PDCA (Plan Do Check Act) ist damit gemeint. Besonders der letzte Act, bei dem wir das erlernte aufgreifen und beim nächsten Vorgehen einsetzten. Das ist nicht nur dafür, um die Effizienz zu verbessern, sondern auch die Effektivität und damit den Nutzen für den Kunden.
Arbeiten in kleine Batches (Einheiten) teilen. Viel Arbeit, benötigt viel Zeit. Diese Arbeit in kleine Einheiten zu teilen, reduziert nicht nur die Dauer der Arbeit, sondern auch die damit verbundene Komplexität und das Risiko.
Warteschlangen reduzieren - Stop starting, Start finishing. Das bedeutet, wir machen uns Gedanken darüber, wie viel Arbeit ansteht und versuchen uns mehr darauf zu fokussieren, was wir wirklich wichtig finden.
Optimierung der "Time in the Zone" - Zeit, in der aktiv an einem Produkt gearbeitet wird, Reduzierung der verschwendeten Zeit.
Überarbeiten der Richtlinien und Praktiken - Kulturelles Vorgehen hinterfragen, weg vom Gedanken "Das haben wir schon immer so gemacht."

Um zu verstehen, wie damit umgegangen wird, sollten die Metriken einbezogen werden.

Die 6 Flow Metriken nach SAFe 6.0

Metrik	Beschreibung
Flow Distribution	Anteil der Workitems nach Typ in einem System. Das heißt auch, zu differenzieren, welche Typen wir haben und wie wir damit umgehen. Das hilft uns auch zu erkennen, welche Themen wie viel von unserer Zeit einnehmen.
Flow Velocity	Anzahl der abgeschlossenen Workitems über einen bestimmten Zeitraum.
Flow Time	Zeit, die vom Beginn bis zum Abschluss eines bestimmten Workitems vergeht. Dies hilft zu erkennen, wie lange wir für etwas benötigen und somit können wir auch besser abschätzten, wie lange es braucht, bis der Kunde etwas Neues bekommt.
Flow Load	Anzahl der derzeit in Bearbeitung befindlichen Workitems (aktiv oder wartend). Um einen idealen zustand zu finden, müssen wir vorher wissen wie viel WIP (Work in Progress) wir haben und diesen dann zu optimieren, beispielsweise limitieren.
Flow Efficiency	Hier geht es darum zu identifizieren, wie viel Zeit wir aktiv und wie viel passiv für etwas benötigen. Das Verhältnis dazu (Active Time/Flow Time) ist unser Effizienzgrad.
Flow Predictability	Wie konsequent sind Teams, ARTs und Portfolios in der Lage, ihre Commitments (Selbstverfplichtung) zu erfüllen.

Flow ist somit erreicht, wenn es einen reibungslosen Übergang der Arbeit durch den gesamten Wertstrom gibt, mit einem Minimum an Übergaben, Verzögerungen und Nacharbeit.

Rolle des SPC im Zusammenhang

Wer ist nun verantwortlich für den Flow? Konkret nennt SAFe 6.0 hier die Rollen der Coaches, also SM/RTE/STE und die SPCs.

Beim SPC wird die Tätigkeit Coaching Flow genannt. Er hat die Verantwortung, überall zu unterstützten.

Beim Scrum Master / Team Coach Improving (Verbessern) Flow; Beim Release/Solution Train Engineer Optimizing (Optimieren) Flow. Für mich gehen die zwei Begriffe darauf zurück, dass das Verbessern der Start ist, um es später zu optimieren, da die erste Arbeit auf Teamebene stattfindet. Das zeigt auch, dass der Fokus viel mehr auf Flow über alle Ebenen liegt. Es gibt jetzt nicht mehr nur den Scrum Master, sondern alternativ auf einen Team Coach der sich um Kanban Teams kümmert.

Weitere Neuerungen

Neben Flow wurden auch weitere Punkte erneuert. Dazu zählen:

Auf Business Agility wurde intensiver eingengangen
Das Thema OKR (Objectives and Key Ressults) hat nun einen Platz im Big Picture und ist viel detaillierter eingearbeitet
Rollen & Verantwortlichkeiten wurden klarer definiert
Zukunftsthemen wir AI, Big Data und Cloud wurden integriert
Änderung der Bezeichnung (Program → ART; Solution ... → Solution Train ... )

Weitere Themen kommen noch. Falls euch ein Thema konkret interessiert, könnt ihr gerne einen kostenlosen Austausch bei mir anfragen (hier der Link). Wir bieten auch öffentliche und inhouse Trainings zu SAFe 6.0 an.

#perDu, offen für Netzwerk LinkedIn

Quellen & Ressourcen

https://scaledagileframework.com/#
https://scaledagileframework.com/videos-and-presentations/
https://scaledagileframework.com/make-value-flow-without-interruptions/
https://scaledagileframework.com/whats-new-in-safe-6-0/
https://scaledagileframework.com/measure-and-grow/
https://www.goodreads.com/book/show/6278270-the-principles-of-product-development-flow

improuv @ Scaling Agile Summit 2023

christian-braun — Fri, 12 May 2023 08:53:03 +0000

Ganz unter dem Zeichen "Wie können wir Agilität skalieren, auch abseits von Frameworks? Was braucht Agile Leadership, um zu funktionieren?" findet dieses Jahr der Scaling Agile Summit 2023 statt.

Und wir sind ganz vorne dabei und mischen mit:

Am 14. Juni um 13:15 Uhr geht es für Sacha Storz und die Konferenzteilnehmer um "Skalierung mit vernetzten Kanban-Systemen und Flight Levels".

Hier geht es zur Konferenz

Jens Coldewey und Diana Larssen auf der XP 2023

christian-braun — Tue, 13 Jun 2023 09:40:09 +0000

Jens Coldewey gibt am Freitag, 16. Juni, um 13:30 Uhr zusammen mit Diana Larssen einen Workshop zu "Everything You Always Wanted to Know About Agile Planning".

Among the reasons for unhealthy and unsustainable working environments, overcommitment and bad planning practices certainly play a major role. This dysfunctionality sometimes comes despite the best intentions of leaders and other key players simply because of misconceptions about the role and objectives behind planning practices. Consequently, planning is still a big topic in Agile transitions. Even popular recipes seem to fail and “home-grown” approaches often lead into a waterfallish bureaucracy nightmare. In this immersive workshop you will explore the different objectives of planning in a complex environment and which tools and practices help to reach these objectives. Be prepared for some insights even if you're an experienced agilist and for hands-on advice applicable from team level to complex scaled environments. This workshop is a result of the “Supporting Agile Adoptions” initiative of the Agile Alliance

Mini-Workshop "Kanban und Flight Levels" (kostenlos)

christian-braun — Tue, 13 Jun 2023 09:49:18 +0000

In unserem Workshop zeigen wir Dir, wie Du das Flight Levels-Modell mit Kanban optimal nutzen kannst, um Deine Projekte effektiv und erfolgreich abzuschließen. Wir haben tolle Inhalte und Praxisbeispiele für Dich vorbereitet, damit Du das Beste aus der Kombination beider Methoden herausholen kannst.

Sacha Storz und Alisa Ströbele helfen Dir dabei, Kanban-Boards richtig einzusetzen, Prioritäten zu setzen und kontinuierliche Verbesserungen vorzunehmen.

Also, worauf wartest Du noch? Melde Dich jetzt für unseren Workshop an und lerne, wie Du sowohl eure Teams zu mehr Effektivität, als auch die Gesamtorganisation zu Business Agility befähigen kannst.

Hier geht´s zur Anmeldung

Sacha Storz mit einem Talk auf der Agile Austria

christian-braun — Tue, 01 Aug 2023 15:37:02 +0000

Das Thema: "Skalierung mit vernetzten Kanban-Systemen & Flight Levels"

Am 12. Oktober um 16:45 Uhr.

Hier bekommst du mehr Infos.

Abstract:

Ein Dienstleister im Bereich Online-eCommerce-Projekte steht — nicht zuletzt durch das eigene Wachstum — vor einer Herausforderung: Die Projekte werden größer und komplexer und deshalb ist immer mehr die Zusammenarbeit zwischen Teams und Services nötig. Spezialisierung und Differenzierung von Funktionen, etwa Modulentwicklung, Cloud-Infrastruktur, Performance-Marketing, Data Management usw. sorgen zusätzlich dafür, dass das customer-facing Team immer mehr ein Node in einem Wertschöpfungsnetzwerk ist statt eines autonomen Liefer-Teams.

Wie aber soll dieses Netz von Teams und Services zusammenarbeiten? Wie gewährleistet man Flow, Predictability und Alignement über alles hinweg, damit alle an einem Strang ziehen? Damit reibungslos immer das Richtige (effektiv) auf die richtige Weise (effizient) an den Kunden geliefert wird?

Weil die einzelnen Teams zumeist ohnehin mit Kanban arbeiteten, war der Weg klar: Ein Netzwerk von Kanban-Systemen — ein skaliertes Gesamtkonstrukt aus einzelnen Teams/Services, bei dem jeder Service explizit für seine Kunden arbeitet, manche für den externen Kunden, manche als interne Dienstleister.

Dieses skalierte Konstrukt hinzukriegen, war dann doch mehr Arbeit als gedacht, und die Reise dauert schon seit über einem Jahr an — und bleibt spannend. Um aus einzelnen Proto-Kanbans ein zuverlässiges Zusammenspiel zu entwickeln, wendeten wir u.a. folgende Konzepte an:

Standardisierung von Flow-Metriken
Einfache Impact-Metriken über alle Teams/Services hinweg
Team-API: Service-Canvas und Workflow-Canvas
einen (JIRA)Workflow mit viel Freiheit, aber einigen standardisierten Status als Übergabepunkte
Flight Level 1 und 2 Perspektive und Boards für die teamübergreifende Wertlieferung an den Kunden
einen kontinuierlichen Verbesserungsprozess mit Metrics, Agile-Team-Coach-Begleitung und… Zeit(!)

In einem Impulsvortrag möchte ich den zurückgelegten Weg, die genannten Ansätze, die Erfolge und die Challenges darstellen.

Lernziele:

Wie man Kanban Services vernetzt (Kanban-Skalierung)
Wie man mit Service Canvas und Workflow Canvas eine Team-API definiert
Wie man Impact-Metrics einsetzt
Wie man auf Flight Level 2 die übergreifende Arbeit managed

Sacha Storz beim Agile Scale Camp

christian-braun — Tue, 01 Aug 2023 15:51:16 +0000

Agile at Scale, Business Agility, Enterprise Agility - Ein Barcamp für alle, die schon dort sind oder dorthin wollen!

Sacha Storz ist Mitveranstalter des Agile Scale Camp und wir liefern in Kürze noch mehr Infos.

Zur Website

Sacha Storz als Impulsgeber bei der Modern RE

christian-braun — Tue, 01 Aug 2023 16:08:42 +0000

Tag: 11.10.2023

Wann?: 15:50 – 16:30 Uhr

Hier geht´s zur Konferenzpage

Flight Levels sind ein Ansatz, der den Scope eines Projekts auf drei Ebenen betrachtet: Die strategische Ebene (FL3), i. e. das Portfolio, die kollaborative Ebene (FL2), welche die Ende-zu-Ende-Arbeit mehrerer Teams oder Services umfasst, und die operative Ebene (FL1), die sich auf die Arbeit einzelner Teams oder Services fokussiert. Das Konzept der Flight Items und Flight Routes ist dabei eine nützliche Metapher, um zu verstehen, wie die Arbeit über diese Ebenen hinweg fließt und verbunden ist.

Nach der Einführung von Flight Levels für teamübergreifende Projekte suchte ein Dienstleister für eCommerce- und CMS-Projekte nach einem Weg, um Anforderungen, Deliverables und Aufgaben über diese drei Ebenen hinweg zu entwickeln und zu managen. Dazu schien User Story Mapping von Jeff Patton eine passende Methode. Eine kollaborative Praxis, die von Teams verwendet werden kann, um das Product Backlog eines Produkts oder Projekts zu definieren.

Ziel einer Story Map ist, dass sich das Team auf das Benutzererlebnis und den Kundennutzen konzentriert (FL2, End2End). Welche Aspekte des Nutzererlebnisses dabei zu welchem Zeitpunkt betrachtet werden, ist aus der strategischen Perspektive heraus motiviert (FL3). Schließlich werden die FL2-Items, etwa Epics oder Features, in einem gemeinsamen Prozess aller beteiligten Teams und Services zu FL1-Elementen heruntergebrochen, um die gemeinsame Lieferung zu planen und zu koordinieren.

Dieser letztlich einfache Ansatz ermöglicht es, die Gesamtzusammenhänge der anstehenden und laufenden Arbeit, Abhängigkeiten, den Connect zur Strategie und Grad der Scope Completion transparent zu machen und effektiv zu managen.

improuv zu Gast beim Digital Future Congress

christian-braun — Wed, 02 Aug 2023 09:31:52 +0000

Nadine Bleck und Sacha Storz besuchen Ende September den Digital Future Congress in München.

Sagen Sie den beiden gerne "Hallo!".

Hier gibt es mehr Infos.

Jens Coldewey als Impulsgeber auf der Solutions Hamburg

christian-braun — Wed, 02 Aug 2023 09:42:54 +0000

Jens Coldewey ist am 6. und 7. September mit gleich zwei Themenslots als Impulsgeber vor Ort:

Wir freuen uns schon diesen spannenden Kongress mitzugestalten.

Hier gibt es mehr Infos.

Jens Coldewey als Speaker auf der Manage Agile 2023

christian-braun — Wed, 02 Aug 2023 13:29:44 +0000

Jens Coldewey gibt den Workshop "Agile Metriken und Kobras – oder warum an mittelalterlichen Marktplätzen so schmale Häuser standen".

Wann? Am 15. November um 14:00 Uhr

Wo? Vor Ort in Berlin

Hier geht´s direkt zur Konferenz.

improuv ist Teil des Scrum Gatherings in Amsterdam

christian-braun — Thu, 03 Aug 2023 09:28:27 +0000

Am 10. Oktober sind wir mit zwei Talks beim Scrum Gathering in Amsterdam vertreten:

Hedi Buchner gibt Impulsvortrag "After Work ZukunftsChancen" bei der IHK

christian-braun — Mon, 18 Sep 2023 14:57:16 +0000

Am 26. September um 17:30 - 19:30 Uhr am IHK Campus (A&B), Orleansstraße 10-12, in München.

Hedi Buchner und sowie Katja Hennecke, Gründungs-Partnerin der OrgWerk Organisationsberatung, zeigen, wie sich eine agile Herangehensweise positiv auf Teamarbeit, Unternehmenskultur und das Verständnis von Leadership auswirkt. So werden Innovationskraft, Motivation und Bindung der Mitarbeiterinnen und Mitarbeiter im Unternehmen gestärkt.

Anhand von Praxisbeispielen und im interaktiven Format arbeiten wir heraus, welche Ansätze und Strukturen dabei unterstützen. Im Anschluss besteht Zeit zu Austausch und Networking.

Die Veranstaltung wird organisiert von der IHK für München und Oberbayern im Rahmen der Bildungsinitiative ZukunftsChancen von Google Zukunftswerkstatt, Bildungsallianz des Mittelstands, BVMW München sowie IHK für München und Oberbayern.

Zur Anmeldung

Wann wird es fertig? - Forecasting in der agilen Softwareentwicklung

paul.marshall — Thu, 05 Oct 2023 08:33:37 +0000

Zuverlässige Voraussagen (Forecasts), wann größere Software-Features fertig werden: Wer hätte das nicht gerne?

Manche Teams oder Organisationen machen seit Jahren extrem verlässliche Voraussagen zu ihrer jeweils nächsten Softwarelieferung.

Andere versuchen es und scheinen mit ihren Voraussagen gegen eine Wand zu laufen. Irgendwann verlieren sie die Lust, es überhaupt noch ernsthaft zu versuchen.

Den betroffenen Teams und ihren Managern ist meist nicht klar, woran es liegt:

Ist es der aktuell gewählte Ansatz?
(“Schätzen wir unsere Story Points vielleicht falsch?")
Liegt es an mangelnder Einsicht in die Relevanz von Forecasting?
(“Entwickler wollen einfach coden und haben auf Schätz-Meetings keine Lust”)
Trauen die Teams sich vielleicht nicht, realistische Vorhersagen zu machen, weil dies Konflikte und Reibungen auslöst?
Oder liegt es an grundsätzlichen Eigenschaften der Aufgabenstellung, gegen die zumindest kurzfristig gar kein Kraut gewachsen ist?

Was steckt hinter diesen unterschiedlichen Szenarien?

Warum ist Forecasting wichtig?

In den meisten Bereichen muss es Terminabsprachen geben. Marketingkampagnen müssen abgestimmt werden, Lizenzgebühren werden fällig, Produktionsstraßen rollen an. In all solchen Fällen gibt es natürliche Termine, die Synchronisationspunkte mit dem Rest der Welt darstellen.

Und auf der etwas dunkleren Seite gibt es immer noch den künstlichen Termin. Ein Manager hat mir sein “Erfolgsrezept” mal in der Kaffeeküche erklärt:
“Ich setze immer einen unmöglich frühen Termin, damit sich das Team nur auf das Wesentliche konzentriert.”

Woher die Termine auch kommen, von der hellen oder der dunklen Seite, eines ist klar: Verfügt ein Team nicht über das nötige Instrumentarium zum Forecasting, zum flexiblen Scoping und praktiziert damit nicht laufend faktenbasierte und effektive Termin- und Scope- Kommunikation, kommt es im Nahfeld irgend eines Termins unweigerlich zum Unheil.

Der häufigste Fall ist, dass irgendwann so viel Druck entsteht, dass das Team nach außen hin mit quietschenden Reifen liefert. Tschaka! Die Probleme dringen aber ins verborgene Innere der Software ein. Code wird nicht mehr richtig nach-strukturiert. Tests und Validierungen werden weggelassen. Manuelle Schritte werden nicht automatisiert. Man spricht von technischen Schulden. Wenn aber Druck in dieser Form endemisch ist, werden diese Schulden wahrscheinlich nie zurückgezahlt.

Aus einem Mangel an Transparenz und entsprechender Kommunikation im Umfeld von Terminen entsteht also Druck und daraus relativ direkt schlechte Qualität.

Später wird in diesem Artikel klar werden, dass die Kausalkette auch in der Rückrichtung funktioniert. Aus verminderter Qualität folgt nämlich auch die verminderte Fähigkeit, Voraussagen zu machen.

Eine Negativspirale kann also in Gang kommen, aus der es sehr schwer ist, auszubrechen.

Betrachten wir dagegen den positiven Fall, in dem Forecasting gut funktioniert. Hier passiert rund um den Termin das, was sich der Manager mit dem „künstlichen Termin“ eigentlich gewünscht hatte: Eine Fokussierung. Aus der transparenten Kommunikation darüber, was fertig wird und was nicht, werden sinnvolle Entscheidungen abgeleitet.

Diese Art der transparenten Kommunikation schafft auch Vertrauen zwischen der Stakeholder- und Teamseite,woraus wiederum viele positive Entwicklungen folgen.

Welche Voraussetzungen gibt es?

Kein Forschungscharakter der Arbeit

Es gibt angrenzend zur Softwareentwicklung Bereiche, in denen Forecasting fundamental nicht möglich ist - beispielsweise manche Aufgaben in der Data Science oder der künstlichen Intelligenz.

Diese Art von Arbeit lässt sich am ehesten mit einer Suche nach dem Haustürschlüssel in einer sehr großen Wohnung vergleichen (Forschung). Die Dauer der Suche hängt davon ab, an wie vielen Stellen man suchen muss und man weiß nie, ob man den Schlüssel überhaupt noch findet. In einer solchen Umgebung streuen die Zeiten, in denen Wert generiert wird, so stark, dass Forecasting mit Bordmitteln nicht funktioniert.

Interessanterweise sieht man es Aufgaben in der Softwareentwicklung von außen nicht unbedingt an, ob sie eher mit Forschung oder mit geordnetem Handwerk vergleichbar sind.

Finden Aufgaben nämlich in einem Codebereich statt, der hinreichend kaputt und schlecht strukturiert ist, kann die Arbeit schnell mal Forschungscharakter annehmen.

Beispiel: Eine Entwickler:in will etwas scheinbar einfaches verändern. Das klappt beim einen Mal direkt und so einfach wie erwartet. Bei der nächsten ähnlichen Aufgabe stößt die Entwickler:in aber zufällig (!) auf gravierende Hindernisse. Um diese zu umgehen, muss sie etwas umbauen, was wiederum zufällig (!) unerwartete Konsequenzen nach sich zieht usw. Man spricht von “Accidental Complexity”. Fachlich einfache Dinge können unerwartet(!) sehr aufwändig werden. Die Zeitdauer streut in erheblichem Maß, genau wie bei typischer Forschungsarbeit.

Ähnlich verhält es sich mit einer Fehlersuche. Manche Fehler sind trivial und werden schnell behoben. Andere brauchen Tage und Wochen.

In so genannten Legacy - Systemen kommen beide Dinge zusammen: Ein hohes Maß an “Accidental Complexity” und häufig entstehende Fehler. Forecasting ist hier kaum noch möglich.

Die Rolle von Craftsmanship in der Software

Ganz anders im handwerklich hochwertigen Bereich der Softwareentwicklung (Craftsmanship). Hier gestaltet das Team (oder mehrere Teams) ein Produkt, dessen lineares (!) Anwachsen über die Zeit zu beobachten ist und dessen letztendliche Größe und Gestalt zunehmend abschätzbar wird.

Fehler werden nicht nachträglich gesucht, sondern durch gründliche Tests vor(!) der Entwicklung vermieden (Test Driven Development oder TDD).
Accidental Complexity wird kontinuierlich abgebaut, indem die Software laufend restrukturiert (aufgeräumt) wird. Refactoring ist Teil von TDD.
Regressionsfehler werden durch einen hohen Grad der Testautomatisierung vermieden.
Integrationsrisiken werden durch kontinuierliches, automatisiertes Integrieren laufend adressiert.
Akzeptanzprobleme werden durch kontinuierliche Lieferung von nutzbaren Features und entsprechendes frühes Feedback vermieden.

Das Team behält so nachhaltig die Kontrolle und verhindert das Abgleiten in den Legacy-Bereich.

Software Craftsmanship ist also mehr als die halbe Miete, wenn es um die Fähigkeit eines Teams geht, gutes Forecasting zu machen.

Weitere Voraussetzungen zum Forecasting

Forecasting hat aber noch ein paar zusätzliche Voraussetzungen, die ich hier kurz erwähnen will.

Einfach gesagt müssen sich zukünftige Inkremente mit den bereits fertiggestellten vergleichen lassen.

Einige Fragen, mit denen man das eigene Umfeld überprüfen kann:

Welche Qualitätsaspekte wurden bisher bei Inkrementen überprüft, welche sollen erst später zum Release überprüft werden? Steht z.B. zum Schluss noch ein Penetrationstest durch eine Sicherheitsfirma an, müsste man das Forecasting evtl. noch unter Vorbehalt stellen.
Wie aussagekräftig ist das bisherige Nutzerfeedback?
Spielen sich kommende Inkremente evtl. an neuen technischen Schnittstellen, neuen Subsystemen oder in neuen Programmiersprachen ab?
Wie vergleichbar sind organisatorische Abhängigkeiten und Schnittstellen?
Wie vergleichbar sind zukünftig zu verarbeitende Daten mit den bisherigen?
Wie vergleichbar ist die Teamzusammensetzung bisher und in Zukunft?

Oft hat man bezüglich all dieser Fragen für eine gewisse Zeit z.B. für ein paar Wochen oder Monate stabile Verhältnisse. Ich nenne das eine semi-stabile Umgebung. Man kann im Team laufend neu schätzen und lernen. Was dann funktioniert, ist das sogenannte "Rolling Wave Forecasting”. Selten oder nie hält diese Stabilität über einen längeren Zeitraum hinweg. Jahrespläne sollte man in der Regel nicht zu ernst nehmen oder schlicht darauf verzichten.

Sehr gute Teams (und insbesondere Product Owner) setzen sich mit diesen Unwägbarkeiten intensiv auseinander und gestalten ihr Backlog laufend so, dass in jedem der unwägbaren Bereiche früh Erfahrung entsteht.

Wie sich aus der oben aufgeführten Liste zeigt, ist Forecasting eine interdisziplinäre Sache. Es kann nur funktionieren, wenn alle Seiten mitmachen.

Welche Metriken eignen sich?

Die bisherigen Gedanken machen klar, dass es neben den rein zeitlichen Fortschritts-Metriken für gutes Forecasting wichtig ist, laufend die „Linearität“ des Fortschritts und die Vergleichbarkeit des aktuellen mit dem zukünftigen Zustand zu prüfen. Typische Metriken zu diesem Zweck sind z.B. Defect-Count, Mean Time to Repair, Test-Coverage aber auch weichere Faktoren wie der Team Happiness Index oder UX - Metriken wie der Net Promoter Index uvm.

Forecasting in einem Team

Für die rein zeitliche Betrachtung gibt es natürlich die berühmte Velocity, also die Rate, mit der ein Team bisher Features einer Kategorie pro Zeit fertig bekommen hat. Diese ist so bekannt, dass ich darüber gar nicht viel schreiben muss. Sie funktioniert wunderbar, wenn man ein einzelnes interdisziplinäres Team hat, das selbständig Wert schafft und alles oben Erwähnte zur Linearität und Semi-Stabilität gegeben ist.

Forecasting im skalierten agilen Umfeld

Was muss beachtet werden, wenn mehrere Teams an einer größeren Software arbeiten und voneinander abhängen?

Weiterhin ist inkrementelles Vorgehen mit gutem Craftsmanship im Gesamtsystem die zentrale Voraussetzung für gutes Forecasting (mit allen oben beschriebenen Methoden zu erreichen, also mit XP - Praktiken im Kleinen und DevOps Verfahren im Großen). Weiterhin funktioniert Forecasting nur mit der oben erwähnten Semi-Stabilität und auch nur für einen gewissen Zeithorizont.

Ein wichtiger Faktor kommt im skalierten Bereich hinzu: Bei der Übergabe zwischen Teams kommt es zu Wartezeiten. Und diese Wartezeiten dominieren in aller Regel die eigentliche Bearbeitungszeit (ein typisches Verhältnis von Wartezeit zur Gesamtlaufzeit ist z.B. 80%!). Zudem streuen Wartezeiten auch erheblich. Zur Vorhersage von Features werden in diesen Fällen typischerweise Flow-Metriken aus der Kanban-Welt herangezogen, etwa die mittlere Laufzeit von Features durch alle Teams (Lead-Time), idealerweise sogar die statistische Verteilung von Laufzeiten (Lead-Time-Distribution). Warum? In den Flow-Metriken ist die Wartezeit enthalten. Velocity bezieht nur die geschätzte Arbeit von Paketen mit ein.

Aber hier zeigt sich gleich die Schwierigkeit von skaliertem Forecasting: Daten zu Flow-Metriken kommen überhaupt erst in relevanter Zahl zustande, wenn die Wartezeiten nicht exorbitant sind. Dazu wiederum müssen die Teams entsprechenden Fokus haben, an wenigen Features gleichzeitig arbeiten (WIP-Limits). Je nach Spezialisierung leiden darunter der Durchsatz und die Auslastung.

Neben der technischen Reife gehört hier vor allem einiges an organisatorischer Reife dazu. Ein Thema für Bücher und weitere Blogs.

Will eine Organisation mit skaliertem Forecasting erfolgreich werden, empfiehlt es sich substanziell in Visualisierung von Wertschöpfung (nicht nur der Arbeit), Fokus, breit angelegte Kommunikation auf der Koordinations-Ebene zwischen den Teams, Metriken und kontinuierliche Verbesserung zu investieren. Wer hier nach mehr Halt sucht, ohne gleich SAFe zu installieren, kann sich den Flight Levels von Klaus Leopold zuwenden.

Fazit

Forecasting ist überall dort überaus wichtig, wo es Termine gibt.

In Kombination mit flexiblem Scope und proaktiver Kommunikation kann es die Gesundheit des Gesamtsystems erhalten.

Werden XP-Praktiken konsequent eingesetzt, gleitet das System niemals zum Legacy-Code ab, sondern bleibt dauerhaft linear.

Diese Linearität ist für gutes Forecasting entscheidend.

Darüber hinaus bedarf es der Bereitschaft und Einsicht, sich als Team interdisziplinär für das Erheben, Pflegen und Modellieren von Forecasting-Daten zu engagieren, da es noch viele andere Unwägbarkeiten, als nur die technischen gibt.

Rolling Wave Forecasting auf einen Zeithorizont über einige Monate funktioniert dann in aller Regel. Jahrespläne sollte man weiterhin mit sehr viel Skepsis betrachten.

Ich hoffe, mein Überblick über die Welt des Forecasting war wertvoll und für die eine oder den anderen hilfreich.

Ich freue mich über Kommentare und Diskussionen.

Agile und Organisationsentwicklung — Freunde fürs Leben

sacha.storz — Thu, 19 Oct 2023 09:16:01 +0000

Auf einem Open Space kürzlich sagte ein Agile Coach, er beschäftige sich jetzt vermehrt mit Organisationsentwicklung. Ich kenne ihn und weiß, wie lang er schon mit Agile unterwegs ist, wie erfahren und hochqualifiziert, deshalb brachte mich das zum Nachdenken. Ich persönlich war immer der Ansicht: Agile ist Organisationsentwicklung. Ersteres geht nicht ohne Letzteres.

Fangen wir einfach an und klären ganz kurz, was ich unter Agile und OD, Organizational Development bzw. Design, verstehe. Könnte man ja auch anders sehen (dann gerne melden: LinkedIn / Website :).

Was ist agil?

Agile ist ein Ansatz, schnell Wert auszuliefern und sich schnell an neue Gegebenheite anzupassen. Dabei stehen bestimmte Werte und Grundsätze im Vordergrund. Wenn wir auf das Agile Manifest schauen, sind das: Menschen über Prozesse, Funktionierendes über Dokumentation, Kundenzusammenarbeit über Verträge und Reagieren auf Veränderungen über das Befolgen von Pläne.

Gestartet als leichtgewichtige Softwareentwicklungsmethode, ist Agile heute eine allgemeine Vorgehensweise für komplexe und unsichere Problemstellungen, die Kollaboration, Kundenzentrierung, Wertschöpfung und Anpassungsfähigkeit ins Zentrum stellt. Und zwar nicht mehr nur auf Team-Ebene, sondern für die gesamte Organisation: Business Agility / Organizational Agility. Und da bin ich auch schon bei Organisationsentwicklung und Organisationsdesign.

Was sind Organisationsentwicklung und Organisationsdesign?

Organisationsentwicklung (OE) ist ein fortwährender Prozess zur Identifikation und Entwicklung der notwendigen Fähigkeiten in einer Organisation, um die Strategie umzusetzen und die jeweils gesetzten Ziele zu erreichen. OE konzentriert sich dabei darauf, die Gesamteffektivität und Leistungsfähigkeit der Organisation zu verbessern. Aha! Klingt nach globaler (statt lokaler) Optimierung, und wenn man akzeptiert, dass Reaktionsfähigkeit, Kundenzentrierung und Wertlieferung wichtig sind, ist das m.E.: Business Agility.

Organisationsdesign (OD) bezieht sich auf die Gestaltung und Anordnung der verschiedenen Komponenten einer Organisation, also Strukturen, Prozessen, Rollen und Verantwortlichkeiten. Ich schmeiße Organisationsentwicklung und Organisationsdesign meistens in einen Topf, was man bestimmt nicht sollte, aber für die Zwecke dieses Artikels halte ich es für legitim — und benutze ab jetzt die Bezeichnung OD (organizational design und organizational development). Mit Widerspruch bitte gerne wieder melden. Es geht bei OD darum, bewusste, informierte Entscheidungen zu treffen, wie die Organisation funktionieren und sich entwickeln soll. Ziel sind Effizienz, Effektivität, Nachhaltigkeit usw., also gängige moderne Definitionen von Erfolg (hier ein Shoutout für improuv-planet.com, unsere Nachhaltigkeitsberatung: Nicht-nachhaltiger Erfolg ist kein Erfolg).

Was haben Agile und OD gemeinsam?

Agile und OD zielen beide darauf ab, die Wirksamkeit einer Organisation zu verbessern und sie in die Lage zu versetzen, sich an Veränderungen in ihrem Umfeld anzupassen. OD ohne Fokus auf Anpassungsfähigkeit ist (denke ich) nicht zeitgemäß, und Agilität hat genau dies zum Ziel. OD hat sinnvollerweise das Konzept kontinuierlicher Verbesserung im Fokus, ebenfalls eine starke Überschneidung mit Agile. Sinnvolles OD wird, denke ich außerdem, die Menschen ins Zentrum stellen, eine Übereinstimmung mit dem agilen Ansatz “people over process”. Und da Organisationsentwicklung und Agile beide “Change” bedeuten, legen sie beide großen Wert auf Kommunikation und Kollaboration.

Warum ist mir das eigentlich wichtig? Weil ich behaupten will: Agile geht nicht ohne OD und sinnvolle OD geht nicht ohne Agile. Man kann Agile nicht einführen/leben, ohne die Organisationsentwicklung und das Organisationsdesign zu adressieren. Und eine Organisationsentwicklung, die nicht auf Reaktionsfähigkeit, Innovationskraft, Kundenzentrierung und Market-Fit abzielt, wäre zumindest merkwürdig.

Was kann OD, was Agile nicht kann?

Natürlich decken Organisationsentwicklung und Organisationsdesign Aspekte ab, auf die Agile zunächst nicht speziell eingeht, z.B. Strategieentwicklung, strategische Planung, Talentmanagement und Leistungsmanagement.

Es stellt sich jedoch meines Erachtens und nach meiner Erfahrung heraus, dass eine nachhaltige Umsetzung von Business Agility nicht möglich ist, ohne diese Aspekte zu berücksichtigen. Ein Agile Enterprise Coach weiß das und wird es — soweit man ihn/sie lässt, adressieren.

Mein Fazit: OD ohne Agile ist sinnlos, Agile ohne OD ist wirkungslos

Mein Fazit ist, dass OD und Agile eine symbiotische Beziehung haben müssen, beide sind miteinander verwoben, wenn es darum geht, eine effektive, zukunftsfähige Organisation zu bauen und weiterzuentwickeln. Traditionelle Organisationsentwicklungsmethoden allein sind m.E. nicht mehr ausreichend, um der heutigen, komplexen, sich ständig verändernden Business-Umgebung gerecht zu werden.

Und agile Methoden, die einfach “eingeführt” oder noch schlimmer “ausgerollt” werden, ohne in einen OD-Ansatz eingebettet zu sein, können zwar auf einer operativen Ebene eventuell effektiv sein — ohne eine übergeordnete organisatorische Strategie, Struktur und Kultur, die sie unterstützen, wird ihre volle Wirkung jedoch selten, wenn überhaupt, erreicht.

Agile World 2024

christian-braun — Fri, 01 Dec 2023 18:44:08 +0000

Am 1. und 2. Juli ist es wieder soweit: Die Agile World geht dieses Mal unter dem Titel "Leading towards Trust" in die nächste Runde und wir sind schon voller Vorfreude!

Alle Infos und Tickets gibt es hier

Agile Tuesday: Impact Mapping 💍 Opportunity Solution Tree mit Büşra Coşkuner

christian-braun — Fri, 01 Dec 2023 18:51:58 +0000

Büşra wandelt idealistische Produkttheorien in reale Produktpraxis um, fokussiert durch ihren No-Bullshit-Ansatz. Mit Erfahrungen von Start-ups, Scale-ups bis Großunternehmen wie u.a. Doodle, Deutsche Telekom und home24 kann sie Frameworks der Situation anpassen. Als Coach im Produktmanagement hilft sie Teams und Führungskräften, neue Methoden effektiv umzusetzen und echte Ergebnisse zu erzielen.

Ein modernes und erfolgreiches Produktmanagement basiert auf einer Insights basierten Entscheidungsfindung und einer strategischen Priorisierung der von uns entdeckten Opportunities. Daher ist es für Product Leaders und Teams von entscheidender Bedeutung, die Opportunities, die wir verfolgen, und die Lösungen, die wir entwickeln wollen, mit der übergreifenden Produktstrategie abzustimmen. In dieser Präsentation wird das Konzept des Impact Mapping und seine Rolle bei der Stärkung der Zusammenarbeit, der Verknüpfung von Product Strategy und der täglichen Arbeit, und dem Kick-off der Product Discovery vorgestellt. Wir werden uns anschauen, wie sich Impact Mapping nahtlos mit anderen beliebten Frameworks wie OKRs, Lean Startup und dem Opportunity Solution Tree verbinden lässt, und werden tiefer in die Verbindung mit dem Opportunity Solution Tree eintauchen.

Das Event ist auf Deutsch, mithilfe von Google Meets kann der Untertitel in jede Sprache live übersetzt werden. Wir freuen uns auf rege Teilnahme.

Hier geht´s zur Anmeldung

Mastering Success with Flight Levels: Propel Your Single Team Journey in 2 Essential Steps

mats.olof.winroth — Mon, 04 Dec 2023 16:40:15 +0000

Discover how Flight Levels, a simple yet powerful approach, can elevate the performance of a single team. Join the conversation as Mats Olof Winroth shares insights alongside Tina Rieger.

The Challenge:

Mats, it's great that you want to share your experience. Using Flight Levels components for a single team success sounds exciting. Before we dive deeper, could you tell us something about the team? What had they already achieved? What did they want to improve?

The team I collaborated with belonged to a global business organization, supporting social media strategies and content globally. Despite functioning as a Scrum team, they struggled with issues arising from the organization's traditional work environment, leading to internal and external friction. The three-week sprints and self-management were unfamiliar territory for the organization. I typically work with teams facing agile process and delivery problems. For me it was initially surprising to encounter a team that had already successfully adopted many "agile" practices. However, one of the significant challenges was a long-term roadmap that got detached from reality, causing trust issues and conflicts

Using Flight Levels:

You used a part of the Flight Levels theory to bring the team closer to their strategic goals. How could Flight Levels help you to address the strategic problem described above?

Flight Levels offers a straightforward coaching model, making problems transparent through visualization and creating a common language, from strategy to implementation. This is a great help to bring in new concepts and ideas and to explain the benefits. One of the key ideas is breaking down the strategy into short-term measurable outcomes that encourages regular planning, review, and learning. Despite having a vision, mission, and strategies aligned in the organization, their roadmap lacked influence on day-to-day operations. The strategy even included one-year measurable goals, encompassing both output, e.g., the number of social media productions, and more outcome-related metrics, e.g., the amount of content utilized by regions in their local campaigns.

The roadmap and the one year goals were actually reviewed every quarter but didn’t have any influence on the day-to-day planning operations and the plans were not adopted based on learnings. Ideas from Flight Levels bridge this gap.

Concrete Steps for an Aligned Strategy:

What concrete steps did you take to get an aligned and impactful strategy and roadmap?

To tackle this challenge, we initiated two experiments:

1. Monthly Strategy Review Meeting:
The team introduced a monthly strategy review meeting, focusing on evaluating the outcomes from the previous three months and updating the roadmap for the next quarter. The plan for the next three months is detailed, while the remaining roadmap can be seen as a rolling forecast. In this strategy meeting also management and stakeholders will be invited, ensuring transparency and alignment of everyone with the roadmap.

Utilizing a shared, aligned, and consistently reviewed roadmap brings transparency to stakeholders, eliminating the previous conflict between a fixed long term plan and delivery. This not only promotes cooperation but also grants the team and stakeholders the flexibility to adapt the scope in response to the present circumstances.

2. Outcome for New Strategy Theme:
In Flight Levels, strategy is deconstructed into valuable and measurable outcomes, accompanied by implementation activities designed to achieve the specified objectives. This binds the strategy to the actual work, carried out in the team.

The team therefore established a time-constrained measurable outcome for one of the strategic themes that couldn't be addressed earlier. To achieve this outcome they defined epics, which carried end to end value, e.g. a specific social media production. The team decided each epic is owned by one of the developers and is reviewed every week.

In addition the team explores ways to establish meaningful, leading measurable outcomes for their initiatives. Currently these outcomes might rely mainly on the actual usage of their material and manual feedback from customers and regions. However, the team also focuses on enhancing analytics capabilities to allow measuring of customer interactions.

The integration of time-boxed work items, specifically real customer value in the form of outcomes and epics, empowers the team with significant benefits. With the definition of epics for value ownership got improved, “We are several team members that work on this new production but I feel responsible to align and ensure we progress”. This not only facilitates a clearer visualization of value flow within the system but also streamlines prioritization and fosters an environment of ongoing learning.

Celebrating Progress:

Many teams struggle to define and track measurable goals, so the team is already further ahead than many others. A reason for me to celebrate? How do you see that?

Well, the journey is also a goal, isn’t it? I think this team is on a good way and they have also adopted a positive experimental approach, with a sound “We don’t know, but let’s try it out!” attitude. I think this is a key factor for every change.

Thank you Mats for your insight. I have taken that with me. The nice thing about a thinking model like Flight Levels is that parts of it can be cleverly useful everywhere. Creating transparency about actual position, building a common language and bringing the right people in regular intervals together have positive effects.It is positive for individual teams and beneficial for scaling.

Final Thoughts:

Would you like to share a few final words?

Flight Levels offers a versatile thinking model, good for any organization or team. It encourages starting where you are, optimizing interactions, experimenting, and adapting to your specific context. This flexibility makes Flight Levels suitable for any environment, even in traditional agile frameworks.

In our discussion, we touch on just one aspect of Flight Levels. Still, the model proves to be a valuable coaching tool for organizations facing complex challenges. By employing adaptable strategies and focusing on measurable outcomes, even a single team can benefit from Flight Levels ideas. While the concepts discussed here aren't unique to Flight Levels, the model provides a comprehensive framework with practical ideas to enhance coaching and organizational improvement at all levels.

More information on Flight Levels:
https://improuv.com/agile-methoden/flight-levels-activities/
https://www.flightlevels.io/

Mastering Success with Flight Levels: Propel Your Single Team Journey in 2 Essential Steps

mats.olof.winroth — Mon, 04 Dec 2023 16:40:15 +0000

Discover how Flight Levels, a simple yet powerful approach, can elevate the performance of a single team. Join the conversation as Mats Olof Winroth shares insights alongside Tina Rieger.

The Challenge:

Using Flight Levels:

Concrete Steps for an Aligned Strategy:

What concrete steps did you take to get an aligned and impactful strategy and roadmap?

To tackle this challenge, we initiated two experiments:

Celebrating Progress:

Final Thoughts:

Would you like to share a few final words?

More information on Flight Levels:
https://improuv.com/agile-methoden/flight-levels-activities/
https://www.flightlevels.io/

Agile Tuesday: "Ask me anything" mit Roman Pichler

christian-braun — Fri, 08 Dec 2023 14:19:38 +0000

Ask Me Anything oder auch AMA ist ein Format bei dem ihr eure Fragen direkt an Roman Pichler stellen dürft.
Wir sammeln vorher bereits fragen, damit wir gut vorbereiten sind.

Deswegen stellt eure Fragen gerne hier ein.

Roman Pichler ist unabhängiger Berater, international renommierter Scrum-Experte und Certified Scrum Trainer. Neben diesem Buch ist er der Autor von „Agile Product Management with Scrum“ (Addison-Wesley, 2010). Seine Kunden schätzen seine langjährige und vielseitige Erfahrung in der Anwendung von Scrum. Einen wichtigen Schwerpunkt seiner Arbeit bilden die Themen agiles Produktmanagement und Product Ownership. Mehr Informationen finden Sie unter romanpichler.com.

Hier geht´s zur Anmeldung

Sabine Canditt als Speakerin auf der OOP 2024

christian-braun — Fri, 08 Dec 2023 16:49:39 +0000

Sabine Canditt gibt am 1. und 2. Februar eine Konferenzsession und einen ganztägigen Workshop auf der OOP 2024.

"Nachhaltige Entwicklung braucht innere Entwicklung: agile Schritte in eine lebensbejahende Zukunft" am 1.2. um 17:00 Uhr
"Product Owner:in im Dilemma – Geschäfte machen vs. Welt retten?" am 2.2. als Ganztages-Workshop ab 9:00 Uhr

Und noch ein I-Tüpfelchen für Sie: Mit dem Code "SPEOOP2024-Hedi Buchner" erhalten Sie 25% Rabatt auf das OOP Ticket.

Hier gibt´s mehr Infos

Agile Tuesday: "Reshaping the future of OKRs" mit Cansel Sörgens und Natalija Hellesoe

christian-braun — Fri, 09 Feb 2024 09:35:25 +0000

10 Trends & Potentiale für wertstiftenden OKRs und neue Perspektiven rund um das Konzept OKRs und einen Überblick über aktuelle Trends

Langsam aber sicher etablieren sich OKRs als feste Größe in Organisationen. Aber ist das eigentlich gut und sinnvoll, oder verkommen sie bald zur nächsten Checkbox im Rahmen von Transformationen, deren Wirkung oft ausbleibt? Wie hilfreich ist die
steigende Popularität für die Weiterentwicklung von OKRs als Framework und die
umgebende Community? Und geht es auch anders?
In ihrem Vortrag werden Cansel Sörgens und Natalija Hellesoe zehn aktuelle Trends zum Thema aufdecken – von OKR-Architekturen bis zur skalierten Umsetzung, von strategischen Kompetenzen bis zum Rollenverständnis im Prozess.
Die OKR Expertinnen gleichen erhoffte und tatsächliche Auswirkungen der Trends ab und hinterfragen deren Sinn für die Organisationsentwicklung. Außerdem zeigen sie auf, wie ein durchdachter Einsatz von OKRs jenseits der “simplen Idee” Wert stiften kann.

Egal ob Ihr erst darüber nachdenkt, mit OKRs zu arbeiten oder diese bereits
eingeführt habt und nach Möglichkeiten suchen, die Strategieumsetzung zu
verbessern: Steigt ein in eine praktische Diskussion, wie die Zukunft von OKRs
neu gestaltet werden kann, um dazu beizutragen, die aktuellen und künftigen
Herausforderungen zu meistern!

:::::::::::::::
Cansel Sörgens
Cansel beschäftigt sich seit 2011 mit Agile Organisationsentwicklung. In schnell wachsenden Organisationen verantwortete sie strategische, abteilungsübergreifende Projekte und Agile Transformation. Seit 2016 implementiert Cansel Sörgens OKR in B2B-, B2C-, B2B2C-Organisationen jeder Größe aus unterschiedlichen Branchen wie E-Commerce, Retails, MedTech, FinTech, InsureTech, Consumer Electronics, Pharma. Ihre langjährige und praxiserprobte Expertise in OKR, Strategie und Leadership teilt sie als Rednerin, Autorin und Gründerin der ersten OKR Lean Coffee und Reshaping the Future of OKRs. Mehr: https://cansel-soergens.com

Natalija Hellesoe
Natalija ist Unternehmerin, Trainerin und Coach und konzentriert sich vor allem auf die Themen Leadership & Responsibility, OKRs sowie auf Agile HR & Learning. Sie unterstützt Teams und Organisationen dabei, ihre Herausforderungen besser zu verstehen, wertschöpfende Ziele zu definieren und sich kontinuierlich zu verbessern.

Vor ihrer Selbstständigkeit war Natalija viele Jahre an der Schnittstelle zwischen HR, IT und Kommunikation tätig und hat Transformationen in verschiedenen Organisationen begleitet. Ihre Arbeit ist geprägt durch Perspektivwechsel und dem Experimentieren mit neuen Methoden und Möglichkeiten, die sie aus der Zusammenarbeit mit globalen Netzwerken, ihren Reisen und der großen Freude an persönlicher Weiterentwicklung schöpft.

Unter der Marke “OKRs AT THE CENTER” begleitet Sie Organisationen auf verschiedenen Abschnitten ihrer OKR Reise von der Einführung, Skalierung, internen Ausbildung bis zur nachhaltigen Verbesserung. Zusammen mit Sonja Mewes hat Natalija das Buch “OKRs AT THE CENTER: How to use goals to drive ongoing change and create the organization you want” bei Sense & Respond Press veröffentlicht und ist seit vielen Jahren sehr aktiv in der OKR Community, u.a. mit monatlichen Meetups, Open Space Events und Beiträgen zu internationalen Konferenzen

Hier geht´s zur Anmeldung

Agile Tuesday: "Ask Me Anything" with Bob Galen (Author of Extra. Badass Agile Coaching)

christian-braun — Thu, 22 Feb 2024 17:18:01 +0000

We are happy to present our next speaker at the Agile Tuesday. Bob will give an AMA (Ask me Anything) Session. Right now we are collecting questions.

Post your question here.

This event will be in English. We are using Google Meet, so you can live translate it into German or any other language if you want to.

Bob Galen
Bob Galen is an Agile Practitioner, Trainer & Coach based in Cary, NC. In this role he helps
guide companies and teams in their pragmatic adoption and organizational shift towards Agile
methods of working. Bob has been doing that since the late 1990s, so he’s deeply experienced.
He is the Director of Agile Practice at Zenergy Technologies, a leading business agility
transformation company. Bob is also President and Head Coach at Agile Moose, a boutique agile
coaching firm.

He is a Scrum Alliance Certified Enterprise Coach Emeritus (CECem), an iCAgile authorized
trainer, and an active member of the Agile Alliance.
He’s published four agile-centric books:

The Three Pillars of Agile Quality and Testing in 2015
Scrum Product Ownership, 3’rd Edition in 2019,
Agile Reflections in 2012,
Extraordinarily Badass Agile Coaching in 2022.

He’s also a prolific writer & blogger (www.rgalen.com and www.agile-moose.com) and podcaster (at www.meta-cast.com )
Connect with Bob here

improuv gibt Impulse auf der Agile Tour Luxembourg

christian-braun — Wed, 06 Mar 2024 09:49:52 +0000

Hedi Buchner ist Teil der Agile Tour Luxembourg 2024.

Ihr Talk am 19. April trägt den Titel: Sustainable development needs inner development - agile steps towards a life-affirming future

Hierum geht´s:

Agility is used within our economic system to keep the business running and growing if possible. But let's face it: this very system is the cause of the climate crisis and other related sustainability problems. Can we use agility as an "accelerator" to achieve the UN Sustainable Development Goals (SDGs)? What inner capabilities do we need to deal with these increasingly complex challenges and foster global transformation? What small steps can we start with to make a lasting impact?
The workshop aims to raise awareness of this challenge - and the responsibility that comes with it. As an inspiration, we will show concrete examples of Agilist:ins who have already embarked on a sustainable path. Together we explore the SDGs and develop ideas on how we, as agilists, can contribute to them: in product development, with our teams and organizations, but also in our personal lives. We will take a look at the Inner Development Goals (IDGs) and consider how they can enhance our agile competencies to achieve sustainable goals, for example through long-term orientation and caring for others.

Mehr Infos und Tickets zur Konferenz

Wenn Selbstorganisation scheitert

jens — Fri, 08 Mar 2024 09:06:25 +0000

Wenn manche Leute über selbstorganisierende Teams sprechen, habe ich gelegentlich den Eindruck, als sei Selbstorganisation der Zauberstab, der alle Probleme löst. Seien wir ehrlich: Selbstorganisation kann scheitern und zu Dysfunktion und sogar zur Selbstzerstörung führen. Ja, selbstorganisierte Systeme verfügen über ein erstaunliches Maß an Widerstandsfähigkeit gegenüber externen Störungen. Aber sie haben auch ihre Schwachstellen.

Einige Beispiele für Fehler in selbstorganisierenden Systemen: Ein epileptischer Anfall ist ein Fehler in der Selbstorganisation des Gehirns. Krebs ist ein Versagen der Selbstorganisation von Zellen. Und selbst Märkte können versagen und eine Hyperinflation oder eine Bankenkrise auslösen (Es tut mir leid, mein neoliberaler Freund, aber Adam Smith hatte unrecht). In vielen dieser Fälle kann ein Eingriff von außen z.B. durch eine Ärztin oder eine Regierung die Auswirkungen des Versagens verringern und dem System helfen, wieder zu "heilen" oder zumindest den Verfall zu verlangsamen.

Wo liegen nun die Grenzen der Selbstorganisation von Teams? Die menschliche Selbstorganisation ist auf offene Kommunikation und ein gewisses Maß an Vertrauen angewiesen. Wenn die Kommunikation zusammenbricht, z. B. weil in einer Remote-Umgebung zu wenig auf Kommunikation geachtet wird, kollabiert die Selbstorganisation. Wenn man einen Psychopathen oder einen pathologischen Narzissten in das Team holt, können er oder sie das Vertrauen und die Zusammenarbeit völlig zerstören. Diese Situationen haben ein hohes Potenzial, das gesamte Team in eine dysfunktionale Gruppe zu verwandeln.

Aber auch gut funktionierende, selbstorganisierte Teams sind manchmal nicht in der Lage, bestimmte Entscheidungen zu treffen. Zum Beispiel, wenn Interessenkonflikte zwischen persönlichen Zielen und Belangen der Organisation die Oberhand gewinnen.

Auf dieses Problem stößt man regelmäßig bei Diskussionen über die Teamstruktur in einer skalierten Umgebung: Gut funktionierende Teams sind mehr als Kästchen im Organigramm, sie sind ein soziales Zuhause für ihre Mitglieder. Sie werden sich gegen jede Bedrohung dieser Heimat wehren, egal wie überzeugend Ihre Excel-Tabellen sind.

Ein weiteres Beispiel sind Änderungen des Gehaltsmodells: Der Konflikt zwischen dem eigenen Bankkonto und dem "großen Ganzen" kann zu groß sein, als dass das Team eine Lösung finden könnte, ohne auseinanderzubrechen.

Natürlich könnte man sagen "Was auch immer passiert, ist das Einzige, was hätte passieren können" und das Team den Bach runtergehen lassen. Das passiert in völlig selbstorganisierten menschlichen Beziehungen, wie zum Beispiel in Freundschaften. Aber in Organisationen existieren Teams nicht um ihrer selbst willen, sondern um einen Zweck zu erfüllen. Wenn sie nicht in der Lage sind, diesen Zweck zu erfüllen, sind sie dysfunktional.

Als Führungskraft müssen Sie erkennen, wann die Selbstorganisation eines Teams zu zerbrechen beginnt. Und man muss eingreifen, so wie ein Arzt eingreifen muss, wenn die Selbstheilungskräfte des Körpers an ihre Grenzen stoßen. Um die richtige Intervention zu finden, braucht man ein gutes Verständnis dafür, wie Selbstorganisation funktioniert und wo das Kernproblem liegen könnte. Genauso wie eine Ärztin ein gutes Verständnis davon haben muss, wie der menschliche Körper funktioniert und was passiert, wenn man an einer Krankheit leidet.

Und so wie ein Arzt die Wahl hat, ein mildes Medikament zu verschreiben oder einen in eine große, gefährliche Operation zu schicken, haben Sie auch die Wahl zwischen milden und brutalen Eingriffen. Zu den milden Maßnahmen gehört es, Menschen zusammenzubringen oder externe Unterstützung zu organisieren. Brutale Maßnahmen können darin bestehen, die Entscheidung eines Teams zu überstimmen oder jemanden zu entlassen. Und wie bei großen Operationen brauchen Teams besondere Betreuung und Zeit, um sich von einem harten Eingriff zu erholen. Wenn man jede Woche eine gefährliche Operation durchführt, wird das Team wahrscheinlich sterben. Meine persönliche nachträgliche Überprüfung harter Eingriffe ist, wenn sich die Leute beschweren: "Warum hast Du so spät eingegriffen?" Greifen Sie nur dann zu harten Maßnahmen, wenn Sie zuvor alle weicheren Optionen ausprobiert haben.

“Nie wieder” ist jetzt! Warum wir unseren Claim ändern

jens — Fri, 20 Sep 2024 12:39:47 +0000

Vor ein paar Jahren haben wir uns für einen neuen Claim entschieden: „Es ist Zeit für einen Wandel“. Er gefiel uns - und gefällt uns noch immer -, weil er das Bedürfnis unserer Kund:innen ausdrückt. Er zeigt, dass in der Vergangenheit erfolgreiche Rezepte, für unsere dynamische Zukunft nicht mehr wettbewerbsfähig sind. Unsere Kund:innen wissen, dass man sich für neue Herausforderungen fit machen muss, statt sie zu ignorieren oder gar zu versuchen, sie zu verhindern. Unsere Kund:innen wissen, dass unsere Unterstützung ihnen hilft, dieser Herausforderung gerecht zu werden. Und sie wissen, dass jetzt die Zeit dafür ist, bevor sie von der Dynamik überrollt werden.

Nun verwendet eine rechtsextreme, von Neonazis unterwanderte Partei einen sehr ähnlichen Slogan im Wahlkampf in Brandenburg. Wir distanzieren uns ausdrücklich von den Zielen, den Mitteln und Drahtziehern dieser Partei. Nachdem der juristische Weg hier leider aussichtslos ist - unser Slogan ist nicht geschützt und auch nicht schutzfähig - haben wir uns schweren Herzens von unserem Claim verabschiedet.

Wir stehen für eine Arbeitswelt, die von psychologischer Sicherheit geprägt ist. Wir stehen für einen respektvollen Führungsstil, der Realitäten anerkennt und nachhaltige Lösungen sucht. Wir stehen für die Kraft der Diversität im Denken. Wir stehen für vertrauensvolle Zusammenarbeit, unabhängig von Abstammung, Staatsbürgerschaft, Kultur, Religion und privater Lebensgestaltung. Wir stehen für den Willen, die Zukunft konstruktiv und nachhaltig zu gestalten. All diese Punkte sind das Gegenteil dessen, was jene Partei propagiert.

Deshalb heißt es jetzt bei uns: „Zukunft schaffen, Führung leben.”

Für improuv

Jens Coldewey
Sacha Storz
Theresa van Bernum
Alisa Ströbele
Sabine Canditt
Margarete Cyll
Nadine Bleck
Sebastian Heglmeier

PI Planning Tag 1

krishan — Wed, 18 Dec 2019 09:04:49 +0000

lean_kanban

krishan — Wed, 18 Dec 2019 10:56:13 +0000

Tag 2 f

krishan — Wed, 18 Dec 2019 11:36:57 +0000

authentic-de

krishan — Wed, 18 Dec 2019 12:42:00 +0000

Fotolia_109877757_S

krishan — Wed, 18 Dec 2019 12:51:19 +0000

trust-vertrauen

krishan — Wed, 18 Dec 2019 13:11:06 +0000

Depositphotos_163603350_1200

krishan — Wed, 18 Dec 2019 14:06:38 +0000

start-with-why

krishan — Fri, 20 Dec 2019 12:21:43 +0000

Fotolia_202719826_S

krishan — Fri, 20 Dec 2019 12:24:53 +0000

icagile

krishan — Fri, 20 Dec 2019 12:29:28 +0000

focus-enable-align-empower-pre_0

krishan — Fri, 20 Dec 2019 12:33:08 +0000

645802-poq15y-707.-1200jpg

krishan — Mon, 25 May 2020 10:19:19 +0000

leader

krishan — Mon, 25 May 2020 11:00:20 +0000

Blog-AL

christian-braun — Wed, 06 Oct 2021 09:43:38 +0000

Crossfunktionale-Teams

christian-braun — Wed, 13 Oct 2021 14:38:16 +0000

Extradependent-teams

christian-braun — Thu, 14 Oct 2021 08:51:31 +0000

ATLux

christian-braun — Tue, 01 Aug 2023 15:59:53 +0000

Das Potenzial von Künstlicher Intelligenz für Product Owner

theresa.vanbernum — Tue, 29 Oct 2024 14:16:41 +0000

Künstliche Intelligenz hat ungeheures Potenzial für Professionals . Besonders für Product Owner, die schnell und effektiv von den Möglichkeiten profitieren können.

Wir haben im letzten Jahr intensiv in verschiedenen Anwendungen Erfahrungen gesammelt und festgestellt: Das spart nicht nur Zeit, sondern verbessert für Product Owner auch die multi-perspektivische Produktsicht, die Entscheidungsgrundlagen, die Scope-Übersicht und die Kommunikation erheblich. Auch beim Brainstorming und Sparring zeigt sich die wahre Stärke der Künstlichen Intelligenz: Richtig bedient, ist sie ein kreativer Partner für das ganze Team, der immer wieder neue Perspektiven einbringt.

In unserem neuen Training "ChatGPT & Co. für Product Owner" teilen wir unsere Erfahrungen aus der Arbeit mit großen Sprachmodellen (LLMs) und Bilderzeugung. Ob Informationsextraktion aus qualitativen Daten, Roadmapping, Chart-Erstellung, Stakeholder-Kommunikation, Brainstorming oder RE-Sparring – die Anwendungen sind vielfältig und die Ergebnisse super spannend.

Der Trainer Sacha Storz hat sich die letzten zwei Jahre intensiv mit generativer KI beschäftigt, geschult unter anderem an der Stanford University, IBM, der University of Pennsylvania, DataCamp und deeplearning.ai. Er vermittelt nicht nur die Chancen, sie die Technologie speziell auf für POs bietet, sondern auch relevante Aspekte wie Privacy, Security und Bias, damit ihr sicher und verantwortungsvoll mit GenAI arbeiten könnt.

Das Training findet Anfang Dezember 2024 remote in zwei 3-stündigen Blöcken erstmals statt, und wir freuen uns riesig, schon jetzt eine Durchführungsgarantie geben zu können! Die Nachfrage ist groß, und wir sind begeistert, euch auf dieser Lernreise zu begleiten.

Sei dabei und entdecke, wie GenAI deine Arbeit als Product Owner und Produktmanager bereichern kann: Mehr Infos und Buchung hier.

Und übrigens: Für die Verlängerung Deiner Zertifizierung als CSPO oder CSM kannst Du Dir für dieses Training 6 SEUs gutschreiben!

lib-discover-to-deliver

krishan — Wed, 18 Dec 2019 13:44:46 +0000

csmfrauen

krishan — Sat, 28 Dec 2019 21:00:37 +0000

heathrow-2019-12

krishan — Wed, 29 Jan 2020 16:26:24 +0000

Business in London Heathrow

improuv-logotype_ANIM

hedi.buchner — Fri, 15 Nov 2019 06:57:04 +0000

covid-19-4939288_1920

stefanie — Wed, 20 May 2020 08:51:02 +0000

hr-process-4783430_1920

stefanie — Wed, 20 May 2020 09:09:49 +0000

word-cloud-1758159_1280

stefanie — Wed, 20 May 2020 09:24:09 +0000

people group floating on paper boat rear view men women team traveling on sheep discovery concept mix race male female cartoon characters flat horizontal

krishan — Mon, 25 May 2020 10:59:23 +0000

change-4056014_1920

christian-braun — Fri, 03 Jul 2020 09:11:17 +0000

Blogchat Screenshot

christian-braun — Wed, 08 Jul 2020 15:11:54 +0000

BlogEvent-Post

christian-braun — Fri, 02 Oct 2020 09:22:25 +0000

Blogbild Krishan

christian-braun — Tue, 06 Oct 2020 08:51:16 +0000

Blogpic Weiterbildung

christian-braun — Thu, 03 Dec 2020 11:54:56 +0000

Blogchat

christian-braun — Fri, 11 Dec 2020 10:30:48 +0000

Blog-Klimawandel

christian-braun — Fri, 08 Jan 2021 13:39:09 +0000

maxresdefault

christian-braun — Tue, 17 Aug 2021 07:41:05 +0000

maxresdefault-1

christian-braun — Tue, 17 Aug 2021 07:41:13 +0000

maxresdefault

christian-braun — Mon, 22 Nov 2021 09:08:56 +0000

Scrum-Master-Blog

christian-braun — Wed, 10 Mar 2021 15:26:11 +0000

Praktiken-1

christian-braun — Wed, 17 Mar 2021 11:40:57 +0000

Praktiken-2

christian-braun — Wed, 17 Mar 2021 11:42:02 +0000

Praktiken-3

christian-braun — Wed, 17 Mar 2021 11:43:03 +0000

Gedicht

christian-braun — Wed, 17 Mar 2021 13:37:25 +0000

Scrum-Master-2

christian-braun — Wed, 24 Mar 2021 12:11:06 +0000

Sprint Review

christian-braun — Thu, 01 Apr 2021 11:44:26 +0000

Stakeholder

christian-braun — Fri, 16 Apr 2021 14:54:14 +0000

Schätzungen

christian-braun — Fri, 23 Apr 2021 14:36:43 +0000

Team-meint-Team

christian-braun — Fri, 30 Apr 2021 12:40:36 +0000

Sprint-Ziel

christian-braun — Fri, 28 May 2021 07:51:32 +0000

Blog-AL

christian-braun — Wed, 06 Oct 2021 09:43:38 +0000

Crossfunktionale-Teams

christian-braun — Wed, 13 Oct 2021 14:38:16 +0000

Extradependent-teams

christian-braun — Thu, 14 Oct 2021 08:51:31 +0000

logo-sub-title

christian-braun — Fri, 03 Dec 2021 12:11:16 +0000

iag_kanban

christian-braun — Fri, 03 Dec 2021 12:16:27 +0000

AT Februar21

christian-braun — Fri, 03 Dec 2021 12:22:54 +0000

Vorlage-jBlog-Titel

christian-braun — Wed, 02 Feb 2022 11:28:39 +0000

Blog-Glasdecke

christian-braun — Wed, 02 Feb 2022 11:28:54 +0000

2022.03.08.ExtradependentTeams.AgileTuesday.JC

christian-braun — Wed, 09 Mar 2022 10:05:07 +0000

Führung

christian-braun — Mon, 21 Jun 2021 10:44:00 +0000

Product-Backlog

christian-braun — Mon, 05 Jul 2021 14:25:07 +0000

Product-Backlog

christian-braun — Mon, 05 Jul 2021 14:25:07 +0000

Blog-Konflikt

christian-braun — Fri, 18 Feb 2022 09:43:45 +0000

brooke-cagle-g1Kr4Ozfoac-unsplash

christian-braun — Tue, 08 Mar 2022 13:47:34 +0000

Onboarding

christian-braun — Tue, 08 Mar 2022 13:55:18 +0000

Leadership-Event

christian-braun — Wed, 09 Mar 2022 10:50:50 +0000

Onboarding Reise

christian-braun — Wed, 09 Mar 2022 13:30:55 +0000

Lernbereiche

christian-braun — Wed, 09 Mar 2022 13:32:00 +0000

Lernmethoden

christian-braun — Wed, 09 Mar 2022 13:33:02 +0000

eisberg_modell

christian-braun — Wed, 09 Mar 2022 13:33:54 +0000

Flight1

christian-braun — Fri, 01 Apr 2022 11:21:17 +0000

Flight 2

christian-braun — Fri, 08 Apr 2022 08:04:53 +0000

Scaling-Agile-Talk

christian-braun — Wed, 13 Apr 2022 08:20:53 +0000

Psychologie-der-Veränderung-2

christian-braun — Wed, 27 Apr 2022 09:23:04 +0000

Agilität-und-Kultur

christian-braun — Wed, 01 Jun 2022 11:02:58 +0000

Agile Challanges

christian-braun — Wed, 01 Jun 2022 11:26:47 +0000

Kernkulturen

christian-braun — Wed, 01 Jun 2022 11:28:11 +0000

Frameworks

christian-braun — Wed, 01 Jun 2022 11:28:43 +0000

Flight-levels-3-levels

hedi.buchner — Tue, 19 Jul 2022 09:35:43 +0000

Flight-Levels-5-activities

hedi.buchner — Tue, 19 Jul 2022 09:37:07 +0000

jensgathering

hedi.buchner — Tue, 19 Jul 2022 10:00:52 +0000

maxresdefault

hedi.buchner — Thu, 11 Aug 2022 11:47:09 +0000

Einführung-Flight-Levels

christian-braun — Wed, 17 Aug 2022 10:15:55 +0000

maxresdefault-1

christian-braun — Mon, 29 Aug 2022 14:15:39 +0000

Flight-Levels-Day-international-2022-35e8eb2d96412209

christian-braun — Mon, 29 Aug 2022 14:36:36 +0000

FLD

christian-braun — Mon, 29 Aug 2022 14:40:17 +0000

manageagile

christian-braun — Mon, 29 Aug 2022 14:44:42 +0000

ama

christian-braun — Mon, 29 Aug 2022 14:59:18 +0000

Bildschirmfoto 2022-09-16 um 18.45.27

hedi.buchner — Fri, 16 Sep 2022 16:48:32 +0000

nr1

christian-braun — Fri, 21 Oct 2022 14:15:10 +0000

nr2

christian-braun — Fri, 21 Oct 2022 14:15:44 +0000

nr3

christian-braun — Fri, 21 Oct 2022 14:16:39 +0000

traffic-jam-2-960 (1)

christian-braun — Mon, 24 Oct 2022 15:10:57 +0000

Vorlagsdfge-Blog-Titel

christian-braun — Mon, 24 Oct 2022 15:12:36 +0000

dos

christian-braun — Tue, 25 Oct 2022 09:30:35 +0000

uno

christian-braun — Tue, 25 Oct 2022 09:30:35 +0000

ol

christian-braun — Tue, 25 Oct 2022 09:32:01 +0000

ol-1

christian-braun — Tue, 25 Oct 2022 09:32:38 +0000

o

christian-braun — Tue, 25 Oct 2022 09:32:38 +0000

Logo-mit-Host4

christian-braun — Mon, 14 Feb 2022 14:06:29 +0000

maxresdefault

christian-braun — Fri, 18 Mar 2022 13:36:14 +0000

o-1

christian-braun — Tue, 25 Oct 2022 09:33:39 +0000

Voasdfsarlage-Blog-Titel

christian-braun — Tue, 25 Oct 2022 09:37:02 +0000

lok

christian-braun — Tue, 25 Oct 2022 13:06:41 +0000

FLs

christian-braun — Thu, 10 Nov 2022 15:02:15 +0000

Service-Canvaspng

christian-braun — Thu, 10 Nov 2022 15:03:07 +0000

Kanban-Skalierung

christian-braun — Thu, 10 Nov 2022 15:17:44 +0000

Deine-Arbeit-Kanban

christian-braun — Wed, 23 Nov 2022 14:17:19 +0000

Schwarm

christian-braun — Mon, 23 Jan 2023 14:53:18 +0000

ggUnbenannt

christian-braun — Tue, 07 Feb 2023 14:57:09 +0000

g2

christian-braun — Tue, 07 Feb 2023 14:58:09 +0000

g3

christian-braun — Tue, 07 Feb 2023 14:58:33 +0000

g4

christian-braun — Tue, 07 Feb 2023 14:59:51 +0000

EMU

christian-braun — Tue, 07 Feb 2023 15:07:14 +0000

71VFx-UPAKS

christian-braun — Wed, 15 Feb 2023 14:56:33 +0000

bücher-1

christian-braun — Wed, 15 Feb 2023 15:05:03 +0000

Disruptive Technologies Konferenz

hedi.buchner — Thu, 02 Mar 2023 13:13:53 +0000

ABIT

hedi.buchner — Thu, 02 Mar 2023 13:14:59 +0000

Agile Tuesday - Playful Agile Coaching

Wed, 08 Mar 2023 09:36:19 +0000

Bildschirmfoto-2023-03-18-um-22.37.45

christian-braun — Wed, 22 Mar 2023 15:39:46 +0000

BlogKanban

christian-braun — Wed, 22 Mar 2023 15:50:55 +0000

FLBlog1

christian-braun — Thu, 23 Mar 2023 15:10:04 +0000

FLBlog2

christian-braun — Thu, 23 Mar 2023 15:10:51 +0000

BlogFLKanban

christian-braun — Thu, 23 Mar 2023 15:20:43 +0000

51iFb8wfNpL

christian-braun — Thu, 23 Mar 2023 15:49:16 +0000

Lieblingsbuch2

christian-braun — Thu, 23 Mar 2023 15:51:28 +0000

This_is_Lean

christian-braun — Fri, 14 Apr 2023 08:43:50 +0000

Library-3

christian-braun — Fri, 14 Apr 2023 08:59:33 +0000

Blog-unfix

christian-braun — Thu, 20 Apr 2023 13:57:56 +0000

IMG_5382

christian-braun — Thu, 20 Apr 2023 14:39:24 +0000

BlogActivities

christian-braun — Thu, 20 Apr 2023 14:43:56 +0000

pexels-rifqi-ramadhan-788200

ugurakin — Mon, 24 Apr 2023 10:02:36 +0000

pexels-rifqi-ramadhan-788200

ugurakin — Mon, 24 Apr 2023 10:04:48 +0000

pexels-annam-w-1057861-3

ugurakin — Mon, 24 Apr 2023 10:07:05 +0000

Skalierung-auf-5-bis-10-Mio.-Euro-als-Coach-Berater-oder-Agentur-BAULIG-CONSULTING-Public-Version-v1

ugurakin — Mon, 24 Apr 2023 13:14:17 +0000

Screenshot-2023-04-24-at-15.27.07

ugurakin — Mon, 24 Apr 2023 13:27:23 +0000

Screenshot-2023-04-24-at-16.55.16

ugurakin — Mon, 24 Apr 2023 14:56:06 +0000

image

ugurakin — Tue, 25 Apr 2023 16:21:00 +0000

image-1

ugurakin — Tue, 25 Apr 2023 16:30:00 +0000

safeugur

christian-braun — Tue, 02 May 2023 12:30:45 +0000

SAS

christian-braun — Fri, 12 May 2023 08:50:22 +0000

XP23

christian-braun — Tue, 13 Jun 2023 09:36:44 +0000

Workshop

christian-braun — Tue, 13 Jun 2023 09:46:58 +0000

Agile-Austria

christian-braun — Tue, 01 Aug 2023 15:36:05 +0000

Agile-Scale-Camp

christian-braun — Tue, 01 Aug 2023 15:50:48 +0000

ModernRE

christian-braun — Tue, 01 Aug 2023 16:08:25 +0000

Future-Congress

christian-braun — Wed, 02 Aug 2023 09:31:31 +0000

SolutionsHamburg

christian-braun — Wed, 02 Aug 2023 09:42:32 +0000

digi2

christian-braun — Wed, 02 Aug 2023 09:44:08 +0000

ManageA

christian-braun — Wed, 02 Aug 2023 13:29:14 +0000

ScrumGatheringAmsterdam

christian-braun — Thu, 03 Aug 2023 09:28:07 +0000

IHKafterwork

christian-braun — Mon, 18 Sep 2023 14:55:49 +0000

forecast

christian-braun — Thu, 05 Oct 2023 08:32:55 +0000

team

christian-braun — Thu, 19 Oct 2023 09:15:16 +0000

1699977368380

christian-braun — Fri, 01 Dec 2023 18:49:57 +0000

Flight_Levels_planes

hedi.buchner — Mon, 04 Dec 2023 16:26:49 +0000

Blog-FLights

christian-braun — Tue, 05 Dec 2023 13:45:01 +0000

Blog-FLights

christian-braun — Tue, 05 Dec 2023 13:45:01 +0000

OOP-Events

christian-braun — Fri, 08 Dec 2023 14:27:53 +0000

imp-signet-agileworld-RGB-pos-ohne-claim

christian-braun — Mon, 01 Nov 2021 14:46:50 +0000

AgileTourLux

christian-braun — Wed, 06 Mar 2024 09:43:53 +0000

ddsfg

christian-braun — Fri, 08 Mar 2024 09:04:32 +0000

Nie Wieder Ist Jetzt

jens — Fri, 20 Sep 2024 12:37:27 +0000

Foto: Dominik Türk, lizenzfrei

image_720-2

theresa.vanbernum — Tue, 29 Oct 2024 14:16:22 +0000