Schlagwort-Archive: agile

„Wie ihr das Ganze hier organisiert, ist echt cool!“

Im Sommer 2017 unterstützten uns für drei Wochen Emily (15) und Lilly (15) als Schülerpraktikantinnen. Beide besuchen die Reformschule Winterhude in Hamburg, an der sie regelmäßig Praktika machen, um konkrete Arbeitserfahrung zu sammeln. Während ihres Praktikums bei it-agile haben sie unser Münchener Team begleitet.

“Sag mal, hat it-agile Verwendung für zwei aufgeweckte, selbstorganisierte, kreative und sehr charmante Praktikantinnen von der agilsten Schule Deutschlands?” Na klar! Bis zu dieser Twitter-Nachricht im Mai hatte it-agile noch nie Schüler-Praktikanten. Folglich waren wir uns sicher, dass wir dadurch etwas lernen können. Unser Münchener Team zeigte schnell Interesse und so starteten Emily und Lilly im Juni ihr Praktikum bei it-agile in München.

Zum Praktikumsabschluss haben die Kollegen Christian Dähn und Peter Rößler mit ihnen ein Interview geführt.

Chris: Warum habt ihr euch bei it-agile beworben?

Lilly: Vor allem wussten wir, dass wir ein Praktikum machen müssen und haben uns ein paar Möglichkeiten angeguckt. In unseren bisherigen Praktika waren wir in sehr klassischen Agenturen und Unternehmen. Daher wollten wir einen anderen Weg kennenlernen, wie man später zusammenarbeiten und sich als Unternehmen organisieren kann. Und so ist es it-agile geworden.

Chris: Und habt ihr das erfahren können oder kennengelernt?

Emily: Auf jeden Fall. Wir hatten ehrlicherweise nicht so viele Erwartungen. Wir wollten in jedem Fall Spaß haben und bei it-agile reinschnuppern. Und das haben wir hier.

Lilly: Und wir hätten nie gedacht, dass wir bei so vielen Kundeneinsätzen mit dabei sein würden und bei so vielen Schulungen mitmachen dürfen. Bei den bisherigen Praktika waren wir bei den Meetings nur passive Beisitzer.

Peter: Die drei Wochen mit euch vergingen wie im Fluge. Erzählt mal, was ihr in dieser Zeit alles erlebt und gemacht habt.

Emily: Wir haben ein Instagram Account aufgebaut und versucht, regelmäßig etwas zu posten. Damit Leute sehen, wie das Leben als Praktikant hier läuft. Und wir haben uns eine Retrospektive für unsere Klassenkameraden entworfen.

Lilly: Dann haben wir bei Peters Retrospektiven-Training mitgemacht. Da waren wir eingebunden wie alle anderen Teilnehmern und haben gelernt, wie eine Retrospektive funktioniert.

Dann haben wir die Schulung Management Agiler Teams und einen Kundentermin mit vorbereitet. Und nebenbei haben wir unsere Fähigkeiten in Sketchnoting verbessert. Hier hat uns Chris gute Tipps gegeben, z.B. den grauen Schatten hinzuzufügen.

Emily: Und wir waren bei EduScrum, einer Informationsveranstaltung, auf der erklärt wurde, wie Scrum in Schulen eingesetzt werden kann. Auch bei ein paar Kundenterminen waren wir dabei und konnten einfach zuhören und beobachten, wie eure Interaktion mit den Kunden läuft.

Lilly: Dann konnten wir erleben, wie ihr als Team in München arbeitet. Emily und mich hat sehr begeistert, dass ihr sehr offen miteinander umgeht.

Emily: Ja, ihr seid eine tolle Teamgemeinschaft: Da kann sich manch einer echt etwas abschneiden.

Chris: Ihr habt ja bereits andere Praktika gemacht. Was habt ihr dabei erlebt?

Lilly: Also bei mir war es so: Ich bin da hingekommen und dann musste ich erstmal warten, weil alle beschäftigt waren. Und dann haben die sich gar nicht so richtig auf mich eingestellt. Dann habe ich gewartet und dann hieß es irgendwann: „Ja, dann komm mal mit”.

Emily: Bei meinem letzten Praktikum habe ich als Abschiedsgeschenk 100 Pfannkuchen für alle gebacken, weil ich in meiner Bewerbung erzählt hatte, dass ich in meiner Kochgruppe viele Pfannkuchen gebacken habe. Beim Praktikum dort stand ich dann stundenlang in der Küche und habe für sie Pfannkuchen gebacken.

Peter: Was war der größte Unterschied zwischen den bisherigen Praktika und den letzten drei Wochen bei it-agile?

Lilly: Auf jeden Fall, dass ihr immer versucht habt, uns einzubinden. Bei meinem letzten Praktikum habe ich manchmal Sachen gemacht, die gar nicht wichtig waren. Nur damit ich beschäftigt bin. Und hier hatte ich immer das Gefühl, dass es etwas bringt, wenn ich etwas mache.

Chris: Mich würde interessieren, was ihr denn von eurem Praktikum in eure Welt mitnehmt?

Emily: Wir haben regelmäßig Projektwochen, in denen wir in einem Team immer ein Thema bearbeiten. Und wenn es da mit der Teamarbeit nicht so läuft, könnten wir eine Retrospektive machen.

Lilly: Für unseren Tutorial-Unterricht nehme ich mit, dass ich da klare und deutliche Ansagen machen muss. Und ich denke, Emily und ich haben hier auf jeden Fall viele Tricks zum Präsentieren gelernt und wie man vor anderen Leuten sprechen kann.

Emily: Bei uns haben wir auch jeden Tag Gruppenzeit. Da reden wir über generelle Bildungsthemen. Und da könnten wir einen Check-In machen: Somit wären alle von Anfang an eingebunden, haben gleich was gesagt und würden sich dann eventuell auch im Anschluss mehr einbringen.

Peter: Wir haben euch wirklich als „aufgeweckte, selbstorganisierte, kreative und sehr charmante Praktikantinnen” erlebt. Und auch Teilnehmer, die euch in unseren Schulungen kennengelernt haben, waren beeindruckt. Ihr beide habt als gleichberechtigte Teilnehmer auf Augenhöhe mit den anderen Teilnehmern agiert. Und ihr seid Teil unseres Teams geworden. In Retrospektiven konnten wir uns ehrliches Feedback geben und die gegenseitigen Erwartungen abgleichen.

Wie habt ihr uns wahrgenommen? Was wollt ihr uns mitgeben?

Lilly: Ihr solltet auf jeden Fall weiterhin so offen und ehrlich miteinander umgehen.

Emily: Ich würde eure Art zu Moderieren beibehalten, das ist ziemlich eindrucksvoll und vorbildlich. Und die Art, wie ihr euch immer neu erfindet. Und wie ihr das Ganze hier organisiert, das ist echt cool. Ich habe kein schlechtes Feedback an euch.

Lilly: Ja, ich habe auch nichts mitbekommen, was schlecht war.

Und was haben wir als Münchener Team durch das Praktikum von Emily und Lilly gelernt? Neben dem vielen guten Feedback fühlen wir uns bestätigt, dass wir als Team auf einem guten Weg sind. Wir haben zudem gelernt, dass wir Praktikanten problemlos integrieren können, wenn wir mit ihnen wie mit Erwachsenen umgehen und sie so behandeln wie neue Kollegen bei it-agile. Das bedeutet in den ersten Wochen alles mitzumachen und unterschiedlichste Situationen kennenzulernen.

Die drei Wochen reichten nicht aus, damit Emily und Lilly die komplette Organisation it-agile kennenlernen konnten. Einen Eindruck vom Hamburger Büro, unseren monatlichen Treffen mit allen Business-Teams oder den gemeinsamen Open Spaces werden die zwei erst bei einem weiteren Praktikum oder als zukünftige Mitarbeiter von it-agile bekommen.

Dank Emily und Lilly haben wir als it-agile jetzt auch einen eigenen Instagram-Account.

Beim gemeinsamen Abschlussgrillen hat sich das Münchner Team in jedem Fall wahnsinnig gefreut, als jeder von Emily und Lilly mit einem persönlichen Brief und Geschenk überrascht wurde. Und selbstgebackenen Kuchen gab es auch.

Vielen Dank, Emily und Lilly.

Abschlusscollage

Advertisements

[Update] Über den Umgang mit Unsicherheit – Bericht über das Muckibuden-Retreat im Juni 2017

Wir waren vom 07. bis 09. Juni auf der Firstalm für unser diesjähriges Retreat auf dem es zwei Besonderheiten gab: 1. Wir waren auf einem Berg 2. Drei von uns kamen gerade vom Liberating Structures Workshop. Diese Mischung machte das Retreat für uns sehr erfolgreich.

Den Abend nach dem Aufstieg auf die auf 1.300 Meter liegende Alm verbrachten wir mit einem Kasten Bier und einer Brotzeit und philosophierten, wie wir die nächsten zwei Tage miteinander verbringen wollen. Das Ergebnis davon war, dass wir versuchen wollen, viel in der Natur zu machen und die Themen auf uns zukommen zu lassen, statt eine lange Liste von Post-its versuchen abzuarbeiten.

Den ersten Tag begannen wir mit einem Aufstieg auf die Brecherspitze, der vor allem dazu diente, uns zu connecten und Geschichten über die Muckibude zu erzählen (Leitfrage: “welche Ereignisse haben unser Team bisher geprägt?”). Auf auf der Hälfte des Weges formulierten wir die Idee, dass wir – wenn wir wieder unten sind – unseren Vertrieb näher ins Auge fassen, da wir zu der Zeit mit sehr vielen Vertriebsanfragen beschäftigt waren.

Angekommen am Gipfelkreuz verfeinerten wir die Idee zur Untersuchung unseren Vertriebs und beschlossen, diesen mit der Struktur “Critical Uncertainties” zu bearbeiten.

Der Rückweg war daraufhin recht schweigsam; es war alles gesagt.

Critical Uncertainties im Vertrieb

Die Struktur dient dazu, Strategien für den Umgang mit plausiblen aber unvorhersehbaren Zukunftsszenarien zu entwickeln.

Der erste Schritt bestand darin, eine Liste von Unsicherheiten im Vertrieb anzulegen mit der Frage: “Welche Faktoren im Vertrieb haben wir nicht unter Kontrolle oder können wir nicht vorhersagen”. Die Liste hat zuerst jeder für sich erstellt und dann in der Gruppe geteilt.

Im nächsten Schritt haben uns gefragt, welche dieser Faktoren für den Vertrieb am bedeutendsten sind mit der Frage: “Welche dieser Faktoren hindert uns am meisten erfolgreich zu sein?”

Aus dieser Auswahl haben wir dann die zwei für uns entscheidenden Faktoren extrahiert: Vertriebsanfragen und Auslastung. Diese haben wir dann in eine Matrix eingetragen und jeweils die positiven und negativen Pole dieser Faktoren bestimmt: “genügend” und “zu wenig”. Hinweis zur Methode: wenn man für beide Pole Extreme wählt (also zum Beispiel “0% Auslastung”, “100% Auslastung”) schafft man auf beiden Seiten nicht erstrebenswerte Pole, da nur in der Mitte quasi der Idealzustand wäre. Falls beide Extreme betrachtet werden sollen, müsste man also zwei Critical Uncertainties machen, eine mit “0% Auslastung” und “passender Auslastung” und die andere mit “100% Austlastung” und “passender Auslastung”. In den nächsten Schritten werdet ihr sehen, wozu das nützlich ist.

Der nächste Schritt besteht darin, Namen für die vier Quadranten zu entwickeln und eine kurze Szenarienbeschreibung zu machen. Das dient dazu, eine Vorstellung davon zu entwickeln, wie es in dieser möglichen Zukunft aussehen würde.

Und jetzt kommt der spannendste Schritt dieser Übung: statt zu überlegen, wie man es schafft in den “wünschenstwerstesten” Quadranten zu kommen, überlegt man sich, wie man in jedem dieser Quadranten “überleben”, also erfolgreich sein kann. Da die Faktoren nicht in unserem Einflussbereich liegen ist klar, warum man bei dieser Übung diesen Weg geht.

Zu jedem der Quadranten haben wir somit verschiedene Strategien und eine prägnante Formulierung für “Prio 1” gefunden.

Wir haben dabei festgestellt, dass uns die “Prio 1” am meisten hilft und die Strategien mögliche Optionen zum handeln in dieser Welt sind.

Unser Aktion daraus ist, bei jedem Muxl festzustellen, in welchem Quadranten wir uns befinden und dann die entsprechenden Strategien anzuwenden.

Aktuell befinden wir uns in “Hoffnung am Horizont” und damit ist Vertrieb unser “Prio 1”. Die letzten Tage haben wir nach dieser Prämisse verbracht und sehr viel gemeinsamen Vertrieb gemacht. Für Daten ist es noch zu früh aber unser Gefühl sagt uns, dass wir den besten Vertriebszustand seit langem (wenn nicht seit jeher) haben.


Wie man ein chaotisches Team organisiert

Wir bei it-agile in München sind ein recht chaotischer Haufen. Wir lieben unsere Freiheit, sind alle sehr unterschiedlich und haben es uns zur Aufgabe gemacht, zu einem erfolgreichen Team heranzuwachsen.
Der klassische Weg klingt verlockend: Wir schauen auf die Auslastung der Kollegen und ziehen uns genau die Anfragen, die uns eine stetige Auslastung bringen. Damit sorgen wir dafür, dass wir die in unserer Branche übliche 80%-tige Auslastung erreichen. Das ist zumindest das Ziel, das ich von meinen vorherigen Firmen kenne.

Doch die Natur unseres Geschäfts macht uns dabei viel zu schaffen: Länger als zwei Monate im Voraus kann keiner von uns planen. Kunden haben Unterstützungsbedarf unabhängig von unserer Planung. Meist sehr kurzfristig. Hinzu kommt, dass wir unsere Kunden nicht dauerhaft von uns abhängig machen wollen, sondern sie möglichst schnell in einen Zustand bringen wollen, in dem sie uns nicht mehr brauchen. Das widerspricht natürlich dem oben genannten Ziel. Hinzu kommt, dass wir den Kollegen Wahlmöglichkeiten für die Auswahl von Jobs bieten wollen. Nicht jeder Job den wir machen könnten, sollten wir auch machen. Neben genügend Geld verdienen steht das Interesse der Kollegen, herausfordernde und spannende Jobs zu machen. Schließlich ist die Zufriedenheit der Mitarbeiter mindestens genauso wichtig wie die der Kunden.

Wir brauchen also einen anderen Ansatz.

lego_stack

Diesen Haufen Steine bekommt jeder Kollege und kann damit seine im Jahr verfügbare Arbeitszeit verplanen

Wenn wir uns unser Problem anschauen, ein Umsatzziel in einer nicht-planbaren Umgebung zu erreichen, stellt sich schnell raus, dass es ein Limitierungsproblem ist. Kurzes googeln zeigt, dass ein Jahr 250 Arbeitstage hat (zumindest in Bayern 🙂 ). Die Ausgangsfrage lässt sich also darauf reduzieren, dass jeder Kollege an jedem Tag entscheiden kann, welche Art von Arbeit er macht: Arbeitet er für einen Kunden, bildet er sich weiter, arbeitet er intern oder macht er Urlaub. Für jeden Tag im Jahr muss diese Entscheidung getroffen werden. Klingt wie gemacht für Kanban-Karten: jeder Tag ist ein Signal, dass dort eine bestimmte Arbeit verrichtet werden kann.

Nichts leichter als das: wir besorgen 250 verschiedenfarbige Lego-Steine für jeden Kollegen und teilen diese in fünf Kategorien: 140 für Kundenarbeit (orange), 20 für Weiterbildung (blau), 30 für Orga (gelb) und 30 für Urlaub (weiß). Dann bleiben noch 30 für Slack (grün), also ungeplante Zeit übrig. Damit ist die gesamte verfügbare Arbeitszeit eines Jahres abgebildet und wir schauen uns regelmäßig an, wie viele Steine jeder Kollege verbraucht hat. Wir betrachten unser System retrospektiv und können für jeden Augenblick sagen, wie wir gerade dastehen: wir kennen die durchschnittliche Erwartung an ausgegebenen Steinen und die tatsächlich erzielte Anzahl. Damit haben wir ein Bild, ob wir gerade über oder unter der statistischen Erwartung sind.

Natürlich reicht das noch nicht. Rein statistisch steht jedem Mitarbeiter pro Monat 2,5 Tage Urlaub zu. Die Realität zeigt jedoch, dass Kollegen den Urlaub nicht gleichverteilt nehmen, sondern sich diesen zum Beispiel für einen ausgedehnten Sommerurlaub aufsparen. Die Konsequenz davon sollte sein, dass wir in nicht-Urlaubszeiten mehr orange, also Kundentage, und weniger weiße Steine sehen, da hier der Kollege Urlaub anspart.

lego_calender_year

Unser Teamkalender aus LEGO – Es gibt vier Reihen von links nach Rechts in denen die Monate abgebildet sind. Links oben Januar, rechts unten Dezember

lego_calender_rows.jpg

Jeder Kollege hat eine Reihe um seine Steine zu setzen – Hier zu sehen: Januar, Februar und April, Mai

Um das abzubilden, ist es naheliegend, das gesamte Jahr als Kalender nachzubauen und darauf alle Steine zu verteilen. Damit haben wir ein für das Jahr abgeschlossenes System und können die Auswirkungen der tatsächlich erzielten Arbeitsverteilung auf die Zukunft direkt erkennen. Das heißt ich deale mit mir selbst. Macht ein Kollege mehr Kundentage als im Durchschnitt, wird sofort sichtbar, dass er in der Zukunft mehr Urlaub, Slack oder Weiterbildung machen muss. Und umgekehrt.

lego_calender_dealing.jpg

Das Dealen läuft in 4 Schritte ab: 1) Ich stelle fest, dass sich etwas ändert und ich tauschen möchte. In dem Beispiel möchte ich an den zwei Tagen Slack gerne beim Kunden sein. 2) Ich machen den Platz an dem die Steine standen frei. Ich entferne den Slack. 3) Ich suche mir eine nicht geplante Stelle, von der ich Kundensteine entnehmen kann und entferne diese. 4) Ich setze die entnommenen Steine an die zu ändernde Stelle und umgekehrt. Der Slack wandert jetzt also an die vormalige Kundenstelle und ich kann beim Kunden sein

Was ist aber, wenn jemand mehr Urlaub haben möchte oder mal eine größere Weiterbildung machen will? Hier beginnt das Teamdealen. Wenn ich mehr weiße Steine haben will, muss ich die von einem Teammitglied „abkaufen“ indem ich orange Steine eintausche.

Wir sind noch mitten in der Erfahrungssammlung mit unserem neuen System. Bisher können wir sagen: die Lego-Steine geben uns die individuelle Freiheit bei gleichzeitiger Betrachtung des Team-Ergebnisses. Mit unseren jeweiligen 250 Steinen kann jeder planen, so wie es ihm damit am besten geht. Und wir sehen auf unserem gemeinsamen Kalender sofort, welche Auswirkungen unsere Entscheidungen auf das Teamergebnis hat und ob wir etwas anpassen wollen.

Habt ihr Anregungen wie wir das System noch verbessern können? Dann schreibt uns. Wir freuen uns, die Ideen auszuprobieren.


Gute Vorsätze fürs Neue Jahr – folge dem Nordstern

Feuerwerk in Hamburg - da fliegen sie die Vorsätze

Stehen bei Ihnen gerade Veränderungen an? Starten Sie gerade ein Projekt in ihrer Firma oder haben privat eine Richtungsänderung vor? Dann könnte das hier etwas für Sie sein.

Viele Veränderungen, die ich beobachte, beginnen so: Ein Topmanager hat die Idee, innovativer zu werden, einen neuen Markt zu erobern oder mehr Geld zu verdienen. Daraufhin ändern Manager und Mitarbeiter viele Teile der Organisation, bilden cross-funktionale Teams, lösen Hierarchien auf oder strukturieren die Organisation um. Veränderungsgeist liegt in der Luft und es macht Spass dem Treiben zuzusehen. Doch nach einiger Zeit mehrt sich der Eindruck, dass es zwar viele Veränderungen gibt, diese aber insgesamt nicht das Ergebnis bringen, was sich die Initiatoren erwünscht haben. Und weil es so schwer ist, das Gewünschte in Worte zu fassen, können diese häufig nur machtlos dem Scheitern der Veränderung zusehen.

Was ist passiert? Veränderungen sind eine Reise ins Unbekannte, in eine Richtung, die grob durch eine Vision vorgegeben ist, an deren Ziel noch keiner war. Keiner in der Organisation weiß, wie es dort aussieht oder kennt den genauen Weg dorthin. Es gilt, den Weg gemeinsam zu finden und sich in Richtung Vision vorzutasten. Und genau hier besteht das Problem: wenn wir den Weg nicht kennen, wie stellen wir fest, ob wir uns in Richtung Vision bewegen? Was ist unser Kompass?

klassisch und True North im Vergleich

Klassisch und True North im Vergleich

Aus meiner Sicht ist dies genau der True North [1] [3]. Er gibt Orientierung, wenn unklar ist, in welche Richtung es weitergehen soll. Er motiviert, die notwendigen Veränderungen anzugehen und Lösungen für die auf dem Weg liegenden Probleme zu finden. Was genau der True North ist, lässt sich im Vergleich mit dem klassischen Vorgehen zeigen.

Wenn eine Firma auf klassischem Weg eine Vision erreichen will, wird die Vision zunächst in kleinere Ziele pro Hierarchieebene zerlegt und anschließend mit Führen über Zielvereinbarung [2] gesteuert, dass die Ziele erreicht werden.

Anders funktioniert der True North. Statt die Vision in kleinere Ziele zu zerlegen, formuliert die Firma einen Satz von Idealzielen, die zwar unerreichbar, gleichzeitig aber richtungsweisend sind. Diese gelten dann unabhängig von der Hierarchieebene überall gleichzeitig und richten damit eine Firma gemeinsam aus.

Das Problem bei klassischen Vorgehen ist, dass beim Zerlegen in kleinere Ziele eine Annahme über das Zusammenspiel aller Einzelteile der Firma getroffen wird, ohne diese systemisch vollständig zu verstehen. Sie geht also davon aus, dass Dinge aus einem bestimmten Grund passieren, ohne dass dies zum Beispiel durch Daten belegt ist. Häufig stützt sie sich dabei auf Erfahrungen anderer (“das hat XY gemacht, darum machen wir das auch”), lässt dabei jedoch den individuellen Charakter der eigenen Firma ausser acht.

Ein Beispiel soll helfen den Unterschied zu zeigen: Angenommen eine Firma stellt fest, dass sie zu wenig Innovationen hat, um am Markt zu konkurrieren. Die Firma soll infolge dessen dahin ausgerichtet werden, Innovationen zu fördern. Nach dem klassischen Model würde die Firma ihren Innovationsprozess analysieren, feststellen, was jede Abteilung, jede Hierarchieebene und jeder einzelne dazu beiträgt und abgleichen, wie sie den Sollzustand erreichen möchte. Daraus würden sich dann ganz unterschiedliche Ziele ergeben, die je nach Beitrag zum Ganzen aufgeteilt sind. Im Support könnten das “10% weniger Beschwerden von Kunden” sein, in F&E wäre ein Ziel “jeden Monat ein Innovation-Day” vorstellbar und für die Mitarbeiter könnte “10% der Zeit sind zur freien Verfügung” gelten. Woher weiß die Firma, dass es genau diese Ziele sind, die ihr helfen ihre Vision zu erreichen und nicht andere? Die Antwort ist: sie weiß es nicht. Es kann sein, dass es diese Ziele sind, es können auch andere sein. Und viel schlimmer: sie weiß noch nichteinmal, ob das Gesamtziel erreicht wird, wenn alle Einzelziele erreicht werden. Ganz anders beim True North.

Mit diesem Vorgehen würde die Firma ein Ziel zum Beispiel mit  “Jeden Tag entsteht eine Innovation” formulieren, welches dann für alle Abteilungen gelten würde. Der Support, die F&E-Abteilung und jeder einzelne Mitarbeiter müssten sich dann zusammen die Frage stellen, welchen Anteil am Innovationsprozess sie derzeit haben, wie lange es derzeit dauert, von einer Idee zur Innovation zu kommen und wie sich diese Zeit verkürzen lässt. Da es sich um ein Idealziel handelt, liegt der Fokus hierbei auf dem nächsten Verbesserungsschritt, der Target Condition, die hilft, sich schrittweise in Richtung True North zu bewegen.

True North - Workshop example

Ableitung des True North aus der Vision

Wie toll das funktioniert, zeigte mir folgende Erfahrung. Ein Kunde von mir wollte die Transformation hin zu einer Agilen Organisation starten. Er wollte wieder mehr “Spirit in die Mannschaft bringen” und “innovativer” werden. Gemeinsam fanden wir heraus, dass der Wunsch allein nicht ausreichen wird, um eine erfolgreiche Veränderung zu starten. Wir nahmen uns vor, es mit einem True North zu probieren und luden dazu die gesamte Führungsmannschaft zu einem zweitägigen Workshop ein.

Wir starteten mit der Vision, die der Geschäftsführer mit dem Führungskreis ausgearbeitet hatte und überlegten uns, was mögliche Schritte sein könnten, diese zu erreichen. Als wir dann einige konkrete Ideen hatten, sind wir dazu übergegangen daraus allgemeine Prinzipien als Kandidaten für einen True North abzuleiten. So haben wir zum Beispiel aus den Ideen “lieben was wir tun”, “Trends von morgen erkennen” und “Mitarbeiter sind ihren Aufgabe gewachsen” den True North Punkt “Jeder Mitarbeiter arbeitet nur in seinen Stärken” entwickelt.

Von diesen hatten wir nach kurzer Zeit um die 20 – für einen True North deutlich zu viel. Also konsolidierten wir diese auf fünf Punkte, indem wir einerseits priorisierten; andererseits konzentrierten wir uns darauf, möglichst die Extremform der Richtung zu nehmen. Hatten wir zum Beispiel die Auswahl zwischen “Teams entscheiden woran sie arbeiten” und “Teams entscheiden alles”, präferierten wir Letzteres. Dies war zu Beginn für die Teilnehmer merkwürdig, da sie Angst hatten, diese Prinzipien würden zu weit gehen. Doch das ist genau die Idee: das Prinzip beschreibt den Idealzustand, nicht den Zustand an dem wir ankommen wollen. Es soll so definiert werden, dass es herausfordernd ist. Das bedeutet, dass es unmöglich erscheinen kann, den angestrebten Zustand – zum Beispiel “Teams entscheiden alles” – auch tatsächlich zu erreichen. In dieser Art stellten wir dann alle Punkte auf die Probe, kürzten, formulierten um und fassten zusammen bis wir schließlich die fünf Punkte hatten, die es in den True North schafften.

Beispielhafter Nordstern eines Unternehmens

Beispielhafter Nordstern eines Unternehmens

Und spätestens hier war klar: die Firma meint es ernst. Wer sich traut seinen Mitarbeitern solch einen True North anzubieten, meint es wirklich ernst mit der Veränderung.

Wie ernst meinen Sie es? Schreiben Sie uns.

Nachlese


Scrum funktioniert bei uns nicht – oder: wie wir ein Millionenprojekt retteten

Ich höre es immer wieder. Dieser eine Satz lässt mich nicht los. Bei Training, bei Workshops, bei Diskussionen an der Kaffeeküche und bei Vertriebsgesprächen: Scrum funktioniert bei uns nicht! Boom! Damit ist die Diskussion tot, der Gegenüber auf seiner Position verharrt und unwillig, weiteren Argumenten Beachtung zu schenken. Scrum funktioniert bei uns halt nicht.

Früher in der Beratung

Seit einiger Zeit erzähle ich dann immer eine Geschichte. Eine, aus meiner Zeit bevor ich Coach wurde. In der ich Projektarbeit gemacht habe und dieser ganze Hype um Scrum und Agil noch nicht Mainstream war. Ich war damals in der Beratung für Softwareentwicklung – Kunden holten uns, wenn sie ein Projekt nicht mit den eigenen Leuten stemmen konnten.
Eines Tages lag eine neue Anfrage auf unserem Tisch: Migration eines Altsystems in ein neues Verfahren bei einer Bundesbehörde. Das Projekt klang abenteuerlich: innerhalb weniger Monate sollten wir ein Verfahren abgelösen, migrieren und an einem festgelegten Stichtag einführen. Umfang ein paar hunderttausend Euro (dachte man). Die erste Phase des Projekts (intern abgewickelt) bereits Monate aus dem Plan, die mitgelieferte Spezifikation war weder leichtgewichtig noch konsistent und die Technologie Neuland für die internen Entwickler. Kurzum, das Projekt war bereits bei der Ausschreibung too late.

Waren wir radikaler!

Die einzige Chance die wir sahen: radikales Vorgehen. Wir führten Scrum ein. Naja, eigentlich „führten“ wir es nicht ein, vielmehr übernahmen wir mit Scrum einfach das Projekt. Wir waren schließlich keine Coaches damals, wir wollten für den Projekterfolg sorgen. Festgesetzte Regeln standen dem Projekterfolg im Wege und wir schafften diese radikal ab. Wir hatten das Glück, dass das Projekt bis hoch zu einem Minister bekannt war und wir diesem so alles unterordnen konnten.
Mit Auftragsbeginn haben wir gesagt, der Termin ist unhaltbar, doch das war egal: der Termin musste gehalten werden. Wir haben ca. 80% des Scopes reduziert und der Termin war immer noch unhaltbar. Das war immer noch egal. Wir haben die nichtfunktionalen Anforderungen reduziert und weiterhin gab es keine realistische Möglichkeit das Projekt in time abzuschließen.
Wenige Wochen vor Projektende gab dann schließlich der Lenkungsausschuss nach und gestand ein, dass das Projekt nicht im vorgesehenen Zeit- und Budgetrahmen durchführbar war. Wir hatten alle Optionen ausgeschöpft und auch die reduzierte Version des Projekts war im gegebenen Rahmen nicht realisierbar. Die Gegenstellen, die unseren Webservice auf Kundenseite anschließen mussten, brauchten nur Stunden um nach unserer Ankündigung ebenfalls die Reissleine zu ziehen und einzugestehen, dass sie kaum etwas hatten.

Und es funktionierte doch!

Doch das Projekt war damit nicht vorbei. Im Gegenteil: es war lebendiger denn je. Wir hatten nämlich zum Zeitpunkt des Scheiterns nicht nichts, sondern einen Teil der Funktionalität produktionsreif umgesetzt. Wir hätten also in Produktion gehen können, nur eben in einem erheblich kleinerem Masse als geplant. Und das war die Wende. Wir haben mit unserer radikalen Art die minimale Dauer gefunden, die die Anforderungen benötigten. Es gab kurzfristig keine Möglichkeit, daran etwas zu ändern. Es war die untere Schallgrenze, die wir stets durch laufende Software beweisen konnten.
Mit diesen Erfolgen im Rücken und dem Vertrauen des Managements in unsere Arbeit war der Rest fast zu einfach: TDD, Pair-Programming, Product-Owner-vor-Ort, automatisierte Tests, Probe-Livegang, Produktion, Regelbetrieb. All dies konnten wir mit der Überzeugung “Das hilft dem Projekt!” einführen. Dem Ziel ordneten wir alles unter, Regeln und Konventionen warfen wir über Bord und Veränderungen führten wir ein, wenn wir sie brauchten.
Es war ein harter Kampf bei dem wir viel Lehrgeld bezahlt haben. Wir waren nicht immer nett und heute, als Agiler Coach, würde ich Einführungen auch nicht mehr unbedingt so machen.

Probier es doch auch!

Wenn ich aber höre “Bei uns funktioniert Scrum nicht!” dann denke ich immer wieder an unser Projekt von damals und sage leise: “Du hast es nur noch nicht genügend probiert!