Das fing ja gut an. Ich traf 18:58 an der angegebenen Adresse ein, scheiterte jedoch an den eigenwillig gestalteten Bedienelementen des Fahrstuhls. Interessanterweise schloß sich Falk meinem Scheitern an. Erst durch weitere, erfahrene Benutzer verstanden wir, wie die Aufzüge zu “rufen” waren.

Wenig später standen wir dann vor dem Eingang des gastgebenden Unternehmens und vor verschlossener Tür. Ein Blick auf die Details der meetup-Einladung gab uns den entscheidenden Hinweis.
Wir mussten den Nebeneingang nehmen.

Wenige Minuten später betraten wir die Szenarie.

Ich entdeckte Sveto, den ich wahrscheinlich seit dem Barcamp nicht mehr getroffen habe. Er berichtete mir, dass ihn die Wartelisten abschrecken würden und er sich dann gar nicht mehr registrieren würde. Dieses Verhalten war all die anderen Male auch gerechtfertigt. Wer angemeldet war, kam meist auch. Die hinteren Plätze der Warteliste hatten meist keine Chance. Mittlerweile wandelt sich das Verhalten. Wir hatten viele, die ihre Plätze kurzfristig freigaben und auch ein paar “noShows”. Am Ende hätten sogar noch mehr Personen teilnehmen können als tatsächlich erschienen.

Kurz bevor es losging konnten Anne Semko und ich uns wenigstens noch kurz begrüssen. Sie wollte Präsenz zeigen, bevor es sie weiter zog. Anne hat eine Alternativveranstaltung ins Leben gerufen. Das Scrum Meeting Leipzig ist als lockere Ergänzung gedacht – keinesfalls als Konkurrenzveranstaltung.

Der Rahmen bietet die Möglichkeit, sich informell über das Thema Scrum und Agilität zusammen zu finden. Ich habe den ersten Stammtisch sehr genossen. So etwas hatte ich seit vielen Jahren nicht mehr.
Die nächste Veranstaltung ist am Dienstag, 19.6. “Wir müssen reden:)”

Peter dokumentierte uns mit einem Gerät über dessen Nutzwert ich seither nachdenke. Wer zum Teufel braucht heute – im Zeitalter des Smartphones und der Fotodrucker im Drogeriemarkt – eine Sofortbildkamera? Wenn ich das rausgefunden habe kann ich die Person nach dem fragen, was mich eigentlich bewegt: wofür?

Sei es drum. Nach ein paar Minuten des Sammelns ging es los.

/Begrüssung und Pitching

Peter stellte seinen neuen Arbeitgeber und unseren Gastgeber vor. Die Fa. XPURE macht “irgendetwas mit Automotive”. Was genau das ist, darf wg. diverser Schutzklauseln nicht verraten werden. Ich kenne das. Ich druckse ja auch immer haarscharf an der Linie der Vertragsverletzung herum. Vor SoC (“Start of Communication”) dürfen wir gar nichts sagen. Und danach auch nur sehr wenig. Das ist oft sehr hinderlich, wird aber mittlerweile besser. Ich bin andernorts recht erstaunt, wieviel mittlerweile preisgegeben wird. Vor 10 Jahren war das definitiv sehr anders.

Peter stellte dann noch die Räumlichkeiten vor. Das ergab eine 2×2 Agenda-Matrix.

Der beste Ort auf jeder Party ist die Küche. Zumindest für mich. Und so blieb ich wo wir ohnehin schon alle waren. Es passte ganz gut, dass wir dort jeweils zwei thematisch beieinander liegende Angebote zusammenfassen konnten.

Die nun folgenden Ausführungen orientieren sich entlang meiner chronologischen Wahrnehmung.

/Praxistest: Out of Story Error

Ich hatte etwas vor.
Ich wollte dieses Treffen nutzen, um die Praxistauglichkeit eines Workshops zu überprüfen. Ich hatte das Thema zögerlich fragend angebracht als ich Verständnisfragen zum Call for Papers bei den Veranstaltern der “Modern RE” stellte. Ich erhielt wohlwollende Rückmeldung. Das Thema ist bereits gesetzt. Bevor ich das Script nun endgültig einreiche, wollte ich noch verproben, wie praxisrelevant das von mir mittlerweile regelmäßig beobachtete Phänomen ist.

Ich wollte mit diesem Test der Überschwänglichkeit im Neuen begegnen.
Habe ich einen Hammer geschenkt bekommen und sehe jetzt überall nur Nägel?

Ich erkannte Gemeinsamkeiten mit dem Thema, das Carsten mitbrachte und so schlossen wir uns zusammen. Das erhöhte den Druck zusätzlich. Für den Workshop habe ich auf der Konferenz 100 Minuten. Hier mussten wir nun zunächst zwei Themen ausloten und dann noch Ergebnisse erarbeiten.

Die Vorstellungsrunde fiel daher knapp aus. Es fanden sich einige Teilnehmer aus Konzernumgebungen zusammen. Eine häufiges Setup ist “die IT-Abteilung des Konzerns” – manchmal in der Form von Ausgründungen mit Konzern-Auftraggebern. Ein solches Szenario scheint bei öffentlichen Versorgern recht beliebt. Das Szenario, das mir häufig begegnet, ist “externer Dienstleister im Auftrag des Konzerns”. In diesem Fall qualifiziert sich ein Unternehmen durch seine Expertise dafür, kritische Projekte übertragen zu bekommen. Oft herrscht beim Dienstleister die Annahme, dies geschehe aufgrund technischer Expertise.
Thomas Fleck von netresearch hatte es einst sehr deutlich ausgesprochen. Es ist sei nicht das derzeitige Wissen um eine Technologie, die Kunden veranlasst die Aufträge zu vergeben. Es ist das Zutrauen, man werde das Projekt im Sinne des Auftraggebers erfolgreich zum Abschluß führen.

Die Tragik dabei liegt in den Details. Der Auftraggeber ist sich oft nicht im Klaren darüber, was das für ihn bedeutet. Ich habe es sehr oft erlebt, dass “Business” keine Vorstellung (mehr) von technischen Möglichkeiten hat und noch weniger dazu in der Lage ist, seine Anforderungen abstrakt zu formulieren. Im Zuge der Digitalisierung führt das zu dem merkwürdigen Phänomen, dass der Auftraggeber und vermeintliche Nutznießer seine Rolle nicht erfüllen kann. Kennen wir doch …

Der Kunde weiß nicht, was er will, bevor er es sieht.

Vielmehr erwartet er vom Dienstleister, dass der schon wisse, was gebraucht wird. Und viele wissen das auch. So ergibt sich ein Teufelskreis, der sich immer weiter verstärkt. Auf der IT-Seite wird immer mehr Geschäftskompetenz aufgebaut und mit technischer Kompetenz vereint. Investitionen in Technologie und “Digitalisierung” verstärken das Phänomen noch zusätzlich.

Es gibt immer weniger Transferanlässe, um Wissensaustausch zu betreiben. Die Digitalkompetenz der Fachabteilung verkümmert, während die Fachkompetenz der IT-Abteilung immer weiter steigt.

Das Phänomen “Out-of-Story-Error” ist daher zunächst etwas schwer wahrzunehmen. Alle Beteiligten sind schwer beschäftigt, das Backlog ist gut gefüllt. Niemand würde behaupten, es gäbe nichts zu tun. Tatsächlich sind zwar “alle” beschäftigt und simulieren ein “Tun”. Die spürbare Wirkung muss jedoch lange gesucht werden. Man steckt fest, tut sich aber schwer, das einzugestehen.

Interessanterweise treffen hier Ursache und Wirkung aufeinander und stabilisieren einen gegenseitigen Teufelskreis. Man spricht nicht wirklich aufrichtig miteinander und kann daher keine Klarheit über den tatsächlich geringen Wirkungsgrad erzielen.

Woher kommt das?
Die Auftraggeber (egal ob intern oder extern) sind es gewohnt, eine Zeitlang ihre Anforderungen zu formulieren (Lasten- und Pflichtenhefte). Dann werfen sie diese Anforderungen in Form eine Auftrags “über den Zaun”. Sie wenden sich ab und anderen Dingen zu. Das geschieht in der Erwartung, die eigene Vorstellung verwirklicht zu bekommen. Nach einer gewissen Zeit – bspw. 2 Jahre – bekommen sie ein Teilergebnis präsentiert, das selbstverständlich kaum etwas mit ihren unausgesprochenen Vorstellungen zu tun hat und der Zank beginnt.
Niemand hat das so ausformuliert, niemand will es so haben und keiner kann es akzeptieren wenn es so kommt. Und dennoch ist es immer wiederkehrende Realität.

“Wasserfall” und “Agile” sind bei diesem Phänomen ähnlich. Allerdings kommt man “agile” früher an den Punkt an dem es genug zu tun geben müsste und keiner etwas tun kann.

Die Ursachen liegen nicht bei dem Gegenstand der realisiert werden soll. Es hat nicht wirklich etwas mit eingesetzten Leuten und auch nichts direkt mit dem Vorgehensmodell zu tun. Der Einführungszeitpunkt agiler Methoden ist schlicht günstig. Ein Vorgehen wie Scrum macht systemische Defizite schneller sichtbar und gibt auch noch das erforderlich Rüstzeug mit an die Hand. Durch Retros, Scrum Master und das Gewicht des Entwicklungsteams hängt viel weniger von einer Person ab.
Im Wasserfall steht und fällt alles mit der Person des Projektleiters. Wenn diese Person über genug Erfahrung verfügt, Kritik zugänglich ist und es versteht, die erforderlichen Dinge in die Wege zu leiten, dann wird der “Crash” des Vorhabens kleiner ausfallen.

Mit ein paar Weichenstellungen muss es gar nicht so weit kommen. Erfolg ist nur eine Frage der Vorbereitung.

Ein wichtiger Hinweis kam hier, wie auch später von einer Teilnehmerin, die ich noch nicht näher kenne. Durch Hinweis von Peter weiß ich nun: es war Katharina König.
Das Hauptproblem entsteht ihrer Ausage nach dadurch, das der Kommunikationsbedarf eines Scrum Teams vollkommen unterschätzt wird – von allen Beteiligten.

Das kann ich nur bestätigen. Ich hätte es so formuliert: “zwischen all dem, was man tun müsste, verkümmert der PO. Er hat keine Vorstellung davon, was er tun soll.”

Warum?
Es genügt nicht mehr, linear seinen Stiefel durchzuziehen. Jede Komponente des Systems muss ihre Position bestimmen und dieser Erkenntnis entsprechend einnehmen. Soweit besteht noch Gemeinsamkeit. Neu ist, dass diese Position sich aus gegenseitigen Einflüssen immer wieder neu bestimmt. Die Zeitabstände zur Auslotung und Übereinkunft müssen immer kürzer ausfallen, je mehr Ungewissheit vorherrscht. Je bekannter das Umfeld, je bekannter der Handlungsgegenstand umso seltener muss die Position bestimmt werden.

Am Anfang ist der Investitionsbedarf ins Verstehen hoch und die Sichtbarkeit von Ergebnissen niedrig.
Je besser hier Grundlagen gelegt wurden, desto rasanter fällt hinterher der Anstieg der wahrnehmbaren Ergebnisse aus.

Warum wird das nicht gesehen?
Agilität wird aus gutem Grund im Umfeld der Digitalwirtschaft so hoch geschätzt.
Die Änderungsgeschwindigkeiten sind hier außerordentlich hoch. Die gegenseitigen Einflußnahmen entsprechend groß in der Auswirkung. Es braucht ein Vorgehen, das dem Rechnung trägt: Scrum und Konsorten.

Der Kommunikationsaufwand in der Digitalwirtschaft fällt nicht so deutlich auf, weil es dort den Kern des Geschäfts betrifft. Insofern ist jede Kommunikationsbeziehung durch den Kern des Geschäftszwecks gerechtfertigt.

Anders verhält es sich, wenn der Dienstleister agil entwickelt und einen Kunden hat, dessen Geschäft digitalisiert werden soll. Dort muss die Bestandskultur, die dieses Unternehmen bis hierhin erfolgreich gemacht hat, hinterfragt und auf die geänderten Bedürfnisse angepasst werden. Es ist eine Operation am offenen Herzen mit genau dieser Kritikalität – kann gutgehen, muss aber nicht.

Christoph Becker brachte dann noch zwei Aspekte, die ich ebenfalls für mein Workshop-Konzept  als essentiell identifiziert habe.

Das eine ist die auf Nutzen fokussierte Kommunikation. Ich erkannte eine These wieder, die ich an anderer Stelle formuliert habe. “Wenn Du den Nutzen nicht ausdrücken kannst, dann lass es ganz.”

Maximize work undone!

Der andere Aspekt betrifft Schätzungen. Für mich sind Schätzungen (Backlog Refinement, “Estimation Meetings” usw.) Kommunikationsanlässe, die das Verständnis schärfen. Sie sind wertvolle Indikatoren darüber, ob sich ein Team im “Tune” befindet. Ob sie einen Mehrwert für das Produkt darstellen ist höchst umstritten.
Christoph gehört zu den Vertretern der #noEstimates-Seite. Ich kann das nachvollziehen. Seine ehemalige Arbeitsumgebung ist genau das eine Szenario, das ich als Ausnahme anerkenne – Ein Team, ein Produkt. Für alle anderen Varianten verweise ich auf Conway’s Law. Es besagt nach meiner Lesart, dass sich im Entwicklungsergebnis die Kommunikationsbeziehungen der Entwickler wiederfinden – oder eben nicht.
Für mich bedeutet das: je schlechter die Qualität der Kommunikation während der Entwicklung, umso geringer die Erfolgschancen des Produkts.

In Bezug auf meinen Workshop bei der Modern RE heißt das:

• Das Phänomen ist im “Konzernumfeld” bekannt und weit verbreitet
  • Es wurde bisher selten thematisiert oder benannt
• Scrum und Digitalisierung machen es wahrnehmbar
  • Sie sind weder Ursache noch Lösung, nur “Kontrastmittel”
• Es gibt mehrere Wirkebenen in der Organisation
  • Mikro: Nutzenbasierte Kommunikation
  • Meso: Rollenbasierende Interaktion
  • Makro: Vernetzende Umgangsformen (aka “Unternehmenskultur”)
• Der Unternehmensgegenstand ist wichtig
  • Je digitaler das bestehende Geschäft, desto weicher der Übergang
  • Je pyramidaler die HORG, desto größer der Wachstumsschmerz
• Die Personen in der PO- Rolle müssen wissen, was auf sie zukommt.
  Das Umfeld kann und muss die Rolle unterstützen.
  • Woher bezieht der PO seine Arbeitsgrundlage?
  • Worauf muss der PO hinwirken?
  • Worauf muss der PO dabei achten?

Simone Ilgert von XPURE hat unsere Session am Flipchart protokolliert.

Das Phänomen “Out-of-Story” tritt immer dann auf, wenn die Entwicklung sowohl zeitlich als auch inhaltlich als separate Einheit betrachtet wird.

Kern des Irrtums ist eine Wasserfall- oder auch Stage/Gate-Denkweise. Das zeigt sich auf der Anfordererseite in der Annahme, ein Dokument “wie man es bisher gemacht habe” genüge weiterhin. Wenn dann niemand am Übergabepunkt die Abnahme verweigert, dann nimmt das Unheil seinen Lauf. Das übergebene Material (P/L-Heft) reicht gerade so weit, dass die Anforderer sich in trügerischer Sicherheit wähnen. Die Wissensträger rechnen dann nicht mehr mit Nachfragen – “ist ja alles beschrieben”. Sie wenden sich anderen Themen zu und sind für Verständnis vertiefende und absichernde Nachfragen nicht zu erreichen. Am Zeitpunkt der ersten Ergebnispräsentationen wird es dann sehr ernst.

Wie kann man dem begegnen?

• Als Dienstleister nur Kapazität und Fähigkeit in überprüfbarer Qualität (DoD!) verkaufen
  – keine Sachzielerreichung versprechen
  Stichwort: agiler Festpreis
  Wirkung: “Money for nothing, and the change for free“
• Die Führungsebene des Auftraggeber muss agile Werte leben

An dieser Stelle warf ich ein. Es war etwas provokant im Ton und nicht so unrealistisch gedacht, wie es vielleicht für manchen geklungen hat:

Und jeden Tag ist Weihnachten!

Ich arbeite u.a. mit zwei DAX-Konzernen, die sich auf den Weg gemacht haben, agil zu werden. Beim einen habe ich eine Sachaufgabe im IT-Kontext. Dort hilft es, den agilen Hebel zu kennen und anzuwenden. Dort bin ich quasi in der Position des Scrum-Teams für meine Sachaufgabe. Ich liefere ein Gewerk. Das geht ganz gut, weil die Rolle recht gut ausdifferenziert ist und es ein breites Regelwerk gibt, auf das ich zurückgreifen kann. Böse Überraschungen erlebe ich dort nicht mehr.

Beim anderen begleite ich die Tranformation als agile Coach. Ich begleite die Agility Master in der Organisation auf dem Weg zu ihrer eigenen Großartigkeit. Jedes Mal, wenn ich mit dieser Organisation interagiere werde ich ein wenig überrascht und reichhaltig beschenkt – Weihnachten ist langweilig dagegen … und viel seltener.

/Heldenreisen

Die Parallveranstaltung beschäftigte sich mit der Synergie von “Storytelling” und UX. Conrad hat ein paar Parallelen identifiziert, die er mit der Gruppe teilen und vertiefen wollte.

Kern des ganzen ist die Frage: Wer ist wer?

Eine Vielzahl von Mißverständnissen, die sich dann zu ernsthaften Konflikten auswachsen, entstehen daher, dass die Beteiligten die Rollen nicht kennen. Manchmal spielen sie auch eine Rolle, die ihnen nicht zusteht. Genannt wurde ein Beispiel aus dem Bankenumfeld. Dort wähnt sich so mancher in der Rolle des Helden. Andere wähnen sich in der Rolle des Mentors (“ich erzähl Dir mal, wie das läuft …”). Tatsächlich sind Banken in den allermeisten Fällen in der Rolle des Helfers, des Ermöglichers (Enabler). Das hat etwas mit Dienen und mit Leistung zu tun.

Ich erinnerte mich bei der Zusammenfassung an einen Moment auf dem diesjährigen freiräume.camp.
Gerhard Wohland intervenierte bei einer Diskussion für seine Verhältnisse scharf.
Es ging um den begrifflichen Unterschied zwischen Kunde und Nutzer.

Es hilft, wenn man sich einen seiner vielen wertvollen Ratschläge in diesem Zusammenhang vergegenwärtigt.

Unterscheide, um den Zusammenhang zu verstehen.
– Gerhard Wohland

Ein anderes schönes Praxisbeispiel fiel mir beim Formulieren dieser Zeilen ein. Ich sah einst eine Dokumentation von der IAA Nutzfahrzeuge. Dort kam ein Speditionsunternehmer zu Wort. Auf die Frage, warum er mit einer Gruppe seiner Fahrer angereist sei, antwortete er: “Ich gebe 250.000€ für eine Zugmaschine aus, in der meine Leute einen großen Teil ihres Lebens verbringen werden.”
Was er meint ist: wenn ich eine Entscheidung gegen die Nutzer fälle, dann werden sie es mit “Minderleistung” honorieren. Sie werden öfter krank oder entwickeln sonstwelche Aktivitäten, um möglichst wenig Zeit “auf dem Bock” zu verbringen.
Oder andersherum: wenn das Umfeld stimmt, bekomme ich die beste, erzielbare Leistung.

Zur Unterscheidung Kunde vs. Nutzer heißt das: für den Dienstleister ist der Auftraggeber wichtig, weil er am Ende die Leistung abnimmt und den Zahlungsfluss auslöst. Der Nutzer ist jedoch derjenige, der die Leistung eigentlich honoriert. Wenn die Lieferung für ihn Nutzen stiftet, wird sie nachgefragt – andernfalls umgangen, vermieden oder nur höchst widerwillig angewandt.

Der Kunde entscheidet, ob etwas angeschafft wird – der Nutzer entscheidet, was es sein soll.

Die Essenz aus dieser Sitzung war für mich die Unterscheidung nach wiederkehrenden Rollen.  Es gibt die Rollen “Held”, “Helfer” und “Mentor”. Manchmal wechselt die Besetzung zwischen den Beteiligten. Das wurde aber nicht gesagt.

Ich habe diese Erkenntnis von einer Agility Mistress aus dem Umfeld eines Kunden:

Erfolgreiche Zusammenarbeit im Konzern ist wie Impro-Theater.

– Angelika Fichtner

Der “Held” ist der Hauptakteur. Je nach Kontext kann es ein Kunde oder Nutzer sein. Es kommt darauf an, wem das Produkt Nutzen stiften soll. Und hier sind die Worte wiederum ein guter Zugang zu den dahinterliegenden Denkmodellen. In einer eCommerce-Lösung stimmen “Kunde” und “Nutzer” oft überein. Wenn ich aber ein kommerzielles Produkt entwickle, dann fallen diese Rollen sehr oft auseinander. Der Kunde ist Ansprechpartner des Vertriebs. Der Vertrieb ist daher ein wichtiger Impulsgeber bei einer Produktentwicklung – was verkauft sich und was ist “schwer zu kommunizieren”? Der Nutzer ist derjenige, bei dem das Produkt einen Vorteil durch dessen Benutzung bewirken soll. Wie stelle ich den erzielbaren Nutzen dar? Ist das Produkt unter MitHILFE seiner Begleitkommunikatoren dazu in der Lage, wird es früher oder später Nachfrage geben? Die Rückmeldungen aus diesem Bereich sollten sehr ernst genommen werden. Die Kommunikationskanäle für Rückmeldungen sollten weit offen stehen, um die außerordentlich wichtigen Impulse von dort aufzunehmen. Warum schreibe ich das so deutlich?
Weil “Kommunikation” in der Vorstellung vieler uni-direktional (ich à Du) stattfindet.
Der Rückkanal (“die” ß ich) kommt in der Vorstellung vieler gar nicht vor. Sehr viele Menschen sind sich überhaupt nicht bewusst, dass es seitens der Hersteller ein dringendes Bedürfnis nach ihrer Anwendersicht gibt.

Erfahrene Personen wiederum können als Mentoren zum Einsatz kommen. Sie müssen das Produkt nicht selbst verwenden und keinen eigenen Nutzen damit erzielen. Ihre Erfahrung ist vielmehr ein Haltegriff, damit “der Held” seinen Weg erkennen und ihn gehen kann. Mentoren sind überall zu finden. Im Vertrieb, bei den Entwicklern und im User-Helpdesk. Man muss ihnen nur zuhören und ihre Ratschläge in die eigene Situation übertragen können.

Exkurs aus gegebenem Anlass:
Vor ein paar Tagen hatte ich eine Zusammenkunft, um ein Coaching-Mandat auszuloten. Der Vermittler war überzeugt, ich würde genau das verkörpern, was der Kunde sucht. Bis zum Ende des Gesprächs war ich der gleichen Auffassung.
Kurz darauf kam die Absage. Sie würden sich jemanden für die Transformation zur agilen Organisation wünschen, der mental näher an ihrem alltäglichen Arbeitsumfeld dran wäre. Ich war Ihnen zu wenig #Maschinenbau und #Automation

Das hat mich schwer irritiert. Ich war nahezu erschüttert. Aus meiner Sicht ist das, was ich seit knapp 25 ernsthaft und gegen Entgelt betreibe genau das (gewesen). Die Erschaffung individueller IT-Systeme, von der Kundenanalyse bis hin zur Systemeinbindung ist nicht #Maschinenbau? Wirkungsgewinne aus #Automation ist bei meinen Kunden der eigentliche Treiber hinter der IT/Digitalisierung – immer schon gewesen.

Nach etwas Verarbeitungszeit kam ich für mich zu diesem Ergebnis:

Wer einen agile Coach mit Branchenkenntnis sucht, der sucht auch einen Mathelehrer, der die Aufgabe schon einmal gerechnet hat.

Wo ist der Unterschied? Im Deutschen ist das nicht so leicht. Das Wort “Lehrer” wird vieldeutig verwendet. Es kommt auf den Kontext an, um den Begriffsinhalt zu erfassen – s. oben. Im Englischen wird etwas präziser unterschieden. “Instructor” ist derjenige, der eine Handlungsweise zum vorgesehen Zusammenhang abstrakt darstellt. Es werden die einschlägigen Umstände betrachtet. Er erläutert das erwartete Verhalten und die Punkte, die beachtet werden sollten. Es geht um konkrete Theorie.
Ein “Trainer” betreut das Einüben in der Praxis. Haltungsfehler werden aufgezeigt und hin zu einem besseren Wirkungsgrad korrigiert.
Ein Coach führt seine Schützlinge (“Coachees”) dorthin, wo sie ihre eigene Großartigkeit entdecken, entwickeln und zur vollen Wirkung bringen können.

In einer späteren Sitzung brachte Conrad das Beispiel seines Sohnes und dessen Klavierlehrer. Für den Sohn ist der Klavierlehrer das Mittel, um etwas zu erlernen, was der Sohn will. Der hatte es im Fernsehen gesehen und will das nun auch können – grob gesagt: er will Rock’n Roll Pianist werden.
Wenn der Lehrer gut ist, kann er alle drei Teilaspekte der Lernhilfe bedienen.
Ich hatte dieses Glück, wenn auch sehr selten. Meist musste ich mir es aus den verfügbaren Angeboten selbst zusammenstellen. Das ist nach meiner Erfahrung aufwendiger als es zunächst scheint. Ohne die oben getroffene Unterscheidung zwischen Instructor, Trainer und Coach wird es schwer einen “Guide” zu finden, der den jeweiligen Bedarf adressieren kann. Wenn man Glück hat, ist der Lehrer zu all dem in der Lage und kann sich auf den Lernstand des Schülers einstellen.
Wenn man den Bauplan aber nicht kennt, ist die Suche nach den fehlenden Teilen eine große Herausforderung.

Wenn alle den selben Begriff verwenden, dann geben nicht einmal unterschiedliche Worte einen Hinweis darauf, wonach man möglicherweise sucht.

/Pause

Ich bin mit Carsten im Gespräch hängen geblieben. Meine Ausgangssituation für den “Out-of-Story-Error” gleicht einer Herausforderung vor der sein Unternehmen derzeit steht. Die Entwickler sind guten Willens, der Auftraggeber auch. Die Kommunikation ist offen und zugewandt. Allerdings bekommt man fachlich keinen Griff dran. Der Auftraggeber liefert nicht das, was die Entwickler brauchen, um ihre volle Wirkung zu entfalten. Wir kamen überein, der Sache gemeinsam auf den Grund zu gehen. Wir tauschten Kontaktinformationen aus und verabredeten, am Folgetag die Sache weiterzuverfolgen.

Ich kam gerade noch dazu, die ersten Bissen von meinem “Sub” zu nehmen als auch schon der zweite Durchgang begann. Zu meiner Entlastung musste ich an dieser Stelle nichts beitragen und konnte zuhören während ich aß.

/Live-Konfliktberatung: Integrationsverweigerung

Nach der Pause konnten wir ein weiteres Mal Zeuge von Conrads Künsten werden. Falk bot uns das dazugehörige Praxisbeispiel. Für mich war es deshalb interessant, weil ich einige der Beteiligten von meiner Zeit bei netresearch noch persönlich kenne. In der Zwischenzeit ist einiges passiert. Den gesamten Kontext konnte ich daher nur aus Falks Erzählungen schließen. Sören war glücklicherweise auch da. So konnte ich vertiefende Fragen stellen, wo mir das Bild noch fehlte.

Als wir den Fall gehört hatten, begann die Untersuchung. Es zeigte sich, dass die Einbindung des neuen Kollegen nicht so erfolgt, wie es erforderlich wäre. Er wurde aufgrund seiner fachlichen Kompetenz rekrutiert und in das Team dirigiert. Der Aspekt der “Freiwilligkeit” wurde vermeintlich eingespart.
Im Team wird die anstehende Aufgabe nicht erkannt oder ignoriert. In jedem Fall erfolgt keine Aufnahme in die Gruppe. Die Beteiligten wollen oder können nicht wahrhaben, dass sie sich in Phase 1 der Teambildungs-Phasen nach Tuckman befinden.
Die Bestandsmitglieder empfinden sich weiterhin als “das Team”. Der neue Kollege fühlt sich dadurch nicht als Bestandteil und verhält sich entsprechend. Der Konflikt bindet alle Beteiligten und die Kompetenzerweiterung über diesen neuen Kollegen bleibt aus. “Unter’m Strich” ist die Situation also noch schlechter, als wenn “der Neue” überhaupt nicht aufgetaucht wäre. Soviel zum Thema “Effizienzirrtum“.

Im Verlauf des Herausarbeitens trugen die übrigen Teilnehmer weitere Beispiele zusammen. Immer wieder stellte sich heraus, dass Teambuilding vernachlässigt wurde – “ham’ wir schon gemacht”.
Ja, aber das ist keine Einmalveranstaltung. Spätestens mit einer Änderung in der Zusammensetzung der Beteiligten müssen alle Phasen des Teambuildings erneut durchlaufen werden.
Es gibt sogar Behauptungen, die Phasen würden jedes Mal durchlaufen, wenn ein Termin begonnen wird. Manchmal braucht es dafür wenige Sekunden, manchmal einige Minuten. Besonders wichtig ist hier auch, dass nach der Performance im Zusammentreffen, die weiterführenden Schritte verabredet werden und das Auseinandergehen sauber erfolgt. Die Phase 5 (“Adjourning”) ist ebenfalls wichtig und wird ebenfalls nur zu gern “eingespart” – “man sieht sich immer (n>1) Mal im Leben.”

Katharina sagte einen, aus meiner Sicht, sehr wertvollen Satz zu ihrem Vorgehen.
“Als Scrum Master gebe ich dem Team das, was es in dieser Phase noch nicht hat.”
Je weiter das Teambuilding vorangeschritten ist, umso mehr von außen angebotene Elemente werden sich vom Team zu eigenen gemacht.

“Inspect & Adapt” beachten!

1. Formgebung – wer steht wie zu wem?
2. Storming – Aufbruch. In welche Richtung? Wer führt dorthin?
3. Norming – wie sollten wir vorgehen, um unser Ziel bestmöglich zu erreichen?
4. Performing – woran messen wir unseren Erfolg?

In der Performance-Phase sind dann diese Elemente vorhanden, an die Bedürfnisse angepasst, eingeübt und unterbewusst praktiziert. Man muss nicht mehr Nachdenken, man tut einfach miteinander. Es braucht allerdings die Erinnerung an den Weg dorthin. Der Weg muss immer wieder neu beschritten werden
– nicht derselbe Weg, sondern der neue auf die gleiche Weise.

Die Kollegen von (ex) Rohde & Schwarz berichteten von einem lang währenden Integrationsversuch. Die Vorkommnisse haben sich über Monate hingezogen, mehrere Scrum Master wurden nacheinander eingebunden und das Management immer wieder mit dem Fall beschäftigt. Das Durchhaltevermögen spricht für das Unternehmen. Allerdings blieben alle Ansätze einigermaßen fruchtlos. Zähigkeit allein führt also noch nicht zum Erfolg. Die betreffende Person war einfach nicht integrierbar.

Über den scheinbar nebensächlichen Aspekt des Hobbies dieser Person – Segelfliegen – hatte Conrad wertvolle Hinweise, die er interpretieren konnte.
“Segelfliegen” sei nur das Mittel. Dahinter stehen “Freiheit”, “Ausgeübte Kontrolle” und “Nervenkitzel”.

Das ist, was Conrad meint mit

Niemand kämpft gegen etwas – jeder kämpft nur für etwas.
Finde heraus, was das ist und arbeite damit.

Für Conrads Sohn ist der Klavierlehrer nur “das Mittel”, um Rock’n Roll-Pianist zu werden. Conrad weiß das. Ich hoffe, der Klavierlehrer auch.

Als ich am folgenden Tag im Kanupark auf die stehende Welle stieg, hatte ich die “Learnings” des Vortags bereits verinnerlicht. Ich erzählte dem Wave-Instructor von meinem Ziel (“Green Room before 50”). Ich erzählte ihm wo ich herkam und welche Zwischenschritte ich gesetzt hatte.
An der Welle besprachen wir, inwiefern die Muscle-Memory vom Snowboarden hilft oder behindert. Gegen Ende hatten wir die Nuancen erörtert und ich wusste, was ich mit dem betreffenden Board in meinem Kompetenzgrad nicht erwarten durfte. Das hat mich befreit. Die zwei weiteren Wave-Sessions waren meine bisher besten im Kanupark.
Zuvor hat mich der Guide wiederholt gefragt, ob er mit mir offen sprechen könne. Selbstverständlich kann er das!
Er kennt mein Ziel (s.o.). Alles was mich dem näher bringt ist willkommen und den Rest könne er auch sagen. Aus seinen Handlungen schließe ich, dass mein Verhalten für ihn unüblich ist. Die Gäste dort sind wohl oftmals unzugänglich für Ratschläge. Ich kann das nicht begreifen. Immerhin sind diese Guides die “Locals” auf der stehenden Welle.
Wenn sie schon Hilfe anbieten, dann … und nun fällt mir etwas ein, dem ich mit Sörens Hilfe seit Jahren auf den Grund gehe. Ich sollte mich weniger um “die Anderen” kümmern.
Oder wie mein Vater sagen würde “Wer nicht will, der hat schon”.

/Scrum: Fördert es das “Gammeln in Gruppen”?

Haben Sie wirklich? Oder gibt es Defizite in der Erkenntnisfähigkeit?
Immerhin wurde Wissen über Jahrhunderte bewahrt und geheim gehalten. Wissen war Macht.
Vor allem Methodenwissen. Wer das Geheimnis hinter der Seide jemandem außerhalb Chinas verriet wurde mit dem Tod bestraft …

Diese Geheimniskrämerei hat tiefe Spuren in der Kommunikationskultur hinterlassen.
Darf man offen sprechen? Mit wem? Ab wann? Und worüber?

Bis es soweit ist, findet kein wirklicher Austausch statt. Eher vorbereitende Annäherung. Man lotet die gemeinsame Basis aus. Wer übernimmt welche Rolle? Worum geht es überhaupt?
Alles Vorbereitungsmaßnahmen für Phase 4 des Tuckman-Modells.
Woher soll also jemand aus dem Stand wissen, was er will?

Der Aufhänger für das Parallelangebot zur Konfliktsession war die Vermutung, das Scrum-Framework könne auch verwendet werden, damit sich das Entwicklerteam “einen lauen Lenz” machen kann. Das Phänomen wurde bereits vom “Org Project” beschrieben. Damals war es noch öffentlich zugänglich.

Mich erinnerte es an eine Thematik, die Peter in der agiLEipzig-Gemeinschaft schon mehrfach als “Toxic Scrum” aufgebracht hat. Es gibt auch den Begriff des “Dark Scrum”, was so etwas wie “Rapids” – also Stromschnellen beschreibt. Ein anderer Begriff dafür ist “Rapid Waterfalls”. Vor knapp zwei Jahren hatten wir das Thema.

Diese Thematik hier erschien mir anders. So wie ich es verstanden habe, hat das weniger etwas mit dem Vorgehen – also grob “Wasserfall” vs. “Agile” – zu tun. Das dahinter liegende Phänomen ist wohl eher auf eine Gruppendynamik zurückzuführen.

Für mich ergaben sich erstaunliche Parallelen zu der Situation, die bei der Live-Konfliktberatung am Ursprung des Konflikts herrschte und durch den Konflikt erst wahrnehmbar wird. Ich vermute, die Team-Stabilität, die den Kollegen beunruhigt, ist vergleichbar mit dem Team-Zustand der Falk umtreibt. Die stabile Bezogenheit aufeinander führt im Zusammenspiel mit dem “#EffizienzIrrtum” zur Unfähigkeit des Systems führt, neue Komponenten (andere Kollegen) zu integrieren. In einer extremen Form sind die Kollegen dann nicht einmal in der Lage, Impulse von innen und außen aufzunehmen und zu verarbeiten.
Das wäre dann kein Scrum mehr. Es wäre nur noch Lean ohne Feedback und ohne KVP. Also die ganz monotone Nummer.

Wenn das Team also mit sich überein gekommen ist, den Weg des geringsten Widerstands zu gehen, dann ist das für mich absolut nachvollziehbar. Es ist energieeffizient. Jede Anpassung kostet Energie und birgt das Risiko des Fehlschlags in sich. Wenn das Umfeld nun Risikovermeidung honoriert und Minderleistung toleriert, dann stabilisiert sich ein Team genau dort. Das Regelwerk gibt ihnen sogar Mittel dafür an die Hand. “Over-Commitment” wird in solchen Umgebungen vermutlich nicht häufig auftreten.

Aus meiner Sicht war die gute Nachricht aus dieser Sitzung: Das Vorgehen funktioniert. Der Rahmen stimmt.
Wie so häufig ist es eine Frage des Umfelds, der Führung, der Unternehmenskultur, was man draus macht.

Auch NOKIA hat eingesehen, dass es zu wenig ist, keine Fehler zu machen.
Der Preis dafür war allerdings recht hoch.

/Ausklang

Wir wurden auf den harten Anschlag durch die Alarmanlage aufmerksam gemacht. Um 23:00h muss der Raum geräumt sein und keine Bewegung darf registrierbar sein. Nach gemeinschaftlichem Aufräumen standen wir rechtzeitig vor der Tür.

Dort lernte ich Monty kennen. Er stand mit Sören zusammen. Die Geschichte, die ihn zu dem Treffen geführt hat, ist sehr erstaunlich. Ein anderes Mal vielleicht mehr davon …

Sören, Monty und ich fuhren dann noch ein Stück gemeinsam zu unseren jeweiligen Zielen.

/etc

Blogbeiträge wie dieser sind übrigens Verarbeitungsergebnisse meiner persönlichen Erlebnisse.
Neben der reinen Wiedergabe des Gewesenen, den vermeintlichen Fakten, gebe ich zusätzlich Einblicke in die Zusammenhänge, wie sie sich mir darstellen. Das entspricht meiner Auffassung von Mehrwert und wie er erzeugt werden kann.

Was auch immer ich sonst noch für beachtenswert halte, teile ich über Blogbeiträge hier und anderswo.
Den besten Überblick über alle Fragmente vermittelt mein twitter-Kanal.

/Medien

Die verwendeten Fotos stammen von der meetup-Plattform und von mir.
Die Flipcharts stammen von Michael Dietrich. Die Fotodokumentation erfolgte durch Peter. Die eingebundenen Fotos stammen von hier.

Ich ordne den Abend als Versammlung gem §23, I , Nr. 3 KUG ein.
Widerstrebende berechtigte Interessen sind mir derzeit nicht ersichtlich.
Wer dennoch nicht fotografisch in Erscheinung treten möchte, kann sich gern an mich wenden.
Ich werde die Fotos dann entsprechend ändern.
Weitergehende Informationen bspw. hier.

Meine Fotos dürfen unter Namensnennung weiterverwenden und verändert werden. CC-BY-SA.

/lebewohl

Lebe lang, in Frieden und Wohlstand.
Mögen sich alle Bedürfnisse in Realität auflösen.

/berühmteletzteworte

Verläuft Dein Leben im Kreis?

Das Leben verläuft in Kreisläufen. Manche sind größer, andere kleiner.
An Ihrem Ende findet sich kein Ende – nur ein neuer Anfang.

Sprich zu denen, die es angeht. Teile, was Dir wichtig ist.