Disclaimer

Moin,

der nachfolgende Beitrag verwendet bewußte literarische Überzeichnungen und soll zeigen, dass gerade das Thema Agilität und die Veränderung der Unternehmenskultur hin zu agilen Methoden auch einem Berater einiges abverlangen.
Letztlich ist das Ziel aber richtig und sollte konsequent verfolgt werden.

Nehmen Sie als Leser also nicht alles Ernst, was im nachfolgenden Text aufgeführt ist ... und viel Freude beim Lesen ...

Mein neues Projekt ist agil.
Ich meine wirklich agil.

Das Team ist klein, nur 6 Personen, viele sind neu und man hilft sich gegenseitig.
Das Backlog ist gut gefüllt, alle wissen was noch zu tun ist und was als nächstes ansteht und monatlich wird ein neues System angebunden oder eine Lösung geschaffen und produktiv genommen.

Nicht alles funktioniert auf Anhieb, testen wird zum Teil nachgeholt, die Retro findet eher in der Küche statt, mit der Frage:
"Was war gut, was lief richtig scheiße?" und dann wird das kurz geklärt. Eigentlich reicht dafür ein Espresso, maximal ein Cappuchino.

An der Wand hängt der Kalender mit den Urlaubseinträgen und Abwesenheiten, die Doku ist im Sharepoint abgelegt, nicht immer aktuell, aber lesbar
und der Plan für die nächsten 3 Monate steht an der Weißwandtafel im Projektbüro.
Eigentlich weiss jeder was anliegt, man sitzt ja in einem Büro. Diesen Monat die Risikodaten, nächsten Monat die Liqui-Strecke und dann sind da noch technologische Altlasten, die auch noch zu beheben sind. Das wird vermutlich im zweiten Monat ca. 50% der Zeit kosten, muss aber gemacht werden, damit die Performance nicht leidet. Effizienzgrad ca. 85%, keine Überstunden.

An der Wand hängt dann noch ein Zettel, darauf steht:

"Machen ist wie wünschen, nur krasser!".

Übrigends weiss keiner der Entwickler oder der Projektleiter wirklich, was agil bedeutet. Also zumindest nicht so richtig. Aber das gemeinsame Verständnis, das sie sich aufgebaut haben besteht aus den Begriffen

"Backlog", "Retro", "Daily", "Standup" und "machen!".

Das Büro hat übrigends 16 qm, ist mit 4 Personen besetzt (nicht alle sind immer das, aber dafür ist öfters mal jemand vom Fachbereich da, der Fragen beantwortet und beim Testen Unterstützung braucht).
Ist nicht so ganz Arbeitsplatz-Konform. Es gibt auch keine Metawandtafel oder Flipchart, keine Sofa-Ecke, keinen Kicker, kein Agile-Coffee (wenn man einmal vom Kaffee in der Automatenkantine absieht) und es gibt keinen Coach und keinen agile Master. Auch die Rolle des Produkt-Owners ist eher fließend, da es sich ja um ein regulatorisches Projekt mit einer Deadline handelt.

Der Fokus primär auf das Ergebnis gerichtet.

Es wurden die Tools eingesetzt, die da waren, weil es einfach darum ging, ein Datawarehouse zu entwickeln und Daten anzubinden, damit die Anforderungen termingerecht erfüllt werden können.
Also im Grunde genommen und streng betrachtet, ist mein neues Projekt gar nicht agil. Es benutzt einfach nur die selben Begriffe, wie agile Projekte und es arbeitet nach einer Vorgehensweise, die es eigentlich streng genommen gar nicht gibt: "Backlog", "Retro", "Daily", "Standup" und "machen!".

Hätte ich zuvor nicht bei einem anderen Kunden gearbeitet, der eine ganz klare agile Perspektive und eine stringente agile Umsetzungsstrategie verfolgt, hätte ich vermutlich in meinem CV und meiner Homepage das Wort "agile" oder "Scrum" / "Kanban" benutzt ohne zu ahnen, dass ich diese Methodik überhaupt nicht kenne.

Ganz insgeheim habe ich mich natürlich gefragt, ob es jemandem aufgefallen wäre, dass ich nur die Worte "Backlog", "Retro", "Daily", "Standup" und "machen!" benutzen würde, ohne tatsächlich zu wissen, was im agilen Kontext wirklich damit gemeint ist. Ich hätte bei kritischen Rückfragen natürlich noch das Wort "Refinement" ergänzen können.
Das hätte vermutlich auch den letzten Kritiker davon überzeugt, dass ich diese Methodik beherrsche.

Was mir ja keiner glaubt, ich beherrsche AGILITÄT tatsächlich.
(Bei mir wird sie groß geschrieben, wie man sieht)

Weit über ein Jahr habe ich agile Transformation mit mehreren Agile Mastern, einem Profi-Coach, zweimal wöchentlichem Agile-Coffee, diversen Tools, Wandtafeln, Karten, Planning-Sessions, time-boxing, Retros, verschiedenen Sprint-Durationen, kreativen Sessions mit 1:30 Min (= 90 Sek.) Ideenfindung, 2:30 Min (=150 Sek.) Priorisierung und 5:00 Min (= 300 Sek.) getimexboxten Diskussionen je Thema mit gesplitteten Teams erlebt.

Nicht vergessen werde ich die laminierten, aus rotem, grünen und gelben Papier liebevoll ausgeschnittenen T-Shirts in verschiedenen Größen (6 - 10 cm) mit den Aufschriften "S", "M", "L", die in den Planning-Sessions zur Aufwandsschätzung genutzt wurden.
Es gab natürlich auch die ganz klassischen Planning-Poker-Karten mit den Zahlenfolge 1, 2, 3, 5, 8, 13, 20, 40, 100.
Aber nach mehreren Planning-Sessions der zunächst auf 4 Wochen, dann auf 2 Wochen verkürzten Sprint-Zyklen, wurde deutlich, dass diese Komplexität für die im Projekt geforderten Umsetzungsaufgaben nicht benötigt wurde. "S", "M" und "L" erwiesen sich als hinreichend komplex.

An dieser Stelle möchte ich noch völlig zusammenhanglos die Begriffe "Story", "Task" und "Epic" einstreuen.
Das vermittelt auch dem letzten Zweifler die Gewissheit: Der Typ hat es drauf. Und genau so ist es!

Ohne jede Ironie sei gesagt, dass ich noch nie eine solch positive Freizeit-Teamkultur erlebt habe mit einer Kiste Bier, einer Flasche Helbing, dem Joy-Stick von der Playstation-Emulation auf einem Raspberry pi und einem gut geölten Profi-Kicker.
Natürlich ganz zu schweigen vom Glücksgefühl beim Beschreiben und Versetzen haptisch erfahrbarer Post-IT-Zettel, die beim Anfassen, Abziehen und Versetzen auf das agile-Board-Feld "Done" ein kribbelndes Glücksgefühl mit zughöriger Endorphin und Dopamin-Ausschüttung bewirkten.

(Hier die selbstkritische Anmerkung, dass ich die Post-IT-Zettel trotz mehrfacher Ermahnung meiner Agile-Masterin nicht agil-konform von der Seite links oben nach rechts unten vom Block bzw. vom Board abgezogen habe und die Zettel sich dadurch nicht, wie im agilen Manifest festgelegt, plan auf dem Whiteboard anheften ließen, sondern gewellt und damit faktisch unbenutzbar und völlig sinnbefreit an der Wand klebten. Egal was auf dem Zettel stand, so war er nicht für's agile Vorgehen nutzbar.
Das meine letztlich doch schon provokativ ignorante Verhaltensweise nicht nur das Team ärgerte, sondern auch in der Community inzwischen als gravierendes Projektrisiko eingeschätzt wurde, wurde mir durch Zusendung des folgenden YouTube-Beitrags nochmals bestätigt: https://www.youtube.com/watch?v=6M2Qa2NbT4k

Ergänzende Anmerkung zum Thema Dopamin-Ausschüttung durch haptisches Begreifen von Sub-Task-Zetteln am physischen agile-board: Dopamin löst zwar nachgewiesenermaßen Glücksgefühle aus, jedoch sind auch unerwünschte Wechselwirkungen denkbar, die vom Coach nicht erwähnt wurden. Daher die Empfehlung, den agilen "Beipackzettel" immer vollständig auch auf Nebenwirkungen hin zu studieren, und ggf. bei größeren Projekten auf ein elektronisches Board zu wechseln, um Suchtgefahr oder gravierendere Störungen durch erhöhte Dopamin-Ausschüttungen zu vermeiden - siehe Wikipedia )

Wem der vorausgehende Satz zu viele Aspekte enthielt, dem sei gesagt: Das war nur eine kleiner Auszug aus dem, was tatsächlich agiles Entwicklungskonzept bedeutet.
Und ich spreche wirklich aus Erfahrung, denn der Profi-Coach, von dem ich die Ehre hatte lernen zu dürfen und der mich mit dem wenigen an Wissen und Erfahrung, was er an mich vermittelt hat, bereits völlig überwältigt hat, dieser Coach war einmalig.

Durch ihn und die ebenso engagierte, wie auch empirisch versierte agile Masterin wurden mir Spektren erfahrbarer Realitäten eröffnet, die ich nie zu träumen gewagt hatte.
Nie hätte ich es für möglich gehalten, dass man einem Bank-Kunden sagen kann, dass er seine Banklizenz zeitweise abgeben möge, dafür aber vielleicht irgendwann eine Programmlösung erhalten könnte, die seine Anforderungen erfüllt.
Ich hätte diesen Coach noch am selben Tag rausgeschmissen, erst recht, wenn es ein externer Berater ist.
Aber es trat das Gegenteil ein! Der Coach wurde für seine Offenheit gelobt, das Team legte sich zurück und wartete ab. Vielleicht war der Druck, den man auf die Entwickler bis dahin bzgl. Termineinhaltung und Qualität ausübte ja völlig unbegründet.
Vielleicht musste man ja wirklich auch gar nichts abliefern. Der Coach hat es doch gesagt und keiner hat ihn rausgeschmissen. Das war ein Zeichen.

Was geschah dann?

Ich war eine Woche im Urlaub, der Coach nicht. Ich kam wieder, die Wandkalender waren weg.

Wofür Kalender, wenn absolute Termine im agilen Kontext bedeutungslos sind? Ich war der einzige, dem dies seltsam erschien. Auch ich hatte in dieser Woche Urlaub ein wenig ausgespannt und das Gefühl für die Zeit verloren.
Aber als ich zurück kam, fragte ich mich, warum ich dafür Urlaub genommen hatte. Verlust der zeitlichen Orientierung hätte ich auch im Büro erfahren können. Sogar bezahlt. Mich hat der Urlaub Geld gekostet und Verdienstausfall noch dazu, denn als Externer kann ich
Urlaub nicht dem Kunden fakturieren. Mir wurde klar, es gibt weit mehr an Möglichkeiten, als ich bis zu diesem Zeitpunkt in meiner engen, beschränkten Sicht für vorstellbar gehalten hatte.
Auf meine Frage, warum der Kalender nicht mehr an der Wand hängen würde, wurde mir in schon fast sektenähnlicher Ruhe erklärt, dass dort jetzt das Burndown-Chart für den aktuellen Sprint seinen Platz gefunden hätte.
Die zeitliche Orientierung des Teams solle nicht mehr auf Monate hinaus erfolgen, sondern sich auf die jetzt und hier anstehenden Aufgaben konzentrieren. Dazu bedürfe es keines Kalenders.
Dann fiel noch beiläufig das Wort "Fokussierung" und dann wurde geklatscht. Alle klatschten, der Coach am lautesten und ich nicht. Also klatschten nicht alle, sondern alle ausser mir.

Mir wurde in dem Moment klar, dass letztlich das gesamte Team klatschte. Ich nicht, ich gehörte ab diesem Moment nicht mehr dazu.
Um diesen Absatz nicht melancholisch enden zu lassen sei gesagt, dass mich das Team nicht ausgeschlossen hat. Sie haben mir die Hand gereicht und mich immer wieder in der jetzt eingetretenen schon fast sektenähnlicher Ruhe eingeladen dazu zu gehören und mich einfach gebeten, die Regeln agiler Entwicklung und die des Coaches zu verstehen und zu beherzigen.

Zweimal in der Woche war das agile Coffe, wo der Coach oder andere externe agile Master wissenschaftliche Vorträge praktischer agiler, soziologischer, wirtschaftspsychologischer oder gender-spezifischer Themen abhielten.
Hierzu wurden in vielen Fällen Flipchart-Bilder vorbereitet, die dann anschließend im Flur aufgehängt wurden, damit auch alle anderen Interessierten, die nicht zum für alle freiweilligen offenen agile coffee kommen konnten, nachlesen konnten, was vermittelt wurde.

Ich hatte eben im Absatz davor den Begriff der "wissenschaftlichen Vorträge praktischer agiler ... Themen" aufgeführt.
Damit die intellektuellen Anforderungen nicht zu niedrig angesetzt sind, hier die praktische Bedeutung:

6 Monate * 4 Wochen (vereinfacht) * 2 Tage/Woche ein agile coffee Diskurs = 48 Flipchartblätter
(manchmal waren es auch 2 Blätter je Session, dafür haben andere Termine eher wissenschaftlich praktischen Inhalt gehabt ^*)).

Je Flipchart-Blatt mit einer Breite von 71 cm (B1-Format) =>
48 Blätter  * 71 cm/Blatt = 34,08 m reine Papierbreite ohne Zwischenraum.

Was soll ich sagen; ich war vor wenigen Wochen nochmal zu Besuch in den Räumen, weil ich mein Sacko vergessen hatte.
Einfach überwältigend! Unfassbar, was möglich ist, wenn man einmal eine Grenze überschritten hat, die man für gesetzt und unverrückbar gehalten hat.
Es ist wie der Sprung in eine neue Dimension, einfach grenzenlos. Unfassbar!
Wie beschränkt ich bis dahin war und was ich mir selbst für Grenzen auferlegt hatte, die gar nicht wirlich existierten.

Im agilen Kontext geht einfach alles, was man sich nur vorstellt.
Was hatte ich bis dahin doch nur für einen eingeschränkten Fokus und wie wenig Erfahrung.

Mir ist der oben geschriebene Satz aufgrund seiner vielschichtigen Bedeutung noch immer im Kopf und ich bin weiterhin unsicher, wie ich ihn verstehen kann:
"... der Profi-Coach, von dem ich die Ehre hatte lernen zu dürfen, und der mich mit dem wenigen an Wissen und Erfahrung, was er an mich vermittelt hat, bereits völlig überwältigt hat, dieser Coach war einmalig."

Apropos Fokus:

Ob die FinRep-Meldung zum Quartalsende erneut mit der Hand vom Bilanzbereich erstellt wurde, hatte ich jetzt gar nicht mehr gewagt zu fragen.

Danke für die tolle Zeit.

Ulrich

und ich schulde ja noch ein *) von oben.
Also diese wissenschaftliche Praxisübung stand unter dem Kapitel "Gender", "Multikulturelle Strukturen in großen Unternehmungen", "Projektmanagement", "Effiziente Aufwandsplanung in agilen Projekten".
Ich vereinfache jetzt ein wenig und werde damit vermutlich dem Trainer und agile Master nicht gerecht:
Die Übung lautete:
"Stellt auch alle so herum, dass ihr euch nicht seht. Wenn ich "LOS" sage, dann zählt ihr alle für euch selbst 1 Minute, also 60 Sekunden lang und dreht euch dann wieder zur Mitte hin um."   -    "LOS"

Nach 45 - 75 Sekunden standen dann alle wieder in der Mitte.

Der zweite Teil der Übung wurde exemplarisch mit 4 Probanden durchgeführt:
"Geht bitte einmal hier von der Türe aus in den Flur. Und geht so weit, wie ihr meint, dass diese Strecke 1 Minute symbolisiert."

Es wurden Strecken von 1,50m - 5,00m von den Probanden zurückgelegt.

Frage der Teilnehmer: "Was konnten wir jetzt daraus lernen?"
Die Antwort der externen agile Masterin:
"Ich habe in Australien " oder war es Kanada - ich habe es vergessen - "Gender studiert und ich habe mit Teams gemischter Kulturen gearbeitet, z. B. mit Indern und Chinesen und Europäern. Dabei wurde deutlich, dass jeder Kulturkreis ein anderes Verständnis von Zeit und Raum hat und dass man mit der Planungsaussage, eine Aufgabe benötigt z. B. 3,5 Tage bei jedem Menschen zu einem anderen Zeitpunkt fertig wird. Der eine wird in 2 Tagen fertig, der andere hat dann noch gar nicht angefangen und die Inder sind nach 1 Woche noch nicht fertig, da sie an eine Wiedergeburt glauben und es daher weniger bedeutungsvoll ist, wann Aufgaben fertig werden. Dort zählt primär das Wohl der Familie und wenn es dort Probleme gibt, bleibt die Arbeit liegen und sie gehen nach Hause. Das ist so, damit müsst ihr rechnen, wenn ihr mit verschiedenartigen Kulturkreisen arbeitet".

Ergänzende Aussage einer weitere agile Masterin, die als 2. Trainer anwesend war:
"Ja und deswegen macht es auch keinen Sinn bei den Plannings mit exakten Tagen als Aufwand zu planen, weil jeder ein anderes Empfinden hat, wie lange etwas dauert. Wohingegen die Komplexität einer Aufgabe von den meisten gleichartig eingeschätzt wird. Kinder und Erwachsene schätzen z. B. die Höhe eines Autos, eines Hauses und des Eiffelturms unterschiedlich hoch ein, wenn sie exakte Angaben in Meter und Centimeter machen sollen. Aber sie schätzen alle richtig, dass das Auto kleiner ist als das Haus und der Eiffelturm am höchsten. "

Anmerkung eines Teilnehmers (das war nicht ich): "Ja, aber ich muss mein Programm zu einem definierten Kalendertag fertig haben, da hilft es nichts, wenn ich schätze, dass es relativ lang oder relativ kurz dauert. So werde ich den Termin nicht einhalten können."

Die Darstellung der Folgediskussion erspare ich dem Leser.
Es waren keine Inder beim Auftraggeber beschäftigt und die anderen waren zu 98 % Deutsche oder Nordeuropäer.
Dennoch konnten nicht alle der anwesenden Personen die Anmerkung des Teilnehmers nachvollziehen.

Die agile Transformation war zu diesem Zeitpunkt bereits auf einem recht guten Weg.