Wer bezahlt die Bugs?

Diese Gedanken sind noch ein bischen unsortiert, ein Update des Artikels ist daher denkbar und wahrscheinlich. Work in Progress.

Zusammenarbeit mit Dienstleistern in der Software-Erstellung

Die Zusammenarbeit mit Software-Dienstleistern in der Individualsoftwareentwicklung hat natürlich verschiedene (mindestens zwei) Perspektiven: der Dienstleister und der Kunde, als Vertragspartner. Je nach Kontext ist es durchaus relevant, noch genauer hinzuschauen, da z.B. in größeren Unternehmen die Einkaufsabteilung erheblichen Einfluß auf die Vertragsgestaltung nimmt.

Grundsätzlich ist es möglich, mit modernen Arbeitsmethoden und Werkzeugen „NULL BUGS“ anzustreben und umzusetzen.

Perspektive des Kunden

Als Kunde erwarte ich eine fehlerfreie Lieferung, und eine technische Entwicklung auf dem Stand der Technik. Dafür gebe ich ja eine Menge Geld aus. Aber es gibt einige Fallstricke, bei denen der Kunde Einfluß hat auf das Ergebnis seines Auftrags:

Preisdruck: wenn ich als Kunde den Preis versuche beliebig zu drücken, kann ein Dienstleister dafür in der Regel keine hochwertige Arbeit mehr abliefern.
Termindruck: wenn ich als Kunde den Zeitdruck im Auftag zu hoch treibe, kann der Dienstleister keine hochwertige Arbeit mehr abliefern
wenn ich den Aussagen des Dienstleisters zu Zeit und Kosten nicht traue, sollte ich einen anderen Dienstleister wählen
Festpreisprojekte in der klassischen „Gewerk“-Vertragsgestaltung machen mich unflexibel, Nachbesserungs-Aufträge machen es im Nachgang häufig teurer. Durchaus auch ein Geschäftsmodell einer Unternehmensberatungen.
Ist die Auswahl unserer Dienstleister nach dem günstigsten Preis nicht dafür anfällig, Dienstleister zu engagieren die NICHT nach dem Stand der Technik arbeiten?

Das sind ein paar potentiell toxische Haltungen, die eine fruchtbare Zusammenarbeit torpedieren können. Es gibt noch zahlreiche mehr, wer eine Weile in der Branche unterwegs ist kennt die Beispiele. Obwohl es wohlbekannten Schwierigkeiten sind, werden die Fehler immer wieder gemacht.

Perspektive des Dienstleisters

Als Dienstleister versuche ich, dem Kunden ein hochwertiges Produkt zu liefern. Aber es gibt da einige Fallstricke:

Bin ich/meine Teams wirklich in der Lage, Nach dem Stand der Technik zu entwickeln und zu liefern? (TDD, 100% Test Coverage, Static Code Analysis, …)
Haben wir feste Teams mit einer stabile Lieferfähigkeit?
Beruht unser Geschäfts- und Aquisemodell nicht darauf, dem Kunden die Fehlerbereinigung extra zu verkaufen, und uns billig in die Verträge reinzudumpen?

Der Dienstleister fühlt sich häufig in einer schwächeren Position gegenüber großen Kunden. Haltung zu bewahren und sich treu zu bleiben, ist langfristig häufig die bessere Strategie, als um jeden Preis mit einem renommierten Kunden ins Geschäft kommen zu wollen.

Auswege aus dem Dilemma

Es fängt mit der Haltung an: Beide Seiten sollten sich auf Augenhöhe und mit Respekt begegnen. Ein befreundeter Handwerker formulierte das mal so: Freunde von mir vertrauen darauf, das ich ihnen ein faires Angebot mache, und ich vertraue darauf, das sie nicht anfangen zu feilschen. Ich finde, das beschreibt es ganz gut. Als Kunde beauftrage ich einen Dienstleister, weil er Experte für etwas ist das ich selber nicht beherrsche, mit welcher Expertise sollte ich also seine Aussagen bzgl. Kosten und Zeitpunkt der Lieferung anzweifeln? Als Dienstleister habe ich kein Interesse, ein überhöhtes Angebot abzugeben, weil ich dann entweder den Auftrag nicht bekomme oder eine längerfristige Zusammenarbeit davon potentiell Schaden nimmt.

Wenn ich als Kunde feststelle, das etwas so teuer ist, das die Umsetzung nicht lohnt, dann sollte ich es vielleicht auch einfach sein lassen, anstatt in ein Vorhaben zu starten bei dem bei allen Beteiligten nur Frust rauskommen kann!

Der Kunde testet.

Eine Variante könnte so aussehen: der Kunde stellt zum Entwicklungsstart eine automatisierte Testsuite bereit, gegen die der Dienstleister jederzeit das Produkt testen kann. Laufen die Tests sauber durch, ist die Software abgenommen. Für Fehler die außerhalb der Testsuite gefunden werden, bezahlt der Kunde die Bereinigung. Der Kunde übernimmt also die Verantwortung dafür, mit der Testsuite eine präzise und vollständige „Spezifikation“ bereitzustellen. Nachteil: der Kunde braucht die Fähigkeiten und Kapazitäten dazu.

Time and Material

Der Kunde vertraut darauf, das der Dienstleister für ein tolles Produkt entwicklen möchte und mehr Spaß daran hat, tolle Features umzusetzen anstatt Fehlerbereinigung zu betreiben. Die Vertragsart „Time and Material“ ist aber z.B. in Einkaufsabteilungen eher unbeliebt, da es aus der Perspektive eines Controllers zu einfach auszubeuten ist. Dennoch sollte man hier klar die Mitwirkungsverpflichtung des Kunden nicht aus den Augen verlieren, da KEINE mehr oder weniger präzise definierte Produktbeschreibung existiert, braucht es kontinuierlichen Austausch mit dem Kunden. Bei der Nutzung von Scrum könnte es sich z.B. anbieten, die Rolle des PO Kundenseitig zu besetzen.

Eine schöne Ergänzung für agile Verträge finde ich daher z.B. eine Konstruktion, die Verträge einfach kündbar zu machen: Von beiden Seiten kann der Vertrag mit einer Frist von zwei Iterationen ohne Begründung gekündigt werden. Wenn der Kunde der Ansicht ist, der Dienstleister liefert zu wenig, kann er ohne große Bindung raus. Für die Gegenseite genau so, wenn die Zusammenarbeit nicht konstruktiv ist oder der Aufwand zum vereinbarten Preis nicht dauerhaft leistbar ist. Die Kündigungsoption soll dabei beide Seiten in erster Linie ermuntern, in einer frustrierenden Situation das Gespräch zu suchen, und nicht in Duldungsstarre auf das Vertragsende zu warten.

#Autokorrektur

Die Formulierung dieser Gedanken ist noch in Arbeit. Sie kann und wird sich vermutlich weiterentwickeln, und dieser Artikel sich damit ändern.

Warum?

Ich bin irgendwie ein „gearhead“, und das Thema Mobilität und Auto hat mich in meinem Leben viel beschäftigt, viel Geld gekostet, viel mentalen Raum eingenommen. Automobilhersteller haben schon zu meinen Kunden gezählt, und ich bin Nutzer ihrer Produkte in verschiedenen Kontexten. Und Mobilitätswandel interressiert mich im Rahmen der Klima-Debatte, da ich von meinem CO2 Fußabruck ja auch runterkommen muss und möchte. Das Auto hat in der Vergangenheit da nicht unerheblich zu beigetragen, meine „Lebensfahrleistung“ dürfte bis jetzt bei ca. 450.000km liegen.

Neben der persönlichen Motivation ist auch die Erkenntnis, das das Gessamtsystem „Auto“ (also inkl. Straßen und anderer Infrastruktur) die Grenze der Nutzbarkeit überschritten hat. So lange die Straßen frei waren, ist individuelle Mobilität mit dem eingenen KFZ eine tolle Sache gewesen. Die Nutzung der Infrastrukturflächen für das Auto macht aber deutlich, das es als Gesamtsystem nicht mehr funktioniert, und Korrekturen im Detail (mehr Parkflächen! mehr Spuren auf der Autobahn!) längst nicht den erwarteten und gewünschten Effekt hat. Der Flächenverbrauch und die Infrastrukturkosten zugunsten des KFZ werden berechtigterweise mehr und mehr in Frage gestellt.

„Das Auto“ ist eine grandiose Erfindung. Da im Moment die Kritik, nachgerade das „Bashing“ des Autos eher populär ist, finde ich es wichtig, auch anzuerkennen welchen Nutzen, welchen Komfort und welche Freiheit das Automobil uns für einige Generationen beschert hat. Mein erstes eigenes Auto (ein sehr gebrauchter, vipergrün-metallic farbener Golf 1) bedeutete für mich, meinen Vater nicht mehr um seinen Fiat Uno anbetteln zu müssen. Selber zu entscheiden, wann und wo ich hinfahren möchte. Nach einer Party auf der Grillhütte einfach auf der flachen Ladefläche im Schlafsack pennen zu können.

Ein bischen später endeckte ich „Auto“ auch als Hobby zum basteln, schrauben, tunen, als Sportgerät und vieles mehr. „Auto“ hat in meinem Leben also viel Zeit eingenommen. Ich erzähle das, weil ich deutlich machen möchte, das ich des undifferenzierten Autohassens unverdächtig bin.

Aber, ich stelle heute fest, das „Auto“ auch in meinem Leben mein Denken geprägt hat. Es hat Lebensentscheidungen beeinflusst. Wie und wo möchte ich leben, wie viel Platz benötige ich. Und an mir selber stelle ich fest, wie sehr sich das Vorhandensein von einem Auto und auf den ersten Blick völlig andere Entscheidungen gegenseitig beeinflussen. Ein Beispiel:

Als Hobby-Musiker (E-Bass) muss ich irgendwie Instrumente und Verstärker und Lautsprecher transportieren. Bassisten brauchen große Lautsprecher, damit es ordentlich klingt, gerade wenn man Rockmusik macht geht das nicht mit Miniaturlautsprechern. Was ich angeschafft habe, war diktiert vom Platz im Auto: es musste in den Golf mit umgeklappter Rückbank reinpassen. Zwei 4x10er Lautsprecher (wem das nix sagt: schwarze Kisten mit ca. 65x65x40cm³), ein Verstärker, zwei Bässe und ein bischen Kleingerödel. Schlafsack und Zahnbürste passten auf den Beifahrersitz. Im Laufe der Jahre tendierte die Ausrüstung potentiell dazu, mehr zu werden. Das Auto ist entsprechend gewachsen, heute sorgt ein Kombi für meine Transportbedürfnisse.

Aber: Hätte ich niemals ein Auto besessen, und diese Möglichkeit niemals gehabt, hätte ich vielleicht nur 1 Instrument mitgenommen. Und einen kleineren Verstärker gekauft. Und den Veranstalter vor Ort was hinstellen lassen, um auf der Bühne Gehör zu finden. Aber da das Auto sowie so da war, haben sich die Fragen nach anderen Möglichkeiten ja nie gestellt.

Ein anderes Beispiel: Für viele Menschen ist Möbelkauf fast ein Synonym für einen Besuch bei IKEA. Natürlich mit dem Auto. Niemand trägt einen PAX-Kleiderschrank zur Bushaltestelle und fährt mit dem ÖPNV nach hause. Ohne Auto, kaufe ich ein anderes Möbelstück in einem anderen Geschäft. Vielleicht im lokalen Möbelhause (von denen es nicht mehr viele gibt). Im Fachgeschäft. Oder beim Schreiner um die Ecke, der mit etwas nach Maß fertigt.

Des Pudels Kern

Mir fällt auf, das viele Menschen heute auf die Autofrage (Könnt ihr auf das Auto verzichten?) antworten, das es ja grundsätzlich richtig wäre darauf zu verzichten, aber bei ihnen halt nicht funktionieren kann. Und erwarten, das die „Autohasser“ ihnen (mundgerechte) Antworten liefern, wie sie ohne Aufwand und ohne Komfortverlust ihren Mobilitätsbedarf befriediegen können ohne eigenes Auto.

Das geht natürlich NICHT!

Kaum eine andere Mobilitätslösung bietet im Moment für viele Menschen einen vergleichbaren Komfort wie das eigene Auto. Daher wird es da keine Alternative geben, die genau das 1:1 ersetzen kann. Selbst ein Taxi mit kürzester Verfügbarkeitszeit und günstigen Kosten wird das nicht lösen, da für viele Menschen das eigene Auto noch zahlreiche Funktionen jenseits der Mobilitätsversorgung (erweiterte Wohnung, Altglassammlung, mobiles Gepäckschliessfach, Telefonzelle, Seitensprungzimmer…) übernommen hat.

Aber die Abhängigkeit beruht häufig auf euren eigenen Entscheidungen, die ihr vielleicht vor 15 oder 20 Jahren getroffen habt! Ihr lebt im Grüngürtel einer Großstadt? Das ist eine Entscheidung, die ihr nur getroffen habt weil ihr ein Auto habt! Die Tochter soll zum Musikunterricht in der 30km entfernten Stadt statt in die lokale Musikschule? Das ist eine Entscheidung, die ihr nur getroffen habt weil das Auto „eh da“ ist!

Auch die Rahmenbedingungen in der Planung von Wohnsiedlungen und Stadtentwicklung sind seid einigen Jahrzehnten immer selbstverständlich(er) von der Nutzung eines (oder mehrerer) eigenen KFZ ausgegangen. Das macht die Hürde sich aus der Abhängigkeit vom Auto zu lösen im Moment häufig größer.

In dem Moment, in dem ich mir bewusst mache welche Entscheidungen ich nur treffe weil das Auto da ist, oder welche Entscheidungen die Abhängigkeit vom Auto weiter persistieren, anstatt sie zu lösen, kann ich anfangen andere Entscheidungen zu treffen. Was bin ich bereit zu verändern, damit ich bestimmte Bedarfe nicht mehr habe? Welche Alternativen habe ich, meinen Bedarf anders zu befriedigen als mit der einfachsten Antwort: „mir dem eigenen Auto“?

Ausblick

Bei mir geht die Frage nach Veränderung im Kopf rum. Und mittlerweile frage ich mich nicht nur „wird es elektrisch? kann es schon autonom fahren?“ sondern auch „brauche ich wirklich noch ein eigenes KFZ? Welche Möglichkeiten habe ich, ohne eigenes KFZ auszukommen?“.

Carsharing ist bei mir im Ort leider nicht gut ausgebaut, aber es ist mittlerweile grundsätzlich vorhanden. Ein Cargo-Bike mit oder ohne Motorunterstützung könnte eigentlich den restlichen lokalen Bedarf für Einkauf und Baumarkt (ich bin und bleibe ein Bastler 😉 ) abdecken. Für alles Andere könnte man Bedarfsgerecht mieten – vom Kleinwagen über den Kombi bis zum Lieferwagen.

Die Fernstrecken erledige ich eigentlich ohnehin lieber mit der Bahn, wenn nicht gerade Gepäck (Musik, Trainingsmaterial, …) die Bahnreise schwierig machen.

Die Kosten? Kann man versuchen zu rechnen, zu erfassen, zu planen. Ich bin da entweder zu schlecht drin, oder in der Vergangenheit haben die Unwägbarkeiten des Lebens meine Planungen immer zerschossen. Ich glaube, von 10% Kosten rauf oder runter hängt keine Entscheidung ab. Klar ist, das wegfallende Kosten eines eigenen KFZ in anderen Bereichen wieder verbraucht werden – mehr Mietwagen, Carsharing oder Taxi-Nutzung. Höhere Investitionen in Fahrrad und entsprechender Kleidung. Wie und wohin sich mein Leben entwickelt, und damit der Mobilitätsbedarf im Detail, kann ich ohnehin nicht vorhersagen.

Noch habe ich ein eigenes Auto. Aber ich habe zunehmend das Gefühl, das es vermutlich mein letztes eigenes Auto sein wird.

Weiterlesen

Sehr inspirierend und aktiv (und „Antreiber“ das Hashtags #autokorrektur auf Twitter) ist Katja Diehl @kkklawitter, meine Empfehlung: folgt ihr!

Software-Architektur und Agilität

Dieser Blog Artikel ist „Work in Progress“ und könnte sich bisweilen ändern…

Auslöser

Der Impuls meine Gedanken zum Thema aufzuschreiben, entsprang einer lebhaften Diskussion auf Twitter zwischen Leonid Lezner und Boris Gloger: Thread . Herzlichen Dank dafür! Da meine Gedanken zu umfangreich sind auch zu lange „gegärt“ haben, jetzt als Blogeintrag und nicht als Twitterantwort.

Der Architekturbegriff

„Architektur“ ist ein Begriff, der für die Softwareerstellung eine Metapher ist. Im Ursprünglichen Sinn bezeichnet Architektur „Den Aufbau und die Gestaltung von Bauwerken“. Die Assoziation mit dem Bauwerk ist nach wie vor tief verankert, und so sickern weitere Metaphern aus dem „Bauwerk“-Kontext in unsere Vorstellung von „Softwarearchitektur“ ein, die heute vielleicht eher schädlich als nützlich sind: Fundamente die gelegt werden und auf denen alles aufbaut, die Vorstellung von einer langfristigen Stabilität und Nutzung. Das „Big Picture“, der große Gesamtplan der Überblick und Sinnhaftigkeit deutlich macht.

Allerdings ist die Softwarelandschaft heute schnelllebiger geworden. Statt langlebiger Denkmäler ist schnelle, dynamische Reaktion auf wechselnde Prioritäten und veränderliche Märkte und Kunden gefragt. Das Bild des großen Bauwerkes beschränkt dabei unnötig unsere denkbaren Assoziationen. Der Mensch tendiert dazu, innerhalb einer Metapher weiterzudenken. Ich persönlich halte das Architekturbild daher nicht mehr für hilfreich, sondern für hinderlich.

Die Architektur in großen Organisationen

In Konzernen wird geredet von „Pflege der Softwarelandschaft“ oder „Bebauungsplänen“. Es wird viel Zeit und Geld investiert, um die gewachsenen Strukturen zu erfassen, verstehen, konsolidieren und einem zentral gesteuerten Strategie zu unterwerfen. Ich habe allerdings noch nie erlebt, das es funktioniert und belegbar die herbeipostulierten „Business-Cases“ dieser Zentralisierung auch realisiert werden.

Was ich aber erlebe, ist das aus „Zustand A“ ein neuer „Zustand B“ geplant wird, budgetiert wird und in die Umsetzung geht. Drei Jahre später, ist die Umsetzung so auf halbem weg, 20% der alten Landschaft ist weg, der Rest läuft noch weil er ja noch nicht vollständig umgesetzt wird. Das Budget ist zu Ende, die Umsetzung wird langsamer weil 70% der Leute nicht mehr weitermachen dürfen, als man feststellt das die neueste Gartner-Studie den „Zustand B“ als Legacy-Lösung einstuft und man anfängt, den „Zustand C“ mit der aktuell angesagten Technologie zu planen. Also Zeit für einen neuen Bebauungsplan, neues Budget und neue Initiativen, die das aktuelle „Big Picture“ in die Umsetzung bringen sollen. Die Geschichte wiederholt sich…

Ganze Abteilungen werden dem Thema gewidmet. Aus meiner Wahrnehmung ist der Einfluss auf das Tagesgeschäft der Entwickler minimal und wird selten als hilfreiche Unterstützung wahrgenommen, sonder eher als sinnentleerte Belastung.

Wozu eigentlich Architektur?

Die Aufgabe einer „Softwarearchitektur“ ist es, bestimmte Eigenschaften in der Software sicherzustellen. Das ist, allgemein gesprochen, ein Ausschnitt aus den nichtfunktionalen Anforderungen (NFR), wie z.B. Wartbarkeit, Betreibbarkeit, Interoperabilität, Veränderbarkeit und Modularität, Wiederverwendbarkeit, etc.pp. Für viele dieser NFRs bietet sich der Begriff der Architektur gar nicht mal direkt an, da die Anforderungen eher Richtung eines kleinen, temporären, und vielseitig Verwendbaren „Etwas“ gehen, Eigenschaften die man mit einem Bauwerk nicht unbedingt verbindet.

Was könnte man anders machen?

Vielleicht ist eine andere Metapher hilfreicher als das Architekturbild. Ein Garten, in dem man Bäume und Büsche pflanzt? Oder ein Baukasten, in dem man die Steine immer wieder neu zusammensetzen kann? Oder ein Orchester, in dem viele Musiker und Komponisten gemeinsam großartige Musik machen? Oder ein Vogelschwarm, der Schwarmverhalten und Individualverhalten unter einen Hut bringt? Ich habe da noch nicht DIE EINE kraftvolle Metapher gefunden, die für viele Menschen gleichermaßen funktionieren würde, aber andere Begrifflichkeiten auszuprobieren könnte helfen, an das Thema heranzugehen.

Man sollte sich von der Vorstellung verabschieden, ein „Big Picture“ wäre hilfreich. Es braucht immer wieder Anpassungen und Korrekturen, bevor auch nur Teile des Big Picture umgesetzt sind, warum sollte man also so viel Energie in die Erschaffung dieses Bildes investieren? Was man braucht, sind die Rahmenbedingungen innerhalb derer Entscheidungen getroffen werden können, und die Ziele, an denen die Entscheidungen ausgerichtet und bewertet werden können.

Teams und Architektur — Architektur und Teams

Häufig wird Architektur als eine sehr technische Angelegenheit verstanden. Systeme und Technologie stehen im Fordergrund. Dabei ist dieser Aspekt gar nicht mehr der spannendste, da es für viele Aufgabenstellungen gute und bewährte Musterlösungen gibt. Mit Microservice-Konzepten rückt ein anderer Aspekt mehr ins Blickfeld: Die Aufteilung der Teams entlang von fachlichen Abgrenzungen. Da eine Stabilität der Teams eine nicht unerhebliche Rolle bei der „Performance“ von Teams spielt, ist es sinnvoll bei größeren Vorhaben die mehrere oder viele Teams umfassen die fachliche Aufteilung in den Vordergrund zu stellen gegenüber technischen Faktoren. Domain Driven Design kann helfen, das große Vorhaben in „self contained“-Einzelteile zu zerlegen, und entlang dieser Einzelteile können sich die Teams formieren.

Und die Architekten?

Das ist im Moment ein Problem, da Software-Architekt ein „natürlicher“ Karriereschritt für einen Software-Ingenieur zu sein scheint. Raus aus dem Tagesgeschäft von Coding und dem Leidensdruck schlechter Projektentscheidungen, endlich selber am großen Rad drehen und dafür sorgen das es endlich einmal richtig gemacht wird. Leider erfüllt sich dieser Wunsch selten. Die Projekte machen doch was sie wollen, da die Architekten nur lose zugeordnet sind. Die Entwickler empfinden die Architektur als untauglich, als veraltet oder als zu umständlich. Die Architekten ziehen sich in ihren Elfenbeinturm zurück und reden erst gar nicht mehr mit den Entwicklern, sondern produzieren Schaubilder ohne Relevanz. In verschiedenen Konzernen habe ich solche Entwicklungen beobachtet oder das Ergebnis beobachten können.

Was wir statt Menschen in der Rolle „Architekt“ brauchen, sind Menschen in den Teams (also vorwiegend Entwickler) die das Wissen und die Erfahrung und den Gestaltungswillen mitbringen, die Lösungen ihrer Teams mit einem Blick über die Grenzen des Teams hinaus zu Gestalten, für Interoperabilität, der Ausrichtung an strategischen Zielen, und anderen nichtfunktionalen Anforderungen.

Und wenn sich die Rolle des Architekten in der Organisation noch wiederfindet, muss sich das Selbstverständnis deutlich verändern: Vom „Senior Oberchecker“ der den ganzen Junior-Devs die Regeln vorgibt, hin zu einem Mentor der die Entwickler dabei begleitet selber sinnvolle Entscheidungen zu treffen.

Fazit

Aus meiner Sicht ist die Vorstellung einer Softwarearchitektur überholt und in weiten Teilen nicht mehr hilfreich, da er unser Denken ein eine nicht hilfreiche Richtung lenkt. Es ist an der Zeit, eine neue Metapher zu suchen, unter der wir eine Reihe von NFRs zusammenfassen und beschreiben wollen. Insbesonders agile Methoden in der Softwareentwicklung könnten von einer neuen Metapher profitieren.

Der große Bauplan hat sich erübrigt, da auch moderne Lösungsarchitekturen andere und viel dynamischere Möglichkeiten bietet, als es vor 35 oder 40 Jahren der Fall war, als der Begriff der „großen Planung“ in das Software-Engineering Einzug gehalten hat.

Heute ist die Aufteilung eines großen Systems auf handlungsfähige Teams wesentlich bedeutsamer geworden gegenüber der lange vorherrschenden technologischen Betrachtung von System-Design.

Coach Reflection Day

Dieser Beitrag ist „Work in Progress“ und wird sich gelegentlich ändern!

Was ist ein CoRe-Day?

Warum CoRe Day?

Menschen die mit Menschen arbeiten brauchen einen sicheren Raum zur Reflektion und zum Austausch. In vielen „sozialpflegerischen Umfeldern“ wie Pflegeberufe oder Sozialarbeit ist seit Jahrzehnten eine entsprechen berufsbegleitende Arbeit unter dem Begriff „Supervision“ etabliert, die unter ausgebildeter Begleitung einen solchen Rahmen bietet.

In der eher technischen Umfeldern (wie kommerzielle Produkt oder Softwareentwicklung) ist solcher Austausch bislang unüblich. Mit der Veränderung hin zu agilen Arbeitsweisen haben sich auch neue Rollen etabliert, die Menschen in Veränderungen begleiten und Veränderungen in Organisationen gestalten, aber in der Regel keinen geschützten Raum haben um ihre eigenen Themen dabei zu bearbeiten und zu reflektieren. Nachdem dieser Mangel erkannt wurde, haben sich Menschen aus der agilen Community Gedanken gemacht und das Format „Coach Reflection Day“ entwickelt, um diesen Rahmen anzubieten.

Zeitaufwand und Kosten sollten dabei so gestaltet werden, das es den Teilnehmern auch ohne Unterstützung des Arbeitgebers ermöglicht wird, einen solchen Termin wahrzunehmen. Die Kosten liegen daher deutlich unter den üblichen Kosten für einen ganztägigen Workshop in IT-Umfeldern.

Wie läuft ein CoRe Day ab?

Das Intro

Eine kurze Einstimmung ins Thema, oft begleitet von einem kurzen Impulsvortrag mit Coachingbezug

Kollegiale Fallberatung

Ein stark strukturiertes Format zur Gewinnung von neuen Perspektiven zu einem gegebenen Fall. Das Format gewinnt neue Hypothesen und Lösungsoptionen aus der Aussensicht unbeteiligter Kollegen, die häufig sehr konkret helfen Handlungsblockaden aufzulösen.

Coaching Dojo

Das Coaching Dojo ist ein Übungsformat aus verschiedenen Coaching-Ausbildungen. Mit einem echten Fall können Menschen üben, Coaching-Gespräche zu führen.

Walk and Talk

Eine Übung um die Fähigkeiten als Zuhörer zu verbessen.

Open Space / Lean Coffee

Zum Tagesabschluss eine offene Runde, die zur Reflektion oder zur weiteren Bearbeitung von Coaching-Verwandten Themen in kleineren Gruppen genutzt werden kann.

Was kann ich von einem CoRe Day mitnehmen?

Die „Fallgeber“ bekommen in aller Regel hilfreiche und wertvolle Anstöße für den weiteren Umgang mit ihrem „Fall“ aus dem beruflichen Umfeld.

Die Coaches können ihre Fähigkeiten trainieren Coaching-Gespräche zu führen, bekommen dazu wertvolle Rückmeldungen mit denen sie lernen können. Sie können sich trauen, neue Dinge auszuprobieren oder erstmalig gezielt in die Rolle als Coach zu schlüpfen und erfahren wie sie sich darin fühlen.

Die Beobachter lernen auch aus der Beobachtung, und helfen dem Coach sich weiter zu entwickeln. Viele Teilnehmer äußern sich im Anschluss so, das sie aus der Rolle als Beobachter am meisten für ihre eigene Arbeit als Coach mitnehmen.

Links und Verweise

Coach Reflection Day

3. CoRe Day Ruhr am 18. Oktober 2019

Organisations-Reverse-Engineering

oder wie Mitarbeiter ihre Zeit damit vertüddeln zu verstehen, wie ihr Unternehmen eigentlich funktioniert.

„Ich habe keine Ahnung“ ist eine Antwort, die ich häufig von meinen Kollegen und Ansprechpartnern in Konzernen bekomme, wenn ich danach Frage wie X oder Y funktioniert. Wie bestelle ich einen großen Monitor oder ein VC-System für den Teamraum? Wie können wir zwei überflüssige Schreibtische entsorgen lassen? Wie bekommen wir einen permanenten Teamraum, statt untauglicher Meetingräume? Mit wem müssen wir reden, wenn wir im Rahmen unseres Projektes einen Prozess ändern wollen, an dem wir andocken oder zu dem wir beitragen?

Dieser Effekt begegnet mir immer wieder. In verschiedenen Branchen. In verschiedenen Ebenen. In Bereichen, die das Arbeitsumfeld unmittelbar betreffen, von Beschaffungen, Einrichtung, und grundlegenden und eigentlich simplen Bedürfnissen.

Für den Alltag der Kollegen hat das leider auf allen Ebenen unerfreuliche Konsequenzen. Sobald sich etwas verändern soll, findet sich niemand, der simple Fragen zur Verantwortung oder dem „richtigen“ Vorgehen beantworten kann. In dem natürlichen Bemühen es richtig zu machen wird dann mehr oder weniger Zeit investiert, um herauszufinden ob und wie das gewünschte Ziel zu erreichen ist. Oder anders formuliert: die Mitarbeiter des Konzerns „reverse-engineeren“ die Abläufe, um herauszubekommen wie sie zum Ziel kommen. Und wenn es immer weniger „operative Routine“ gibt, wie in Projektgetriebenen Organisationen üblich, dann verbringen sie mitunter auch die Hälfte ihrer Arbeitszeit damit, solches organisatorisches Reverseengineering zu betreiben. Die Zeiten, in denen eine Sekretärin als „gute Seele“ Bescheid wusste, oder eben der nächste Vorgesetzte erklären konnte wie es richtig geht, sind lange vorbei.

Ich postuliere: Der Verlust an Wissen über die Prozesse mit seinen Konsequenzen frisst alle Effizienzgewinne durch zentrale Lösungen (Prozesse/Tools) restlos auf.

CAL1 (Certified Agile Leadership 1) Training mit Olaf Lewitz und Alex Kylburg

Dieser Blogbeitrag ist in Arbeit, und mag sich gelegentlich noch ändern, ergänzt oder erweitert werden. Rückmeldungen und Fragen und Kommentare sind jederzeit willkommen!

Vorgeschichte

Mit dem Begriff „Leader“ habe ich ein leichtes Magengrummeln. Ich habe mich selber nie als solcher wahrgenommen und auch wahrnehmen wollen. Selber habe ich mich als Coach und Berater verstanden, aber nie als Leader. Da es in meiner Beratungspraxis aber natürlich immer mal wieder Konflike mit „unagilen“ Abteilungsleitern oder anderen Managern gab, war ich sehr begeistert als ich gesehen habe das die Scrum Alliance an einem entsprechenden Programm arbeitet und erste Trainings zum „Certified Agile Leadership 1“ im Kalender auftauchten. Endlich ein Training für alle die Abteilungsleiter, Gruppenleiter und Management-Menschen, die in einem Scrum Master Training ohnehin fehl am Platz sind.

Als Olaf Lewitz dann seine ersten Trainings angeboten hat, sprach er mich verschiedentlich darauf an, erst für Nürnberg, und dann natürlich erst recht als er in Köln in Zusammenarbeit mit Paragraph 1 ein entsprechendes Training plante. Und nach etwa einem Jahr „Gärungszeit“ war es dann bei mir so weit – Termin, Zeit und Ort waren passend, und ich habe mich kurzerhand mit Alex Kylburg kurzgeschlossen und signalisiert, das ich das Training am 10. und 11. Juli 2018 im Startplatz in Anspruch nehmen wollte und ihn gebeten mir einen Platz freizuhalten. Das CAL1 Training findet sich auch weiterhin im Angebot von Paragraph 1.

Das Training

Die Location „Startplatz“ in Köln kannte ich bereits von anderen Veranstaltungen und habe mich gefreut dort mal wieder zu Gast zu sein. Die Teilnehmer trafen grösstenteils

ein paar Minuten früher ein, und man machte sich bei einer Tasse Kaffee schon mal miteinander bekannt.

Da hing erst mal ein straffes Programm an der Wand als Agenda — gefühlte 25 Arbeitspunkte für die zwei Tage.

Agenda Teil 1

Agenda Teil 2

Und kurz nach dem wir gestartet sind ein eine erste Vorstellungsrunde, eine kleine Gruppenarbeit, ging es auch schon in die erste Reflexion. Und das war ein Element, das uns erhalten bleiben sollte: immer wieder Reflexion in der Gruppe zum gerade erlebten und gelernten. Immer wieder mit der Triggerfrage „was ist jetzt anders?“ um uns in der Gruppe eine Hilfestellung zu geben, wie wir auch in kleinen Schritten lernen.

Ein weiteres Element, das sich in verschiedenen Aspekten wiederholen sollte, waren „Maps“ – mit einer sehr offenen Visualisierung verschiedener Themen im Bezug auf den Teilnehmer und danach einem Austausch in Paaren entwickelte sich zum einen zunehmend ein wenig Routine im schnellen Visualisieren, und in der Erklärung an den Arbeitspartner eine intensive Reflexion über das gezeigte.

Die Themen waren breit gestreut, mein Eindruck war das es mehr darum ging eine Idee zu vermitteln, welche Breite Themen rund um „Agile Leadership“ haben und zu inspirieren, als eines der Themen in der Tiefe erschöpfend auszuloten.

Ja, und wie war es jetzt so, das CAL1 Training?

Eine bunte Gruppe von sehr unterschiedlichen Menschen hat ist sich dort begegnet und hat in immer wieder neuen Konstellationen verschiedene Themen bearbeitet. In Maps. In Gesprächen. Verschiedene Modelle zu Leadership-Themen wurden angerissen – zu jedem dieser Modelle hätte man wohl alleine 2 Tage Workshop veranstalten können.

Bodenarbeit

Wir haben sehr viel über das Gelernte reflektiert und es damit greifbar gemacht.

Wir haben viel gelacht.

Wir haben selber Verantwortung für unsere Themen übernommen, und einen Teil des Workshops ausgestaltet.

Was habe ich für mich mitgenommen

meine Kontexte bewusst und mit Intention managen: Zeit, Ressourcen, Aufmerksamkeit
Temenos: Mein geschützter Raum, in dem Ich sein kann. Und in dem Ich werden kann.
Meine Intention macht einen signifikanten Unterschied.

Nach(t)gedanken

Nach den zwei Tagen war ich dann erst mal platt, und habe die Nacht geschlafen wie ein Stein. Ich bin nicht der Mensch, der mit einer neuen Idee unmittelbar losrennt und Neues ausprobiert. In Summe waren viele kleine Details und einige große Anstöße dabei, die nachwirken und auch noch weiter nachwirken werden.

Ein Punkt zum Beispiel, den ich nach einem Mapping mit deutlich mehr Klarheit sehe, ist mein Umgang mit Zeit und mit Zeitplanung: Um Dinge zu tun (egal was), muss man ihnen Zeit einräumen. Wenn ich also etwas tun möchte, fängt es damit an zu überlegen WANN ich es tun möchte, und wie viel ZEIT ich der Aktivität initial einräumen werde. Ein Haltung im Sinne von „ich maches es wenn ich mal Zeit habe“ KANN nicht dazu führen, zielgerichtet und ergebnisorientiert irgendwas anzugehen, egal was.

Nachgedanken 2, im April 2019

Ich habe mich entschieden, auch den umfangreicheren und längeren Weg zum CAL 2 zu beschreiten, auch mit Olaf Lewitz im Rahmen seiner Trust Temenos Academy.

Der interne Kunde

Bei vielen meiner Beratungskunden, die ich als agile Coach oder Scrum Master unterstütze, treffe ich auf den Begriff des „internen Kunden“. Das Entwicklungsteam aus der „Unternehmens-IT“ (oder ein von der IT beauftragter und gesteuerter Dienstleister) baut also irgend etwas, was eine andere Abteilung oder ein anderes Team braucht. Der Begriff „interner Kunde“ wird benutzt, um in der IT deutlich zu machen: Wir arbeiten nicht für uns selber (die Diskussion warum man das für notwendig hält, ist eine andere Geschichte). An sich also keine schlechte Sache, leider ist das nur eine Facette des Systems. Andere Facetten sind z.B. die folgenden:

Interne Kunden haben häufig kein Wahlrecht. Sie haben noch nicht mal die Entscheidung über „make or buy“. Sie MÜSSEN die hausinterne IT-Abteilung beauftragen, weil das im Unternehmen halt so läuft, und die IT-Abteilung auch keine externe Konkurrenz bekommen soll (hat der IT-Vorstand so entschieden).
Sie müssen das Produkt was erstellt wird auch nicht bezahlen. Das wird in der jährlichen Budget-Planung der IT-Abteilung eingeplant. Eine Kosten-Nutzen Rechnung wie sie ein Kunde normalerweise machen würde, findet nicht ernsthaft statt, eine Auseinandersetzung darüber findet nicht statt und ist auch oft nicht gewollt (Betriebsfrieden und so)
Auch ein benachbartes IT-Team in der Wertschöpfungskette wird auch oft als interner Kunde bezeichnet und betrachtet. Das führt häufig zu Systemen, die Lehrbeispiele für Conways Law sind.

Nur weil die Nachbarabteilung jetzt „Kunde“ genannt wird, ändert sich erst mal nix, im Gegenteil: der Begriff verschleiert, das man nach wie vor in Silos denkt und arbeitet, und NICHTS unternommen hat, gemeinsam Probleme zu bearbeiten und zu lösen, die man im Unternehmen hat. Ich beobachte dabei, das der Begriff dazu führt das eine Distanz aufgebaut wird („Die wissen sowieso nicht was sie wollen oder brauchen, wir machen das schon“) und der Begriff zur Abgrenzung genutzt wird, als das die Zusammenarbeit mit den Kollegen davon profitiert. Eine gemeiname Sicht auf Unternehmensinteressen oder die Wertschöpfungskette wird verhindert, jeder denkt nur bis zum Tellerrand.

Wie erlebt ihr den Begriff „interner Kunde“ in eurem Alltag, ist das ein hilfreiches Konstrukt oder ein klassisches Beispiel für Neusprech? Ich freue mich, wenn ihr einen Kommentar hinterlasst.