Thorben Egberts' Blog

Warum vs. Wofür: 5-Why

Sun, 10 Dec 2017 15:19:00 +0000

In einem gewissen Alter beginnen Kinder damit, ständig „Warum?” zu fragen. Dabei geben sie sich mit einer einzelnen Antwort oft nicht zufrieden, wodurch lange „Warum-Ketten” entstehen. So eine Kette endet im besten Fall durch eine zufriedenstellende Antwort. Viel öfter jedoch wird die Kette durch ein „Weiß ich nicht!”, „Deshalb!”, „Das ist einfach so!” oder – abhängig davon, wer der Gefragt ist – „Frag eine Mutter!” unterbrochen.

Später in der Arbeitswelt beginnen diese Kinder, egal ob sie nun Chefs oder Angestellte sind, erneut mit den Warum-Fragen. Meist, wenn etwas schief gegangen ist, eine Problemursache analysiert wird oder etwas optimiert werden soll.

Die 5-Why-Methode wird gern für Problemanalysen oder Retrospektiven verwendet. Ausgehend von einer Problemstellung wird fünfmal „Warum?” gefragt. Jede Antwort ist Ausgangspunkt für eine weitere Warum-Frage. Die Annahme ist, nach fünf solcher Fragen auf die Problemursache (Root Cause) zu stoßen. Diese kann nun als Verursacher des Problemsymptoms beseitigt werden.

5-Why für komplizierte Probleme

Für die 5-Why-Methode liefert Wikipedia dieses Beispiel:

Problemstellung: Das Fahrzeug startet nicht.

Warum startet das Fahrzeug nicht? → Die Starterbatterie ist leer.
Warum ist die Starterbatterie leer? → Die Lichtmaschine funktioniert nicht.
Warum funktioniert die Lichtmaschine nicht? → Der Keilriemen ist gerissen.
Warum ist der Keilriemen gerissen? → Der Keilriemen wurde nie ausgewechselt.
Warum wurde der Keilriemen nie ausgewechselt? → Das Fahrzeug wurde bisher nie gewartet.

Eine mögliche Maßnahme wäre, das Auto in einer Werkstatt warten zu lassen und von da an regelmäßigen Wartungen zu unterziehen.

Diese Problemstellung bewegt sich in einem kausal-mechanischen Kontext. Ursache und Wirkung ist dem Beobachter bekannt oder kann in einer Dokumentation nachgelesen oder von einem Experten festgestellt werden.

Ähnliche Problemstellungen wären:

Eine Software hat einen Fehler
Der Prozess der Buchhaltung im Unternehmen soll optimiert werden
Eine Fräsmaschine hat ein defektes Teil

Warum-Fragen sind hier zweckmäßig, weil sie rückwärts die Kausalitätsketten aufdecken, die vom eigentlichen Auslöser zum Problemsymptom geführt haben. Die Ursache des Problems lag bereits im Problem selbst. Die Systemtheorie spricht hier auch von einfachen und komplizierten Problemen, von denen die komplexen zu unterscheiden sind — im Gegensatz zum allgemeinen Sprachgebrauch, in dem „komplex” als „besonders kompliziert” verstanden wird.

5-Why für komplexe Probleme

Komplex werden Probleme dann, wenn das Verhalten von Menschen eine Rolle spielt. Hier ein Beispiel, an dem wir die 5-Why-Methode ebenfalls durchführen wollen.

Problemstellung: Ein Projekt wurde nicht zum vereinbarten Datum fertiggestellt. Frage an den Projektmanager:

Warum ist das Projekt nicht pünktlich fertig geworden? → Weil wir die Vereinbarungen nicht halten konnten.
Warum konnten die Vereinbarungen nicht gehalten werden? → Weil wir nicht unseren vollen Einsatz gegeben haben.
Warum habt ihr nicht euren vollen Einsatz gegeben? → Anna hat nicht so viel programmiert wie sonst.
Warum hat Anna nicht so viel programmiert wie sonst? → Weil sie selten an ihrem Platz war.
Warum war Anna so selten an ihrem Platz? → Sie war einfach nicht da. Vielleicht fehlte ihr die Motivation und war oft Kaffee trinken?

Anna wird daraufhin zum Personalgespräch gebeten. Sie wird mit dem Vorwurf konfrontiert. Die Arme verschränkend faucht empört: „Das stimmt doch garnicht! Ohne mich wäre es noch schlimmer geworden.” Auch Anna durchläuft die 5-Why:

Warum ist das Projekt nicht pünktlich fertig geworden? → Es sah alles gut aus, aber dann gab es Probleme mit einer Programmbibliothek.
Warum gab es Probleme mit einer Programmbibliothek? → Die Programmbibliothek erfüllte nicht die notwendigen Anforderungen.
Warum erfüllte die Programmbibliothek nicht die notwendigen Anforderungen? → Das andere Team, das die Programmbibliothek entwickelt hat, hat diese nicht implementiert.
Warum hat das andere Team die Anforderungen nicht implementiert? → Weil die neuen Anforderungen sich erst kurz vor dem geplanten Fertigstellungstermin ergeben haben.
Warum haben sich die Anforderungen erst kurz vor dem Fertigstellungstermin ergeben? → Weil der Kunde etwas anderes brauchte als zunächst geplant.

Jetzt gäbe es zwei neue Ansatzpunkte, die verfolgt werden können: Warum hat sich der Kunde umentschieden? War das andere Team zu langsam? Wir bleiben bei der ursprünglichen Problemstellung. 5-Why mit einem Mitglied des anderen Teams:

Warum ist das Projekt nicht pünktlich fertig geworden? → Wir konnten die Programmbibliothek nicht mehr rechtzeitig anpassen.
Warum konntet ihr die Programmbibliothek nicht rechtzeitig anpassen? → Weil die Anforderung zu spät bekannt war.
Warum war die Anforderung zu spät bekannt? → Der Projektmanager hat uns zu spät Bescheid gegeben.
Warum hat der Projektmanager euch zu spät Bescheid gegeben? → Ich weiß nicht, er hat es vermutlich vergessen.
Warum hat der Projektmanager es vergessen? → Er ist viel unterwegs und hat viel um die Ohren. Anna hatte Kontakt zum Kunden und hat es von ihm erfahren. Sie hat unser Team darauf intensiv dabei unterstützt, die Programmbibliothek anzupassen. Sie hat sich sogar zu uns ins Büro gesetzt. Aber es war einfach zu viel Arbeit.

So kann es noch sehr lang weitergehen. Es würden immer mehr Sichtweisen und vermeintliche Problemursachen hinzukommen. Auf manche Warum-Fragen gäbe es mehrere Antworten.

Nicht jeder hatte zu jedem Zeitpunkt die Information des anderen. Schuldfragen entstehen, genau wie „Cover-Your-Ass”-Verhalten und politische Manöver. Schuld wird zugewiesen und abgelehnt. Un- und Halbwahrheiten kommen ins Spiel.

Eventuell werden sogar konkrete Maßnahmen getroffen, personelle Konsequenzen entstehen oder es wird alles als verhängnisvolle Kette von ungünstigen Ereignissen deklariert

Irgendwann stellt sich dann die Frage: War das nützlich? Hat sich das gelohnt? Stehen die Mitarbeiter, das Team und die Organisation nun besser da als vorher? Gibt es positive Auswirkungen auf Zusammenarbeit und Vertrauen? Spätestens, wenn es nur noch darum geht, Schuldige zu finden: Vermutlich nein.

Das Problem ist nicht nur die Asymmetrie der Informationen, also dass nicht jeder Person zu jedem Zeitpunkt die selben Fakten vorliegen. Dazu kommt, dass Menschen keine Automaten mit kausal-mechanischem Verhaltenden sind. Jeder Mensch filtert die Fakten und baut sich dadurch seine eigene Realität der Dinge. Dazu kommt, dass diese Fakten auf Basis der bisherigen Lebenserfahrungen bewertet und transformiert werden. Gleichzeitig wird die Lebenserfahrung durch neu erlebtes verändert. Werden die gleichen Fakten oder Situationen noch einmal wahrgenommen, kann es also passieren, dass diese nun zu einem ganz anderen Bewerten und daraus resultierenden Verhalten führen.

Hier wird auch von einer systemisch-konstruktivistischen Perspektive bzw. in der Systemtheorie von Komplexität gesprochen. Der Unterschied zwischen komplexen und einfachen bzw. komplizierten Zusammenhängen ist der, dass komplexe Verhaltensweisen (praktisch) nicht vorhersehbar sind, da es zu viele sich gegenseitig beeinflussende Faktoren gibt, die potentiell selbst neue (Problem-)Faktoren erzeugen können.

Wir also für ein komplexes Problem eine vermeintliche Kausalkette beobachtet, so kann sich diese bei der nächsten Beobachtung unvorhersehbar verändern. Eine Analyse mit der 5-Why-Methode, deren erfolgreiche Anwendung von festen Kausalketten abhängig ist, kann hier also nicht zweckmäßig sein.

Warum-Fragen schaffen Problemträger

„Warum” zu fragen führt uns rein sprachlich schnell auf Abwege. „Warum machst du das?” „Das mache ich, weil…” Damit landen wir schnell in einer Situation, in der wir uns plötzlich verteidigen und rechtfertigen müssen. Der Gefragte fühlt sich als Problemträger adressiert. Keine gute Grundlage, um Problemlösungen anzugehen, geschweige denn kreativ und kollaborativ.

Eine besseres Fragewort wäre „Wofür”. „Wofür machst du das?” „Ich mache das, damit…” Zwar zielt das „Wofür” ebenfalls auf das Verhalten der Person ab, wird aber durch den Fokus auf den Zweck bzw. das Ergebnis (das „Damit”) entpersonalisiert. Durch den fehlenden Problemträger wird auch das vermeintliche Problem entpersonalisiert. Eine gute Grundlage, um auf der Faktenbasis (statt auf der Beziehungsbasis) an der Problemlösung zu arbeiten.

Warum-Fragen führen auf Umwege oder nirgendwohin

Warum-Fragen führen auf unnötige Umwege und sind nicht ergebnisorientiert. Sie lassen uns immer weiter in den Problemraum abdriften. Emotionen und (unterschwellige) Schuldzuweisungen nehmen zu. Das kostet viel Zeit, Energie und Motivation.

Stattdessen sollte vom eigentlich gewünschten Ergebnis aus gedacht werden: „Was wollen wir stattdessen?” oder „Wofür brauchen/wollen/machen wir das?” Das folgt dem Lean-Prinzip, Arbeitsweisen vom Ergebnis (Outcome) aus zu denken und zu verbessern. Problemwissen, das für die Lösung notwendig ist, wird ganz von allein aufkommen. Wichtig: Nicht wieder zu sehr in den Problemraum abdriften lassen. Ein Coach oder Facilitator kann (insbesondere bei Gruppen oder Teams) diesen Prozess unterstützen.

Unterschiedliche Perspektiven erlauben, erkennen und nutzen

Beim ersten Beispiel mit dem nicht startenden Auto könnten wir mit mehreren Kfz-Experten die 5-Why durchgehen, sie würden in der Mehrheit zum selben Schluss kommen. Geht es aber um das Projekt-Beispiel, bei dem menschliches Verhalten involviert ist, könnten wir mehrere Personen fragen: Es kommt fast immer etwas anderes dabei heraus.

Das Beispiel des Projekts, dessen Fertigstellungstermin nicht eingehalten wurde, zeigt, dass es mehrere Perspektiven gibt, aus der die Situation betrachtet werden kann. Der Guardian hat 1986 eine Werbung geschaltet, die das wunderbar verbildlicht:

Bei der Bearbeitung komplexer Probleme muss also allen Beteiligten bewusst sein, dass:

Jeder das Problem anders wahrgenommen hat und in seiner „eigenen Realität” lebt
Informationen unter den Beteiligten asymmetrisch verteilt sein können („Ich weiß nicht, was du nicht weißt”)
Verhaltensweisen aufgrund der bisherigen Lebenserfahrungen und jetzigen Lebens- und Arbeitsumstände von außen nicht immer rational sind oder erscheinen
Verhaltensweisen nicht auf den eigentlichen Charakter einer Person hinweisen („Ich bin ein Teil von jener Kraft, die stets das Böse will und stets das Gute schafft.”)

Für die Bildung von Vertrauen und Empathie kann das persönliche Erleben einer Situation bzw. die Schilderung des Problems von allen Beteiligten — möglichst ohne Unterbrechung und Stellungnahme anderer — geschildert werden.

Aber Vorsicht: Das Ausleuchten des Problems in der Vergangenheit kann zusätzliches Leiden verursachen und kostet Kraft, die für die Problemlösung benötigt wird. Der Fokus sollte daher nicht auf der Untersuchung des Problems liegen, sondern auf der Erarbeitung einer Lösung. Die unterschiedlichen Perspektiven können hier nützlich sein, wenn sie mit konstruktiven Fragen kombiniert werden.

Konstruktive Fragen

Die Problemlösung kann durch konstruktive Fragen unterstützt werden:

Was wollen wir statt dem Problem (konkret in einem bestimmten Kontext)?
Wer kann uns dabei unterstützen?
Welche Hindernisse gibt es?
Was sind wir bereit, für die Lösung zu investieren?
Was wäre ein erster Schritt, was ein zweiter?
Wer macht was?
Wann treffen wir uns wieder, um über die Lösung zu sprechen (und ggf. den Plan anzupassen)?

Fazit

Wie alle Werkzeuge ist die 5-Why-Methode weder „gut” noch „schlecht”. Abhängig vom Kontext (kompliziert oder komplex) sind Warum-Fragen entweder nützlich oder unbrauchbar. Die Säge eignet sich nicht gut für das hämmern von Nägeln, auch wenn es der ein oder andere vielleicht doch versucht. Es muss also klar werden: Was habe ich vor mir? Einen Nagel oder ein Stück Holz? Kompliziert oder komplex? Dann wähle ich das passende Werkzeug.

Mahara Hui 2017

Mon, 04 Dec 2017 10:45:00 +0000

„Agile Learning Culture for Success” war das Motto der 5. Mahara Hui, die Fachtatung für Portfolioarbeit im Barcamp-Format vom 30. November bis 2. Dezember. Mahara ist eine Open-Source-Software für E-Portfolios, die insbesondere von Schulen und Universitäten, aber zunehmend auch von Unternehmen benutzt wird. „Hui” ist Maori und bedeutet so viel wie „Zusammenkunft”. Bei dieser Zusammenkunft ging es nicht nur um die Mahara-Software selbst, sondern allgemein um das Thema Lernen heute und in der Zukunft und wie zeitgemäße technische und organisatorische Ansätze nützlich sein können. Ausgerichtet wurde das Barcamp von Lpaso, dem Institut für Lernkultur in den Räumlichkeiten der Max-Eyth-Schule Kassel.

Tag 1

Nach kurzer Suche fanden meine Arbeitskollegen von plentymarkets und ich die Anmeldung im 1. OG der Max-Eyth-Schule. Alles verlief entspannt und problemlos. Für Kaffee und Donuts war gesorgt. So kann es gern starten.

Technologieunterstütztes Lehren und Lernen

Das Barcamp begann am Samstagmorgen mit einer Keynote von Dr. Thomas Strasser, Professor für Fremdsprachendidaktik und technologieunterstütztes Lehren und Lernen an der Pädagogischen Hochschule in Wien. Hier ging es darum, wie Smartphones und Apps nutzbringend in den Schulunterricht integriert werden können, statt dies zu verteufeln und zu verbannen. Unter anderem war dabei die Live-Demo von Aurasma interessant. Mit der App lassen sich mittels Augmented Reality Videos und andere Inhalte in der realen Welt „verstecken”, egal ob in Schulbüchern oder im Museum. Diese können darauf von den Schülern interaktiv entdeckt werden.

Kritisch sehe ich an solchen Entwicklungen, ähnlich wie in Unternehmen, dass mit dieser „Tool-Geilheit” die eigentlichen Probleme mit scheinbar einfachen Lösungen übertüncht werden. Im komplexen Umfeld, wie es ein Klassenraum mit Lernenden wohl ist, können solche Tools immer nur ein Begleiter und Unterstützter sein und ersetzen nicht eine gute pädagogische und didaktische Grundlage und Vorbereitung.

Vorstellung und Agenda

Es folgte die Vorstellung der insgesamt etwa 150 Teilnehmer. Die allermeisten Besucher stammten aus dem Bildungswesen. Meine Kollegen und ich waren einer der wenigen Vertreter aus der Wirtschaft. An der Reaktion der Teilnehmer war zu erkennen, dass wir auf dieser Konferenz die Wundertiere sein würden.

Die gemeinsam erstellte Agenda umfasste neben dem Hauptthema Mahara die Themen Digitalisierung, Industrie 4.0, Lern-Tools, Agile (insbesondere eduScrum) und Veränderungsarbeit im und am Schulsystem. Ich konzentrierte mich an diesem Tag auf die Themen Digitalisierung und Industrie 4.0 (trotz vermeintlichem Buzzword-Hagel) und eduScrum.

Digitalisierung und Industrie 4.0

Die Session stellte die Frage, wie sich Angebote der berufsbildenden Schulen für Vertreter aus Handwerk und Industrie inhaltlich an die Verwerfungen durch die sogenannte Digitalisierung und Industrie 4.0 anpassen müssen. Ausgangspunkt war ein Schulungskonzept, das versucht, die Industrie in verschiedene Segmente zu Unterteilen, beispielsweise Konstruktion, Teilefertigung, Montage usw. Je Segment sollten User Stories entwickelt werden, die in einer „Geschichte” auf die jeweiligen Besonderheiten eingeht. Story Telling ist hier sicher ein guter Ansatz. Rückblickend frage ich mich aber, ob diese segmentäre Trennung nicht das Silodenken innerhalb der Industrie unterstützt und den holistischen Ansatz, den die Industrie von Morgen sicherlich braucht, ignoriert. Damit meine ich, dass die „Fabrik von morgen” weitgehend unabhängig von Zulieferern sein und kurze Feedbackschleifen von der Konstruktion hin zum Kunden besitzen muss, um das Lernen und das Anpassen von Fertigungsprozessen an die Marktbedürfnisse zu beschleunigen. Ganz agil halt.

Jedoch sind sind wir thematisch schnell abgedriftet und haben vor allem die Eigenschaften diskutiert, die Mitarbeiter in einer „digitalisierten Welt” mitbringen müssen. Für mich stellt sich hier vor allem das Problem, dass die einfachen Arbeiten, die von Maschinen erledigt werden können, wegfallen werden. Übrig bleiben nur noch die schwierigen Aufgaben, die Meisterschaft verlangen. Meiner Meinung nach müssen Schulen und berufliche Bildung dabei helfen, genau solche Menschen hervorzubringen. Bei der betriebliche Ausbildung von Azubis kann es dann nicht mehr (nur) darum gehen, die einfachen Handgriffe zu vermitteln, sondern zukünftige Meister ihres Fachs heranzuziehen. Das erfordert vor allem von den Ausbildern und Handwerksmeistern ein ganz anderes Skill-Set, nämlich über das rein fachliche Können hinaus Fähigkeiten im (Lern-)Coaching. Dazu kommt, dass Mitarbeiter zukünftig wohl mehr in interdisziplinären Teams arbeiten müssen, um gemeinsam exzellente Gesamtlösungen zu erstellen. Das erfordert vom Mitarbeiter Wissen aus der jeweils anderen Disziplin. Die Mitarbeiter müssen also T-geformt ausgebildet werden und bleiben. Das führt automatisch zu einer T-transformation der Ausbildung, weg von monothematischen Ausbildungsberufen hin zu Schwerpunktberufen. Wie da der aktuelle Stand der Überlegungen ist, weiß ich momentan leider nicht. Ist aber ein spannendes Feld!

Damit gab die Session einen Vorgeschmack auf die Themen, die Gunther Dueck mit seiner Keynote des nächsten Tages provozieren sollte.

Ubongo Flow Game

In meine eigenen Workshops integriere ich immer wieder Spiele, um den Teilnehmern bestimmte Kernpunkte zu verdeutlichen. Die Theorie zu kennen und zu verstehen ist das eine. Sie in der Praxis und mit eigenen Händen wirklich zu erleben, ist etwas ganz anderes. So werde ich immer neugierig, wenn ich von Agile Games höre, die ich noch nicht kenne.

Das Ubongo Flow Game simuliert drei Workflows: Wasserfall, Kanban und Scrum. Die Basis stellt der Spieleklassiker Ubongo dar.

Im ersten Durchlauf werden feste Rollen verteilt: Auftraggeber, Analyst, Lieferant, Entwickler, Protokollant und Manager. Der Auftrag ist, ausgehend von einer Spielkarte eine Puzzle-Platte mit einem bestimmten Muster zu finden und dieses Muster anhand der Vorgaben nachzubauen. Dabei werden die Puzzle-Platten in 6er-Paketen in den Prozess gegeben, wobei das Paket immer nur als Ganzes in den nächsten Arbeitsschritt (z.B. Analyse) gelangen darf. Das sollte den klassischen Wasserfall-Prozess darstellen. Wie früh abzusehen war: Wir bekamen massive Zeitprobleme und letztendlich war nichts wirklich fertig.

Für den zweiten Durchlauf blieben die Regeln gleich, es sollten jedoch Arbeitspakete in Größe „1” weitergegeben werden, statt in 6er-Paketen. Gleichzeitig wurde vor jedem Prozessbeteiligten ein Puffer von maximal zwei Arbeitspaketen geschaffen. Das sollte die Lean-Prinzipien „Small Batch Size” und „Limit Work in Progress” simulieren. Damit konnten wir tatsächlich ein paar Puzzle komplett fertigstellen. In dieser Runde war ich Entwickler und hatte beim Puzzeln sogar einen Flow-Moment. Interessant war, dass selbst diese kleine Regeländerung trotz unveränderter Rollen schon einen großen Unterschied gemacht hat.

Wo der zweite Durchlauf noch eher evolutionäre Veränderungen brachte, wurde es im dritten Durchlauf revolutionär anders. Die Rollen Entwickler, Zulieferer und Analyst wurden alle zum „Entwickler” zusammengefasst. Diese arbeiteten nun gemeinsam ohne äußerlich definierte Prozessschritte in kurzen Iterationen. Unterbrochen wurde das Puzzeln von Retrospektiven, in denen wir unsere Vorgangsweise hinterfragten und ggf. anpassten. Durch die bessere Arbeitsteilung und Konzentration aufs „fertig werden” erzielten wir hier die mit abstand besten Ergebnisse.

Wie gut ist das Ubongo Flow Game? Natürlich tilgt so ein Spiel viele für die Praxis notwendigen Details. Auch fehlte mit den relativ klaren Vorgaben der Ubongo-Puzzle der komplex-kreative Aspekt, den Lego-Simulationen wie das Scrum Lego City Game oder das Walking Skeleton Game vermitteln können. Jedoch war der Aha-Effekt, der bei der Gegenüberstellung von Wasserfall, Kanban und Scrum entstehen soll, gegeben. Und das in relativ kurzer Zeit und mit wenig Aufwand. Daher vielleicht gut geeignet, wenn wenig Zeit oder Platz da ist oder der Transport von Lego zu aufwendig wäre.

Eine genaue Anleitung zum Nachspielen gibt es auf teamworkblog.de.

eduScrum

Nach einer guten Portion Chili con Carne in der Kantine der Max-Eyth-Schule ging es zum eduScrum-Workshop. Willy Wijnands, der eduScrum auf der Grundlage des ScrumGuides entwickelt hat, stellte gemeinsam mit Schülern aus den Niederlanden das auf Selbstorganisation beruhende Lern- und Lehr-Framework vor. Dabei ging er zunächst auf die Werte und Prinzipien ein, die hinter eduScrum stehen. Diese Dinge waren für ihn besonders wichtig:

Die Schüler müssen vermittelt bekommen, warum (ich glaube eher er meinte „wofür”) die Schüler etwas lernen
Lernen zum Teamerfolg machen, was Ellbogen-Mentalität vorbeugen soll
Um im Team Lernergebnisse zu schaffen, braucht es Vertrauen, offene Kommunikation (und Konflikte), Selbstverpflichtung und Übernahme von Verantwortung

Für Schüler, die aus dem klassischen Frontal-Unterricht in so eine Umgebung geraten, ist so ein Wechsel vielleicht gar nicht so einfach.

Darauf haben wir in kleinen Teams ein „Flip” gebaut, was in eduScrum so etwas wie der Sprint Backlog ist, verschmolzen mit einer Team-Charter.

Leider war die Zeit für den Workshop recht knapp bemessen, vielleicht war der „Overload” aber auch gewollt. Ich denke, um alles zu verstehen, benötigt es sogar mehr Zeit als ein regulärer Scrum-Workshop. Das ist meiner Meinung nach auch deshalb so, weil eduScrum mit zusätzlichen Regeln ein engeres Korsett mitbringt als Scrum selbst. Ob Kinder hier mehr Regeln brauchen? Darüber lässt sich nachdenken. Bei mir hat es beim Mitmachen eher mehr Fragen und „falsches” Verhalten provoziert.

Details zu eduScrum und der eduScrum Guide finden sich auf der dazugehörigen Website.

Tag 2

Einige Teilnehmer schienen noch müde vom gemeinsamen Dinner am Vorabend zu sein. Ich konnte leider nicht teilnehmen, vielleicht beim nächsten Mal. Muss gut gewesen sein.

Bewaffnet mit Kaffee und Donuts setzten wir uns schon einmal in den Keynote-Raum, um auf Gunther Dueck zu warten. Ich hatte ihn kurz vorher schon an der Garderobe getroffen, hatte mich aber in einem Anfall von teenagerhaftigem Idol-Respekts nicht getraut, ihn persönlich zu begrüßen. Nun gut.

Shift Happens

Wer Gunther Dueck nicht kennt, den verweise ich auf die zahlreichen YouTube-Videos. Seine Vorträge bedienen sich aus einem großen Fundus interessanter und bedeutungsschwangerer Inhalte, die vor allem aus seinem Blog und seinen Büchern stammen. Der Fokus sollte auf dem Thema „Core Competence Shift (Happens)” liegen. Hierbei stellt er fest, dass zukünftig durch technologischen Fortschritt (nennen wir es vorsichtig „Digitalisierung”) Jobs teilweise oder ganz wegfallen. Wer noch arbeiten möchte oder kann, der muss ein ganz anderes Skill-Set mitbringen, was sich vor allem auf die Soft-Skills und People-Skills” bezieht: Empathie, Beziehungen herstellen und pflegen, Projekte organisieren, Kreativität, hohe Lernbereitschaft, Gesamtlösungen herstellen, Storytelling usw.

Gunther Dueck versteht es, seine Themen erzählerisch und mit Humor vorzutragen. Heute sollte es nicht anders sein. Er ging vor allem auf die Unterschiede zwischen Menschen ein: Es gibt Hunde und Katzen. Diese Unterschiede führen oft dazu, dass in Sachen Innovation und dringend notwendiger Veränderungen am Ende gar nichts passiert. Grund: Hund und Katze verstehen sich nicht. Katzen sind in der Unterzahl, besitzen aber die zukünftig vermehrt notwendigen Fähigkeiten. Die Katzen wollen etwas ändern, aber die Hunde sind an der Macht. In der Zwickmühle sitzen wir.

Quintessenz des Vortrags: Wir müssen endlich nicht nur überlegen (die Ideen sind jetzt da), wir müssen ins Machen kommen! Für die Anwesenden bedeutete das vor allem: An Schulen und im Schulsystem konkrete Veränderungen schaffen.

Nach dem Vortrag trafen wir uns noch einmal in einer kleineren Gruppe mit Gunther Dueck, um Fragen zu diskutieren. Hier konnte ich mitnehmen bzw. ich fühle mich darin bestätigt, dass wir bei Innovation und Veränderungsarbeit immer auch die Leute in ihrer jetzigen Rolle wertschätzen und ihre Sprache kennenlernen müssen. In fast allen Fällen führt das zu Win-win-Situationen und im allerbesten Fall wird ein neuer Mitstreiter gewonnen.

Fazit

Im Bildungswesen stellen sich die gleichen Fragen wie in der Wirtschaft: Was muss verändert werden, um auf eine sich immer schneller verändernde Umwelt zu reagieren? Wie gehen wir mit Unsicherheit um? Wie stellen wir sicher, dass der „Kunde” (die Gesellschaft?) stets das passende Produkt (den ausgebildeten Schüler, was auch immer das genau bedeutet?) erhält?

Für mich ergibt sich dadurch die Aufgabe und moralische Pflicht, dass die Wirtschaft (und andere Vertreter der Gesellschaft) viel enger mit dem Bildungswesen (vor allem den Schulen und Bildungsinitiativen vor Ort) zusammenarbeiten muss. Im Moment kommt es mir eher so vor, als gibt es ein allgemeines und wenig lösungsorientiertes Bildungs-Bashing. Ich bin selbst Ausbilder und bekomme vor allem mit, dass sich Unternehmen beim Sprechtag bei der Schule beschweren, statt lösungsorientiert mitzuwirken. Damit das gelingt, sind Initiativen von beiden Seiten gefordert. Zukünftig sollten auf solchen Konferenzen auch viel mehr Vertreter aus der Wirtschaft (und anderen Teilen der Gesellschaft) vertreten sein, um die Außensicht reinzubekommen. Das große Problem an solchen Konferenzen ist ja, dass hier „im eigenen Saft geschmort wird”. Die, die für die Lösung gebraucht werden, sind irgendwo anders.

Das Mahara Hui 2018 findet wohl in Wien statt. Ich versuche dort zu sein!

Impressionen finden sich unter #mahEU17.

1. Norddeutsches ScrumMaster-Gathering in Hannover

Sat, 25 Nov 2017 11:43:00 +0000

Am 24.11.2017 habe ich das 1. Norddeutsche ScrumMaster-Gathering in Hannover besucht. Das ScrumMaster-Gathering ist eine Unkonferenz im Open-Space-Format.

Teilnehmer

Es gab ca. 30 Teilnehmer, was für eine Erstauflage ordentlich ist. Anwesend waren nicht nur ScrumMaster, sondern auch einige Agile Coaches und andere, die sich im agilen Kontext bewegen oder zukünftig bewegen wollen. Auffällig war für mich, dass zunehmend Mitarbeiter größerer Unternehmen und Konzerne auf solchen Events anzutreffen sind. Auch die Zahl von Vertretern der Versicherungs- und Bankenbranche nimmt gefühlt zu.

Agenda

Thematisch war die Agenda gut gemischt. Auch hier viel auf, dass viele Pain Points großer bzw. vom klassischen Management geprägten Unternehmen auftauchten, wie beispielsweise „Agile at Scale”, „Agilität vs. individuelle Mitarbeiterziele” und „Agile einführen”. Ich konzentrierte mich auf die Themen:

Wie nähert man sich dem Thema Agilität?
Agile Werte (mit der Frage, wie sich daraus ein Workshop entwickeln lässt)
Zusammenarbeit zwischen ScrumMaster und Personalverantwortlichen

Thema: Wie nähert man sich dem Thema Agilität?

Hier tummelten sich mehrere Grundfragen. Wie lässt sich das Thema Agilität den Mitarbeitern vermitteln? Hier waren wir uns einig, dass zunächst der Zweck und Nutzen von Agilität klar sein muss. Dem sollte die aktuellen Vorgehensweisen und die daraus resultierende Kultur möglichst gut visualisiert gegenübergestellt werden. Wie lässt sich auf „agil” umstellen? Entweder über eine Hybrid-Struktur aus klassisch und agil, bei der der agile Anteil sukzessive hochgefahren wird. Oder ad hoc durch die Änderung der Unternehmens-Architektur à la Pfirsich-Modell Niels Pfläging.

Was mir bei Diskussionen auf solchen Konferenzen missfällt ist der laxe Umgang mit unscharfen Begriffen wir „Agilität”, „Scrum”, „ScrumMaster”, „Product Owner” usw. Jeder Diskussionsteilnehmer hat hier seine eigenen Bilder, die sich auf Nachfrage teilweise stark voneinander unterscheiden. Auch scheint nicht immer jedem klar zu sein, für welche Umgebungen Frameworks wie Scrum nützlich sind. Manchmal wird davon gesprochen, „Scrum im gesamten Unternehmen einzuführen”, was dann zu starken Konflikten führt. Es wird kaum über Systeme und die Erfordernisse des Kontexts, in dem sie sich bewegen, gesprochen. Stattdessen wollen die Teilnehmer möglichst viele neue „Methoden”, „Best Practices” und „Tools” mitnehmen. Vielleicht reicht für tiefere Diskussionen auch nicht die Zeit.

Auch wird oft beklagt, dass die „normalen” Mitarbeiter ihr „Mindset” geändert bekommen müssen, bevor mit Agile durchgestartet werden kann. Ein wenig wie Gehirnwäsche. Aber ist das Mindset nicht erst das Resultat von einem Lernprozess, der aus der Arbeit mit den Vorgehensweisen entsteht und muss deshalb garnicht im Fokus stehen? Die Mitarbeiter sind ja auch nicht mit ihrer aktuellen geistigen Haltung geboren worden, sondern haben sich (vermutich auch ohne große PR-Kampagnen) an die Umstände angepasst. Wer sagt, dass sie es nicht wieder tun werden?

Thema: Agile Werte

Dem Initiator des Themas ging es grundsätzlich darum, einen Workshop zum Thema „agile Werte” zu gestalten. Gemeint waren die Werte aus dem Agilen Manifest und aus dem Scrum-Guide. Die Absicht dabei ist wohl, den Mitarbeitern das Fundament von von Agile zu vermitteln, das auf bestimmten Werten beruht, wie die Scrum-Werte „Selbstverpflichtung”, „Mut”, „Fokus” und „Offenheit”. Workshops zu diesem Thema zu machen finde ich schwierig. In meinen eigenen Scrum-Workshops gehe ich ebenfalls auf die Werte ein und begründe es damit, dass sie viele Fragen zum Thema Scrum mit diesen beantwortet werden können. Was mich bei den Scrum-Werten stört ist, dass sie sich als absolut darstellen, keine Abgrenzungen bieten bzw. nur schwer konkrete Handlungsoptionen ableiten lassen. Ich vermisse hier eine Unterscheidung bzw. Gewichtung, wie es das Agile Manifest macht:

Through this work we have come to value:

Individuals and interactions over processes and tools

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Ich wünschte mir hier so etwas wie:

…we have come to value:

Commitment over…
Courage over …
Focus over …
Openness over …

Vielleicht Stoff für einen zukünftigen Artikel :-)

Thema: Zusammenarbeit zwischen ScrumMaster und Personalverantwortlichen

Ein spannendes Thema, was uns auch immer wieder bei plentymarkets beschäftigt. Wir haben uns gegenseitig unterschiedliche Modelle vorgestellt, die ich teilweise stark voneinander unterschieden. In großen Unternehmen und Konzernen herrscht ein hierarischer Dschungel. In kleinen und mittleren Unternehmen haben beispielsweise Scrum-Teams fast immer einen Teamleiter oder „agilen Projektleiter” – was immer das im Einzelfall bedeutet.

Ich frage mich aktuell, warum es überhaut den Personalverantwortlichen geben muss. Für mich ist „Personalverantwortlickeit” ein Set von Aufgaben und Arbeitsergebnissen, die von der Organisation für bestimmte Zwecke gefordert werden. Dabei habe ich ca. 12 Bausteine entdeckt, die sich meiner Meinung nach auf Rollen verteilen lassen und von Mitarbeitern innerhalb und außerhalb des Teams übernommen werden können.

Fazit

Das alles klingt jetzt irgendwie negativer, als es tatsächlich war. Tatsächlich konnte ich einige neue Impulse mitnehmen. Am wertvollsten war für mich die Gelegenheit zur Reflexion über meine aktuellen Interventionen und Projekte. Auch habe ich ein paar neue Gesichter aus der Agile Community Hannover und der Region kennengelernt, welche bisher ein blinder Fleck für mich war. Im nächsten Jahr werde ich mich sicher einmal beim Agile Wednesday Hannover blicken lassen.

Die Organisation des Events war tadellos, die Location bei tecRacer sehr angenehm und die von Arvato E-Commerce gesponsorte Verpflegung tadellos.

Ich komme also gerne wieder und bringe sicher noch jemanden mit!

Impressionen sind unter #1smgh zu finden.

Is X Allowed in Scrum?

Fri, 04 Aug 2017 16:35:00 +0000

Great Scrum Teams continuously improve their way of working. Sooner or later the team asks itself: Is this “allowed” in Scrum? Or: Is it “compatible”?

This is a decision that the Scrum Master should facilitate. But especially for new Scrum Masters this question is often a tough one.

The Scrum Guide says:

Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques.

And:

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

In short: Adding something is okay, removing not. But out in the wild its often not that easy. The answer is often: ”It depends.” It can help the team to ask itself the following three questions.

1. Does It Reduce Our Ability to Inspect and Adapt?

The power of Scrum and Agile is the ability to respond to changing conditions quickly. This is getting more useful in contexts with high uncertainty in means of requirements or technology.

With this in mind: Does the proposed change reduce the ability to inspect and adapt? Here some examples.

Reduces ability to inspect and adapt:

Getting rid of
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
- Backlog Grooming

Why? Each of these events is a point to stop, check the current situation and react accordingly.

Increases ability to inspect and adapt:

Collaboration with the Product Owner on a daily basis
Invite users to user acceptance tests
Test Driven Development
Continuous Integration

Why? Each of those shortens the feedback cycle, so we have the information to act upon earlier.

2. Does It Serve the Scrum Framework or Adds It to Distraction?

The Scrum framework itself is lightweight and easy to understand. It should support the team in conducting their work as a team. By adding something to the framework, ask yourself: Will it serve the framework as a whole? Or will it add distraction? If distraction is added, the team may loose focus on what is most important: Deliver working software frequently to generate feedback. Here, too, some examples.

Does not serve the Scrum Framework, increases distraction:

Complicated collaboration software
No collocation or working remote
Excessive customer integration can become a disturbance to developers
Extending the timebox of the Daily Scrum
Hand-offs (even within the team, ”Mini Waterfall”)

Does serve the Scrum Framework, reduces (or does not add to) distraction:

Visible Definition of ”Done” beneath the task board: Clear focus on what’s ready or not.
Sticky notes on the door indicating time and place of the Scrum events: No asking around, no calendar software that needs to be kept up to date.
Poster with action items from the last retrospective beneath the coffee machine: Reminder for your commitments while you’re not focussed on the Sprint’s work.
Colocation: No collaboration software to tinker with.
Dedicated team room: Reduces organisational overhead and provides a save place.
Deployment checklist: A step by step guide to deployment prevents headache.

3. If We Do It, When Will We Inspect and Adapt?

However, all this is specific for the team’s context at hand. If the Scrum Team decides to add or remove something to their way or working and it doesn’t violate any given constraints of sef-organisation, it can do so. But it’s their responsibility to take over responsibility for the change, inspect the results at a given time and adapt accordingly. So the last question would be: If we do it, when will we inspect and adapt?

No Product Owner, No Sprint Review?

Fri, 04 Aug 2017 12:51:00 +0000

Sooner or later a Scrum Team finds itself in the situation that the Product Owner is not available for the Sprint Review. They ask themselves what to do: Reschedule the Sprint Review? Or just skip it?

Rescheduling the Sprint Review

The Sprint Review can be rescheduled if the Product Owner would be available sometime soon, like on the same day or the next day.

Scrum Events should take place on the same time and same place, to reduce organisational overhead. Everyone should keep this in mind. Rescheduling should be an exception. Especially if rescheduling the Sprint Review leads to rescheduling all following events like the Sprint Retrospective and the Sprint Planning.

Skipping the Sprint Review

What happens if the Scrum Team just skips the Sprint Review? The Scrum Guide says:

[E]ach event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

The Sprint Review is the time and place to inspect the “Done” Increment to generate feedback for the further product development. If you miss this “opportunity to inspect and adapt”, it can cost you dearly.

Alternatives

What could be better alternatives to rescheduling or skipping the Sprint Review? Here are some suggestions.

Decouple from the Sprint Review

A Scrum Team shouldn’t depend completely on the Sprint Review to generate feedback for the product. The Agile Manifesto says:

Business people and developers must work together daily throughout the project.

Means that the Product Owner (or even stakeholders) should work with the team on a day-to-day basis and provide feedback continuously. By doing this the Sprint Review’s topics shift from using the software to working on product strategy. The whole Scrum Team gets a shared understanding where the product needs to go. That leads to appropriate decisions, even if the Product Owner isn’t available.

However, this doesn’t make the Sprint Review obsolete. It just reduces the blow radius of a Sprint Review that doesn’t take place or if the Product Owner can’t attend the meeting.

Go Remote

Okay, so the Product Owner isn’t there. But maybe he can join the Sprint Review via phone call or video conference software? The latter enables visual presentation or even using the software remotely by sharing mouse and keyboard input.

If you have stakeholders that wish to join the Sprint Review, make sure everyone has the same experience and ability to provide feedback.

Hallway Sprint Reviews

As a equivalent to hallway usability testing the Scrum Team can invite specific or even random people to its Sprint Review. This can be appropriate if else there would be no one present except the Development Team, not even stakeholders. Guests should use the software and asks questions to the Development Team. Any feedback is better than no feedback.

You will even be surprised what people come up with. Inviting random people can be a refresher for any Scrum Team’s Sprint Review. Try it!

The Scrum Master’s Responsibilities

However, this alternatives are addressing the symptom, not the cause of the problem. If the Product Owner is regularly unavailable, in the Sprint Review or throughout the Sprint, it’s the Scrum Master’s responsibility to work with the Product Owner and the rest of the organisation to find a appropriate solution. How this can be done, is another matter. But both the Product Owner and other persons in charge should be made clear that any lost opportunity to inspect and adapt can mean serious harm to the product and customer satisfaction and therefore a harm to the company as a whole.

Agile Building Games @ Spartakiade

Sun, 26 Mar 2017 16:57:00 +0000

Die diesjährige Spartakiade in Berlin war ein gelungenes Event. Gefühlt reibungslose Organisation, angenehme Teilnehmer und Teilnehmerzahl. Viele und abwechslungsreiche Workshops. Und – da hat sich das Schwärmen von Matthias Seul bewahrheitet – sehr gutes, reichliches und abwechslungsreiches Essen und Getränke. Laut Torsten Weber, einer der Organisatoren, einer der wichtigsten Eigenschaften der Spartakiade und vergleichbarer Events. Denn Essen und Trinken hält schließlich Leib und Seele zusammen und stärkt während der intensiven Workshops die „Truppenmoral”. Auch die Location war mit der Immobilien Scout GmbH gut gewählt. Gut aufgeteilte Räumlichkeiten und abwechslungsreiche Rückzugsmöglichkeiten.

Was vorher geschah

Ich bin eher zufällig zur Spartakiade geraten. Matthias hatte sich ursprünglich für zwei Workshops am Samstag und Sonntag zur Verfügung gestellt. Matthias ist immer viel unterwegs. Durch eine Änderung in seinem Terminkalender konnte er leider nur noch den Workshop am Samstag durchführen. Kurzerhand meldete sich Matthias mit der Frage bei mir, ob ich den Workshop am Sonntag nicht übernehmen könne – nicht ohne mich mit den guten Rahmenbedingungen der Spartakiade in Verführung zu bringen.

Für den Samstag hatte Matthias einen ganztägigen Workshop zum Thema LEGO Serious Play vorgesehen. Für den Sonntag war ein Workshop geplant, der neben einer erneuten Einführung in das Thema LEGO Serious Play auch einige Agile Games mit LEGO enthalten sollte. In meinem Terminkalender sprach nichts dagegen, den Workshop am Sonntag zu übernehmen. Gleichzeitig nehme ich gern jede Gelegenheit wahr, meine Fähigkeiten als Trainer und Facilitator zu verbessen. Also sagte ich direkt zu.

Matthias und ich trafen uns wenige Tage vorher, um noch ein paar Dinge durchzugehen. Die drei Agile Games LEGO Minimum Viable Product (MVP) Game, LEGO Product Owner Challenge und LEGO Walking Skeleton Game hatte ich bereits als Teilnehmer erlebt. Ebenso eine Grundeinführung zum Thema LEGO Serious Play durch Matthias. Doch letzteres hat eine gewisse Tiefe, insbesondere was Ablauf und Facilitation angeht, sodass ich mir vor allem hier noch eine Menge Input von Matthias abholen konnte. Matthias ist Certified LEGO Serious Play Facilitator.

Nach der Anreise Freitag Abend fielen wir nur noch geschafft ins Bett, um fit für den nächsten Tag zu sein. Matthias hatte eine längere Anreise und Termine hinter sich. Ich selbst hatte am selben Tag auf dem plentymarkets Online-Händler-Kongress in Kassel einen Vortrag zum Thema „Schneller zum richtigen Produkt durch Kundenfeedback” gehalten und war von dort direkt nach Berlin gekommen. Das Get-together der Trainer in der Volkskammer, das wir ursprünglich noch besuchen wollten, viel damit für uns flach.

Erster Workshop-Tag

Nach einem reichlichen Frühstück im Hotel machten wir uns recht früh auf zur Spartakiade. Unser Hotel war glücklicherweise keine zwei Minuten Fußweg entfernt. Matthias wollte die Zeit nutzen, um in Ruhe seinen Workshop vorzubereiten. Mit einem Koffer voller LEGO rollten wir zunächst zum Check-In, der dank eines ausgeklügelten Self-Service-Systems für alle Teilnehmer schnell und reibungslos verlief. An der „Wall of Fame”, direkt hinter dem Eingang, hingen die Bilder aller Trainer. Da es mein erstes Event als Trainer war, fand ich den „Fame” cool, aber auch etwas gewöhnungsbedürftig. Matthias zog es direkt in seinen Workshop-Raum, das „Spielzimmer” genannt. In diesem Raum spielen die Mitarbeiter von Immobilien Scout sonst Kicker. Der Raumname konnte für die nächsten zwei Tage kaum passender sein.

Mich hingegen zog es direkt zur Kaffeemaschine. Ich hatte an diesem Tag nichts konkretes geplant, bis auf dass ich meinen Workshop für den nächsten Tag zu strukturieren und tieferes über LEGO Serios Play zu erfahren. Matthias hatte mir dafür ein Arbeitsheft von seinem damaligen Facilitator-Training überlassen. Außerdem hatte ich vor, mich vormittags in den ein oder anderen Workshop zu setzen, von denen es ja reichlich interessante gab.

Doch wie es immer so ist, kommt alles anders als gedacht. Denn als ich bei Matthias vorbeischaute, der fleißig mit dem Sortieren und Zurechtlegen seiner LEGO-Teile beschäftigt war, viel uns etwas auf. Wir hatten doch nicht, wie ursprünglich von uns beiden gedacht, ausreichend Steine für das LEGO Walking Skeleton Game dabei. Oder anders gesagt wäre doch recht viel Improvisation durch die Teilnehmer notwendig gewesen, um mit den vorhandenen Teilen wie vorgesehen ein Haus aus LEGO zu bauen. Kurzerhand rief ich einen neuen neuen Punkt auf meine Vormittags-Agenda: Einen Besuch beim LEGO Store Berlin.

Ich sage es gleich: Es gibt schlimmeres, als LEGO kaufen zu müssen. Und ist es dann noch ein offizieller LEGO Store: Um so besser. Nach einer halbstündigen Fahrt mit der U-Bahn erreichte ich meinen Zielort und betrat mit einer gewissen Vorfreude das LEGO-Paradies. Ich hatte leider nicht so viel Zeit, um mir alles anzusehen. Daher ging es einigermaßen Zielstrebig zu einem der in mehr als ausreichender Anzahl vorhandener Store-Mitarbeiter, die mich sehr engagiert beim Kauf berieten. So hatte ich schnell ein paar mehr oder weniger passende Pakete LEGO zusammen, die für den Folgetag ausreichen sollten. Bevor es zurück zur Spartakiade ging, brachte ich das LEGO ins Hotel, und bereitete es entsprechend für den nächsten Tag vor.

War dann noch mal shoppen für morgen☺️ #spartakiade pic.twitter.com/4OioQzzNjA
— Thorben Egberts (@thorbenegberts) March 18, 2017

Auf der Spartakiade wurde zwischenzeitig der Grill angemacht und es roch sehr gut, als ich das Gebäude betrat. Wie erwartet war alles super lecker. Satt und gut gelaunt machte ich mich darauf daran, meinen Workshop für den nächsten Tag vorzubereiten. Gut versteckt in einem der Rückzugsorte, die das Gebäude von Immobilien Scout bot und unterstützt durch reichlich Kekse, Kaffee Cola (leider keine Premium Cola) und was es sonst noch alles gab.

Die Zeit verging während der Vorbereitung wie im Flug, sodass ich dann doch gar keine Workshops mehr besucht habe. Gegen 18 Uhr begann die Party. Dort trafen Matthias und ich uns wieder. Er erzählte mir von seinem Workshop. Die Teilnehmer spielten die Situation, ein neu gebildetes Team zu sein, das sich im Laufe des Tages findet, indem es sich selbst und ihre Beziehungen untereinander mit LEGO „baut”. Etwas konkreter wurden diese Fragen beantwortet: Wer sind wir jeweils? Welchen Prinzipien und Werten wollen wir folgen und welchen nicht? Das alles symbolisiert durch LEGO-Modelle, als sicht- und anfassbare Metaphern. Hier kam es zu regen und teils kontroversen Diskussionen. Das Feedback zu Matthias Workshop war sehr gut, was sich auch in Gesprächen mit Teilnehmern am nächsten Tag noch einmal bestätigte.

Wir blieben leider nicht sehr lange auf der Party. Matthias musste am nächsten Morgen schon sehr früh seinen Flieger erreichen. Ich selbst war auch noch ziemlich erschöpft von den letzten Tagen, in denen ich nicht sehr viel Schlaf bekommen hatte. So ging es wieder zurück ins Hotel. Rückblickend eine gute Entscheidung, denn so war ich am nächsten Tag recht frisch für meinen eigenen Workshop.

Zweiter Workshop-Tag

Nach einem entspannten Frühstück und dem Check-Out im Hotel ging es rüber zur Spartakiade. Ich war nun ganz gut vorbereitet, alle Materialien waren vorhanden, die Agenda stand. Nach einem kurzen Zurechtlegen der Materialien und Facilitation-Tools und der Vorbereitung einiger Flipchart-Poster konnte es dann losgehen. Dem Beginn der Workshops ging noch eine energiespendende Morgen-Ansprache durch die Organisatoren voraus. Dann trudelten die Workshop-Teilnehmer im Raum ein, insgesamt zehn. Gute Gruppengröße. Nach der Check-In-Runde wurde klar: Trotz dem zu erwartenden Entwickler-Überschusses bestand die Gruppe aus Teilnehmern mit ganz unterschiedlichen Hintergründen und Persönlichkeiten.

Einführung LEGO Serious Play

Im Gegensatz zu Matthias bin ich selbst kein ausgebildeter LEGO Serious Play Facilitator. So musste ich auf die Theorie zurückgreifen, die ich mir bisher aneignen konnte, um dennoch eine gute Vertretung darzustellen. Es ging für die Teilnehmer nun darum, zu einer offenen Frage Metaphern aus LEGO zu bauen. Die Frage war: „Wie sieht für dich das perfekte Produkt aus?” Die zur Verfügung stehenden LEGO-Steine waren bewusst ausgewählt und relativ begrenzt. Durch diese Begrenzung erreichten die Teilnehmer schnell den Punkt, an dem sie ins abstrakte Denken wechseln mussten. Im Kopf entstanden Bilder und Metaphern. Diese verwandelten sich über die Hände in LEGO-Modelle, die die anderen Teilnehmer anschauen konnten. Die individuellen Vorstellungen kamen so aus den Köpfen der Teilnehmer heraus in die greifbare Realität. Die anderen Teilnehmer stellten jeweils klärende Fragen zu den Modellen. Ein gemeinsames Verständnis entwickelte sich. Es war faszinierend zu sehen, wie kreativ und ideenreich die Modelle waren, die durch die Hände der Teilnehmer entstanden. Weitere Spielarten von LEGO Serios Play sehen vor, diese Mechanismen für Teambuilding, Unternehmens- und Strategieentwicklung zu nutzen. Dies konnte in der Einführung jedoch nur erwähnt werden.

Darauf folgte die Mittagspause. Am Kopf der Warteschlange, die größtenteils im Regen von Berlin stand, gab es Burger aus dem Burger-Truck. Und wieder war es sehr lecker. Neben dem Essen gab es interessante, wenn auch nur kurze Gespräche mit einigen Workshop-Teilnehmern.

LEGO Minimum Viable Product (MVP) Game

Auf diese Weise gestärkt ging es über vom LEGO Serious Play zu den LEGO Agile Games. Das erste Spiel war das LEGO Minimum Viable Product (MVP) Game. Für ein MVP gibt es viele unterschiedliche Definitionen. Hier meine ich ein konkretes Produkt, das früh in die produktive Verwendung geht, um Klarheit über zuvor getroffene Annahmen (Produktplatzierung, Gestaltung, usw.) zu erhalten bzw. um Feedback für die weitere Produktentwicklung einzuholen.

Mit diesem Spiel näherten wir uns dem Konzepts des MVP aus zwei Richtungen: Zunächst ging es darum, ein Umfangreiches Modell schrittweise auf eine geringere Anzahl von Teilen zu reduzieren. Die Teilnehmer lernten hier „loszulassen”, was dem einen leichter, dem anderen schwerer fiel. Auch lernten sie, wann ein MVP nicht mehr „viable” ist und zu stark reduziert wurde, um noch am Markt überlebensfähig zu sein. Sich dieser Schwelle bewusst zu sein, ist bei der Entwicklung eines MVP essentiell wichtig.

MVP wer erkennt das Raumschiff ? #spartakiade pic.twitter.com/JdNlxZW8ST
— Freddy Porsch (@minfler) March 19, 2017

Darauf gingen wir das MVP von der anderen Seite an. Im Rahmen eines Szenarios mit sich häufig wechselnden Anforderungen bzw. Umgebungsvariablen bauten die Teilnehmer ihr Modell schrittweise wieder auf. Dabei wurde klar, dass es sich in so gearteten Umgebungen lohnt, kleinschrittig zu arbeiten, früh auszuliefern und das Modell in der realen Umgebung zu testen. Bei einer langlaufenden Entwicklungsphase wäre das Modell vielleicht schöner geworden. Aber es wäre nicht nur erst spät produktiv einsetzbar, sondern würde aufgrund der zwischenzeitig veränderten Umgebung nicht mehr das „richtige” Produkt und damit weitgehend wertlos sein. Dieses Vorgehen ist damit gut geeignet, um im roten Problembereich zu manövrieren.

(Hier folgt noch eine Verlinkung auf eine ausführliche Anleitung zu meiner Variante des LEGO Minimum Viable Product (MVP) Games)

LEGO Product Owner Challenge

Nach einer kurzen Verschnaufpause ging es direkt weiter mit der LEGO Product Owner Challenge. Ein Spiel, bei dem es vor allem um die Kommunikation von Anforderungen geht.

Wir bildeten zwei Gruppen: Entwickler und Product Owner. Diese fanden sich daraufhin in Zweiergruppen zusammen. Jeder Product Owner wählte sich nun ein LEGO-Modell aus, das darauf vom Entwickler exakt nach Anleitung gebaut werden sollte. Problem dabei: Der Entwickler hat keine Einsicht in die Anleitung, die auf der anderen Seite des Raumes liegt. Der Product Owner muss nun zwischen Entwickler und Anleitung hin und her pendeln. Dabei gibt er den Entwickler Anweisungen, welches Teil wo hin zu gehören hat, ohne die LEGO-Steine selbst berühren zu dürfen. Am Ende der Bauphase kontrollierten wir, ob die Modelle Abweichungen von der Anleitung besitzen.

Wie erkläre ich jemandem am besten, was ich gebaut haben möchte - und selbst nicht bauen darf? #LEGO #spartakiade pic.twitter.com/U8yJL23J9H
— Thorben Egberts (@thorbenegberts) March 19, 2017

Zu Beginn der zweiten Bauphase erklärte ich den Teilnehmern das Konzept und Aufbau von User Stories. Daraufhin hatten die Product Owner ein paar Minuten Zeit, das vorher nach Anleitung gebaute Modell in eine oder mehr User Stories zu übersetzen. Dabei hatten sie den Freiraum, ihre eigenen Vorstellungen zum zu bauenden Modell einfließen zu lassen.

Nun vermittelte der jeweilige Product Owner dem Entwickler seine User Stories. Der Entwickler begann darauf, diese Vorstellung in ein LEGO-Modell zu übersetzen. Parallel dazu gab der Product Owner immer wieder Feedback zur Gestaltung und Funktionsweise des Modells. Es war spannend zu sehen, wie die Modelle entstanden. Product Owner und Entwickler führten Gespräche über die User Stories. So veränderten sich die ursprünglichen Vorstellungen des Product Owners während der Bauphase und Ideen befruchteten sich gegenseitig. Das kam der Qualität der Modelle zugute, die Ergebnisse waren toll.

Ein #LEGO Sportwagen entsteht anhand von User Stories, getrieben von Feedback, ganz ohne Anleitung #spartakiade pic.twitter.com/Yo6i6Ll51s
— Thorben Egberts (@thorbenegberts) March 19, 2017

In einer Reflexionsrunde besprachen wir die Unterschiede, die sich im Bauen nach Anweisung und Kontrolle in der ersten Bauphase und dem Bauen mit Vertrauen und Feedback in der zweiten Bauphase ergaben. Hier kam zum Ausdruck, dass die zweite Bauphase entspannter und produktiver war und zudem mehr Spaß gemacht hat. Für den Product Owner ergaben sich Freiräume, über sein Produkt nachzudenken, weil er nicht mehr mit dem Micromanagement des Entwicklers beschäftigt war. Der Entwickler auf der anderen Seite konnte sein Können beweisen und fühlte sich wertgeschätzt, weil seine Ideen vom Product Owner aufgenommen und gemeinsam weiterentwickelt wurden. Eine Win-Win-Situation!

(Hier verlinke ich demnächst noch eine ausführlichere Anleitung zu meiner Variante der LEGO Product Owner Challenge)

LEGO Walking Skeleton Game

Eine kurze Pause später ging es zum letzten Agile Game des Tages: Dem LEGO Walking Skeleton Game. Das Spiel wurde ursprünglich von Matthias und Patrick Koglin für den Agile Building Day 2016 in Kassel entwickelt. Das Spiel ist besonders für Softwareentwickler interessant, aber auch allgemein für jeden, der mit Produktentwicklung zu tun hat.

Wir bildeten zwei Teams von fünf Personen, die nun jeweils ein eigenes Haus aus LEGO bauen sollten. Ich als Trainer übernahm dabei zwei Rollen: Die des Auftragnehmers bzw. Projektleiters, der die Teams beschäftigt. Er ist teilweise Übersetzer des Kunden für das Team, folgt aber auch seinen eigenen (wirtschaftlichen oder „politischen”) Interessen und ist dem Team gegenüber weisungsbefugt. Die zweite Rolle ist die des Kunden. Der Kunde taucht immer wieder auf, um den Teams seine Vorstellungen von seinem Haus zu vermitteln. Dabei äußert er sich gern unspezifisch oder widersprüchlich und tritt mit plötzlichen Sonder- oder Änderungswünschen an das Team. Gleichzeitig sind die Aussagen von Auftraggeber und Kunden nicht konsistent bzw. folgen scheinbar unterschiedlichen Interessen.

In der ersten Hälfte des Spiels lief alles ungeordnet und chaotisch. Die Bauphase begann unerwartet. Der Teamleiter erklärte kurz die Projektsituation. Der Kunde erschien und vermittelte dem Team das, was er sich unter seinem zukünftigen Haus vorstellte. Dabei verstrickte er sich in Details, ohne Hinweise auf das große Ganze zu geben. Genau so schnell wie er erschien, war er auch wieder verschwunden. Zwischendurch tauchen Auftragnehmer und Kunde immer wieder auf, um auf das Team einzuwirken. Die Atmosphäre wirkte schon bald gestresst und angespannt. Um es auf die Spitze zu treiben, erhielten einzelne Teammitglieder Sonderaufgaben oder wurden unter Vorwänden mit Mitglieder des anderen Teams vertauscht.

Aufgrund von Zeitmangel konnten wir das Spiel leider nicht in voller Tiefe ausspielen. So endete die Bauphase nach 30 Minuten mit der Abnahme durch den Kunden. Das Ergebnis war (wie ich ein wenig erhofft hatte) für beide Teams kein gutes. Teile des Hauses waren offen (Mauern bzw. Dach fehlte), Zimmer halb fertig oder durch Änderungswünsche mitten in einer Umbauphase. Diese Ruine war alles andere als durch den Kunden beziehbar. Entsprechend enttäuscht und schlecht gelaunt war der Kunde. Der Auftragnehmer war ebenfalls unzufrieden mit Ergebnis und dem Team. Manche Teilnehmer fühlten sich hier an Projekte erinnert, die in ihrer Erinnerung ganz ähnlich verlaufen sind. Diese Situation war insgesamt überspitzt gestatltet, um einen besseren Kontrast zur zweiten Bauphase herzustellen und die Lernpunkte zu verdeutlichen.

Zu Beginn der zweiten Hälfte hielt ich einen kurzen Impulsvortrag zum Konzept des Walking Skeletons von Alistair Cockburn. Es beschreibt ein Vorgehen für eine sich parallel zum Projektverlauf entwickelnde Software-Architektur. Dabei werden kleine Teile von Funktionalität durch alle Schichten (Benutzeroberfläche, Business Logik, Datenbank usw.) des Systems entwickelt. Diese Teile können nun „End-to-End” unter realen Bedingungen getestet und, wenn erwünscht, bereits vom Anwender benutzt werden. Bildlich gesehen kann das „Skelett” bereits laufen und erhält mit der Zeit Fleisch und Muskeln dazu. An dieser Stelle ließ sich der Bogen zurück zum LEGO Minimum Viable Product (MVP) Game von vorher schlagen.

Diese Vorgehensweise des Walking Skeleton wird von sinnvollen Standards bzw. klar definierten Schnittstellen und Modularität begünstigt. Gleichzeitig entsteht (automatisiert) testbarer Code und eine elegante, leicht änderbare Architektur. So lässt sich leichter und schneller auf sich ändernde Anforderungen reagieren.

Aus diesem Konzept abgeleitet lieferte ich den Teilnehmern Vorschläge, mit denen sich das Haus ebenfalls kleinschrittig und modular bauen lässt, beispielsweise indem sich das Team sich auf eine einheitliche Mauerhöhe einigt, Standard-Elemente vorfertigt und sich auf den Bau gleich großer Zimmer-Module einigt, die untereinander ausgetauscht werden können.

Mit diesen Informationen beginnt eine zweite Bauphase. Aufgrund des Zeitmangels erklärte nun geänderte Vorgehen während der Projektphase: Die Bauphase war ab jetzt in Iterationen von 10 Minuten unterteilt, mit einer anschließenden zweiminütigen Produkt-Review durch den Kunden. Der Kunde tauchte nicht mehr während der Bauphase auf, sondern gab sein Feedback in der Review. Der Auftragnehmer wechselte in ein Verhalten ähnlich eines Scrum Masters und stellte sicher, dass das Team alles hat, was es benötigt, gab Ratschläge und ließ das Team ansonsten einfach nur möglichst störungsfrei bauen. Wie sich herausstellte, hatten manche Teilnehmer hier ein kleines Flow-Erlebnis.

Aber auch in dieser zweiten Bauphase gab es Momente, in denen sich das Team an neue Gegebenheiten anpassen musste. Beispielsweise musste Teilnehmer den Workshop frühzeitig verlassen und fehlte plötzlich. Darauf habe ich den Workshop-Raum verlassen und auf dem Flur eine Teilnehmerin als Ersatz gefunden, die sich netterweise dazu bereit erklärte, dem Team auszuhelfen. Das neue Teammitglied musste jedoch vom Team eingearbeitet werden und brachte gleichzeitig ein wenig Chaos ins Geschehen. Dank seiner selbst definierten, dem neuen Teammitglied einfach zu erklärbaren Standards konnte das Team dies jedoch besser abfangen als es bei Veränderungen in der ersten Bauphase der Fall war.

Am Ende jeder Iteration waren nun neue Teile des Hauses tatsächlich fertig und für den Kunden bezugsbereit. Änderungswünsche konnten leichter realisiert werden. Sogar ganze Räume konnten im Stockwerk wechseln, ohne größere Auswirkungen auf andere Teile des Hauses zu haben.

In einer nun folgenden Reflexion verglichen wir die beiden Bauphasen miteinander und fanden Parallelen zur Softwareentwicklung und agilen Vorgehensweisen, welche wir noch in gewisser Tiefe besprechen konnten. Eine ausführliche Anleitung findet sich in Patricks Blog.

Dann war er leider schon vorbei, der zweite Workshop-Tag. Und damit auch die gesamte Spartakiade. Nach dem hastigen Zusammenräumen und einem kurzen Sprint mit einem riesigen Koffer voller LEGO zum Ostbahnhof von Berlin setzte ich mich wohlig erschöpft in den ICE nach Kassel.

Fazit

Das Teilnehmer-Feedback zum Workshop war insgesamt gesehen positiv, aber (wie ausdrücklich gefordert) auch kritisch-konstruktiv. Für mich war es ein gutes Training, auch wenn die Gruppe sehr handzahm und gut zu handeln war.

Mit etwa sechs bis sieben Stunden reiner Workshop-Zeit war es mein bisher längster Workshop. Trotz dieser Länge war die Zeit für die Einführung zum Thema LEGO Serious Play und die drei Agile Games zu knapp bemessen. Das LEGO Walking Skeleton Game konnten wir nicht in der eigentlich notwendigen Länge ausspielen, auch wenn die Kernpunkte trotz Kürzungen und Improvisation transportiert worden sind.

Die Kombination von LEGO Serious Play und Agile Games war nicht für jeden Teilnehmer nachvollziehbar und sorgte für etwas Verwirrung. Auch wenn es beides mit LEGO zu tun hat – der Ansatz ist doch sehr unterschiedlich. Bei dem einen geht es um das Bauen von Metaphern und das gemeinsame Verständnis. Beim anderen geht es eher um das spielerische Vermitteln von Konzepten bzw. die Festigung einer Haltung, die auf agilen Werten und Prinzipien beruht. Manche hätten gern mehr von LEGO Serious Play erfahren und wären beim Workshop von Matthias am Vortag besser aufgehoben gewesen. Auch hätte ich selbst eine klarere Trennlinie zwischen den beiden Teilen ziehen müssen.

Dies und der zeitliche Aspekt lassen mich zur Entscheidung kommen, bei einer möglichen Wiederholung auf den Teil mit LEGO Serious Play zu verzichten. Statt dessen sollte dem Thema LEGO Serious Play ein ganzer Workshop-Tag gewidmet werden, wie ihn Matthias am Vortag angeboten hat.

Außerdem überlege ich ernsthaft, jetzt wo ich mich noch intensiver mit LEGO Serious Play beschäftigt habe, das Training zum LEGO Serious Play Facilitator zu machen. Ich habe nun noch mehr gemerkt, wie mächtig und lösungsorientiert dieses Werkzeug sein kann und dass ich es selbst sehr gut einsetzen könnte, um Personen, Teams und das Unternehmen in dem ich Arbeite auf der Lösungsfindung zu unterstützen.

Gesamt gesehen fand ich das Event sehr gelungen. Wie schon erwähnt: Tolle Location, gutes Essen, interessante und nette Menschen, große Vielfalt von Workshops. Ich würde es wieder machen. An dieser Stelle auch noch einmal vielen Dank an die Organisatoren, die Teilnehmer meines Workshops und Matthias, der an mich als Vertretung gedacht hat!

Hier finden sich Eindrücke vom Event: https://goo.gl/photos/dnweEcXo9BY8KPUH6. Um das Album mit den personenbezogenen Bildern erhalten möchte, schreibt mir bitte eine Privatnachricht bei Xing, LinkedIn oder Twitter.

Weitere Eindrücke findet ihr unter dem Hashtag #spartakiade

PS: Torsten und Gregor veranstalten im Oktober im 10 Jahr in Folge den Developer Open Space in Leipzig.

Continuous Improvement Template

Wed, 28 Sep 2016 15:41:00 +0000

During my work as a Scrum Master and Agile Coach I attended lots of retrospectives by various teams. One thing I noticed quite a lot is that team members struggle to recall events that happened during the Sprint. This is even more the case for teams that are overburdened or stressed. This is quite a tragedy: Especially those teams could profit from changes. Changes in how they accept work, allocate it within their team, keep track of it and protect themselves against overload. However, it can’t be in the interest of the organization to have overloaded teams. In the long term they lack predictability of velocity not only due to illness and signs of burnout, but also because of technical debt that’s easy to dismiss if you have to take shortcuts all the time. A peak of assumed high performance is followed by a vale of tears.

However, those teams are in a vicious cycle as long as they don’t take a break and agree on real improvements. It’s not just that those teams are too busy to improve. For our brain it’s hard to notice and remember things while we are in a rush or act in panic. It takes calmness to be mindful.

Do you know such a team? Or are you even part of such a team or their Scrum Master? Here’s a suggestion on how to change this situation. It’s easier to keep track of things if you get them out of your head. To-do lists are a good example. This in mind, I created the Continuous Improvement Template. Maybe you want to start using it on your own. Or maybe you want to suggest in your next retrospective that everyone on the team starts using it. At least for one Sprint to validate the results. Download, print and hand it to your team members. Don’t forget to provide a pen, too. Now every time something noteworthy happens, even small things that could matter, take a short note in one of the columns that are:

Keep (doing something)
Less (of something)
More (of something)
Stop (doing something)
Start (doing something)

After jotting it down, you can go back into busy mode. It’s out of your head now. Next time you’re participating in your team’s retrospective, take your Continuous Improvement Template with you. Reflect on things that happened. Together, agree on a first little step to improve the situation. After that, print a fresh copy of the Continuous Improvement Template and keep track of events that verify the effectuality of your change or whatever comes across that could be an input for your next retrospective.

You can download the template here or view it below.

© 2016 by Thorben Egberts, thorbenegberts.com – This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 License (international). http://creativecommons.org/licenses/by-nc-sa/4.0/.

Moving the Blog

Sat, 17 Sep 2016 10:22:00 +0000

I’m currently moving my the from Ghost to Jekyll. You can find the old blog here until the domain is not switched to the new blog.

Unread Email Count

Tue, 13 Oct 2015 20:46:00 +0000

I’m a strong advocate of inbox zero. Inbox zero is an approach for keeping your inbox empty all the time. It helps me stay on top of things. For each email I read, I decide consciously between respond, delete, delegate, defer or do. And I ry to read each mail just once. If I deal with an email more than once it would be both a waste of time and energy.

If I’m stressed both in a positive or negative way, I wouldn’t realize it immediately. Often it was my girlfriend, family or peers who notice a change of behavior and made me aware of it.

Over time, I realized a astonishing reliable “metric” for my personal stress level: the count of unread emails. It seems to be natural for me that if I’m very engaged with something or stressed by work, even if I would have enough time in between to deal with email, I wouldn’t have enough mental resources left to do so.

Now every time I notice that I don’t reach inbox zero for a couple of days or hours, I know it is time to cool down and cut me some slack. For me this is a strong feedback mechanism.

Scum and FrAgile

Sun, 11 Oct 2015 19:17:00 +0000

Patrick Koglin from Agile-is-Limit.de and me started a new project: Scum and FrAgile! It’s a satirical take on Agile and Scrum and points to common misconcepts and misunderstandings. Until now the content is mostly in German, but feel free to contribute in any language with hashtag #Scum on Twitter!

@thorbenegberts Es gibt Dinge, die man einfach tun muss :) http://t.co/Vr9KXcXAVS
— Patrick Koglin (@patrickkoglin) October 11, 2015

#scum Wie arbeiten wir? Agil! // Thanx for funny impulse - @thorbenegberts pic.twitter.com/UhPByf3FDt
— Patrick Koglin (@patrickkoglin) October 9, 2015

@patrickkoglin Ticket Driven Development (TDD) #Scum #FrAgile pic.twitter.com/gNowwmnyGf
— Thorben Egberts (@thorbenegberts) October 11, 2015