Gemeinsam kochen, gemeinsam essen — Kollaboration nach DevOps-Art

Ihr wollt mal wieder ein paar Freunde zu einem gemütlichen Abendessen einladen, aber nicht selber kochen.

Stellt euch vor, dass ihr lange keinen schönen Abend mehr mit euren Freunden verbracht habt. Ihr wollt sie gerne zu einem gemütlichen Abendessen zu euch nach Hause einladen. Nur muss dieses Abendessen auch jemand kochen. Denn ihr wollt euren Gästen kein Lieferdienstessen servieren. Das hat beim letzten Mal nicht besonders gut funktioniert. Bleibt also die Aufgabenstellung, das Abendessen zu kochen. An anderen Abenden dieser Art habt ihr die Erfahrung gemacht, dass es keine Option ist, selbst zu kochen. Denn die letzten Male habt ihr die meiste Zeit in der Küche verbracht und nicht viel von euren Gästen gehabt – und die auch nicht von euch.

Das Problem ist aber schnell gelöst. Ihr habt nämlich einen Bekannten, der wirklich gut kocht und von dem ihr wisst, dass er das auch schon bei anderen Leuten für deren Gäste getan hat. Ihr fragt diesen Bekannten und er willigt auch ein, muss sich aber natürlich mit eurer Küche, euren Vorräten und dem ganzen anderen drumherum vertraut machen. Ihr kommt kurz in Versuchung, ihn einfach für denselben Abend wie die Gäste zu bestellen – einfach eine halbe Stunde bevor die anderen kommen. Er aber winkt aber ab und sagt: “Ich schlage dir vor, dass ich mal eine Woche vorher am Samstagabend vorbeikomme, wir eine gute Flasche Wein aufmachen und dabei in deiner Küche schon mal was kochen. Sonst kommt am Abend, an dem die Gäste kommen, erfahrungsgemäß Hektik auf, weil ich dich immer wieder nach diesem oder jenem fragen muss.” Das klingt total einleuchtend, ihr willigt ein und beide Abende werden ein voller Erfolg.

Der Bekannte schlägt vor, dass ihr lieber eine Woche vorher mal in Ruhe in eurer Küche kocht.

Der Vorschlag des Bekannten, sich in Ruhe mit der fremden Küche vertraut zu machen, klingt total einleuchtend, oder? Auch seine Einwände gegen die Idee, einfach am selben Abend eine halbe Stunde früher zu kommen. Es ist nur so, dass wir uns öfter eher so wie in der “halbe Stunde vorher”-Alternative verhalten, wenn wir Software-Produkte übergeben. Mit einer Übergabe meine ich hier, dass in Zukuft ein anderes Team die Software warten und weiterentwickeln wird, als das bisher geschehen ist. Eine solche Situation tritt z.B. oft auf, wenn ein Dienstleister eine Software entwickelt und vielleicht sogar betrieben hat und sie jetzt in die volle Verantwortung des Auftraggebers übergeht. Oder wenn das Software-Produkt langsam den Lebensabend erreicht und nicht mehr umfangreich weiterentwickelt wird, aber immernoch gute Umsätze erwirtschaftet.

Vor allem bei der Übergabe eines Dienstleisters an den Auftraggeber findet dann in der Regel ein mehrtägiger Übergabe-Workshop statt. In diesem Workshop erzählt das bisherige Team dem zukünftigen “alles”, was sie über die Software wissen. Zusätzlich schreiben sie noch die Aspekte in einem Wiki auf, die ihnen wichtig erscheinen. Warum ist dieses Vorgehen nicht besonders nachhaltig?

• Von den Inhalten des Workshops hat das übernehmende Team dann nach wenigen Tagen das meiste vergessen.
• Da wir Menschen nicht besonders gut im Gedankenlesen sind, hat das vorherige Team alles aufgeschrieben, was sie für nötig halten. Das ist aber oft nicht hilfreich für die Nachfolger (“Sag mir, was du noch nicht weißt”). Vieles von dem, was hilfreich gewesen wäre, ist sogenanntes implizites Wissen oder Tacit Knowledge. Das alte Team weiß nicht, dass es das weiß, und das neue Team weiß nicht, dass es es nicht weiß.
• Das grundlegende Problem mit dieser Kombination ist auch, dass das übernehmende Team sozusagen nur die Fotos eines Urlaubs gezeigt bekommt, bei dem es nicht dabei war. Und jetzt sollen sie basierend auf diesen Fotos einen Reisebericht schreiben.

Wie sieht der Vorschlag des Bekannten übertragen auf die Software-Produktentwicklung aus? Beide Teams müssen einfach einen Teil des Weges gemeinsam gehen und echte Arbeit am Produkt selbst erledigen. Dabei teilt das abgebende Team dann auch die ein oder andere Hintergrundgeschichte, was sie warum in der Vergangenheit auf die ein oder andere Weise gelöst haben.

Der gemeinsame Weg der beiden Teams dauert mindestens sechs, besser zwölf Wochen. Bei großen, komplexen Softwareprodukten noch deutlich länger. Für diese Zeit werden die beiden Teams entweder wirklich zu einem Team (1) oder das übernehmende Team hospitiert immer tageweise beim abgebenden (2). Diese beiden Modelle sind inspiriert durch die DevOps Topologies.

Die beiden Teams können entweder durch Einbettung oder kontinuierliche Kollaboration zusammenarbeiten.

In meiner Erfahrung ist die erste Variante deutlich wirksamer, weil es kaum Störgeräusche gibt und sich beide Gruppen voll auf die gemeinsame Arbeit fokussieren können. Wenn das aus irgendeinem Grund nicht möglich sein sollte, ist die zweite Variante aber immernoch deutlich wirksamer als eine Kombination aus Workshop und Dokumentation.

Bedeutet das, dass es in diesem Fall keinen Workshop und keine Dokumentation gibt? Das schließt sich nicht aus, beide Aspekte haben aber eine ganz andere Gestalt. Der Workshop hilft dem übernehmenden Team dabei, einen ersten Überblick über die Software zu bekommen. Die Dokumentation schreibt am besten auch dieses Team. Dann ist die Wahrscheinlichkeit auch viel höher, dass etwas Nützliches drinsteht. Das bedeutet natürlich nicht, dass das abgebende Team vorher nicht wichtige Architekturentscheidungen durch ADRs dokumentiert hat oder es keine API-Dokumentation gibt.