Zusammenarbeit mit Externen – zwischen Kontext und Kontrolle

Agiles Arbeiten ist nicht wegzudenken (und das ist gut so).

Externe sind nicht wegzudenken (und das ist oft gut so).

Häufige Muster, die mir dazu begegnet sind, führen dazu, dass diese beiden wichtigen Komponenten der Zusammenarbeit leider nicht zusammen passen.

Daher möchte ich ein Plädoyer für zwei alte Bekannte führen. Zusammen gebracht sorgen sie dafür, dass exzellente, agile Zusammenarbeit entstehen kann.

Dieser Artikel ist eine Niederschrift des Vortrages, den ich im Rahmen der Lean-Agile-Scrum-Konferenz in Zürich am 23.06.2022 gehalten habe.

Warum ist das Thema wichtig?

Dass agiles Arbeiten eine Bedeutung hat, zeigt schon dieser Tag. Ich bin fast nicht mehr überrascht, wer in meinem Freundeskreis von Agilität als Organisationsidee gehört hat.

Die Cello-Spielerin? Ja.

Der Möbeltischler? Auch.

Was mich allerdings nach wie vor überrascht, ist der Umfang der unternehmensübergreifenden Zusammenarbeit. Ich habe bisher kaum Firmen gesehen, die nicht in irgendeiner Art mit Menschen aus anderen Unternehmen, den “Externen” zusammengearbeitet haben. Im Gegenteil, ich sehe diese Zusammenarbeit sogar in den Bereichen der Kernkompetenz einiger Unternehmen, in ihrer Forschung und Entwicklung.

Belastbare Statistiken dazu zu finden, scheint schwer. Willkürlichen Kategorisierungen, mangelnde Representativität (Reliabilität), zehn oder mehr Jahre alte Daten, all dies und mehr lässt einfach keine repräsentativen, aktuellen Aussagen zu. Daher müssen wir auf Erfahrungswerte vertrauen und ich frage in den Raum: Wer kennt ein Unternehmen, in dessen IT- oder F&E-Arbeit keine Externen eingebunden sind? Die Antwort, hier, im schriftlichen ergänzt: Nur drei Personen (von circa 60 anwesenden) hatten sich gemeldet!

Was mich sehr überrascht hat, ist diese Forschungsarbeit, die in Österreich, Schweiz und Deutschland eine durchschnittliche Zusammenarbeitsdauer von etwa vier Jahren nahelegt!

Das ist durchaus eine Zeitspanne, auf die so manches “Team” stolz wäre, zusammen bleiben zu können. Entsprechend ergibt es Sinn, zu schauen, wie die Zusammenarbeit verbessert werden kann.

Zwei Dynamiken kommen zusammen – und nun?

Halten wir kurz fest, was wir bisher herausgefunden haben:

1. Agiles Methoden sind relevant. Es handelt sich um mehr als die notwendigerweise verzerrte Wahrnehmung der Teilnehmenden einer agilen Konferenz.
2. Zusammenarbeit mit Externen ist relevant. Zwar lässt sich der Anteil an der Schweizer Gesamtwirtschaft nicht zuverlässig quantifizieren aber die gemeinsame Suche nach dem schwarzen Schwan im Rahmen der Präsentation zeigte eine klare Tendenz: Nur drei Personen wussten von einem Unternehmen, welches nicht mit Externen arbeitet; und das unter etwa 60 anwesenden Personen!
   Die Dauer dieser Kooperationsverträge mit im Mittel etwa vier Jahren rechtfertigt Aufwand in einen organisatorischen Rahmen zu investieren.
3. Aus den ersten beiden Punkten lässt sich die wahrscheinliche Schlussfolgerungen ableiten, dass agile Zusammenarbeit mit Externen ebenfalls relevant ist.

Kurze Antworten auf fast Alles

Bevor ich mich jetzt weiter mit vollem Elan auf das Thema stürze, lohnt es sich kurz inne zu halten. Agilität wird so häufig gebraucht, dass es mir ratsam scheint, eine kurze Definition vorzulegen. In der Begleitung von Kunden nutze ich diese minimale Definition dazu in wenigen Sekunden einen bleibenden Eindruck zu hinterlassen.

Demnach ist agiles Arbeiten durch drei “I” gekennzeichnet:

1. Interaktion
   Das heisst, agiles Arbeiten ist stets auch Zusammenarbeit. Gemeinhin ist das Team die kleinste Einheit.
2. Iteration
   Diese Zusammenarbeit findet in geschlossenen Rückkopplungsschleifen statt. In diesen können Annahmen überprüft und korrigiert werden. Der ein- bis vierwöchige Sprint in Scrum ist das Paradebeispiel hierfür.
3. Inkrement
   Damit die Rückkopplung nutzbare Informationen liefert, muss das Ergebnis einer Iteration potenziell nutzbar sein. Zumindest in dem Masse, als dass Rückmeldungen realitätsnah sind und nutzenswerte Impulse für das nächste Inkrement liefern.

Weiter im Text.

Warum ist Selbstorganisation für agiles Arbeiten wichtig?

Ein wesentliches Element von Agilität ist die Selbstorganisation. Auf persönlicher und unternehmerischer Ebene. Für ein Team bedeutet diese Selbstorganisation mindestens die eigenen Arbeitsinhalte zu gestalten, umzusetzen, den Erfolg der Umsetzung zu kontrollieren und daraus zukünftige Massnahmen abzuleiten. In diesem Artikel hatte ich unter dem Stichpunkt “Dezentralisieren” mehr dazu geschrieben und gehe darin auch auf Hackmans Logik der Selbstorganisation ein.

Das agile Manifest gibt drei konkrete, spannende Argumente dafür, wie Selbstorganisation die Resultate prägt:

Welcome changing requirements, even late in 

development. Agile processes harness change for 

the customer’s competitive advantage.

principle #2, https://agilemanifesto.org/principles.html

Wenn kurzfristige Änderungen möglich sein sollen, dann muss ein Team schnell und flexibel handeln können. Wenn jedes Mal zunächst eine Änderungsanfrage ausgefüllt werden muss, die dann zu einem Gremium eskaliert wird, wird aus “late in development” vermutlich “too late in development”.

Zum zweiten:

Build projects around motivated individuals. 

Give them the environment and support they need, 

and trust them to get the job done.

principle #5, https://agilemanifesto.org/principles.html

Alle Beteiligten benötigen eine Basis, die dem Team eine hervorragende Zusammenarbeit ermöglicht. Wir werden gleich sehen, dass bei unternehmensübergreifender Zusammenarbeit auch für die Auftraggebenden eine klare (wirtschaftliche) Basis wichtig ist.

Und zum dritten aber nicht letzten:

The best architectures, requirements, and designs 

emerge from self-organizing teams.

principle #11, https://agilemanifesto.org/principles.html

In kaum einem Falle ist die gesamte Kompetenz bei einer Person und auch nicht einem Gremium vorhanden. Oftmals entstehen neue, bahnbrechende Ideen durch das kreative Zusammenwirken. Eins kommt zum anderen. Daher benötigt also eine agile Zusammenarbeit mit Externen den Raum für diese Selbstorganisation.

Die Herausforderungen des Rechts

Wer jetzt Erfahrungen praktische Erfahrungen hat, der:dem dürfte ein grosses ABER im Kopf aufgegangen sein. Schön und gut aber wie lässt sich das mit dem eingeschränkten Weisungsrecht gegenüber Dritten vereinbaren?

Das Schweizer Ordnungsrecht dazu kurz und knapp, in § 321d OR:

V. Befolgung von Anordnungen und Weisungen

(1) Der Arbeitgeber kann über die Ausführung der Arbeit und das Verhalten der Arbeitnehmer im Betrieb oder Haushalt allgemeine Anordnungen erlassen und ihnen besondere Weisungen erteilen.

(2) Der Arbeitnehmer hat die allgemeinen Anordnungen des Arbeitgebers und die ihm erteilten besonderen Weisungen nach Treu und Glauben zu befolgen.

https://www.arbeitgeberweisungen.ch/gesetzliche-grundlage

P21PS ist auch nicht so spannend wie ein Raketenstart – oder?

Und doch hat dieser eine Satz wesentlich dazu beigetragen, dass sich das Team -natürlich waren alle Externe, nur die Product Owner war eine interne Mitarbeiterin- überzeugt hinter das Ziel gestellt hat.

Was macht also eine gute Zielbeschreibung aus? Hierzu gibt es nicht die richtige Antwort; und umso mehr Möglichkeiten. Ich stütze mich hier auf eine Beschreibung, die auf den Scrum-Guide zurück zu beziehen ist und die wir in unseren Trainings nutzen.

Von der Vision zu den Themen der Umsetzung

Die einzelnen Argumente in dem Bild bedürfen kaum einer Ergänzung, stattdessen fokussiere ich mich darauf, aufzuzeigen, wie das mit der oben genannten Vision funktioniert hat.

Zunächst: Diese “P21PS”-Vision wurde in einem Workshop mit den Teammitgliedern, der PO, internen Architekten, HR-Mitgliedern, einem SAP-Berater und dem Bereichsleiter erarbeitet, insgesamt etwa 20 Personen. Das Ganze hat keine zwei Stunden gedauert, tatsächlich waren wir nach etwa 90 Minuten fertig.

P21PS ist ein sogenanntes SAP-package, das vor allem die Extras in der Payroll-Abrechnung betrifft. Wenn also jemand einen Bonus anerkannt bekommt, wird dieser in diesem Payroll-Zusatzmodul verarbeitet.

Die P21PS-Vision hat einen interessanten Ethos ausgelöst. Das Team war stolz darauf, dazu beizutragen, dass besondere Leistungen besonders vergütet werden.

Aus der vorgenannten Vision lassen sich ausserdem zentrale Themen für die Umsetzung ableiten:

• Es handelt sich um eine neue Einführung, keine Integration mit existierenden Lösungen.
• Das gesamte SAP-Package wird eingeführt.
• Es wird weltweit, für alle Mitarbeiter:innen eingeführt.
• Definitionen für hervorragende Leistungen (bzw. die Eingabe- und Kalkulationsmöglichkeit) werden berücksichtigt.
• Es ist zuverlässig, ein Wort, das sich später gut in eine Quantifizierung überleiten liess.
• Die Empfangenden wurden de facto entlohnt, das Ziel war also die echte Auszahlung auf ein Konto.

Ist der Mensch gut?

Schön und gut, so eine Vision. Aber was, wenn es kritisch wird?

Lasst uns innerlich folgende Frage beantworten:

Ein Flugzeug muss notlanden. Bei der Landung zerbricht es, die Kabine füllt sich mit Rauch. Was passiert nun?

Und, wie beantwortest Du die Frage für Dich?

Das Resultat ist kurios. Die meisten Menschen vermuten Alternative B geschehe. Tatsächlich zeigen die Analysen ähnlicher Katastrophen, das die Alternative A vorwiegt. Dazu kommt, dass die Alternative A immer dann verstärkt wird, wenn Menschen in direktem Kontakt miteinander sind. Das Titelbild dieses Artikels ist ein Ausschnitt einer Buchwerbung.

Der Autor des Buches, Rutger Bregman, beschreibt dieses Beispiel und bezieht sich auf die Untersuchungen, unter anderem von Tom Postmes. Ich habe einen zentralen Artikel zum Thema heraus gesucht, er ist nach Anmeldung bei Research Gate einsehbar.

Verbrennt alle Verträge! Oder doch nicht?

Wenn dem so ist, dass die Mehrheit der Menschen im Sinne der Gemeinschaft handelt, warum sollte es dann überhaupt Verträge geben?

Zwei Gründe:

1. Verträge bieten eine gemeinsame Basis. Sie bringen Klarheit, weil Kriterien besprochen und beschrieben werden müssen. Sie dienen hier der Kontrolle.
2. Verträge bieten eine Absicherung. Zwar handelt die Mehrheit der Menschen im Sinne des grösseren Zieles, aber nicht alle und nicht immer. Sie dienen hier der Absicherung.

Also wird es auch in der agilen Zusammenarbeit mit Externen Verträge geben müssen.

Im agilen Arbeiten sind Kosten und Termin fixiert. Klar: Für jede Iteration kann ich den Endzeitpunkt beschreiben. Davon ausgehend, dass der wesentliche Kostenfaktor die Arbeitszeit ist, dann ist diese je Iteration ebenso fest vorhersagbar. Der Umfang wird jedes Mal zur Planung verhandelt und zum Rückblick kontrolliert, ist also eine Schätzung.

Die beiden anderen Dreiecke im obigen Bild zeigen es schon, die gängigen Verträge passen nicht zu dieser Arbeitsweise.

Beim Festpreisvertrag [auf Nachfrage bedurfte es niemandem hierzu eine Erklärung, einzig kam der Witz, dass der Einkauf im entsprechenden Unternehmen am liebsten auch gleich noch Termine mit fixiere] werden Kosten und Umfang festgeschrieben, häufig in aufwendigen Leistungsbeschreibungen. Jedenfalls passt diese Vertragsart nicht, weil sie die Kadenz im agilen Arbeiten, mit den vielen festen Terminen und den resultierenden Datenpunkten nicht berücksichtigt.

Bei Vertragsarten auf Basis von “Time & Material” (T&M) wird nur der Umfang fixiert, Kosten und Zeit sind flexibel. Ein fixierter Umfang allerdings führt wiederum zu den genannten Problemen der aufwendigen Leistungsbeschreibungen. T&M kann so gestaltet werden, dass Termine fixiert und Umfänge geschätzt werden und kommt damit den Anforderungen des agilen Arbeitens näher, allerdings niemals mit der Absicherung von Kosten. Der wenig reglementierte Umgang mit den Leistungsergebnissen in T&M-Verträgen ergibt gerade in sensiblen Bereichen (R&D, IP) kritische Risiken.

Die grosse Stärke des agilen Festpreisvertrages

In diesem Plädoyer, wie ich es eingangs erwähnt hatte, geht es um alte Bekannte. Der agile Festpreisvertrag (Abk. agiler FPV) ist nach meinen archäologischen Recherchen mindestens zwanzig Jahre alt. Einige der Autoren des agilen Manifests (Alistair Cockburn, Martin Fowler) und einige der Veteranen des Gebietes (Mike Cohn) haben sich mit dem Thema beschäftigt. Der agile FPV lehnt sich an den Festpreisvertrag an, fixiert jedoch Kosten -zunächst als Kappungsgrenze- und Termine als Lieferzeitpunkt zum Abschluss von Iterationen. Entsprechend wird der Umfang zur Schätzung.

Mit all meinen Zeichenkünsten habe ich den agilen FPV visualisiert und möchte ihn nun anhand des Bildes erklären:

Erster Teil eines agilen Festpreisvertrages

Zu anfangs, und das ist eine Brücke zur Vision, werden das Ziel und Kriterien, die von zeitlicher Relevanz sind, beschrieben. Aus diesen wird ein initialer Scope abgeleitet, welcher die wichtigsten Themen enthält, die im Ergebnis geschafft werden sollen. Ich empfehle an dieser Stelle übrigens, das nach quantifizierbaren Indikatoren auszurichten, die Gestaltung würde diesen Rahmen sprengen, aber ich stehe für einen Austausch dazu gern bereit.

Weiters werden die maximalen Kosten festgelegt, nach denen der Vertrag beendet wird.

Der Risk Share beschreibt, zu welchem Anteil welche Partei (“intern” vs. “extern”) die Abweichungen bei Aufwandsschätzungen trägt. Zwischen 30 und 70 Prozent sollte diese Aufteilung betragen und ist ein Gestaltungselement, das wesentlich das zukünftige Backlog beeinflusst. Daher empfehle ich auch hier eine strategisch-überlegte Entscheidung.

Exit-Kriterien beschreiben für alle Vertragsparteien, unter welchen Bedingungen sie den Vertrag beenden können. Exit-Kriterien können Ergebnisse beim Kunden sein, Sicherung von Intellectual Property usw.

Die Erarbeitung dieser initialen Kriterien kann in einer ersten Phase stattfinden, die mehrere Iterationen umfasst, also einige Wochen bis wenige Monate. Diese Phase kann auch mehrfach ausgeschrieben werden und bis hin zu einem MVP-tender reichen.

Zweiter Teil eines agilen Festpreisvertrages

Nachdem diese Grundlagen gemeinsam erarbeitet (und ich betone gemeinsam und erarbeitet) wurden, kann die Arbeit in Iterationen und Inkrementen beginnen. Aus dem initialen Scope wird ein Backlog abgeleitet. Dessen Items werden geschätzt, auf relativer Basis. Hier hatte ich über die Grundlagen des Schätzens von Arbeit ausführlich geschrieben. Das Ziel aller Beteiligten ist es, die Velocity zu verbessern ohne jedoch unrealistische Schätzungen abzugeben, dafür sorgt der vorgenannte Risk Share. Im Rahmen der Velocity können Themen ausgetauscht werden, sofern sie weiters zum grossen Ziel beitragen. Dieser sogenannte “exchange for free” ist ein wesentliches Merkmal des agilen FPV.

Das Ganze kann für so viele Iterationen voran getrieben werden, wie es die Vertragsparteien wünschen und die zuvor Exit-Kriterien ermöglichen.

Für weitere Details empfehle ich das Standardwerk “Der agile Festpreis”, leider ist nur auf Deutsch erhältlich. Es enthält auch keine neueren Initiativen zu procurement-processes und MVP-tenders und contract (reverse) auctioning. Das sind Themen, die in den letzten Jahren hierzu weiter entwickelt wurden aber noch keinen Eingang in Bücher gefunden haben und stattdessen in Vorträgen, Reports und Internetseiten zu finden sind. Wer hierzu mehr wissen möchte, kann sich im Nachgang ebenfalls gern an mich wenden.

Zwischen Kontext und Kontrolle

Schliessen wir den Vortrag mit einer Schleife zum Anfang.

Exzellente Leistungen entstehen durch ausserordentlich motivierte Menschen, die wissen, warum sie handeln. Unabhängig davon, ob in der Zusammenarbeit mit nur internen oder auch externen Mitarbeitenden,

Menschen benötigen in ihrer Zusammenarbeit viel Ausrichtung und ein wenig Absicherung.

Die gemeinsame Vision gibt Kontext, Ausrichtung. Eine gemeinsame Kontrolle, Absicherung kann mit agilen Festpreisverträgen erreicht werden.

Der Raum, der sich zwischen diesen beiden eröffnet, ermöglicht tatsächliches, unternehmensübergreifendes agiles Zusammenarbeiten. Versuche stets diesen Raum zu vergrössern!

to be continued

Dieser Artikel ist einer meiner längsten. Und dennoch sind noch lange nicht alle Fragen beantwortet. Viele Informationen sind nicht in gesammelter Form verfügbar, ich habe mich in diesem Rahmen daran versucht.

Manche Fragen sind auch schlichtweg noch offen, zum Beispiel: Was, wenn nur eine Person eines Teams Externe:r ist?

Was weisst Du noch, was für dieses Thema interessant ist?
Welche weiteren Erfahrungen hast Du?