Schlagwort-Archive: agile

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!