Donnerstag, 31. Dezember 2015

Kommentierte Links (VIII)

FS
  • Brand Eins: Vielen ist bewusst, dass sie Teil eines lächerlichen Spiels sind

  • Ein Interview mit Oliver Weyergraf, einem der Autoren des Buches Mad Business. Von ihm habe ich ein neues Wort gelernt, den "Betafehler". Der liegt vor wenn sich Prozesse in großen Organisationen verselbstständigen und Widersprüche erzeugen, etwa wenn eigentlich gut gemeinte Vorschriften zur Reise- oder Hotelbuchung die Angestellten zu langen Umwegen oder Verzögerungen zwingen. Auch weitere Diagnosen werden jedem bekannt vorkommen, der in großen Organisationen arbeitet: zu viel unrealistische Planung, zu viele Meetings, zu wenig Flexibilität, zu wenig Kompetenz oder auch so genannte "Nebenwährungen", die den eigenen Status anzeigen (Lage des Parkplatzes, Anzahl der Fenster im Büro, etc.). Zuletzt die tragische Diagnose - Unsinn hat oft einen selbstverstärkenden Effekt.

  • Washington Governor: 13-year-old sentencing errors discovered at state prisons

  • Ein weiteres Beispiel für die weitreichenden Auswirkungen von Software-Bugs. Laut dieser Pressemitteilung von Jay Inslee, dem Gouverneur von Washington State, führte fehlerhafte Software seit 2002 (!) dazu, dass Straftäter versehentlich aus den Staatsgefängnissen entlassen wurden bevor sie ihre Strafe abgesessen hatten. Den Recherchen einer lokalen NBC-Station zufolge konnte es so dazu kommen, dass bis zu zwei Jahre der Strafzeit wegfielen. Besonders bemerkenswert ist auch folgender Aspekt: die Fehlfunktion war schon seit 2012 bekannt, konnte aber bisher nicht vollständig behoben werden. Bis auf weiteres werden die Entlassungsdaten jetzt wieder manuell berechnet.

  • Informatik Aktuell: Slack-Time & Open Space – Nächstes Mal mit noch mehr Kuchen!

  • Ein Praxisbericht von Corinna Baldauf von der Firma Sipgate, in dem sie berichtet wie in ihrer Firma so genannte "Open Fridays" eingeführt wurden. In diesem Unternehmen sind das Tage in denen die Mitarbeiter ohne Anleitungen das machen können was sie für ihre Firma für sinnvoll halten. Interessant zum einen, weil sowohl die Häufigkeit (alle zwei Wochen) als auch die positiven Erfahrungen so nur in den wenigsten Unternehmen vorkommen. Interessant aber auch zum anderen, weil die zu Beginn gemachten und später korrigierten Fehler aufzeigen wie man es nicht machen sollte: Wenn man Selbstorganisation will darf man den Mitarbeitern nicht das Gefühl geben gegängelt und in feste Prozesse gepresst zu werden. Tut man es doch wird das Ergebnis von allen Seiten als unbefriedigend empfunden werden.

  • Dilbert: How to produce great Engineering

  • Das ganze Elend des Projekt-Staffings komprimiert in einem Comic-Strip. Um Geld zu sparen werden für das nächste Vorhaben vor allem billige Arbeitskräfte unter Vertrag genommen. Da diese nicht ohne Grund billig sind dauert alles länger, ausserdem entstehen ungeplante Zusatzaufwände durch ständiges Reparieren und Refactoring. Um im Plan zu bleiben werden nicht etwa die grundlegenden Fehler behoben, stattdessen werden die Mitarbeiter aufgefordert mehr und länger zu arbeiten und sich stärker mit der Arbeit zu indentifizieren. Dass das nicht funktionieren kann wird ignoriert und wer es anspricht wird abgebügelt. Ich habe solche Projekte erlebt, und jedes einzelne davon ist wirklich, wirklich teuer geworden.

  • Produktbezogen: Die besten Links des Jahres 2015

  • Sehr Meta: ein Link aus einer kommentierten Linkliste der auf eine kommentierte Linkliste verweist. Eine Sammlung von ausgewählten Artikeln des Jahres 2015, unter anderem zu den Themen (Selbst)Organisation und Agile.

Montag, 28. Dezember 2015

The final Countdown

FS
Bild: Wikimedia Commons/Jhong Dizon - CC BY 2.0

Da das Jahr fast zu Ende ist, einige Überlegungen zum Thema "nahende Deadline". Auch in Scrum oder anderen agilen Vorgehensweisen gibt es fixe Liefertermine, zum Beispiel wenn sich die Software ab dem ersten Januar anders verhalten muss um konform zu neuen Gesetzen oder Vorschriften zu sein. Und auch hier kommt es immer wieder vor, dass einige Sprints vor dem Termin absehbar ist, dass sich nicht alles umsetzen lässt was geplant ist. Wie soll man damit umgehen?

Ein verbreiteter Weg besteht darin, das Ergebnis zu "erzwingen". Die Teams werden angewiesen ihre Velocity zu steigern oder ihre Durchlaufzeit zu verringern und zu diesem Zweck Überstunden zu machen, ausserdem gibt man sich mit Umgehungslösungen und halbfertigen Funktionen zufrieden, solange alles "irgendwie funktioniert". Das kann kurzfristig zum Ziel führen, bringt aber mittel- und langfristig die bekannten Probleme:
  • überarbeitete Mitarbeiter machen mehr Fehler
  • die werden aufgrund der fehlenden Zeit nicht alle korrigiert
  • die Anwendung geht mit Notbehelfen in die Produktion
  • weitere Fehler werden gar nicht entdeckt, da die Zeit nicht für das Schreiben der Tests gereicht hat
  • das nachträgliche Fehlerbeheben und das Ersetzen der Provisorien erweist sich als aufwändiger als gedacht
Am Ende sind Aufräumarbeiten nötig, die sich über Monate ziehen können. Als Nebeneffekt kann ausserdem die Selbstorganisation der Teams schweren Schaden nehmen, wenn diese immer dann "wenn es dringend ist" in den Modus von Befehl und Gehorsam zurückmüssen.

Ein besserer Weg ist der, das Team in die Entscheidungen mit einzubeziehen. Das kann z.B. in Form einer offenen Fragestellung passieren: "Das hier sind die Vorschriften, die zum Stichtag erfüllt sein müssen, das ist die Zeit die wir noch haben - was müssen wir tun um am Tag X das gewünschte Ergebnis zu haben?" Ich selber habe mit diesem Vorgehen sehr gute Erfahrungen gemacht, allerdings bedarf es dazu bestimmter Bedingungen und Voraussetzungen:
  • Das Team muss ein gutes fachliches Verständnis des Produktes haben
    Nur wer das große Bild im Kopf hat kann überhaupt wissen was verzichtbar und was unverzichtbar ist. Wer bisher "an der kurzen Leine gehalten wurde" hat dieses Verständnis in der Regel nicht, und um es kurz vor Ende aufzubauen fehlt die Zeit.
  • Der Product Owner oder Auftraggeber muss bereit sein, auf bereits geplante Features zu verzichten
    Von der Komfortfunktion über den "machen wir immer so"-Workflow bis hin zum Lieblings-Gadget des IT-Chefs - alles was nicht zwingend zum kleinstmöglichen Funktionsumfang gehört muss rausfliegen. Wenn es wirklich so wichtig ist kann es in einem späteren Release nachgeholt werden.
  • Das Team muss (zumindest in dieser Phase) an einem Ort versammelt sein
    Nichts frisst Zeit und Effektivität in vergleichbarem Ausmaß auf wie langsame und schlechte Kommunikation. Unter Termindruck ist schlicht keine Zeit für unverständliche Telefonkonferenzen, langwierigen Email-Verkehr oder wackeliges Screen-Sharing.
Und wenn so etwas einmal geklappt hat kann das auch einen grundsätzlichen Aha-Effekt bedeuten. Die genannten Punkte machen nämlich auch im Normalbetrieb Sinn, selbst wenn es gerade mal keinen Zeitdruck gibt.

Mittwoch, 23. Dezember 2015

Jahresgespräche

FS
Bild: Flickr/Tech.Co - CC BY-SA 2.0

Würde man nach einer Möglichkeit suchen, mit möglichst geringem Aufwand einen möglichst großen Missstand zu beseitigen - für sehr viele Unternehmen der IT-Branche (und die IT-Abteilungen anderer Unternehmen) gäbe es eine einfache Lösung: sie müssten nur die Jahresgespräche ihrer Mitarbeiter abschaffen, jene Termine also in denen man gemeinsam auf das vergangene Jahr zurückblickt. In der Theorie sind diese zwar dazu da, Kommunikation zu verbessern, Vertrauen zu schaffen und die Mitarbeiter für die Unternehmensziele gewinnen, in der Realität sieht das aber oft anders aus, aus einer Reihe von Gründen:

1. Viele Vorgesetzte sind fachlich nicht in der Lage, die Leistung ihrer Mitarbeiter zu bewerten


Ein schwieriges Thema, aber eines an dem man nicht vorbeikommt. Leitende Angestellte kommen erstaunlich oft aus einem eher IT-fremden Bereich (z.B. BWL) und sind mit IT-Themen weitgehend überfordert. Andere sind nach Jahren oder Jahrzehnten im Management mit der eigentlichen Arbeit kaum noch vertraut. Komplexe Themen erscheinen ihnen zu einfach und einfache Themen zu komplex, die Geschwindigkeit des technologischen Wandels überfordert sie und die Einsicht, dass Anwendungen nicht nur aus Benutzeroberflächen bestehen fehlt. Da sie das aber nicht eingestehen wollen versuchen sie das Gespräch in andere Bahnen zu lenken, was zu einem weiteren Problem führt:

2. Leistung wird auf Messwerte (KPIs) reduziert


Überforderte Manager haben die Tendenz sich in einen "Messbarkeitswahn" zu flüchten. Statt konstruktiv darüber zu sprechen was gut lief und was man besser machen könnte wird versucht alles auf zählbare Werte herunterzubrechen. Im besten Fall geht es dabei um Fertigstellungsdaten oder generierte Umsätze, im schlimmsten Fall wird versucht Produktivität zu messen indem man die Einhaltung von Releaseterminen überprüft oder geschriebene Lines of Code, gefundene Bugs oder prozentuale Testabdeckung zählt. Und wenn man damit einmal angefangen hat ist der nächste Fehler nicht weit:

3. Belohnung und Bestrafung finden auf Basis dieser Messwerte statt


 In dem Moment in dem sich die KPIs als zentrales Bewertungskriterium etabliert haben ist es (scheinbar) einfach: Wer seine messbaren Ziele erreicht bekommt ein Lob, wer sie übertrifft bekommt einen Bonus, wer sie nicht erreicht einen Malus. Die Folgen eines solchen Vorgehens wirken sich fast immer negativ auf die Produktqualität aus: Um Releasetermine zu halten wird an Architektur, Dokumentation und Testen gespart und um geforderte Mengen zu liefern werden Codebasis und Defect-Backlog aufgebläht. Die Anwendungen werden dadurch schwerfällig, redundant und schwer zu warten. Und noch ein Nebeneffekt tritt auf:

4. In den Gesprächen geht es oft nur noch um die Festlegung von zählbaren Zielen und um die Diskussion ob diese erreicht wurden


Zur Erinnerung: Kommunikation zu verbessern, Vertrauen zu schaffen und Mitarbeiter für Ziele zu gewinnen sollte das eigentliche Ziel sein. Stattdessen ist es zu oft so, dass sich die Mitarbeiter zunächst für die Zahlen des letzten Jahres rechtfertigen müssen. Wenn Erfolge nicht klar zuzuordnen sind müssen sie beweisen, dass sie dazu beigetragen haben und im Misserfolgsfall findet eine Beweislastumkehr statt - jetzt müssen sie beweisen, dass sie nicht schuld daran sind. Die Zahlen für das nächste Jahr sind häufig "anspruchsvoll" und von noch weiter oben vorgegeben (d.h. nicht verhandelbar). Selbst wenn ausserdem noch ein vertrauensbildender Teil oder ein Personalentwicklungsgespräch vorgesehen ist, kann das jetzt nur noch scheitern. Und apropos Vertrauen und Personalentwicklung:

5. Für Vertrauensbildung und Personalentwicklung sind Abstände von einem Jahr zu lang


In zwölf Monaten kann sich viel ändern. Durch neue Produkte von Konkurrenten ändert sich der Markt, die Technik entwickelt sich weiter, neue gesetzliche Regulierungen haben unerwartete Auswirkungen, Kollegen kommen und gehen und beeinflussen damit die Leistung der Abteilungen, etc., etc. Das alles sind Faktoren die in die Bewertung der Leistungen des letzten Jahres einfließen müssten, genau wie Grippewellen, Infrastrukturausfälle oder insolvente Lieferanten. Das alles in einem jährlichen Termin zu berücksichtigen ist nahezu unmöglich, allein die Auflistung aller relevanten Faktoren würde ewig dauern, ganz zu schweigen von der Diskussion über ihre Auswirkungen. Da das nicht geht entsteht Unmut auf beiden Seiten: der Mitarbeiter fühlt sich ungerecht behandelt, der Vorgesetzte hat das Gefühl nur mit nicht überprüfbaren Ausflüchten konfrontiert zu werden.

Aber wenn nicht so, wie dann?


Flexibler, in kürzeren Intervallen, ohne festes Schema, ohne falsche Anreize.
  • Zunächst einmal müssten solche Gespräche in kürzeren Abständen stattfinden, beispielsweise monatlich. Und dazu müsste auch genug Zeit zur Verfügung stehen. Nur so können alle relevanten Faktoren berücksichtigt und Ziele ggf. angepasst werden.
  • Die Bewertung dürfte nicht mehr auf einer quantitativen sondern auf einer qualitativen Ebene stattfinden. Dazu wäre es notwendig, dass der Vorgesetzte auch fachlich kompetent ist, was selbstverständlicher klingt als es ist.
  • Es müsste auf jeden Mitarbeiter und seine Situation individuell eingegangen werden, also weg mit einheitlichen Gesprächsleitfäden und Checklisten.
  • Und zuletzt müssten sämtliche Anreizsetzungen kritisch hinterfragt werden. Wenn ein individuelles Ziel negative Auswirkungen auf Teamarbeit oder Produktqualität haben kann, dann sollte man es nicht vorgeben. Auch hier gilt aber: um das erkennen zu können braucht es Fachkompetenz.
Es ist übrigens nicht so als ob es das nicht bereits gäbe, viele Unternehmen haben ihre Prozesse bereits entsprechend angepasst oder sind gerade dabei das zu tun. Genausoviele verharren aber noch in den alten Mustern und führen weiterhin Jahresgespräche durch die eher Schaden anrichten als Nutzen stiften. Und wenn es immer wieder nach diesen Gesprächen zu Kündigungen kommt, ist die Verwunderung groß.

Montag, 21. Dezember 2015

Ein Bild sagt mehr als 1000 Worte (IX)

FS
Eine schöne Visualisierung vom Bent Flyvbjerg, über dessen unsichtbare Hände des Projektmanagements ich ja schonmal etwas geschrieben hatte.

Donnerstag, 17. Dezember 2015

Zertifizierungen schaden nicht - oder doch?

FS
Bild: Wikimedia Commons/XXconquistadorXX - CC BY-SA 2.0

Über den Nutzen und Wert der Agile- und Scrum-Zertifizierungen von Scrum Alliance, Scrum.org, ISTQB, ISQI, PMI, Prince2, TÜV1 und wer weiß wem sonst noch gibt es deutlich auseinandergehende Meinungen. Von nützlichem Grundlagenwissen bis sinnlosem Geldverbrennen ist alles dabei, die Wahrheit dürfte wie so oft in der Mitte liegen. Konsens herrscht allerdings darüber, dass sie zumindest nicht schaden - dachte ich zumindest bis vor kurzem. Bei Menschen die in großen Consulting-Unternehmen sozialisiert wurden kann es nämlich durchaus einen Minuspunkt bedeuten wenn man Inhaber mehrerer verschiedener Zertifikate ist.

Um zu verstehen wie es dazu kommen kann muss man die interne Struktur einiger dieser Unternehmen kennen. Viele von ihnen rekrutieren die Berater die sie zu ihren Kunden schicken in einem internen Projektmarkt. Ähnlich wie Freelancer auf dem normalen Markt muss man sich auf die hier ausgeschriebenen Stellen bewerben und ein Auswahlverfahren durchlaufen bevor man angenommen wird. Wer dabei aussortiert wird fällt allerdings nicht in die Untätigkeit zurück sondern wird angehalten sich weiterzuqualifizieren, etwa durch Trainings, Fortbildungen oder eben Zertifizierungen.

Was eigentlich dazu gedacht ist die Chancen beim nächsten Projekt zu verbessern kann sich im schlimmsten Fall zum Stigma auswachsen: Wer in größerem Ausmaß Zertifizierungen gesammelt hat gerät in den Verdacht, dass er von vielen Projekten  abgelehnt wurde, woraus negative Rückschlüsse auf Qualifikation, Teamfähigkeit, Selbstdarstellung oder Ähnliches abgeleitet werden. Zunächst ist das ein rein internes Phänomen großer Beratungshäuser, das aber auch Auswirkungen auf andere Unternehen haben kann - wenn ein Unternehmensberater in das Management einer anderen Firma wechselt nimmt er seine Vorurteile im Regelfall mit.

Im Großen und Ganzen dürfte es zwar der Ausnahmefall sein, ganz ausschließen kann man es aber nicht: Möglicherweise bringt die Zertifizierung bei der nächsten Bewerbung keinen Bonus sondern einen Malus. Man kann es eben nicht jedem Recht machen.


1No kidding: Der TÜV bietet Scrum-Zertifizierungen.

Dienstag, 15. Dezember 2015

Scaled Agile: Hybrid-Strukturen vs. Meta Teams

FS
Ein Thema das mich seit meinem ersten agilen Projekt begleitet ist die Frage nach der Skalierung. Dass Scrum in kleinen Teams funktioniert sieht noch fast jeder ein, sobald es in Größenordnungen von fünf Teams aufwärts geht kommen aber Zweifel auf. Einer der häufigsten Einwände: da sich die Teams selbst untereinander koordinieren müssen steigt mit jedem weiteren dazukommenden der Kommunikationsaufwand. Früher oder später ist der nicht mehr zu bewältigen und die Koordination bricht zusammen. Die Teams zerschießen sich dann gegenseitig den Code, arbeiten redundant oder bauen inkompatible Komponenten. Als Lösung wird von klassischen Managern häufig ein Hybrid-Modell installiert: die Entwicklungsteams arbeiten weiter agil, oberhalb von ihnen wird ein Wasserfall aufgesetzt, der die Anforderungen erfasst und auf die Teams verteilt (das bekannteste Framework dieser Art ist das Scaled Agile Framework, bzw. SAFe). Ein solches Modell sieht etwa so aus:


Auf den ersten Blick mag das zwar ganz sinnvoll erscheinen, in der Realität kollabiert die Kommunikation in diesem Modell aber erst recht. Wenn z.B. Team 1 bemerken sollte, dass versehentlich eine nicht umsetzbare Anforderung in eine Story geflossen ist, muss es das an die nächsthöhere Ebene zurückmelden. Diese muss dann gegebenenfalls auch Team 2 zurückrufen, da auch dieses von der Falschannahme betroffen ist. Da aber der Weg von Team 1 nach oben und von dort wieder nach unten Zeit in Anspruch nimmt hat Team 2 bereits mit der Arbeit begonnen. Die war damit umsonst und kann jetzt weggeworfen werden. Noch verheerender wird es wenn von dem Fehler in der Anforderung auch eines der Teams drei bis sechs betroffen ist: der Feedbackweg geht dann noch weiter nach oben und von dort wieder nach unten, die Benachrichtigung der anderen Teams erfolgt noch später, noch mehr Zeit und Geld werden verschwendet. Das ist also kein sinnvoller Weg.

Es bleibt die Frage: Wenn nicht so, wie dann? Dass sich jedes Team mit jedem anderen direkt abstimmt führt ja auch zu Problemen (siehe oben). Ein möglicher Ausweg geht so:


Man sieht: ein deutlich flacheres Modell. Der hier gewählte Lösungsansatz ist der, dass thematisch oder technisch verwandte Teams enger kooperieren als andere. Die Teams eins und zwei arbeiten beispielsweise gemeinsam am CMS, drei und vier am Shop, fünf und sechs an verschiedenen Mobile-Apps. In den zusammengehörigen Teams finden engere Abstimmungen statt, etwa zwischen den POs (die sogar ein Meta-PO-Team bilden können) und zwischen den Entwicklungteams (durch gemeinsame Groomings, Reviews, etc.). Die verschiedenen Gruppierungen stimmen sich dann direkt (ohne koordinierende Management-Ebene) mit den jeweils anderen ab, etwa in Form eines Scrum of Scrums. Reibungsverluste gibt es zwar auch hier (ganz vermeiden kann man die im skalierten Vorgehen nie), sie sind aber deutlich geringer als im oben gezeigten Modell. Zum Einen weil es kaum Kommunikationswege über mehrere Hierarchieebenen gibt, zum anderen weil die Entwickler ohne technikfremde Zwischenpersonen direkt miteinander kommunizieren können. Im Großen und Ganzen erfolgt die Koordination so wesentlich effektiver.

Was dabei allerdings klar sein muss: auch dieses Modell ist nicht universell anwendbar. Es ist eine Lösungsmöglichkeit, die zwar besser als das Hybrid-Modell funktioniert, je nach Kontext aber weiter angepasst werden muss. Für diese Anpassungen gibt es dann wieder weitere Möglichkeiten wie z.B. Communities of Practice, Gilden, teamübergreifende Plannings und Backlogs oder Unterstützungs-, bzw. Spezialistenteams. Das sind dann aber wieder Themen für sich.

Donnerstag, 10. Dezember 2015

Scrum-Kochen

FS
Diese Woche haben wir beim Bonner Scrumtisch etwas gemacht was ich schon lange ausprobieren wollte: Scrum-Kochen, also die Zubereitung eines (Abend)Essens nach Scrum-Regeln. Die jeweils 40 Minuten lange Vor- und Zubereitung eines Gangs entspricht einem Sprint, die einzelnen Teile (z.B. Fleisch, Beilage, Tisch decken) entsprechen einer Story, einzelne Tätigkeiten (Schneiden, Stampfen, Servietten falten) entsprechen den Tasks. Und genau wie in der Software-Entwicklung gibt es auch hier ein Kanban-Board und die Rollen und Regeln von Scrum. Für das Aufteilen einer Story in Tasks gibt es beispielsweise ein Planning.


Um das Ergebnis vorwegzunehmen: es entstand ein sehr gutes und leckeres Essen. Genauso wichtig waren aber auch die Erkenntnisse, die ich für einen möglichen Einsatz dieser Idee bei einem Kunden mitgenommen habe1:
  • Regeln sollten vorab und sehr klar definiert und kommuniziert werden: Dass vor dem Sprintbeginn ein Backlog Refinement liegen sollte (um zu klären was mit den vorhandenen Zutaten überhaupt gekocht werden kann) und dass es während des Sprints kurze Scrum Meetings am Board geben sollte war nicht für alle gleich offensichtlich.
  • Es sollte vorher eine kurze Einführung in die Küche stattfinden: Ceranfelder die sich bei Bedienfehlern selbst ausschalten oder dezent getarnte Mülleimer können ein hartnäckiges Impediment sein.
  • Die Koch-Erfahrung der Teilnehmer sollte berücksichtigt werden: Wer die "Komplexität" der Zubereitung oder die "Velocity" der Teammitglieder falsch einschätzt wird möglicherweise einen unrealistischen Forecast abgeben.
  • Es sollten mehrere Sprints (Gänge) mit vergleichbarem Aufwand eingeplant werden, damit sich über die "Iterationen" Lerneffekte feststellen lassen. Auch dass man für Inspect & Adapt Retrospektiven benötigt sollte in der Zeitplanung berücksichtigt werden.
  • Es sollte immer genug Amaretto vorhanden sein.
Es war also nicht nur lecker und unterhaltsam, es war auch lehrreich. Was kann man mehr wollen? Und vielen Dank an Chefkoch.de für das Bereitstellen der Küche (zum Eintrag im Chefkoch-Blog). 


1Hintergrund des Scrum-Kochens ist, dass damit die Methode spielerisch vermittelt wird und auch von Personen ohne IT-Kenntnisse verstanden werden kann

Dienstag, 8. Dezember 2015

Thomas Tuchel Rulebreaker

FS
Fussball ist ja extrem beliebt, wenn es darum geht, Vorbilder für jegliche Art von Teamarbeit zu finden. Oft erschöpft sich das in relativ flachem Sprücheklopfen ("Du bist immer nur so gut wie Deine Mannschaft", "In der Nachspielzeit geben wir noch mal Gas", etc.), manchmal ist aber auch erstaunlich inspirierend. Hier etwa im Rahmen eines Vortrags des Mainzer und Dortmunder Trainers Thomas Tuchel, der mit erstaunlicher Leichtigkeit vieles von dem anspricht, was sich auch im modernen Management wiederfindet: Trial & Error, Inspect & Adapt, Leitplanken statt Vorschriften, Anreize statt Bestrafungen, Servant Leadership, Selbstkritik und Motivation.

Freitag, 4. Dezember 2015

The Zombie Cage

FS
Zu den Problemen in einem meiner vergangenen Jobs gehörte der klassische Konflikt zwischen Projekt und Linie. Auf dem Papier waren einige Kollegen zu 50% von ihrer Linientätigkeit freigestellt, Ausnahmen davon gab es nur wenn äusserst dringende Aufgaben anlagen. Das Problem: es war praktisch immer irgendetwas äusserst dringend. Infolgedessen konnte es durchaus vorkommen, dass der eine oder andere dem Projekt tage- oder sogar wochenlang nicht zur Verfügung stand.

Das gegenüber dem Kunden zu thematisieren gestaltete sich unerwartet schwierig - obwohl ständig einzelne Aufgaben auf unserem Kanban-Board "feststeckten" sorgte die Arbeit der anderen Kollegen dafür, dass insgesamt ein beständiger Flow stattfand, in dem die Blockade der einzelnen Tasks, bzw. Personen nur noch schwer sichtbar war. Das für die Überplanung der eigenen Mitarbeiter verantwortliche mittlere Management konnte so immer behaupten, dass es gar kein Problem gäbe, schließlich ginge es doch beständig voran und alles würde abgearbeitet. Um die Blockaden so sichtbar zu machen, dass sie sich nicht mehr kleinreden liessen suchten wir nach einer guten Visualisierung und erfanden den Zombie Cage.


Der Zombie Cage war eine einzelne Box unterhalb des eigentlichen Boards, in die alle Tasks verschoben wurden, die während der letzten vier Meetings nicht bewegt worden waren. Durch ihre Platzierung auf dem Board waren diese Tasks bis dahin "lebendig" (d.h. in Arbeit befindlich) erschienen, obwohl sie in Wirklichkeit schon längst "tot" (aus dem Bearbeitungsstatus herausgefallen) waren, daher der Name. Sie nach unten zu verschieben erfülte zwei Zwecke: zum einen führten sie jetzt weiter oben nicht mehr zu "Work in Progress-Stauungen", zum anderen konnte das mittlere Management die personell bedingten Blockaden nicht mehr wegreden. Als besonders hilfreich erwiesen sich dabei die ungewöhnliche Benennung und die auffällige Gestaltung des Cage, die das sporadisch vorbeikommende obere Management immer wieder dazu bewegten diesen Bereich genauer anzusehen.

Plötzlich waren die Blockaden ein regelmässiges Thema in den Projektleitungsrunden und das Problem der Überplanung wurde offensichtlich. Letztendlich führte die Situation dazu, dass die überplanten Kollegen auf Druck von ganz oben ganz aus dem Projekt herausgenommen wurden, da es zu offensichtlich war, dass sie gar keine Zeit für eine zielführende Mitarbeit hatten. Die Nichtverfügbarkeit der ursprünglich zugesagten Ressourcen war damit offiziell beschlossen und führte auch zu einer Anpassung der Projektplanungen, die damit wieder ein Stück realistischer wurden. Gegen Ende war der Zombie Cage dann nur noch selten in Benutzung, alleine seine Anwesenheit sorgte aber dafür, dass Überplanungsversuche kaum noch stattfanden.
Powered by Blogger.