Nach einem Tag voller Unwägbarkeiten und Planverletzungen war es Zeit für einen stabilen Rahmen und ein bekanntes Vorgehen.
Am 14. September war die Leipziger Meetup-Runde zu Gast bei Lecos.

Ich war noch sehr mit den Kindern beschäftigt als mich überraschend Jan Fischbach anrief.
Er war gerade für einen Kundentermin in der Stadt und hat durch seinen Kunden erfahren, dass es das Meetup gibt.
Anders als bspw. bei Berliner Meetups ist es bei uns so, dass die angemeldeten in der Regel auch vollzählig kommen oder wahrnehmbar absagen, sodass die angebotene Anzahl von Plätzen einerseits ernst zu nehmen ist, andererseits auch recht schnell vergeben ist.

Ich war mir dennoch sicher, dass wir Jan auch ohne Anmeldung unterbringen würden.
Bspw. hatte Sven kurzfristig abgesagt. Das ist einerseits schade, andererseits nehme ich an, dass er einen sehr guten Grund für seine Absage hatte.

Ebenfalls vermisst habe ich Anja und Sebastian aus Dresden. Aber die arbeiten seit Jahren agil im selben Unternehmen und sahen deshalb vielleicht keinen ausreichenden Grund für die Anreise. Den selben Grund vermute ich hinter der Abwesenheit von Steffen und Sveto. Das sind allerdings nur Vermutungen.

Bei Conrad haben wir schon früh erfahren, dass er außerhalb weilt.

/Einleitung durch Karsten

Nach der kurzen Eröffnung und Begrüßung durch Rolf und Peter begann der Abend mit einer Darstellung der agilen Reise von Lecos durch Karsten.

Lecos umfasst insgesamt fast 200 Mitarbeiter. Die Kunden sind in der Öffentlichen Hand beheimatet und die Stadt Leipzig einer der wichtigsten davon. Das Tätigkeitsfeld entsteht auftragsgetrieben und erstreckt sich von Hardware aus dem Bereich der Bürokommunikation bis hin zum Hosting von Software für Fachverfahren.

Der Geschäftsführer, ein anderer Peter als “unserer”, hatte einst den Entschluss gefasst das Unternehmen agiler zu gestalten.
Schulungen wurden besucht und die Entscheidung getroffen, die Agilisierung selbst über das Scrum-Vorgehen einzuführen.
Die Scrums wurden aus den Führungskräften gebildet und zwei Durchgänge zu etwa drei Monaten mit 2-wöchigen Sprints abgehalten.
Eine der herausragenden Erfahrungen war laut Karsten, das Erfahren der Führungskräfte wie Arbeiten unter Gleichen sich anfühlt.
Es ist trotz dieser Erfahrung noch ein langer Weg zu gehen.
Außer Karstens Team zur Entwicklung der Fachverfahrens-Software arbeiten wenige Bereiche wirklich agil.
Es gibt noch eine Strategie-Abteilung, die sich intensiv mit Motivation und Richtung für die Lecos beschäftigt.

Ich habe dann in der Q&A mit Impulsgedanken nachgefragt, warum die übrigen “auftragsgetriebenen” Einheiten nicht wenigstens Kanban für ihre Selbstverwaltung einsetzen.

Nach meiner derzeitigen Vermutung liegt es an dem gewählten, externen Beratungsunternehmen, die einen starken Focus beim skalierten Scrum setzen. Und so habe ich auch Karstens Ratschlag aus diesem Einführungsvortrag verstanden.
“Sucht Euch auf jeden Fall externe Hilfe durch Berater und Coaches.”

Ich kann dieser Aussage nur voll zustimmen.

Meine Begründung dazu: wenn das System erfolgreich und stabil läuft, wie im Fall der Lecos, braucht es schon eine massive Einwirkung von außen, bis es sich aus sich heraus anpasst. Meistens sind diese Einwirkungen so etwas wie Marktzusammenbrüche oder der Wegfall des oder mehrerer tragender Kunden.

Ein Impuls von innen, bspw. durch den Geschäftsführer, mag auslösend wirken, ist aber wenig antreibend.
Ohne ein Verstehen des “Warum” und das übernehmen eines Zielbilds als das eigene, wird die erforderliche intrinsische Motivation ausbleiben.

Externe Berater und Coaches wiederum konfrontieren den Status quo durch Nachfragen mit den Gründen dafür, warum etwas ist, wie es ist. Meist ist es nur so, weil es immer schon so war. Und wenn man schon bei der Reflektion angelangt ist, dann kann man auch ein Experiment wagen, es besser zu machen. Meist hat der Coach schon eine Geschichte an der Hand, welches Vorgehen in einem ähnlichen Kontext Erfolg gezeigt hat.

/erster Durchgang

Nach dem Vortrag und der anschließenden Fragerunde wurde der Thementeil eröffnet.

/Paradigmenwechsel “klassisch” > “agil”

Wie Rolf in der vorherigen Einleitung berichtete, können sich

Prozesse zur Erstellung von Software für die Verwaltung

schnell in

die Verwaltung von Prozessen zur Erstellung von Software

verwandeln. Das sei seine aktuelle Wahrnehmung.

Gemeint ist ein Problemfeld, das Alexander Krause einmal bezeichnet hat als

Command & Control eats Agile for Breakfast

Dahinter steht ein wirtschaftlich außerordentlich relevanter Umstand.

Wenn Scrum oder andere agilen Vorgehensweisen als Cargo Kult betrieben werden, können sie in etwa 20% Produktivitätsvorteil erzielen – Vielen genügt das schon. Noch mehr Verbesserung wird schon fast als Betrug angesehen.

Wenn aber noch die richtige Einstellung dazu trifft – das sog. “agile Mindset” – dann können es auch schon mal 300% Steigerung werden. Schwer zu messen, leicht zu erleben.
Was wiegt schwerer?

Gute erste Schritte sind:

• Alle Beteiligten: die selben Werte über alle Hierarchie-Ebenen etablieren
• Geschäftsleitung: Vorleben statt Nachmachen
• Gruppen: gemeinsam Entscheiden anstatt dass einzelne Bestimmen
• Jeder Einzelne: Fragen stellen und Irritation gezielt nutzen

/Scrum und Standardsoftware

Durch Rolfs Thema ist mir überhaupt erst aufgefallen, dass mein Normalfall eine Ausnahme darstellt.

Ich arbeite ausschließlich projektbezogen, wohingegen die meisten ein Produkt wie bspw. eine Webseite liefern und betreiben.
Wo ist der Unterschied? Das Projekt liefert, die Linie betreibt.
Das einzige, was das Projekt in dem Sinne “betreibt” ist die CI-Umgebung.
Und die wiederum nur auf Anwendungs- und nicht auf Systemebene.

Als Besonderheiten im Projekt wurden identifiziert:

• Qualitätsstabilität ist Muss-Kriterium für Scrum.
  Daher muss sich das Projekt auf eine Umgebung zur Sicherung und zum Nachweis der Qualität einigen und das Vorgehen beibehalten – Stichwort “DoD”.
• Oberflächen- und Akzeptanztests erfordern Testwerkzeuge, die dafür geeignet sind.
  Nicht jede UI wird an einen Web-Browser ausgeliefert.
• Customizing von Standardsoftware führt zu Herausforderungen in Folge-Releases.
  Welche Auswirkungen hat die Aktualisierung der Basis-Software auf individuelle Erweiterungen und Anpassungen? Regressionstests 😉

/Vision

Jan und ich haben unabhängig voneinander einen Bedarf erkannt. In der Fragerunde hat Sebastian, der Prokurist von Lecos, von der Schwierigkeit berichtet, eine Vision zu formulieren. Ich dachte bei mir “Da kann man doch etwas machen”. Jan hatte wahrscheinlich ähnliche Gedanken und so haben wir uns schnell zusammengefunden.

Die dritte Runde im ersten Durchgang wollte sich mit Visionen beschäftigen.
Am Ende waren es 5 interessierte sowie Jan und ich. Perfekte Größe.

Allerdings hatten wir kein gemeinsames Ziel, dass uns als Team zusammengeschweißt hätte. Vielmehr haben wir Erfahrungen und Befürchtungen geteilt.
Und natürlich Methodenwissen.

/Vision als eine von mehreren Möglichkeiten

Jan berichtete von einer sehr hilfreichen Methode, die u.a. Shell einsetzt.
Sie wird englisch Scenario Planning genannt.

Der große Wert dieser Methode liegt daran, dass man für bestimmte Szenarien bereits Indikatoren bestimmt hat, bevor eine solche Situation eintrifft. Wenn dann also ein bestimmter Indikator auftritt weiß man, welches Szenario zum tragen kommt und kann die damit verknüpften Handlungen ausführen.

Worin liegt der Vorteil?
Durch das Vorausdenken anhand der Szenarios, hat bereits weitgehend passende Maßnahmenpläne entwickelt.
Die Zeit zur Maßnahmenentwicklung wird eingespart und die Handlungen können direkt begonnen werden.

Kein Wunder, dass diese Methode ihren Ursprung beim Militär hat.

Insgesamt ist dieses Vorgehen hervorragend geeignet, um einen Status quo zu schützen und möglichst reibungslos wieder zu stabilisieren. Im Falle von Shell ist es ein sehr übersichtliches Geschäft, das jedoch von einer Menge politischer und militärischer Unsicherheit, ökonomischer Ungewissheit gepaart mit großen Investitionsvolumen und Ausbeutungszeiträumen auftritt.

Bei einer solchen Konstellation macht man sich lieber ein paar Gedanken mehr im Konferenzraum, bevor man ein paar Milliarden Euro in der Nordsee versenkt.

/Vision als das Ziel

Es geht auch anders. Ich persönlich beschäftige mich lieber mit dem zukünftigen Status quo als damit, den bestehenden aufrecht zu erhalten.
So gesehen bin ich dann eher Utopist. “Visionär” würde ich auch gelten lassen.
Beides hat erstaunlicherweise einen negativen Beigeschmack in der deutschen Alltagssprache.

Meine Erklärung dazu: “Hemd näher als Hose”
Wenn der materielle Mangel offensichtlich und behebbar ist, dann liegen die Prioritäten auf der Hand.
Da war doch mal etwas mit Nahrungsaufnahme und Moral in der Dreigroschenoper …

Also … ich hatte Ergänzungsbedarf.

Man kann auch ein positives Zielbild entwerfen. Anhand von Messgrößen (Indikatoren) bestimmt man dann, woran man festmacht, diesen idealen Zustand erreicht zu haben.

Der Zustand ist nicht “double-digit-growth!” auch nicht jährlich “20% Umsatzrendite”.
Das sind Wachstumsindikatoren.
Es geht um Zustandsindikatoren. Also woran man erkennt, einen stabilen Zustand erreicht zu haben.
Bspw. Kontinuität im Mitarbeiterstamm, regelmäßige Käufe durch Bestandskunden, Anzahl der Abonnements und dergl.

Das war jetzt ein ergänzender Einschub meinerseits.
In der Session selbst kamen wir nicht mehr dazu.
Da blieb es bei “Friede, Freude, Eierkuchen.”

Oder etwas neutraler “Harmonie” zwischen Anforderungen und deren Erfüllung.
Was man zumindest durch Abwesenheit von Hindernissen und Mängeln erkennt.
Die Anwesenheit von Mängeln und Hindernissen (Obstacles, Impediments und Scarce) deutet darauf hin, dass dieser Zustand noch nicht erreicht ist.

Eine in der Session nicht erwähnte Methode wäre auch OKR.

Was ich dann noch beigetragen habe, war eine konkrete Erfahrung mit der Methode des Visioning. Es war ein Workshop, wo Stephan Kowalski ein ganzes Unternehmen begleitet hat, die eigene Vision von sich in fünf Jahren zu entwickeln. Das ist etwas deutlich anderes als in zwei Tagen die Methode kennenzulernen.

/warum macht das keiner?

Bleibt die Frage, warum sich so wenige mit der Zukunft des eigenen Umfelds beschäftigen.

• Zeitverschwendung?
• Wichtigeres zu tun?
• Zu abstrakt?
• “not my job!”
• “out of scope”

Ein gewichtiger Anteil an der Begründung liegt nach meiner Ansicht darin, dass man Vision und Strategie in der Zuständigkeit von anderen ansiedelt. Man selbst sieht sich allerhöchstens in der Umsetzung und das gern sehr konkret vorgegeben.

Das ist vollkommen verständlich. Der menschliche Körper ist auf Energieeffizienz ausgelegt.
Wenn wir Energie einsetzen, dann muss es sich lohnen. Es muss Freude bringen oder Mangel lindern.

Der größte Energieverbraucher ist das menschliche Gehirn. Es macht etwa 2% des Körpergewichts aus, verbraucht aber im Normalzustand 20% der Energie. Unter Anstrengung kann der Energieverbrauch bis zu 50% zunehmen auf insgesamt 30% des gesamten Energieverbrauchs.

Der größte Energiebedarf entsteht beim Lernen. Das Neuordnen des Hirns ist der konsumtivste Prozess im menschlichen Körper.
Aus Gründen der Überlebenssicherung wurde der Paleo-Körper darauf optimiert, das immer Gleiche so zu verfestigen, dass es ohne übermäßigen Energiebedarf abrufbar ist – Speichern im Unterbewusstsein.

Es muss ein guter Grund erkannt werden, um zu lernen.

• Existenzsicherung
• Wohlbefinden (Freude)

Dadurch, dass die bisherigen Ausbildungsinstitute in Ost wie West einer jeweils semi-erfolgreichen Weltanschauung gefolgt sind, die amüsanter Weise um denselben Irrglauben, nämlich dem Absolutheitsanspruch der Industrialisierung, aufgebaut ist, dadurch haben sich in den letzten 150 Jahren alle Anstrengungen auf die Existenzsicherung konzentriert. Der zweite Aspekt ist dabei in weitgehend Vergessenheit geraten und erzeugt die vielen Sinnkrisen, denen wir uns derzeit gegenübersehen.

Willkommen auf den höheren Ebenen der Maslowschen Bedürfnispyramide.

Neben den vier anderen Gründen, die auf die folgen von Scientific Management (Taylorismus) zurückzuführen sind bleibt noch die Sache mit der Abstraktionsebene. Das ist dann eher die mittelbare Folge aus den anderen Ursachen.

Ein Zustand von Glückseligkeit und Frieden entspricht für viele Personen nicht ihrer Alltagserfahrung.
Die Normalität, die Aufgabe, “der Sinn” entsteht durch die (Wieder-)Herstellung eines definierten Zustands, der selbstverständlich schwer zu erreichen ist. Wenn nun diese Schwierigkeiten nicht mehr existent seien, dann würde die Lebensgrundlage entfallen und die Existenz gefährdet. Ergebnis: das System erhält sich in dem Zustand wie es ist. Wobei wir wieder am Anfang wären.

In diesem Tunnel des Fokus gelten nur messbare, beweisbare Fakten – s. SCIENTIFIC Management.
Das wird dann gern als “konkret” und das wiederum als erstrebenswert deklariert.

Gefühle wie Wohlbefinden und Glück sind über die verfügbaren Messinstrumente nicht erfassbar und daher nicht zugelassen.
Die Schere im Kopf setzt ein und verhindert die Weiterentwicklung.

Dabei basiert der ganze Ansatz auf einem Fehlverständnis vom Begriff “konkret”.
Konkret ist nicht allein, was gegenwärtig und daher zur Zeit nachweisbar existiert, es ist auch etwas Zukünftiges, sofern es beschreibbar ist und anhand von aus der Beschreibung abgeleiteten Kriterien nachprüfbar ist oder präziser “sein wird”.
Konkret bedeutet dem Wesen nach “gegenständlich” und das können sowohl Dinge der physischen äußeren Welt als auch Empfindungen und Ideen sein. Das, was das Konkrete vom Abstrakten unterscheidet ist nicht seine gegenwärtige Existenz, sondern seine Individualität.
Das Abstrakte gilt für mehrere dem Wesen nach unterscheidbare Anwendungsfälle gleichermaßen, wohingegen das Konkrete durch ein oder mehrere Merkmale seine Einzigartigkeit erfährt. Und das tut es, indem eine Kombination von Kriterien (aus der Zielbildbeschreibung abgeleitet) gewählt wird, die nur auf genau einen Anwendungsfall zutreffen.
Bspw. “unser Unternehmen in fünf Jahren zeichnet sich dadurch aus, dass …”

/Zusammenfassung erster Durchgang

Christian Müller, Mitorganisator von Agile Jena, musste sich bereits nach dem ersten Durchgang auf den Weg machen.
Sein Fazit: wir sind eine angenehme, offene Gruppe ohne “Scrum-Nazis”.

Peter musste auch schon nach dem ersten Durchgang gehen.

/Pizzapause

Vegane Quattro Formaggi – was soll ich dazu noch sagen?

Vielen Dank für die vorausschauende Pizzabestellung und das Kaltstellen der Getränke.
Dem Kommentar von Karsten entnehme ich, dass die Vertrauenskasse halbwegs stimmte.
Genau weiß ich das natürlich nicht.

/zweiter Durchgang

Es standen zwei verbliebene Themen zur Auswahl

/agiler Festpreis

Den Aufhänger für diese Session lieferte Falk.
In diesem konkreten Fall leidet das Projekt eher unter dem mangelnden Verständnis und der daraus folgenden Disziplinlosigkeit des Kunden anstatt am Vertragsmodell selbst.

Karsten charakterisierte den agilen Festpreis mit den griffigen, wenn auch nicht vollkommen präzisen Worten

“Money for nothing and the Change 4 free.”

In Anlehnung an die Dire Straits meinte derjenige, der es ursprünglich zu Karsten gesagt hat folgendes:

• Wenn man agil vorgeht und einen “klassischen” Kunden beliefert läuft das Backlog schnell leer.
  Der Kunde kommt mit Abnahme und Stellen neuer Anforderungen selten so schnell hinterher, wie die Umsetzung liefern kann.
  Schnelles Impediment “Out of Story Error” – zu oft erlebt.

  Scrum ist halt anstregend – nicht nur für das Build-Team.
  Der Aufwand für Spezifikation wird gemeinhin vollkommen unterschätzt.
  “Wir sind ja jetzt agil”, heißt es dann. Da machen wir, was gerade anliegt.
  Das ist das übliche Missverständnis zwischen rationalem Vorgehen und impulsiver Reaktion.
  Von impulsivem Taktieren stand nichts im agilen Manifest – wenn ich mich nicht irre.

• Change 4 free meint, dass zwei gleich große Anforderungen gegeneinander getauscht werden können, sofern sie noch nicht “in progress” gesetzt worden sind.
  Natürlich können auch unterschiedliche Stories im Paket behandelt werden. Allerdings erfordert das Vergleichbarkeit bspw. anhand von Storypoints. Und den Überblick über das Backlog.
  Jemand muss beurteilen können, ob der Tausch weitreichendere Auswirkungen hat.
  Wenn nicht technisch, so können doch die wirtschaftlichen Folgen erheblich sein.
  Manche Funktion wird vom Markt händeringend erwartet während andere weitgehend unbemerkt verschoben werden können.
  Dreh- und Angelpunkt ist das Scope-Governance-Meeting.

Rolf hat dann noch ergänzt, dass die Priorisierung des Backlogs im fraglichen Fall nach den wichtigen und den riskanten Stories erfolgen solle.

Muss es nicht ohnehin ständig Funktion gegen Risiko abgewogen werden?
Nach meinem Eindruck war das Thema bei der parallelen Zusammenkunft.

/Features erkauft mit technischen Schulden?

In dem größeren der zwei Durchgänge ging es darum, aufgelaufene, technische Schulden gegen zu liefernde Features aufzuwiegen.

Ganz klares: “Es kommt darauf an”
Je häufiger eine technische Schuld zum Tragen kommt, desto schwerer wiegt sie.
Ist es ein Hilfsskript, das “einfach nur läuft” oder ist es die Kernkomponente eines Systems, von der alles abhängt.
Betrifft es mglw. sogar die mehrmals täglich benutzte CI-Umgebung ohne die ich die DoD nicht einhalten kann?

Was nützen gelieferte Funktionen, die unzuverlässig oder nur selten verwendbar sind?
Waren wir nicht aus dem Zeitalter der “Bananensoftware” herausgewachsen?

/Zusammenfassung und Verabschiedung

Rolf fasste den Abend zusammen (Peter war schon weg).

In diesem Jahr wird es noch ein Meetup und natürlich das Barcamp gegen.
Ob das Meetup davor oder danach stattfinden wird ist noch ungewiss.
Es sprachen aber einige Gründe dafür, es etwa Anfang November zu platzieren.
… wenn der nächste Gastgeber das möglich machen kann.

/stay tuned

/Fazit

Der Anfang einer agilen Transition ist der schwerste Schritt. Das bestehende System wird von der gewohnten Art und Weise vorzugehen stabilisiert und aufrechterhalten. Die Erkenntnis eines Änderungsbedarfs gibt den ersten Anstoß. Zu diesem Zeitpunkt fehlt es aber an Erfahrungswissen über eine andere Art zu Arbeiten. Die bekannten und eingeübten Handlungsmuster stabilisieren weiterhin den gewohnten Zustand, der bereits als änderungsbedürftig erkannt wurde.

Zu diesem Zeitpunkt braucht es dann den entscheidenden Anstoß, etwas auch tatsächlich anders zu machen. Sobald sich die ersten Erfolge eingestellt haben gibt es eine alternative Erfahrung auf die man sich beziehen kann. Von diesem Punkt aus können weitere Erfahrungen gemacht werden.

Wie kommt man nun von der Erkenntnis zur Veränderung?
In einer arbeitsteiligen Geschäftswelt genügt es nicht, wenn einer – egal in welcher Position – den Bedarf zur Änderung erkannt hat.
Es braucht Unterstützung durch das Umfeld. Diejenigen, die ein Verhalten ändern sollen, müssen einen Grund dafür haben.
Eine “Ansage von oben” ist dabei nur der zweitbeste Grund. Noch besser ist es, wenn die Betroffenen verstehen, warum eine Änderung erforderlich ist.

Danach kann dann das individuelle “Wie” gefunden werden.
Hier kommt dann Literatur, Schulung und Training ins Spiel. Aus dem reichhaltigen Angebot an Beispielen kann man diejenigen Ansätze auswählen, die in der jeweiligen Umgebung am erfolgversprechendsten erscheinen.

Schnelle und als positiv empfundene Erfahrungen sind dann der neue Bezugspunkt an dem sich die Handelnden ausrichten können.
Die Erfahrungen müssen nicht alle “Erfolge” sein. Es genügt, dass die schnelle Herstellung von Gewissheit als positiv wahrgenommen wird. Selbst, wenn die Gewissheit lautet “so geht es schon einmal nicht”.

/Heimweg

Ich begleitete Jan ins Hotel. Auf dem Weg konnten wir darüber sprechen, wie Jeff sein Engagement bei der BMW-IT beurteilt.
Die O/FK-Ebene sei offen und hätte eigenständig die Einführung von agilen Arbeitsweisen vorangetrieben.
Ich kann sagen, dass auf der Projektebene zwar die Nachricht angekommen ist, die Wirkung jedoch mangels weitreichendem Verständnis und Orientierung noch auf sich warten lässt. Immerhin wird kein monolithisches Vorgehen mehr erwartet und die Umsetzungen der Vorhaben beginnen früher als zuvor. Das ist ja schon einmal etwas.
Die Vorhaben sind allerdings auch keine Tools oder kleine Webseiten-Änderungen. Es geht in meinem Kontext immer um vollständige Anwendungen mit tatsächlichen Nutzern, die teilweise auch Kunden sind. Alle dieser Anwendungen sind in einen größeren Rahmen vieler gegenseitiger Abhängigkeiten eingebunden. Das wird sich auch in einer agilen Vorgehensweise nicht ändern.

Bei allen Änderungsbemühungen sollte man zunächst erst einmal feststellen, was man ändern will und ob man es ändern kann.
Eine gegenseitige fachliche Abhängigkeit “der Sache” wird sich auch durch den Einsatz agiler Mittel nicht in eine rein komplizierte Sache verwandeln. Allerdings kann ich durch die schnellere Erfahrbarkeit von nutzbaren Ergebnissen durch ein Vorgehen wie Scrum eine bessere Vorstellung davon bekommen, wie sich eine Änderung auswirkt und ob der geänderte Zustand zufriedenstellender ist als der bisherige. Die Kurzfristigkeit der erfahrbaren Ergebnisse ist dabei der Schlüssel.
Einerseits signalisiert es, dass eine Änderung machbar ist, andererseits kann der Zusammenhang von Ursachen und Wirkungen in kürzerem zeitlichen Abstand leichter wahrgenommen und deshalb als überzeugender begriffen werden.

Der Rest kommt dann mit der Erfahrung.