Kommentierte Links (LXXXVII)
Bild: Pixabay / Buffik - Lizenz |
Agile, Scrum, Kanban, Change Management. Und der Rest.
Bild: Pixabay / Buffik - Lizenz |
Grafik: modernagile.org - CC BY-SA 4.0 |
Es soll ja Menschen geben denen sogar ein so minimalistisches Framework wie Scrum noch immer zu viele vorgegebene Regeln, Rollen und Meetings hat. Für diese Menschen (und erfunden von einigen von ihnen) gibt es einen der minimalistischsten agilen Ansätze: Modern Agile. Keine Rollen, keine Meetings, keine Sprints und keine Vorgaben. Nur vier Prinzipien und einige empfohlene Praktiken, die man befolgen kann aber nicht befolgen muss.
Die Prinzipien sind Make People Awesome, Make Safety a Prerequisite, Experiment & Learn Rapidly und Deliver Value Continuously. Es handelt sich bei ihnen nicht um konkrete Handlungsanweisungen sondern um grundlegende Maximen, an denen man jede seiner Handlungen messen kann. Jede Handlung die man im beruflichen Kontext vornimmt sollte auf mindestens eines der Prinzipien einzahlen, ist das nicht der Fall sollte man hinterfragen ob man sie wirklich braucht.
Hinter Make People Awesome (mache die Menschen grossartig) verbirgt sich sowohl eine Leitlinie für den Umgang mit den Käufern und Nutzern des eigenen Produkts als auch eine für den Umgang mit den eignenen Mitarbeitern. Die Idee dahinter ist, dass Produkte und Firmen kein Selbstzweck sind sondern nur Mittel um Nutzern und Mitarbeitern grösstmögliche Selbstentfaltung und Produktivität zu ermöglichen. Diese sollte daher im Mittelpunkt von Produkt- und Organisationsentwicklung stehen.
Make Safety a Prerequisite (mache Sicherheit zur Vorbedingung) umfasst in erster Linie die psychologische Sicherheit, also die Gewissheit im Arbeitskontext alle Meinungen zu äussern und Fragen stellen zu können ohne dafür angegriffen, gedemütigt oder von oben herab behandelt zu werden. In einer weiteren Deutung gehört dazu auch die Arbeitssicherheit, also das Vorhandensein von Techniken und Routinen zur Verhinderung und Begrenzung von Unfällen und Schäden.
Experiment & Learn Rapidly (experimentiere und lerne schnell) ist am deutlichsten als agiles Prinzip erkennbar. Über das klassische Inspect & Adapt geht es allerdings hinaus, da es nicht nur die regelmässige Überprüfung von Teilergebnissen beinhaltet sondern auch die Gewinnung von Wissen durch ergebnisoffene Experimente. Wichtig ist, dass das schnell geschehen soll, die Lern- und Experimentier-Zyklen also möglichst kurz sein sollen.
Deliver Value Continuously (liefere kontinuierlich Mehrwert) geht in eine ähnliche Richtung. In einer bewussten Abkehr von Jahres-, Quartals- und sogar Sprint-Releases soll die Auslieferung neuer Features und Services nicht nur in kurzen Abständen erfolgen sondern auch möglichst regelmässig, idealerweise täglich. Dabei soll nicht bloss ein einmal gefasster Plan abgearbeitet werden, sondern auch der soll sich als Ergebnis der Auslieferung ständig ändern.
Obwohl ursprünglich nicht vorgesehen haben die Erfinder von Moder Agile später ein Mapping ihrer vier Prinzipien auf das Manifest für agile Softwareentwicklung adaptiert:
Neben dem Prinzipien-Teil gibt noch die zu Beginn genannten empfohlenen Praktiken. Zu ihnen gehören unter anderem Charter-Veranstaltungen zu Projektbeginn, Elemente aus Lean Startup und Lean UX, Continuous Integration, Refactoring, Blameless Retrospectives, Radar Charts und Pair- bzw. Mob-Programming. Umgekehrt wird auch von einigen Elementen abgeraten, unter anderem von Sprints, Product Owner- und Scrum Master-Rollen und Story Points.
Wenn die Q&A Session nach einem Vortrag ähnlich lang ist wie der Vortrag selbst, dann ist das ein gutes Zeichen, und bei diesem Vortrag von Marty Cagan ist genau das der Fall. Alleine für sich genommen wäre das schon bemerkenswert, noch bemerkenswerter wird es angesichts des eigentlich destruktiven Themas: was man alles bei agilen Transformationen falsch machen kann. Das nicht nur verständlich sondern auch unterhaltsam aufzubereiten ist hohe Kunst.
Interessant ist darüber hinaus der Seitenaspekt, dass Cagan (genau wie viele andere Thought Leader aus dem Silicon Valley) aus seiner Abneigung gegen Frameworks wie Scrum und SAFe kein Geheimnis macht. Im Übrigen mit dem ebenso interessanten Unter-Seitenaspekt, dass die Variante von Scrum die er kritisiert eher Cargo Cult ist (was seine Kritik wiederum relativiert). Ein bisschen ist das die ironische Pointe: ausgerechnet dieses Missverstehen und falsche Umsetzen der Frameworks hat es nicht in seine Ausführungen über falsch verstandene agile Transitionen geschafft.
Bild: Unsplash / Christina Morillo - Lizenz |
Obwohl sie in keinem der bekannten agilen Frameworks vorkommt gibt es eine "agile Rolle" die in immer mehr Unternehmen anzutreffen ist. Die Rede ist vom Agile Coach (eine Einführung in diese Rolle gibt es hier). Gleichzeitig ist aber auch in immer Unternehmen eine Unzufriedenheit mit den Stelleninhabern zu spüren, die als "zu gefühlig" oder "zu esoterisch" wahrgenommen werden. Warum das so ist müsste noch erforscht werden, eine Hypothese habe ich aber bereits.
Der Begriff des Coach ist im Englischen sehr vieldeutig. Er kann so unterschiedliche Ausprägungen umfassen wie den Financial Coach, der etwa dem deutschen Schuldenberater entspricht, den Sports Coach, den man in Deutschland als Trainer bezeichnen würde und den Vocal Coach, dessen Pendant in Deutschland der Gesangslehrer wäre. Ihnen allen ist gemeinsam, dass sie ihre Coachees nicht nur auf Wunsch unterstützen sondern sie auch anleiten und ihm Spar-, Lern- oder Trainingsziele setzen.
Lediglich einige Spezialausprägungen nehmen sich in dieser Hinsicht völlig zurück und überlassen ihrem Coachee völlig die Entscheidung darüber was durch das Coaching erreicht werden soll und wann es stattfinden soll. Beispiele dafür sind Career-Coaches und Life Coaches, mit deren Hilfe nicht feste Ziele wie Schuldenfreiheit oder Turniersiege erreicht werden sollen, sondern deren Konsultation eher zu Selbsterkenntnis und Klarheit über die eigenen Wünsche und Ziele führen soll.
Betrachtet man mit dieser Differenzierung im Hinterkopf die Tätigkeit von Agile Coaches über verschiedene Unternehmen hinweg fällt eines auf: was von vielen Umgebungen nachgefragt und erwartet wird ist eher der erste Typ, also die auf Organisations- und Kultur-Entwicklung bezogene Entsprechung eines beratenden und anleitenden Finanz- oder Sport-Coaches, die Berufsausübung vieler Agile Coaches ist aber eher an die der sich selbst zurückhaltenden Career- und Life-Coaches angelehnt.1
Erkennungszeichen einer solchen Grundeinstellung sind z.B. der Grundsatz kein Coaching anzubieten das der Coachee nicht aus eigenem Antrieb angefragt hat oder der Verzicht auf Ratschläge oder Anleitungen, an deren Stelle dann "powerful Questions" treten, durch deren Beantwortung der Coachee selbst seine Wünsche oder Konflikte erkennen kann ("Was willst Du damit erreichen?", "Was macht das mit Dir?", "Woran merkst Du, dass Du Dein Ziel erreicht hast?", etc.).
In einem personenbezogenen Lebens- oder Karriere-Coaching ist ein derartiges Vorgehen auch richtig, dort wo es Organisationen darum geht flexibler, reaktionsfähiger oder kundenzentrierter zu werden geht es aber oft am Bedarf vorbei. Hier würde es eher Sinn ergeben auf Fehler aufmerksam zu machen, Potentiale aufzuzeigen und good Practices zu vermitteln - im Coaching durchaus möglich, nur eben in der gerade genannten Verengung nicht.
Warum diese Verengung vieler Agile Coaches auf Career- und Life-Coaching-Praktiken trotzdem stattfindet ist damit die spannende Frage. Eine validierbare Antwort darauf gibt es zwar noch nicht, (dafür wäre eine umfangreiche qualitative Sozialforschung nötig, die es meines Wissens nach zu diesem Beruf noch nicht gibt), dafür aber einige Erklär-Ansätze, an denen eine Diskussion (oder irgendwann auch eine Validierung) ansetzen kann.
Zum einen wäre das der in den letzten Jahren deutlich sichtbare Brain Drain zwischen den beiden Welten. Bedingt durch ein grosses Angebot bei gleichzeig relativ geringer Nachfrage (und Zahlungsbereitschaft) rutschen viele personenbezogene Coaches mit der Zeit in die wirtschaftliche Prekarität ab, gleichzeitig ist in den meistens IT-nahen agilen Organisationen der Fachkräftemangel spürbar. Ein Wechsel macht also für beide Seiten Sinn.
Ausserdem haben die meisten Unternehmen es bis heute nicht geschafft passende berufliche Entwicklungspfade für ihre Scrum Master, Agile Coaches, Team Coaches, etc. zu entwickeln. Auf der Suche nach irgendetwas Passendem stossen viele auf die Coaching-Ausbildungen, die aber meistens personenbezogene Praktiken wie Auftragsklärung, Powerful Questions und Ähnliches in den Mittelpunkt stellen und Organisationsentwicklung und soziale Systeme wenig oder gar nicht behandeln.
Dazu kommt noch eine Motivation die naheliegenderweise meistens verschwiegen wird: Bequemlichkeit. All den Fragen, Hilfsersuchen und Problemen die sich im Umfeld agiler Transitionen ergeben nur mit Gegen- und Sinnfragen zu begegnen kann ein einfacher Weg sein um sich nicht selbst mit diesen oft schwierigen Themen beschäftigen zu müssen. Natürlich ist Bequemlichkeit nicht in allen Fällen das unterschwellige Motiv, in vielen aber eben doch (ggf. auch unbewusst).
Für die Unternehmen die gerade zu besetzende Agile Coach-Stellen haben würde das bedeuten, dass sie selbst regulieren können ob sie diese mit den passenden Menschen besetzen. Nötig dafür wäre es, Vorkenntnisse oder Interesse an Organisationsentwicklung und Analyse sozialer Systeme zu Einstellungs- und Beförderungs-Voraussetzungen zu machen und diese Themen auch in die beruflichen Entwicklungspfade dieser Rollen einzubauen.
Sollte das dazu führen, dass dann der Fachkräftemangel wieder zuschlägt und sich keine geeigneten Kandidaten mehr finden kann es natürlich eine denkbare Alternative sein doch wieder auf Life- und Karriere-Coaches zurückzugreifen, deren Interesse vor allem auf den einzelnen Menschen liegt, allerdings sollte man dann auch die eigenen Erwartungshaltungen an sie überdenken. Überspitzt gesagt - wer jemanden einstellt der gerne Menschen nach ihren Gefühlen fragt erhält eben genau den.
Ein ganz eigenes Thema wäre übrigens noch die Gruppe der systemischen Coaches, die es fast ausschliesslich im deutschsprachigen Raum gibt. Zu denen vielleicht ein anderes mal mehr.
Bild: Wikimedia Commons / r2hox - CC BY-SA 2.0 |
Schon seit einigen Jahren steht es auf meiner To Do-Liste, etwas über technische Schulden zu schreiben. Dieses Phänomen ist in praktisch jedem Softwareentwicklungs-Vorhaben vorhanden und es kann zu spürbaren Verzögerungen führen, bis hin zum totalen Stillstand, dadurch ist es auch eine der Hauptquellen für Frustration und Demotivation der Entwickler. Gleichzeitig ist es einem grossen Teil der oberen Management-Ebenen bis heute unbekannt, was viele Fehlplanungen in IT-Projekten erklärt.
Entwickelt wurde der Begriff als bewusste Analogie zu den finanziellen Schulden. In beiden Fällen werden Verbindlichkeiten aufgenommen um kurzfristig handlungsfähiger zu werden, in beiden Fällen weiss man von Anfang an, dass man sie irgendwann zurückzahlen muss und in beiden Fällen ist es auch klar, dass die Rückzahlung um so teurer wird je später sie stattfindet, da für die gesamte Dauer der Verschuldung Zinsen fällig werden, die zusätzlich abzuzahlen sind.
Der Hintergrund dieser Analogie ist, dass ihr Erfinder, Ward Cunningham, sie sich auf einem Projekt einfallen liess auf dem Buchhaltungs-Software entwickelt wurde. Um für die Fachabteilungen die Probleme der IT nachvollziehbar zu machen wählte er für seine Erklärungen Begriffe die dort bekannt waren, darunter eben den der technischen Schulden. Durch einen Konferenz-Vortrag wurde der Begriff dann bekannt und fand auch branchenübergreifend Verwendung.
Zu Stande kommen technische Schulden dadurch, dass irgendwann in der Software-Entwicklung "schnelle Lösungen" gesucht werden, die dann dadurch erreicht werden, dass eigentlich wichtige Dinge weggelassen werden. Das kann eine verständliche Strukturierung und Formatierung des Code sein, eine Absicherung durch automatisierte Tests, das Integrieren neuer Software-Versionen, etc. Ohne sie wird zwar das kurzfristige Ziel erreichbar, dafür werden ab jetzt alle Weiterentwicklungen schwieriger.
Diese Schwierigkeiten können z.B. daraus bestehen, dass es ab jetzt unverhältnismässig viel Zeit erfordert den schlecht geschriebenen Bestands-Code überhaupt zu verstehen, dass Fehler aufgrund der fehlenden Tests zu spät gefunden werden (und schlimmstenfalls bereits neue Funktionen auf ihnen aufbauen, die dann auch überarbeitet werden müssen) oder daraus, dass veraltete Software-Versionen ständige Probleme mit Stabilität, Kompatibilität oder Regel-Konformität haben.
Wichtig ist dabei eine Abgrenzung: es handelt sich nicht bei nicht jeder qualitativ schlechten Software um technische Schulden, der Begriff ist nur dann angemessen wenn sie bewusst "aufgenommen" wurden. Und genau wie bei finanziellen Schulden kann es auch bei technischen Schulden sinnvoll sein sie aufzunehmen, etwa um vor der Konkurrenz am Markt zu sein. Problematisch werden sie vor allem dann wenn die Rückzahlung immer wieder verzögert wird.
Nicht abgebaute technische Schulden türmen sich mit der Zeit auf, sorgen dafür, dass selbst kleine Veränderungen einem immensen Umsetzungsaufwand mit sich bringen und erzeugen dadurch den Wunsch nach noch mehr "schnellen Lösungen", die dann zu noch mehr technischen Schulden führen. Dreht dieser Kreislauf sich zu lange kann es zu "technischem Bankrott" kommen, einer Situation in der Weiterentwicklung und schlimmstenfalls sogar Betrieb der Systeme nicht mehr möglich sind.
Um es dazu nicht kommen zu lassen empfiehlt sich ein konsequenter Abbau der technischen Schulden, und auch der lässt sich mit Finanz-Analogien erklären. Beide Schuldenberge verschwinden nicht über Nacht sondern nur nach und nach, bei beiden sollte man für den Abbau einen spürbaren Teil der verfügbaren Mittel einplanen und bei beiden sollte man die Schulden mit den besonders hohen Zinsen zuerst angehen, die weniger kostenintensiven dagegen erst später abbauen.
Gegebenenfalls kann sogar eine "Umschuldung" sinnvoll sein, z.B. indem für einige Zeit auf ein Versions-Upgrade verzichtet wird um dafür die alte Version stabilisieren und durch Tests absichern zu können. Überlegungen wie diese zeigen auf, dass technische Schulden nicht per se schlecht sind. Es kann gute Gründe dafür geben sie aufzunehmen - man sollte sich nur der Konsequenzen bewusst sein.
Bild: Wikimedia Commons / Rainer Flassig - CC BY-SA 2.0 |
Stellen wir uns folgende Situation vor: ein Product Owner (oder ein Mensch in vergleichbarer Rolle) kommt zu seinem Team. Er stellt ihm die neueste User Story vor, die auch von allen sofort verstanden wird. Als es dazu kommt eine Aufwandsschätzung abzugeben sind die Entwickler aber ratlos - die Umsetzung müsste in einer Technologie oder in einem System erfolgen mit denen sie noch nie gearbeitet haben. Ohne diese Erfahrungswerte können sie den Aufwand nur raten.
Im klassischen Projektmanagement würde man versuchen dieses Problem zu lösen inden man einem team-externen Experten die Aufwandsschätzung überlässt, z.B. einem Architekten, Lead Developer oder Business Analysten. In einem agilen Vorgehen wäre das aber keine gute Lösung, schliesslich soll die Aufwandsschätzung hier nach Möglichkeit von den Mitgliedern des umsetzenden Teams selbst kommen.1 Wie versetzt man die also in die Lage das zu tun?
Eine Lösung dafür kommt aus dem Extreme Programming, dem Framework dem wir auch die User Story verdanken, und nennt sich Spike Solution (oft abgekürzt zu Spike). Sie besteht in Abgrenzung zur Perfect Solution oder Possible Solution, bei denen zumindest grundlegend klar ist wie gross der Aufwand ist und die direkt neue Funtionen erzeugen sollen.2 Die Spike Solution soll das nicht, ihr Ziel ist es lediglich, die Entwickler mit der Technik vertraut zu machen.
But what if you haven't done anything like this story before? What if it's the beginning of the project and you haven't done anything at all? The answer is simple: do some experimenting. We call such an experiment a "Spike Solution" to remind us that the idea is just to drive through the entire problem in one blow, not to craft the perfect solution first time out. You need to know how long it will take you to do something.
Ron Jeffries and Chet Hendrickson, Extreme Programming Installed, S.55
Was Ron Jeffries und Chet Hendrickson, zwei der drei Erfinder von Extreme Programming, hier sagen streicht die entscheidenden Punkte heraus: wenn die Erfahrungswerte für eine Aufwandsschätzung zu gering sind können diese dadurch hergestellt werden, dass so lange Experimente mit der Anwendung durchgeführt werden bis die Vertrautheit gross genug für eine Schätzung ist. Um möglichst schnell an diesen Punkt zu kommen sollten diese Experimente, bzw. Spikes, möglichst klein sein.
In dem Buch aus dem sein Zitat stammt nennen die beiden auch Beispiele dafür. Eines besteht darin einem System einfache Rechenoperationen hinzuzufügen, ein anderes in der Änderung der Formatierung einer Zahl. Derartige Experimente sind in wkurzer Zeit abschliessbar, geben dem der sie durchführt aber trotzdem ein Gefühl davon wie aufwändig die Arbeit in diesem System ist. Falls das noch nicht reicht kann ein zweites oder drittes folgen, bis ein Grundverständnis da ist.
Wichtig ist dabei, dass der im Rahmen der Spikes erzeugte Code im Anschluss nicht weiterverwendet wird und stattdessen gelöscht werden kann. Nur so kann sichergestellt werden, dass nicht versehentlich etwas beschädigt wird und dass das Experiment dort stattfinden kann wo die Unklarheit am grössten ist. Den bereits erzeugten Code irgendwie weiterverwenden zu wollen ist zwar ein verständlicher Reflex, allerdings ist davon aus den genannten Gründen abzuraten.
Soviel zu den Warum und Wie einer Spike Solution, es bleibt aber noch eine Frage - warum eigentlich der Name? Er leitet sich ab von einem einfachen Stech-Werkzeug mit dem Löcher gebohrt werden können. In Analogie dazu ist es durch den Spike möglich in die "Black Box" des unbekannten Systems Löcher zu bohren, wodurch Licht in das Innere fällt, das dadurch sichtbar und begreifbar wird.
Bild: Pixabay / Bertsz - Lizenz |
Zu den interessanteren Modellen der Change-Kommunikation gehört das so genannte Overton-Fenster, benannt nach Joseph Overton, einnem US-amerikanischen Lobbyisten. Ursprünglich von ihm entwickelt und nach seinem Tod von dem Think Tank Mackinac Center for Public Policy weiter ausdifferenziert beschreibt es den Teil des Meinungsspektrums dessen Ansichten mehrheitsfähig sind (umgekehrt sind diejenigen ausserhalb des Overton-Fensters es nicht).
Die Grundannahme ist, dass Ansichten von den Menschen in eine von sechs Kategorien einsortiert werden: Undenkbar, Radikal, Erträglich, Schwierig, Mehrheitsfähig und Allgemein Anerkannt. Die letzte Kategorie liegt aber nicht am Rand sondern in der Mitte des Spektrums, von ihr aus nimmt die Mehrheitsfähigkeit in beide Richtungen ab. Bedingt dadurch haben nur Meinungen in der Mitte des Spektrums die Chance umgesetzt zu werden, nur sie liegen in dem Fenster um das es hier geht.
Um das mit Konzepten aus der Politik zu veranschaulichen: In der Mitte befindet sich z.B. die Ansicht, dass die soziale Marktwirtschaft eine erstrebenswerte Gesellschaftsform ist, ganz links der Kommunismus, ganz rechts der Manchester-Kapitalismus, dazwischen die äquivalenten Ansichten zu den Übergangstypen wie zum Beispiel der Chicagoer Schule, dem Nordischen Modell, etc. Entsprechend gibt es auch bei anderen Themen extreme Meinungen auf beiden Seiten mit einer kompromissfähigen gemeinsamen Schnittmenge in der Mitte.
Der spannende Punkt ist jetzt, dass das Overton-Fenster sich verschieben kann, bzw. dass Ansichten sich mit der Zeit in es hinein- oder aus ihm hinausverschieben können. Das kann durch Überzeugungsarbeit und Aufklärung geschehen aber auch durch Täuschung und Demagogie, gegebenenfalls sogar nahezu unbemerkt durch schleichende Normalisierung (oder deren Gegenstück, gewissermassen die schleichende Entnormalisierung).
Der Erfolg oder Misserfolg von Change-Projekten in grossen Organisationen lässt sich oft gut mit dem Overton-Fenster erklären. Dass Konzepte wie #NoEstimates oder Beyond Budgeting fast nie umgesetzt werden liegt daran, dass sie als unsagbar oder radikal gelten, selbstorganisierte Teams haben sich in den letzten Jahren von erträglich und schwierig zu mehrheitsfähig verschoben, (oberflächliche) Bekenntnisse zur Agilität sind allgemein anerkannt.
Auch die Gründe die zu diesen Verschiebungen geführt haben lassen sich nachvollziehen. Zu ihnen gehört die Soft Power der agilen Frameworks, die sie irgendwie hip und modern erscheinen lassen und die Erfolgsgeschichten bekannter agil arbeitender Firmen wie Spotify oder Youtube aber (leider) auch der agil-industrielle Komplex, dem man bei aller berechtigten Kritik nicht absprechen kann ein sehr geschicktes Marketing zu betreiben.
Umgekehrt passen auch Gegenbewegungen in dieses Muster. Dass ein Scrum Master nur ein einziges Team begleiten sollte ist z.B. in den frühen Phasen vieler Transitionen mehrheitsfähig, alleine durch den Fachkräftemangel kommt es aber fast überall zu einer schleichenden Normalisierung einer parallelen Begleitung mehrerer Teams oder einer Ausübung in Teilzeit, parallel zu einer Tätigkeit als Entwickler oder Projektmanager. Am Ende ist die Vollzeit-Begleitung nur noch eines Teams eher schwierig.
Wie immer kann alleine die Kenntnis eines Modells wie des Overton-Fensters hilfreich sein, da sie es ermöglicht Verschiebungen in der Mehrheitsfähigkeit zentraler Konzepte zu erkennen und so auf Handlungsbedarf aufmerksam zu werden. Es kann aufbauend darauf auch daran gearbeitet werden sie in dieses Fenster hinein- oder sie aus ihm herauszubewegen, gegebenenfalls kann sogar die Arbeit an denen die zur Zeit noch als radikal gelten auf später verschoben werden um Kräfte zu sparen.
Zuletzt sind auch spannende Differenzierungen möglich. Für die meisten Scrum Master-Communities dürfte etwa SAFe deutlich ausserhalb des Overton-Fensters liegen, für die meisten Management-Kommittees dagegen deutlich innerhalb - selbst wenn beide zum selben Unternehmen gehören. Viele Konflikte dürften so auf einmal viel besser zu verstehen sein als zuvor.
Bild: Pexels / Fauxel - Lizenz |
Neben den an den Wänden hängenden Task- oder Kanban-Boards und dem Pair Programming ist die dritte sofort sichtbare Besonderheit an die sich jeder erinnert, der zum ersten mal ein agil arbeitendes Team oder Projekt besucht, das so genannte Daily Stand Up, also ein kurzes (meistens nur wenige Minuten dauerndes) Abstimmungs- oder Status-Meeting der Teams, das nicht im Sitzen sondern im Stehen abgehalten wird, meistens vor einem der gerade genannten Boards.1
Der Eindruck ist derartig prägend, dass viele Beobachter und Teams davon ausgehen, das Stehen während der täglichen Abstimmung wäre ein verpflichtender Teil des agilen Arbeitsmodus. Tatsächlich ist es aber nur von einem der bekannten Frameworks in sein Regelwerk aufgenommen worden, vom Scaled Agile Framework (siehe hier). Scrum und Extreme Programming kennen es zwar, allerdings nur als Good Practice die man nicht umsetzen muss, die aber aus folgenden Gründen empfehlenswert ist:
Sich stehend auszutauschen hat mehrere Vorteile - durch das Aufstehen wird der Blutkreislauf in Bewegung gebracht, wodurch Sauerstoff ins Gehirn gelangt und die Konzentration steigt, durch das Stehen wird es schwerer es sich (versehentlich) bequem zu machen und den Termin in die Länge zu ziehen, die physische Distanz zum Board an dem gearbeitet wird lässt sich minimieren und (dazu gleich mehr) das Meeting kann stattfinden ohne einen Meetingraum buchen zu müssen.
All das scheint heute extrem naheliegend, ist aber vermutlich eine nachträgliche Begründung. Die ersten Daily Scrum Meetings fanden Anfang der 90er Jahre noch durchgehend im Sitzen statt und auch im den offiziellen Beschreibungen von Scrum wurde (und wird) das Thema nicht erwähnt. In den um das Jahr 2000 entstandenen Beschreibungen von Extreme Programming ist es dagegen wie selbstverständlich enthalten, sein Ursprung liegt also irgendwo in den 90ern.
Wo genau lässt sich wie bei vielen anderen Praktiken nicht genau sagen, vermutlich weil den Erfindern die Tragweite ihrer Entscheidung nicht bewusst war und sie daher nicht dokumentiert wurde. Anekdoten aus der Frühzeit der agilen Bewegung lassen aber vermuten, dass die ersten Stand Ups ohne grössere Überlegungen etabliert wurden und auf Sachzwängen beruhten. Ein Beispiel dafür ist dieses hier, aus dem 2001 erschienenen Buch Agile Software Development with Scrum.
Paul Martin had a Daily Scrum in his office which was so small everybody had to stand up. [...] This was one of the best running Scrum Teams I have seen. (Jeff Sutherland, private correspondence)
Wer schon einmal die Umstellung eines Unternehmens von klassischem Management auf agile Vorgehensweisen begleitet hat wird diese Geschichte sofort nachvollziehen können. Meetingräume für tägliche Termine zu buchen ist durch deren Knappheit schwierig bis unmöglich,2 sie in den eigenen Räumen stattfinden zu lassen ist die naheliegende Alternative. Da dort aber meistens zu wenig Platz oder zu wenig Stühle vorhanden sind muss man eben stehen.
Ein verstärkender Faktor dürfte gewesen sein, dass viele der ersten agilen Teams sich inoffiziell und sogar in bewusster Abgrenzung zu den offiziellen Prozessen etablierten. Da diese Prozesse sehr stark mit der traditionellen Art der Meeting-Durchführung (sitzend um einen Tisch) identifiziert wurden war die Abweichung davon ein bewusstes Statement der Andersartigkeit, wie sich Joe Kinsella (Mitglied des ersten Scrum Teams) erinnert.
By not choosing one of the many available conference rooms, the meeting instantly had a sense of informality and urgency.
Joe Kinsella, The First Stand-up
Bei den noch später gestarteten Teams dürfte sich irgendwann durch die weite Verbreitung des Stehens in den Meetings die Ansicht verbreitet haben, dass das einfach der richtige Weg wäre, auch wenn die ursprünglich dafür sprechenden Gründe irgendwann in Vergessenheit geraten sind. "Wenn man agil arbeitet macht man das einfach so." ist ein häufig zu hörendes Argument, mit manchmal kuriosen Folgen wie z.B. dem Stehen vor dem eigenen Rechner in Remote-Meetings.
Da diese und andere Methodismen und Formalismen häufig zu Abwehrreaktionen führen ist es sinnvoll die ursprünglichen Gründe für die Einführung der Stand Up-Meetings mit dem Team dessen Mitglied oder Coach man gerade ist zu diskutieren. Wenn es diese auch für sich als gegeben ansieht können die Meetings weiter im Stehen durchgeführt werden. Wenn nicht können sich einfach alle setzen.