Donnerstag, 30. August 2018

Kommentierte Links (XL)

Bild: Pixabay / Bru-nO - Lizenz
  • Steve Denning: For Agile, It's The Best And The Worst Of Times

    Der Auftakt zu einer ganzen Serie von Beiträgen über die Ankunft der Agilität im Mainstream. Interessant sind zwei Gedanken. Zum einen, dass die Agilität nach ihrem "offiziellen Startschuss" (dem agilen Manifest) 15 Jahre lang "in den Schatten gelebt hat" bevor sie von den Managern und Unternehmensberatern dieser Welt entdeckt wurde. Demzufolge wurde sie im Wesentlichen ohne diese beiden Gruppen entwickelt und ausdefiniert, was man ihr heute anmerkt: statt der Hierarchie und dem Börsenwert stellt sie den Mitarbeiter und den Kunden in den Mittelpunkt. Der andere Gedanke ist der, dass die Agilität durch ihre untrennbare Verbindung mit moderner Software-Entwicklung nur schwer korrumpierbar ist - wer heute Software zu einem vertretbaren Aufwand erstellen möchte kommt an echter Agilität nicht vorbei, wodurch sie immer wieder zurück auf die Füsse gestellt wird.

  • Lars Vollmer: Denkfehler der New‑Work‑Bewegung

  • New Work ist ein ähnlich schwammig formulierter Begriff wie Agilität, man kann sehr, sehr viel in ihn hineininterpretieren. Eine verbreitete Deutung ist die, dass man arbeiten kann was man will, wann man will und von wo man will. Das ist lange Zeit  illusorisch gewesen, und in den meisten Berufen ist es das heute noch. Nur dort wo der Fachkräftemangel die Unternehmen beutelt lassen sie sich darauf ein. Vollmer geht davon aus, dass das zwar arbeitnehmerfreundlich ist, in der Regel aber auf Kosten der Wirtschaftlichkeit und der Kundeninteressen geht. So gesehen ist New Work auch nicht kompatibel mit Agilität, was überall dort zu Problemen führt wo man versucht beides gleichzeitig einzuführen.

  • Ralph Cibis: Let's charge story points

    Die meisten agile Coaches und Practitioner betrachten es als Dogma: Story Points sind eine abstrakte, fast schon fiktive Berechnungseinheit, die weder zur Schätzung von Zeit noch zur Ermittlung von Kosten herangezogen werden darf. Wie realitätsfremd das ist zeigt sich häufig an der fehlenden Antwort darauf wofür sie dann gut sind. Ralph Cibis geht einen pragmmatischeren, wenn auch nicht unriskanten Weg - wenn den Beteiligten klar ist, dass Story Points kontextbezogen, volatil und fehlbar sind, dann sind sie als Indikator brauchbar, und zwar nicht nur für Planungen sondern auch für Preiskalkulationen. Das ist auch richtig, wird aber in der Realität meistens mit dem Customer-Vendor-Antipattern kollidieren. Funktionieren wird dieser Ansatz nur dort wo die Geschäftsbeziehungen von Ergebnisoffenheit, Respekt und Verständnis geprägt sind. Das gibt es zwar, aber ganz ehrlich - wie häufig?

  • Willem-Jan Ageling: 5 controversial topics that were removed from Scrum

    Eine Geschichtsstunde. Wie oben von Denning beschrieben haben sich agile Ansätze wie Scrum über längere Zeit im Biotop der Software-Entwicklung ausdifferenziert, wobei viele der ursprünglichen Unstimmigkeiten oder Irrwege entfernt oder korrigiert wurden. Was das bedeutet sieht man an den von Ageling aufgeführten ehemaligen Elementen von Scrum, die grösstenteils zwischen 2010 und 2013 aus den offiziellen Regeln entfernt wurden (nur die Abschaffung der verpflichtenden drei Fragen ist neueren Datums. Sie fand erst 2017 statt). Wären sie noch in Kraft würde vieles wesentlich holperiger funktionieren als es heute der Fall ist.

Montag, 27. August 2018

Deine Muda: Motion

Bild: Wikimedia Commons / Roger & Renate Rössing - CC BY-SA 3.0
Vierter Teil der Deine Muda-Serie. Die dritte Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist die Bewegung, auf Englisch Motion. Da sie häufig mit der ersten Muda (Transportation) verwechselt wird macht eine Differenzierung Sinn: unter Transportation versteht man die Bewegung von Gütern, unter Motion die Bewegung von Personen.

Dass diese Personenbewegung als nicht gewinnbringende Tätigkeit gesehen wird liegt daran, dass eine Person während sie sich bewegt nicht in der Lage ist an wertschöpfenden Tätigkeiten teilzunehmen. Wer zu Fuss, mit dem Fahrrad, dem Motorrad, der Strassenbahn oder dem Auto unterwegs ist kann währenddessen nicht arbeiten - wenn er im Auftrag der Firma reist kostet er aber Geld (Zeit/Gehalt). Bis zu einem gewissen Grad kann das in einigen Fällen ausgeglichen werden (z.B. ist arbeiten im Zug eher möglich, zumindest am Computer), auch hier geht aber Zeit durch Planung, Umsteigen, etc. verloren.

Sogar innerhalb eines Gebäudes kann dieses Problem auftreten, besonders dann wenn es sich um Hochhäuser oder weitläufige Anlagen handelt. Ein Scrum Team bei dem die Entwickler im Erdgeschoss sitzen, der PO aber im 10. Stock wäre ein solcher Fall. Ein Team das seinen Arbeitsbereich im Flügel G hat, seinen Meetingraum aber im Flügel B ein anderer. Beides sind real existierende Beispiele aus deutschen Konzernen und in beiden Fällen werden erstaunliche Zeitmengen in Fluren, in Treppenhäusern und in Fahrstühlen verbracht.

Die Besonderheit der Motion-Muda ist, dass für ihre Beseitigung zwei Ansätze möglich sind: man kann die Mitglieder eines Teams oder einer Wertschöpfungskette in einen Raum setzen (oder zumindest auf einen Flur) oder man kann versuchen sie durch digitale Lösungen zu vernetzen, etwa durch Chatprogramme, Videotelefonie und Ticket-Tools. Aus Sicht eines Agile- oder Lean-Coaches wäre Ansatz eins zu bevorzugen, da er einfachere und direkte Kommunikation ermöglicht, in den meisten grossen Organisationen findet man eher Ansatz zwei, da er mit den ohnehin an jedem Arbeitsplatz stehenden Computern einfacher umzusetzen ist.

Dort wo ernsthaft an der Reduzierung von Personenbewegung gearbeitet wird tritt übrigens ein interessanter Seiteneffekt auf: in den meisten Fällen führen diese Bemühungen dazu, dass Teams kleiner, autarker und crossfunktionaler werden. Nur dann lässt sich die Anzahl der für die tägliche Arbeit nötigen Meetings herunterfahren. Der Grossteil aller Personenbewegungen hat nämlich das gleiche Ziel: einen Meeting-Raum.

Donnerstag, 23. August 2018

(Nicht) wie Spotify werden

Bild: Flickr / Jon Åslund - CC BY 2.0
Ein bemerkenswerter Trend der letzten Jahre ist der, dass sich viele Unternehmen im Rahmen ihrer agilen Transition nicht mehr amerikanische Firmen als Vorbild nehmen sondern eines aus Schweden: Spotify (ein aktuelles Beispiel hier). Wie immer in solchen Fällen gibt es mehr als einen Grund dafür, z.B. den, dass Skandinavien aus europäischer Perspektive nicht so entrückt wirkt wie das Silicon Valley, oder den, dass das Produkt von Spotify (Musikstreaming) auf den ersten Blick einfach verständlich zu sein scheint. Was aber für viele Manager besonders verlockend erscheint ist etwas anderes - das mit diesem Firmennamen verbundene Skalierungsmodell.

Der durch Präsentationen und Videos bekannt gewordene Ansatz ist scheinbar einfach: gemeinsam an einem Teilprodukt arbeitende Teams bilden einen Tribe, Spezialisten innerhalb eines Tribes bilden ein teamübergreifendes Chapter und Menschen mit gleichen Interessengebieten schliessen sich unternehmensweit zu Gilden zusammen. Die Frage wie sich agile Teams koordinieren scheint damit beantwortet zu sein: durch ihre Tribes und Chapter. Beziehungsweise (und hier wird es für mittlere Manager interessant) durch ihre Tribe Leads und Chapter Leads.

Das Problem dieses Modells: niemand kann sagen ob es wirklich dauerhaft funktionieren kann, denn es es ist selbst bei Spotify nur wenige Jahre lang umgesetzt worden - und auch das nur in der IT und nur während einer explosionsartigen Wachstumsphase, die wenige Rückschlüsse auf die Umsetzung in einem stabilen Kontext zulässt. Cliff Hazell, einer der agilen Coaches und Chapter Lead bei Spotify, hat es in einem Vortrag auf den Punkt gebracht: für seine Firma ist das Tribe/Chapter/Gilden-Modell eines von gestern (ab Minute 28:10 beschreibt er wo es mittlerweile geändert wurde).

Cliff Hazell - Be best at getting better @ LKCE17 from Lean Kanban Central Europe on Vimeo.

Kurz gesagt - wer Tribes/Chapter/Gilden bei sich einführt der wird nicht so wie Spotify, sondern höchstens so wie die IT-Abteilung dieser Firma im Zeitraum 2012 - 2014 gewesen ist. In vielen Firmen führt selbst diese Erkenntnis aber nicht dazu, dass man dieses Modell nicht mehr anstrebt, im Gegenteil. Selbst das Spotify von damals erscheint vielen Betrachtern besser als der Ist-Zustand ihres eigenen Unternehmens. Ist es nicht bereits ein ausreichendes und lohnendes Ziel diesen Zustand zu erreichen? Wäre das nicht für einen ersten Schritt genug?

Die Antwort: Jein. Selbst wenn man davon absieht, dass das Tribe/Chapter/Gilden-Modell den Beweis seiner langfristigen Funktionsfähigkeit noch schuldig geblieben ist bleiben Probleme. Dass es zeitweise in Schweden funktioniert hat liegt nämlich nicht zuletzt an der mit ihm verbundenen Systemlandschaft und Software-Architektur. Erst durch die auf Microservices beruhende technische Autonomie der einzelnen Teams konnten sich die Chapter und Gilden auf fachliche Koordination und interessenbasierten Erfahrungsautausch beschränken und konnten auf die Vorgabe und Kontrolle von technischen Standards verzichten. In der klassischen Unternehmens-IT mit ihren zahllosen Abhängigkeiten würde das meistens ins Chaos führen.

Ist Spotify also kein Vorbild? Doch, ist es, nur ganz anders als erhofft. Wie oben im Video zu sehen ist das Ziel der dortigen Firmenorganisation, sich ganz im Sinn des agilen Change Managements ständig weiterzuentwickeln und nie stabil zu werden, sich ständig anzupassen, zu verändern und zu experimentieren. Das ist sehr zur Nachahmung empfohlen. Ausgerechnet für die meisten Menschen die behaupten "wie Spotify" werden zu wollen ist das aber nicht mehr das was ihnen gefällt. Ihnen fehlt darin die (scheinbare) Einfachheit.

Montag, 20. August 2018

Zeitschätzungen, Erfahrungen und Prototypen

Bild: Wikimedia Commons / W. Carter - CC0 1.0
Es ist die grosse Frage nicht nur im agilen Kontext sondern auch im Rahmen der klassischen Produktentwicklung: "Sag mir, wann wirst Du fertig sein?" Seitdem zum ersten mal in der Geschichte der Zeit ein Mensch für einen anderen eine Arbeit verrichtet hat wird sie immer wieder gestellt, und zum grossen Verdruss des Fragestellers immer wieder falsch beantwortet. "Können die nicht genauer schätzen?" folgt immer wieder als Anschlussfrage. Die tragische Antwort: Nein, können sie nicht. Zumindest nicht in IT-Projekten.

Um zu verstehen warum das so ist empfiehlt sich zuerst ein Blick auf eine Industrie in der die grosse Frage sehr genau beantwortet werden kann. Nehmen wir die Auto-Industrie. Die grossen Automobilhersteller können z.T. bis auf die Minute genau kalkulieren wie lange es dauern wird ein Fahrzeug zusammenzubauen. Warum sie das können? Weil der Fertigungsprozess hochgradig standardisiert und dadurch berechenbar ist. Wenn aber die Standardisierung der Arbeitsschritte die Lösung ist, ist das nicht der Weg zu verlässlichen Schätzungen? Nochmals die tragische Antwort: Leider nein, zumindest nicht in der IT.

Die Voraussetzung der Standardisierung ist die Erfahrung. Erst durch die weiss man welche Schritte stabil immer wieder das gleiche Ergebnis bringen wenn man sie wiederholt. Und erst durch die Erfahrung weiss man in welchem Abstand zueinender zusammengehörige Schritte gestartet werden müssen, damit die so erzeugten Teilergebnisse gleichzeitig fertigwerden und ohne Verzögerung zusammengebaut werden können. Aber war diese Erfahrung schon immer da? Natürlich nicht.

Wann auch immer eine Auto-Firma (bleiben wir beim Beispiel) zum ersten mal mit einer Produktion beginnt, fehlen zu Beginn die Erfahrungswerte - sonst wäre es kein Beginn. Aufgrunddessen sind die ersten Prognosen durch die Bank unzuverlässig und die ersten Produktionsziele werden verfehlt. Erst nach Jahren ermöglichen die Erfahrungen einen reibungslosen und planbaren Ablauf. Das war so vor einem Jahrhundert bei Ford und das ist heute so bei Tesla.

Um den Exkurs Richtung Automobil abzuschliessen: die Aufwands- und Zeitschätzungen sind dann besonders genau wenn ein identisches Produkt bereits tausendfach erzeugt wurde und dadurch viele Erfahrungswerte vorliegen. Wurde es dagegen erst wenige Male erzeugt ist die Unsicherheit und Unplanbarkeit deutlich grösser, und vorherzusagen wie lange der Bau eines Prototypen dauern wird ist schwierig bis unmöglich. Und an der Stelle schlagen wir den Bogen wieder zurück zur IT - die baut nämlich nur Prototypen. Immer. Ausschliesslich. Sonst nichts.

Wenn auf vierhundert Millionen Rechnern Windows als Betriebssystem läuft, dann wurde das dafür nicht vierhundert Millionen mal gebaut sondern nur exakt einmal. Und dieses eine einzige Betriebssystem wurde dann auf alle vierhundert Millionen Rechner aufgespielt. Alles andere wäre auch wirtschaftlich unvernünftig - warum sollte man Windows in jahrelanger Arbeit für jeden Rechner neu entwickeln, wenn man es nur einmal bauen muss und dann quasi durch Copy und Paste beliebig oft vervielfältigen kann? Das Gleiche gilt auch für jede andere Software.

Wenn aber in der IT nur Prototypen gebaut (oder erweitert) werden, und wenn der für einen Prototypen nötige Aufwand nur schwierig bis gar nicht vorhersagbar ist, dann ist die Folge genau die, die weiter oben beschrieben ist. Es lässt sich nicht genau vorhersagen wann eine Software fertig entwickelt sein wird. Tragisch aber wahr. Das bedeutet natürlich nicht, dass man dem hilflos ausgeliefert ist, es gibt Möglichkeiten damit umzugehen. Aufwandsschätzungen gehören aber nur als begleitender Indikator dazu.

Donnerstag, 16. August 2018

Krisenkommunikation

Bild: Flickr / Katjung - CC BY-SA 2.0
Zu den interessanteren Medienbeiträgen der letzten Zeit gehört ein Interview mit dem Psychologen Reiner Kemmler zum Thema Krisenkommunikation auf Flughäfen. Auf den ersten Blick erscheint das Thema sehr spezifisch, auf den zweiten Blick finden sich aber viele Parallelen zur Agilität: eine bereits komplexe Ausgangssituation, unerwartete Geschehnisse mit zum Teil grossen Auswirkungen, autonom und unkoordiniert vorgehende Akteure, etc. Vieles lässt sich auf andere grosse Unternehmenen und Behörden übertragen.

Der Ausgangspunkt: die Krise

Wo Komplexität zu finden ist, da gibt es auch Krisen, das ist fast schon ein Naturgesetz. Ausfallende Flüge und gestandete Passagiere sind da nur ein Beispiel, andere wären insolvent gehende Geschäftspartner, disruptive Umwälzungem am Markt oder in der Technik, offensichtlich werdende Fehlplanungen, sich ändernde gesetzliche Rahmenbedingungen, Wirtschaftskrisen und vieles mehr. Sie alle stellen die betroffenen Organisationen vor grosse Herausforderungen, von denen es hier um eine gehen soll: wie kann die Krise so kommuniziert werden, dass Märkte, Mitarbeiter und Kunden beruhigt werden statt durch Panikreaktionen alles zu verschlimmern?

Verstärkung der Krise durch fehlendes Reaktionsvermögen

Es ist ein unschöner Klassiker: über Jahre werden Abäufe so auf Effizienz getrimmt, dass jeder Mitarbeiter zu fast hundert Prozent ausgelastet ist und fast jeder Prozess auf dem kritischen Pfad verläuft. Dass eine hundertprozentige Auslastung schlecht ist zeigt sich im Krisenfall - die für eine schnelle Reaktion notwendigen Kapazitäten und Freiräume wurden wegrationalisiert, jeder Zusatzaufwand führt zu Überlastung, Rückstauungen und Stillstand. Und wenn sich die Arbeit erst aufgestaut hat kann sie nur durch Überstunden wieder abgebaut werden, mit den bekannten Folgen: Übermüdung, Frustration, dadurch überhastete und fehlerhafte Kommunikation, die dann noch mehr Aufwände verursacht.

Herrschaftswissen und Flurfunk

Irgendwann ist es offensichtlich - sensible Informationen können während und nach ihrer Bekanntgabe nicht mehr ausreichend genug kommunikativ begleitet werden um Unruhe und Fehldeutungen zu vermeiden. Häufig führt das zu der Entscheidung, dass so lange mit der Bekanntgabe gewartet wird bis man glaubt die Lösung gefunden und umgesetzt zu haben. Allerdings ist das in der Regel nicht möglich, irgendwo sickern immer Teilinformationen durch, verbreiten sich, werden schlimmstenfalls aufgebauscht und sorgen für Misstrauen gegenüber offiziellen Verlautbarungen. Selbst wenn jetzt offen kommuniziert werden würde, gäbe es den Verdacht, dass Informationen zurückgehalten werden.

Endstadium: aus der Krise wird Chaos

Letztendlich treten genau die Gruppendynamiken und Absetzbewegungen auf die man vermeiden wollte. Verunsichert von der schwerfälligen und intransparenten Kommunikationspolitik versuchen Kunden, Partner und Mitarbeiter sich vorsorglich in Sicherheit zu bringen. Aufträge werden storniert, Projekte nicht verlängert, statt für das gemeinsame Ziel wird nur noch für die eigene Absicherung gearbeitet, ganze Abteilungen beschliessen "zu überwintern" bis sich die Situation beruhigt hat. Beruhigende Verlautbarungen werden grundsätzlich nicht mehr geglaubt sondern als Vertuschungsversuche interpretiert. Schlimmstenfalls setzt sich die Situation im kollektiven Gedächtnis der Organisation fest und belastet die Zukunft.

Aber wenn nicht so - wie dann?

Im Grunde durch die Umkehrung der oben genannten Antipattern. Statt die gesamt Organisation bis ins letzte Eck durchzuoptimieren müssen freie Kapazitäten vorhanden sein die auch kurzfristig Kommunikationsaufgaben übernehmen können sobald es nötig ist. Ein passender Vergleich wäre ein Feuerwehrmann, bei dem die Brandbekämpfung auch nur einen kleinen Teil der Arbeit einnimmt. Des weiteren empfiehlt sich grösstmögliche Offenheit von Anfang an. Klar und offen zu zu kommunizieren, dass es eine Krise gibt mag zwar zu Beginn schmerzhaft sein, das dauerhafte Misstrauen das sich aus dem Zurückhalten von Informationen ergibt ist aber langfristig um ein Vielfaches verheerender. Und wenn klar ist, dass Reaktionen möglich sind und bereits stattfinden verliert die Ungewissheit viel von ihrem Schrecken. Es ist ein Allgemeinplatz aller agilen Vorgehensmodelle - wenn man in der Lage ist kurzfristig auf Veränderungen zu reagieren ist es unkritisch wenn sich die Realität anders entwickelt als geplant.

Natürlich muss dafür auch die Gesamtorganisation zu Reaktionen in der Lage sein und nicht nur die Kommunikationsabteilung. Das ist aber dann ein Thema für sich.

Montag, 13. August 2018

Planning Poker

Bild: Wikimedia Commons / Rachmaninoff - CC BY-SA 4.0
Wer bereits Zeit in einem Scrum-Projekt verbracht hat wird das Bild kennen. Irgendwo stellt ein Product Owner eine Idee vor und bittet sein Entwicklungsteam um eine Aufwandsschätzung. Kurz darauf halten die Teammitglieder Karten oder Mobile Apps mit Zahlen darauf hoch und nehmen so die Schätzung vor. Da immer wieder nach dieser zunächst merkwürdig aussehenden Methode gefragt wird kommt hier eine Erläuterung dazu, zum so genannten Planning Poker.

Zunächst einige Kontextinformationen: mit Planning Poker werden normalerweise Story Points geschätzt. Story Points sind personenunabhängige Aufwandseinheiten und nicht mit Stunden und Tagen gleichzusetzen, mehr zu ihnen steht hier und hier. Und Planning Poker ist kein offizieller Teil von Scrum, man könnte es also auch weglassen. Es wird allerdings trotzdem von fast jedem Scrum Team genutzt, da es sich sich als good Practice durchgesetzt hat (mehr dazu hier).

Zur Anwendung: normalerweise werden alle Teammitglieder aufgefordert ihre Schätzung (Karte) in Ruhe auszuwählen, sie noch nicht zu nennen und zu warten bis auch die anderen damit fertig sind. Dann werden die Karten gemeinsam aufgedeckt. Dadurch wird vermieden, dass ein Meinungsführer die anderen bewusst oder unbewusst beeinflusst, die Schätzung ist dadurch repräsentativer.

Da die von den Teammitgliedern geschätzten Werte normalerweise nicht identisch sind kann im nächsten Schritt versucht werden ein einheitliches Verständnis zu erzielen. Immer wieder anzutreffen sind an dieser Stelle Mehrheitsentscheidungen oder Durchschnittswerte, wodurch aber Potential verschenkt wird. Besser ist es, wenn die oberen und unteren Grenzwerte erläutert werden, die Teammitglieder kommen dadurch oft zu Einsichten die sie selbst nicht gehabt hätten.

Neben diesen beiden sehr häufigen Vorgehensweisen gibt es auch weitere, die immer wieder anzutreffen sind. Manche Teams führen für die selbe Anforderung mehrere Schätzrunden nacheinander durch, bis alle die selbe Zahl hochhalten, andere nehmen alle Schätzungen ab einer bestimmten Punktezahl zum Anlass die jeweiligen Anforderungen kleinzuschneiden, wieder andere haben Joker-Karten, mit denen sie einen Experten konsultieren können, etc., etc.

Was all diesen Techniken geimeinsam ist: neben dem Ermitteln des (abstrahierten) Aufwandes steht beim Planning Poker auch ein zweites Ziel im Mittelpunkt - das bessere Verstehen der Anforderung. Die verschiedenen Anwendungsfälle der Karten können dafür sorgen, dass die Ideen des Product Owners gründlicher diskutiert und hinterfragt werden als es normalerweise der Fall wäre. Alleine das ist schon ein Mehrwert.

Donnerstag, 9. August 2018

Agile Roadmaps


Zu den klassischen Planungsinstrumenten gehören die so genannten Roadmaps. bei ihnen handelt es sich (vereinfacht gesagt) um einen Zeitstrahl auf dem verschiedene Fertigungsschritte und -phasen nacheinander und parallel zueinander angeordnet sind. Dieses Instrument hat unverkennbare Stärken: man kann planen was wann gemacht werden soll (ggf. auf dem kritischen Pfad), kann sequentielle Abhängigkeiten darstellen und den Fortschritt überprüfen. Wie viele anderen Planungswerkzeuge ist es aber auch denkbar unflexibel.

Roadmaps gehen immer von einer einzigen Ablauf-Reihenfolge aus, der die man für die ideale hält. Dass es mehrere Varianten geben kann von denen jede ihre Vor- und Nachteile hat geht dabei unter. Auch ist es in der Regel schwierig nachträgliche Änderungen vorzunehmen, und zwar nicht nur da diese den vorgegebenen Zeitplan durcheinanderbringen würden - alleine die Rechtfertigungen und Schuldzuweisungen dafür, dass der ursprüngliche Plan eben doch nicht ideal war, rauben Zeit und Energie.

Eine flexiblere Variante könnte sich an den Streckenempfehlungen der gängigen Karten- und Navigationsdienste orientieren. Gibt man in ihnen Start- und Zielpunkt ein erhält man verschiedene Optionen zwischen denen man wählen kann. Im Fall des oben gezeigten Screenshots bietet etwa die südliche Route in der Mitte noch eine Alternativstrecke, die nördliche aber nicht. Und während die nördliche und die mittlere Route mehrere grosse stausgefährdete Stellen haben hat die südliche nur wenige, führt dafür aber an mehreren Baustellen vorbei. Die Parallelen zu einer Projekt- oder Produktplanung sind offensichtlich.

Durch die frühen oder späten Abzweigungen lassen sich frühe oder späte Architekturentscheidungen symbolisieren, Systeme oder Teams mit begrenzter Bearbeitungskapazität stellen staugefährdete Stellen dar und Systeme an denen auch andere Teams und Projekte arbeiten sind Baustellen. Und sind derartige Faktoren transparent lassen sich auch andere Informationen zu ihnen in Bezug setzen. Nocheinmal zum Screenshot oben: die Südstrecke hat zwar eine etwas kürzere voraussichtliche Fahrtzeit (Projektdauer), durch die Baustellen aber auch ein ungleich höheres Risiko, dass etwas Ungeplantes passiert. Ist der Zeitgewinn dieses Risiko wert? Eine interessante Frage.

Man sieht: die flexiblere Roadmap bietet nicht nur alternative Wege, die ggf. auch eine spätere Umplanung ermöglichen, sie bietet zu den Varianten auch Kontextinformationen, die eine wesentlich differenziertere Abwägung ermöglichen als die klassische, lineare Roadmap. Und die Visualisierung in einer Form die fast jedem Menschen aus seinem Alltag bekannt ist bietet dazu noch einen wesentlich höheren Erkennungs- und Erinnerungswert. Auch das sollte nicht unterschätzt werden.

Dass diese Form der Planung nicht häufiger verwandt wird hat übrigens einen zentralen Grund: sie lässt sich kaum in Powerpoints und Planungstools darstellen sondern praktisch nur auf einer physischen Wand. Und Planung die nicht auf Powerpoints passt ist in vielen Organisationen keine richtige Planung. Das wäre aber ein Thema für sich.

Montag, 6. August 2018

Killing the Monster Merge

Eine enthusiastisch vorgetragene Einführung in das Thema Continuous Integration, und dazu noch eine die mit relativ wenig technischem Verständnis nachvollziehbar ist. Zwar mit einem kleinen Werbeblock ganz am Ende, aber den muss man sich ja nicht ansehen.

Donnerstag, 2. August 2018

Lernen, wie man nein sagt

Grafik: Pixabay / Geralt - Lizenz
Zu den wichtigsten Dingen die man lernen muss wenn man beginnt agil zu arbeiten gehört das "Nein"-sagen. Nur wenn man nicht mehr Arbeit beginnt als man beenden kann wird sie in vertretbarer Zeit fertig, nur wenn man nicht jeden Feature-Wunsch umsetzt vermeidet man kaum noch erweiterbare Bloatware, etc., etc. Das große Problem: viele Menschen haben das nie gelernt, zumindest im beruflichen Kontext nicht.

"Ein Nein akzeptiere ich nicht als Antwort" ist eine beliebte Management-Floskel, die man vom Kleinunternehmen bis zum Grosskonzern immer wieder findet. Die Mitarbeiter solcher Firmen lernen irgendwann, dass das Nein-sagen nur zu Eskalation, Druck und Stress führt und lassen es einfach. Stattdessen wird unkritisch fast alles abgenickt und zugesagt, selbst wenn diese Zusagen völlig unrealistisch sind. Erst kurz vor Schluss gibt es dann die Rückmeldung "Ging doch nicht".

Selbst wenn in diesen Kontexten ein Kulturwandel stattfindet in dem die Ablehnung unrealistischer und nicht zielführender Anforderungen möglich und erwünscht ist, tun viele Mitarbeiter sich schwer die jahrelange berufliche Sozialisation zu überwinden und sagen doch immer wieder Dinge zu, die bei realistischer Betrachtung eigentlich abgelehnt werden müssten. Wenn man es nicht gewohnt ist kann das Nein-sagen etwas sein was man wieder lernen muss.

Eine Methode die ich vor kurzem bei einem der von mir gecoachten Teams kennengelernt habe hat mir aufgrund ihrer Einfachheit gefallen: gegen Ende einer Retrospektive verteilte der Scrum Master fünf "Nein-Karten" an jedes Teammitglied. Die damit verbundene Übung - während des Sprints in fünf relevanten Situationen Nein sagen, die Situation auf der Karte notieren und in der nächsten Retrospektive vorstellen.

Als Effekt kommt es nicht nur dazu, dass mehr nicht zielführende Anfragen abgelehnt werden, die Teammitglieder bekommen auch Übung darin es zu tun. Und dadurch, dass die jeweiligen Situationen in der Retrospektive besprochen werden können, kommt auch eine Kommunikation darüber in Gang, wie man Ablehnungen ausspricht, welche Reaktionen darauf entstehen können und wie man mit denen konstruktiv umgeht. Auch das gehört nämlich zum Nein-sagen dazu.