Kontinuierliche Architekturarbeit

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Sven Johann: Hallo und herzlich willkommen zu einer neuen Folge vom INNOQ Podcast. Heute mit Gernot Starke und Sven Johann.

Gernot Starke: Hallo Sven.

Sven Johann: Hi Gernot. Worüber wollen wir reden? Heute wollen wir über kontinuierliche Architekturarbeit reden. Oftmals kommt man vielleicht auf die Idee, dass Architekturarbeit am Anfang eines Systems gemacht wird. Wir fangen auf der grünen Wiese an und machen dann eine Architektur, vielleicht nicht unbedingt Big Design Upfront, aber man muss schon ein bisschen Design Upfront machen. Das zieht sich über einen gewissen Zeitraum. Aber die Frage ist, was ist, wenn wir schon ein halbes Jahr, ein Jahr, zwei, fünf oder zehn Jahre an einem System arbeiten? Es gibt Systeme, die sind relativ alt. Muss man kontinuierlich Architekturarbeit machen? Es gibt mittlerweile ganz interessante Literatur von Eoin Woods, Murat Erder und Pierre Pureur.

Gernot Starke: Wen du alles kennst.

Sven Johann: Ja. Wir reden nicht über das Buch, vielleicht streifen wir ein paar Dinge aus dem Buch, weil die vielleicht einen anderen Ansatz haben. Aber ich wollte fragen, was Gernot empfiehlt, und da gibt es einige Überlappungen. Genau, legen wir los. Du kommst als Consultant zu einem Kunden, bist vielleicht für irgendetwas angefragt, aber du siehst, wie die Architekturarbeit machen oder sie machen vielleicht gar keine Architekturarbeit an diesem zehn Jahre alten System. Was sind die Probleme, die du siehst.

Gernot Starke: Lass uns einen Schritt zurückgehen. Was ist überhaupt Architektur? Letztlich ist Architektur Entscheidungen treffen. In bestimmte Richtungen kommen wir vielleicht noch drauf. Aber das Team trifft sowieso die Entscheidungen. Ob sie die Architektur nennen oder Entwicklung oder DevOps, die Entscheidungen werden getroffen. Jedes System hat Architektur, ob alt oder neu, die passiert auf jeden Fall. Man kann sich überlegen, passiert sie im Sinne der Stakeholder oder der Anforderungen, oder passiert sie zufällig? Fällt eine Entscheidung vom Himmel, weil eine Mitarbeiterin oder ein Mitarbeiter das so machen möchte und es vielleicht nicht besser weiß, oder gehen wir systematischer vor, gucken uns den Sachverhalt und den Kontext an und entscheiden dann bewusst? Dieses bewusste Entscheidungen treffen, das ist ein wichtiger Anteil von Architekturarbeit.

Sven Johann: Gernot Starke: Wir haben im Vorgespräch über Beispiele geredet. Mir begegnet das oft, dass ich Teams kennenlerne, die erfolgreich Systeme bauen, Systeme, die produktiv sind, wo manche Sachen nicht so gut, aber andere Sachen ziemlich gut sind.

Sven Johann: Gernot Starke: Beim Diskutieren stelle ich fest, dass manche Leute eingeschränktes Wissen über das System haben. Ich nenne das fragmentiertes Wissen. Dann gibt es die Situation, dass das Wissen gekündigt hat. Das ist weg. Dann weiß man das nicht mehr. Das hat dieser Externe gemacht, aber der ist nicht mehr da. Wir wissen nicht, warum das so ist. Wir verstehen es nicht genau. Aber der Sachverhalt ist da.

Sven Johann: Gernot Starke: Ich versuche Leuten klarzumachen, dass das, was wir brauchen, nicht hochkomplex ist, sondern wir müssen euer Wissen explizit machen.

Sven Johann: Gernot Starke: Das, was ihr wisst, das, was ihr entscheidet, vielleicht explizit mit jemand anderem teilen. Man könnte drüber reden, statt es nur für sich zu behalten. Oder sogar, und das ist der Luxusfall, vielleicht schreibe ich es sogar auf. Ich will nicht nach großer Dokumentation schreien, sondern wenn wir Entscheidungen treffen, sollten wir sie bewusst und explizit machen, und wenn es eine gravierende Entscheidung ist, vielleicht jemand anderen dazuholen.

Sven Johann: Gernot Starke: Eine zweite Person, eine zweite Meinung. Das ist etwas, was ich als Defizit erlebe, wo Leute sagen, wir möchten mehr Architekturarbeit machen. Wenn du in eine Git-Historie guckst, in eine Commit-Historie, und guckst, was die in die Kommentare geschrieben haben, dann ist da eine gravierende Entscheidung dabei. Guck mal, da habt ihr eine Komponente zerlegt, habt es zu Service 3 gemacht. Das ist doch eine gravierende Entscheidung.

Sven Johann: Gernot Starke: Wer hat die getroffen, wie ist die getroffen? Wenn du Glück hast, findest du den, der den Commit-Kommentar geschrieben hat. Wenn du Pech hast, war das dieser Externe, der nicht mehr da ist, und keiner weiß, warum das ist.

Sven Johann: Ich muss sagen, ein gemeinsamer Bekannter von uns, IT-Leiter, bekannt als Kunde, aber lustiger Kerl, Komiker im Nebenberuf, der hat das erzwungen. Er hat gesagt, niemand entwickelt hier alleine, klassische Extreme Programming Methoden angewandt: weniger Rechner als Entwickler, und du musstest diskutieren und entscheiden.

Gernot Starke: Auch das ist eine Form der expliziten Arbeit. Explizit einfordern, dass wir vorher denken und reden, bevor wir entscheiden. Es geht gar nicht anders. Das ist vielleicht eine harte Herangehensweise, die sich mit der Verbreitung von Laptops nicht mehr durchsetzen lässt, aber das kann ich nachvollziehen, dass du dadurch Wissen verbreitest, Dinge expliziter machst.

Sven Johann: Die Idee ist, dass Programmieren nicht das Produzieren von Text ist, sondern das Aufbauen eines gemeinsamen mentalen Modells der Software. Damals wurde versucht, durch viel Diskussion ein gemeinsames mentales Modell aufzubauen. Leider zuerst ohne Dokumentation. Später wurde klar, dass ohne Doku immer wieder dieselben Sachen diskutiert werden. Wenn du sagst, wir machen implizite Sachen explizit, denke ich an die Foundation Level Schulung, wo wir bei Kunden immer darüber reden, Dinge explizit zu machen. Wir müssen nicht alles direkt explizit machen, aber es muss einen Hinweis geben, damit man es verifizieren kann. In Schulungen oder Consulting-Aufträgen fällt es mir leicht, das zu sagen. Im Projektalltag passiert es aber oft, dass man implizit annimmt, wie zum Beispiel heute, ob Gernot mit uns zu Mittag isst, anstatt explizit nachzufragen. Gibt es aus deiner Sicht Ideen, wie man das zu einer Gewohnheit machen kann?

Gernot Starke: Lass uns das Automatisieren durch diese Gewohnheit ersetzen. Das wäre mir lieber in der Frage.

Sven Johann: Gernot Starke: Zur Gewohnheit: Ich würde diesen Schritt zurückgehen und sagen, lass uns im Team mit diesen drei, fünf Leuten hinsetzen oder an die Kaffeemaschine stellen und überlegen, wie entscheiden wir im Moment? Lass uns explizit machen, wie diese impliziten Entscheidungsprozesse funktionieren.

Sven Johann: Gernot Starke: Schon da habe ich gemerkt,

Sven Johann: Ach so, genau.

Gernot Starke: Das Team arbeitet seit über einem Jahr zusammen. Dann kommt Gernot, stellt Fragen, und nach fünf Minuten merke ich, dass einer von denen mit der Art der Entscheidung unzufrieden ist. Er sagt, ihr entscheidet immer ohne mich. Wenn man das anspricht, wenn man die Leute fragt, wie triffst du eine Entscheidung und wie würdest du sie gerne treffen?

Sven Johann: Gernot Starke: Oder wie sollten wir sie treffen? Das ist das Explizitmachen eines für mich fast Offensichtlichen: Wenn wir als Team arbeiten, sollten wir eine gemeinsame Vorstellung haben, wie diese Arbeit aussieht. In diese Kerbe kannst du weiterhauen und sagen: Wenn wir überlegt haben, wie wir Entscheidungen treffen, können wir direkt fragen, wie seht ihr das Thema Architektur? Was gehört für uns dazu? Glaubt ihr, die ist erledigt, oder glaubt ihr, wir müssen nachsteuern, oder haben wir noch offene Themen, die wir architektonisch klären müssten? Eine Metadiskussion über unser Vorgehen.

Sven Johann: Gernot Starke: Unser Vorgehen bei der Arbeit, unser Vorgehen bei Entscheidungen. Das lässt sich in einer halben bis ganzen Stunde ansprechen. Ich will das nicht drei Wochen bis zu Ende diskutieren. Ich will aber wissen, ich will explizit rausfinden, haben die Leute eine gemeinsame Meinung, sprechen die diese gemeinsame Sprache? Oder gibt es einen, der unter Architektur versteht, das ist die Prozessorarchitektur auf dem Board, Arm oder X86, und der nächste versteht unter Architektur ein Businessmodell? Das sind Ausprägungen, und im Team hätte ich das gerne homogenisiert. Das ist für mich eine Grundlage: Wenn wir Architekturarbeit machen, sollten alle etwas sehr Ähnliches darunter verstehen.

Sven Johann: Ich stelle mir gerade vor, bei einem Kunden, in einem Team gibt es jemand, der alles weiß. Es wäre kein Problem, wenn man fragen würde, wie macht ihr Architektur, der denkt vor und wir laufen hinterher. Aber könnte ich mir in einem anderen Kontext genauso vorstellen.

Gernot Starke: Stell dir vor, du hast hohen Zeitdruck und diese Person hat viel Erfahrung, hat das fünfmal gemacht, ist tiefenentspannt.

Sven Johann: Gernot Starke: Und dann hast du dabei noch drei Leute, die gerade angefangen haben, sehr junior sind. Da kann ich mir gut vorstellen, dass es eine super Idee ist, eine Person entscheiden zu lassen. Und auch die eine Person durchaus vorgeben zu lassen, was wir unter Architektur verstehen.

Sven Johann: Gernot Starke: Wenn jetzt Leute wie du oder andere unserer Kolleginnen mit sehr, sehr viel Erfahrung zusammenarbeiten, dann kann man, glaube ich, mit ganz anderen Arbeitsmodellen rangehen. Wenn du so ein hohes, gleichartiges Erfahrungsniveau in einem Team hast. Auch das ist etwas, was ich ansprechen würde. Es bricht sich ja niemand einen Zacken aus der Krone, wenn ich sage: Wir entscheiden hier gerade über den Einsatz von Dokumenten-Datenbanken und ich habe da echt wenig Erfahrung. Lass mich lieber im Moment bei der Entscheidung raus, weil ich raten müsste. Und es gibt andere Situationen, wo ich sage: Das habe ich schon dreimal gemacht, bei Regel-Engines würde ich lieber mitentscheiden.

Sven Johann: Gernot Starke: Und das gehört für mich auch zur fortlaufenden, kontinuierlichen Arbeit in einem Team, dass wir da eine gemeinsame Vorstellung haben.

Sven Johann: Findest du, weil du sagst, die fundamentale Aufgabe ist entscheiden? Man könnte meinen, entscheiden bedeutet immer, ich habe diverse Optionen. Wir können natürlich sagen, ich habe die Option, nehme ich diese oder jene Bibliothek, diese oder jene Technologie und so weiter. Aber es gibt natürlich auch Design-Entscheidungen, die ich gar nicht wirklich als Entscheidung zwischen zwei Optionen sehe. Wir sind vielleicht am Diskutieren, am kollaborativen Modellieren, oder wir schauen auf Code und sagen, das ist mit der Struktur nicht optimal, aber ich entscheide jetzt trotzdem, so weiterzumachen, statt ein Refactoring durchzuführen. In meinem Gefühl geht das beim Entwurf oftmals unter. Wir entscheiden zwar, aber das passiert irgendwie nebenbei.

Gernot Starke: Ich verstehe deine Frage so, wie eine Entscheidung in einem beliebig großen Optionenraum. Das klingt jetzt abstrakt, aber ich habe ein weißes Blatt, da habe ich einen Rahmen gemalt. Der Rahmen ist unser System, das wir bauen sollen. Wir kennen jetzt die paar Use Cases oder User Stories oder Features, die das Ding leisten muss, und jetzt muss ich da drin ein Kästchen machen. Das ist genau wie ein Gebäude-Architekturproblem. Du hast die Außenmauern und du weißt, du willst drei Büros unterbringen, wie machst du das?

Sven Johann: Gernot Starke: Du hast wirklich eine unendlich große Menge möglicher Aufteilungen eines gegebenen Außenbereichs, der Außenmauern, und willst darin drei Büros machen. In diesen Situationen, das ist das, was ich bei dir als Design verstanden habe. Genau wie beim UX Design kannst du auf beliebig viele Arten Felder in der Oberfläche anordnen. Und da gibt es nicht die Entscheidung zwischen A und B, sondern da könntest du einen Vorschlag unterbreiten, vielleicht noch eine Variante, und dann sagen: Wir schauen uns jetzt mal die Kopplung an, oder wir prüfen, wie kann ich das deployen, wie kann ich das betreiben? Wie kann ich es auf Teams verteilen? Da sind wir dann ganz schnell bei einem iterativen Verfeinern.

Sven Johann: Wenn wir es auf Teams verteilen, das sind natürlich schon größere Entscheidungen. Da glaube ich schon, dass das im Grunde genommen explizit passiert. Ich kenne es anders, aber vielleicht im kleinen. Aber dieses…

Gernot Starke: Ich zerteile jetzt meine Außenmauern, ich ziehe da jetzt Bürowände ein. Da hast du ganz viele Faktoren. Du willst vielleicht die Menge Baumaterial optimieren, die du verbrauchst. Bei der Gebäude-Architektur, du willst vielleicht die Anzahl der Steigleitungen für Toiletten optimieren. Ich weiß nicht, was du optimieren willst. Und für so etwas haben wir in der IT seit ewigen Zeiten ein iteratives Vorgehen entwickelt. Wir haben gesagt, du machst es, und dann holst du dir dazu ein Feedback, eine Rückmeldung. Die klassische Retro bei einem Sprint oder einer Iteration, wo du prüfst: Ich habe etwas gemacht, passt das?

Sven Johann: Gernot Starke: Und dieses: Du machst etwas und holst dir Feedback, das kannst du doch bitte zeitlich auf eine Stunde oder zwei verkürzen. Da könnten wir uns hinsetzen, wir machen jetzt einen Entwurf, ein Design einer Komponente oder eines Teilsystems, und das zeigen wir dann anderen oder challengen es gegen unsere Qualitätsanforderungen, gegen was auch immer. Und iterieren uns so zu dieser Entscheidung, zu dieser endgültigen, wie wir es dann wirklich machen wollen.

Sven Johann: Im Grunde genommen keine Entwurfsentscheidung alleine. Auch vielleicht ganz kleine schon, aber im Grunde genommen alles, wo man das Gefühl hat…

Gernot Starke: Es hat Konsequenzen, es hat Seiteneffekte zu anderen Komponenten, es könnte Laufzeiteffekte bei anderen Komponenten verursachen. Ich bin der Meinung, dass wir die Mehrzahl der Entscheidungen besser zu zweit oder dritt treffen.

Sven Johann: Gernot Starke: Im Inneren einer hoffentlich definierten Black Box, deines kohäsiven Dings, was eine bestimmte Funktionalität abbilden oder implementieren soll. Dass da jemand seine Implementierungsentscheidung alleine trifft, völlig d’accord. Dafür haben wir Pull Requests, Merge Requests, damit jemand noch mal drüber guckt.

Sven Johann: Gernot Starke: Aber diese größeren strukturellen Entscheidungen, wie wollen wir ein System überhaupt bauen, wie wollen wir das zerlegen? Da bin ich der Meinung, sollten…

Sven Johann: Klar.

Gernot Starke: Allein, ich habe wirklich Sorge vor Flüchtigkeitsfehlern. Ich bin notorisch dafür bekannt, dass ich Kleinscheiß übersehe. Ich verrate jetzt keine Details, aber es ist schon so: Bei meinen Entscheidungen sollte besser noch mal jemand draufgucken.

Sven Johann: Gernot Starke: Nein, das ist nicht Absicht, wo mir das auch schon Leute vorgeworfen haben: Du machst das doch absichtlich falsch, weil das ist doch offensichtlich. Oh, Entschuldigung, das war gar nicht offensichtlich, aber egal. Die andere Art von Entscheidung: Ich habe hier drei Tools, mit allen dreien kann ich das Problem lösen, welches nehme ich? Da hast du einen abgezählten Optionenraum. Da kann ich im Grunde zu jeder der Alternativen Vor- und Nachteile systematisch aufzählen und kann die dann vergleichen. Ich halte das für die einfachere Art der Entscheidung. Weil da ist die Frage, nehme ich diese oder jene Library, React oder Angular, und mehr Optionen sind realistisch im Moment nicht zur Verfügung. Das ist oft etwas, das ich auch mit mehreren entscheiden möchte, aber das fällt mir oft leichter.

Sven Johann: Gut. Was mich immer noch interessiert, gerade bei älteren Systemen, die wurden vor einigen Jahren mit einer gewissen Zielsetzung entwickelt. Und diese Zielsetzung kann sich natürlich ändern, der Markt ändert sich, damit ändern sich auch Architekturziele. Aber wirklich nimmt man das gar nicht wahr, weil man in seinem Trott ist. Wie geht man damit um?

Gernot Starke: Darf ich mich erstmal beschweren? Nämlich, dass eine ganze Reihe Projektteams, die ich in meiner Laufbahn kennenlernen durfte, diese Ziele gar nicht kennen.

Sven Johann: Gernot Starke: Da bin ich wieder bei explizit. Die haben natürlich eine Vorstellung von den Zielen. Und ich habe dann ein paar Mal gefragt: Kannst du mir das Ziel nennen? Damit ich als Externer auch aufgeschlaut bin und das Ziel kenne. Dann sagt mir jemand: Wir wollen das beste Online-Recherche-System für Online-Redakteurinnen bauen. Das bekommt ein anderer Entwickler mit und sagt: Nee, sehe ich aber anders. Dann denke ich: Ihr arbeitet jetzt seit drei Jahren zusammen, aber das Top-Level-Ziel eures gesamten Projektes oder des gesamten Systems, das habt ihr niemals diskutiert.

Sven Johann: Gernot Starke: Und das meine ich jetzt mit Beschwerden, dass du einfach sagst, damals gab es ein Ziel.

Sven Johann: In den Köpfen von jemandem gab es bestimmt ein Ziel.

Gernot Starke: Und das ist leider nur sehr selten gedumpt, explizit.

Sven Johann: Ich sage dazu, mir ist das natürlich vollkommen bewusst. Ich habe zum Beispiel einen internen Workshop, ‘Managing Technical Debt’ heißt der, und zur Vorbereitung – das ist nur inhouse – muss man verstehen, auf welches Unternehmensziel die Software, an der wir arbeiten, eigentlich einzahlt. Was sind die wichtigsten Dinge, die diese Software erledigen muss, um die wichtigsten Ziele des Unternehmens zu erreichen? Und das finde ich immer ganz interessant, weil die Leute Zeit haben, das vorzubereiten. Man kann sagen, sprich mit einem PO. Wenn ihr das nicht wisst, viele wissen das. Aber es fällt auch auf, dass manche es überhaupt nicht wissen und sagen, wir haben nachgefragt. Wir sind schon fünf Jahre dabei, wir haben nachgefragt, wir wissen es nicht. Wir haben nachgefragt, die wissen es auch nicht. Wir bekommen halt.

Gernot Starke: Das gibt es doch, solche Anforderungen. Total schade, oder?

Sven Johann: Ist okay, wir gucken.

Gernot Starke: Du hast mich am Anfang nach kontinuierlicher Architekturbearbeitung gefragt. Das ist eine Schleife, in der ich versuche, den Teams praktische Unterstützung zu geben, indem ich sage: Ihr habt mir jetzt gesagt, dass ihr das Ziel nicht ganz genau formulieren könnt. Jetzt solltet ihr euch aber zwischen diesen beiden Varianten oder Tools entscheiden. Das eine Tool hat vielleicht super Laufzeiteigenschaften, ist dafür aber teurer, und das andere hat andere Eigenschaften und ist günstiger. Wenn ich aber das Ziel nicht kenne, wenn ich nicht weiß, ob ich nach Island oder nach Italien in Urlaub will, dann stehe ich an dieser Kreuzung, wo es links oder rechts geht. Ich weiß echt nicht, wohin ich abbiegen soll, weil es eigentlich egal ist. Was ich gern tun würde, ist, dass ich im Sinne dieser großen Ziele konsistent entscheide. Das ist auch etwas, wo ich sage: Wenn ihr länger an einem Projekt arbeiten wollt, finde ich es total sinnvoll, dass ihr diese halbe Stunde investiert und diese Top-Level-Ziele festlegt. Ein großes Top-Level-Ziel brichst du herunter, zum Beispiel ein Online-Recherchesystem, das ein Content Management System unten hat, eine super Suchfunktion und an eine Nachrichtenredaktion angebunden ist. Das ist einfach eine Basis, die ich meiner Ansicht nach haben muss, die aber günstig zu bekommen ist. Das heißt, ich muss da nicht viele externe kaufen, die jahrelang forschen müssen, sondern es ist im Grunde ein bisschen Hausaufgaben nacharbeiten als Grundlage für weitere Architekturbearbeitung, die dann auch konsistenter und nachvollziehbarer ist.

Sven Johann: Ich habe neulich einen interessanten Kommentar gehört: Das stimmt. Es wäre nicht schlecht zu wissen, was derjenige eigentlich will, aber jetzt können wir nicht mehr fragen. Jetzt ist es zu spät.

Gernot Starke: Nehmen wir an, du bist jetzt lange bei einem Kunden als Architekt oder die Kollegin als Architektin oder PO tätig. Ich nenne das gerne ‘Educated Guess’. Wenn ich niemanden habe, den ich fragen kann, dann glaube ich, dass wir mit etwas Erfahrung in der Branche, der Domäne, dem Projekt und dem Team einen guten Vorschlag machen können.

Sven Johann: Gernot Starke: Wenn ich einen Vorschlag habe, kann ich ihn iterieren. Selbst mit Sekundär-Stakeholdern kann ich diese zwei Sätze zeigen und sagen: ‘Guck, wir glauben, das ist aus heutiger Sicht das Primärziel, das wir hier als Team erreichen sollen. Siehst du das auch so?’ Und selbst wenn der ursprüngliche Stakeholder gar nicht mehr dabei ist, komme ich trotzdem immer noch zu einem relativ gut validierten Satz oder zwei, wo klar ist, in welche Richtung es gehen soll.

Sven Johann: Gernot Starke: Diese Architekturlinie, Architektur basiert auf Anforderungen. Wenn ich keine Anforderungen habe, dann kann ich keine vernünftigen Entscheidungen treffen.

Sven Johann: Genau. Das brauchen wir, aber jetzt nehmen wir an, die ändern sich. Wie bekomme ich das mit? Ich bin in meinem Trott drin, ich meine mal negativ, ich mache und mache und kriege es einfach nicht mit, vielleicht habe ich so ein Gefühl.

Gernot Starke: Eine Möglichkeit, die ich sehe: Nehmen wir an, wir machen etwas Ähnliches wie Scrum. Ich sage jetzt bewusst etwas Ähnliches, aber wenn wir so etwas machen, dann haben wir ein bisschen Zeremonie. Am Beginn einer Iteration machen wir ein bisschen Planning für die Iteration, Sprints, und am Ende eines Sprints machen wir ein bisschen Nachbereitung. Ein ganz kleines bisschen. Ich kann mir gut vorstellen, dass wir in der Nach- oder Vorbereitung einem PO oder einer PO in die Augen gucken und sagen: ‘Hat sich an diesen Top-Level-Zielen im letzten Sprint durch die wichtige Messe, durch was auch immer, etwas geändert?’ Siehst du da einen Change? Wenn nicht, gibt es einfach ein Nein, und dann hat das 10 Sekunden gedauert.

Sven Johann: Gernot Starke: Wenn ja, ‘ach ja, habe ich vergessen euch zu sagen’, danke, dann habe ich aber richtig etwas gelernt. Verallgemeinern wir das mal zur Definition of Ready. Ich möchte gerne, dass wir eine Vereinbarung haben, was die Güte von Anforderungen angeht, und zu Anforderungen gehört, auf welches Ziel die Anforderung einzahlt.

Sven Johann: Gernot Starke: Das sollte zumindest einem PO oder einer PO klar sein, für welches Ziel ich gerade dieses Feature oder was immer auf diesem Kärtchen steht, mache. Ich will keine Formalia einführen, auf gar keinen Fall, sondern ich möchte ein Mindset haben, dass auch den POs klar ist: Mit meiner Anforderung treffen die Teams jetzt teure, große, wichtige Entscheidungen. Und wenn meine Anforderung aber nicht mehr auf ein Ziel einzahlt, dann entscheiden wir irgendetwas und geben Wahnsinns-Lizenzkosten aus, und es ist nicht klar, wofür.

Sven Johann: Gernot Starke: Das heißt, da möchte ich, wie gesagt, keine Formalia, sondern eher Verständnis bei den Stakeholdern, die die Anforderungen schreiben, stellen und uns erläutern.

Sven Johann: Das finde ich eigentlich auch sehr gut, weil wir machen ja immer Stakeholder-Analyse und leiten dann Ziele ab, also eigentlich ‘by the book’. Aber es ist schon nicht so einfach, die Sachen im Kopf am Leben zu halten.

Gernot Starke: Eine ganz wichtige Überschrift ist: ‘Mach es pragmatisch’, ich habe mir das vor einem Jahr mal auf den Arm tätowieren lassen. Mach es so, dass es auch über Zeit noch geht. Das ist ja in den ursprünglichen Agile-Geschichten auch immer klar: Das ist ein Marathon und kein Sprint, auch wenn es ‘Sprint’ heißt. Was wir machen, soll langfristig machbar sein, und deswegen fahrt den Formalismus herunter. Versucht den Leuten klarzumachen, dass sie sich auch auf Modalitäten einigen: Das muss schnell gehen, das kann schnell gehen, und dann müssen wir es kontinuierlich beibehalten.

Sven Johann: Gernot Starke: Ich weiß, dass es Tagesgeschäft gibt und alles schwierig ist, das weiß ich auch.

Sven Johann: Ich gucke gerade auf die Uhr. Gibt es etwas, das du als total wichtig erachtest und das wir auf jeden Fall auch noch tun müssten, weil ich denke, wir haben einen ziemlich großen Katalog von Dingen, die wir machen können?

Gernot Starke: Wir haben uns ja schon mal über technische Schulden und deren Verbesserung unterhalten. Ich finde es sehr schön, wenn wir Fehler machen, das wissen wir. Wir treffen suboptimale Entscheidungen und wissen, dass wir das tun. Das ist alles dem Zeitdruck, dem Budgetmangel oder irgendetwas anderem geschuldet, das wissen wir. Ich finde es schön, wenn wir auch mit den verantwortlichen Stakeholdern abgestimmt haben, wie wir mit Risiken, Problemen, technischen Schulden umgehen. Einfach ignorieren und so tun, als wäre es nicht da, die Leiche zubetonieren, das holt uns irgendwann ein.

Sven Johann: Gernot Starke: Ich hätte einfach gerne einen Modus, wie wir damit umgehen. Ich weiß, dass wir die nicht alle beheben können. Ich weiß, dass es immer Schwachstellen geben wird, die bleiben. Aber ich hätte gerne einen Modus, wie wir damit umgehen. Dazu könnte auch gehören, dass ich ab und zu mal so etwas eskalieren und ab und zu mal sagen darf: ‘Hör mal, das stinkt jetzt so sehr, dass wir das als Team wegbekommen müssen.’ Das muss behoben werden.

Sven Johann: Gernot Starke: Es sollte eben nicht nur einen Modus geben, einen Modus Operandi, wie neue Anforderungen zu uns reinkommen, sondern es eben auch einen explizit geklärten Modus, wie wir mit Defiziten umgehen. Aus einem relativ neuen, gerade vor ein paar Wochen geführten Gespräch über uralte Bibliotheken, die schon ewig nicht mehr aktualisiert wurden, hat das Team gesagt: ‘Nee, jetzt ist der Zug abgefahren, wir kriegen es nicht mehr hin.’ Weil die einfach über ewige Zeiten dieses – ich will jetzt nicht PHP 2 sagen, aber so etwas Ähnliches – ewig nicht aktualisiert wurden, und jetzt ist das Aktualisieren so brutal aufwendig, dass das Team gesagt hat: ‘Nee, nee, ist gescheitert, ist einfach kaputt.’ So ‘broken beyond repair’, und das möchte ich gerne vermeiden.

Sven Johann: Managing Technical Debt ist immer so leicht daher gesagt. Zur Orientierung: Es gibt natürlich Aim 42, das sollten wir vielleicht noch mal erwähnen und verlinken. Aber es gibt auch ein interessantes Buch von Philippe Kruchten, ‘Managing Technical Debt’, und ich finde, da kann man auf jeden Fall einen Haufen Informationen sammeln, wie man Schulden sammelt, aufbereitet und abarbeitet. Denn wie du sagst, da muss ich jetzt ran, und das kann ja jetzt nicht irgendwie aus einer Wut herauskommen, sondern ich muss explizit diese Sachen im Backlog haben.

Gernot Starke: Ich bin komplett dabei. Philippe Kruchtens Ideen, die er da beschreibt, das ist dann, glaube ich, eher schon die noble Variante. Das ist auch aus seiner Sicht total plausibel, wie man es eben ganz richtig macht. Jetzt habe ich Teams, die sagen: ‘So aufwendig kann ich das aber nicht machen.’ Dann machen wir lieber nur einen Teil davon, aber irgendetwas sollten wir in diese Richtung machen.

Sven Johann: Was wäre aus deiner Sicht die eine Idee, das besonders schlank über die Bühne zu bekommen, ohne viel Overhead? Eine Art Technical Debt Backlog, sodass ich wirklich schon mal sehe, was ich überhaupt für Defizite habe. Ich habe mal von unserem ehemaligen Kollegen Alex Heusingfeld das mit den Tokens kennengelernt, dass POs und auch das Dev-Team Steuerungstokens bekommen. Wo sie im Planning die jeweils andere Seite meinetwegen einmal im Halbjahr übersteuern dürfen. Das könnte für ein Dev-Team bedeuten: Der PO gibt dir Features, die wir auch schaffen würden. Und dann spielen wir jetzt unseren Token aus und sagen: ‘Du PO, wir haben hier noch diesen einen gut.’ Das heißt, du kriegst jetzt statt fünf nur vier Features, und dafür bauen wir ein paar Technical Debts ab.

Gernot Starke: Sven Johann: Oder Ähnliches.

Gernot Starke: Sven Johann: Das ist ein gegenseitiges Geben und Nehmen, das braucht Vertrauen zueinander. Diese Tokens müssen auch ernst genommen werden, sodass ich sie wirklich ausspielen kann. Ich bin schon lange dabei, aber ich habe trotzdem noch Optimismus, dass sich das in Projekten umsetzen lässt.

Gernot Starke: Meistens.

Sven Johann: Ich muss sagen, ich kenne auch Leute, die sagen: ‘Ist mir eigentlich egal, in drei Jahren bin ich eh Produktmanager, mache etwas ganz anderes, und ich erreiche meine Ziele, auch wenn ich die Software gegen die Wand fahren muss. Das ist ja ein Problem von jemand anderem.’

Gernot Starke: Sven Johann: Genau, da bleibt einem nichts als eskalieren übrig, hast du eben auch gesagt, dass man mächtig eskalieren kann. Es geht jetzt wahrscheinlich zu weit. Eigentlich müssen wir aufhören, die Zeit ist vorbei, aber eine Sache wollte ich noch erwähnen. Ich weiß.

Gernot Starke: Wir und unser Zeitplan.

Sven Johann: Genau, aber das geht ganz schnell. Und zwar die Architekturbrezel. Hast du davon mal gehört? Nein? Okay.

Gernot Starke: Du hast mich ja vorgewarnt, dass du mir was sagen würdest, was ich noch nicht gehört habe.

Sven Johann: Also, Stefan Tod (nicht Stefan Zörner von Empark) hat die Architekturbrezel in seinem Buch beschrieben. Das fand ich eigentlich eine ganz nette Idee, denn man hat sozusagen eine Brezelform. Wir verlinken es. Er sagt, bei jeder neuen Story stelle ich mir diese Brezel vor: Von oben kommt die Story mit den Anforderungen rein. Dann komme ich praktisch an den Teil, wo alle Brezelteile sich berühren, und frage mich: Muss ich hier Architekturbearbeit leisten oder kann ich das einfach runterprogrammieren? Wenn ich das einfach runterprogrammieren kann, mache ich nichts und programmiere es einfach runter. Andernfalls überlege ich: Muss ich hier Architekturbearbeit machen? Ja? Okay, dann mache ich Architekturbearbeit. Ganz einfach ausgedrückt: Ich muss mir wirklich überlegen, welche Optionen ich habe und welche Entscheidungen ich treffen muss. Das fand ich eigentlich ganz nett, das sozusagen auch in eine Definition of Ready zu packen, um zu sagen: Jede Anforderung kommt rein, kurz blitzlichtartig überlegen, reicht es, einfach etwas dranzuhängen und weiterzuprogrammieren, oder muss ich etwas anderes machen? Muss ich noch einmal überlegen? Brauche ich vielleicht etwas Größeres wie eine Factory?

Gernot Starke: Das ist ja ziemlich offensichtlich. Es klingt, als ob du als vielleicht einer im Team mit Erfahrung oder vielleicht zwei, drei Leute, die so ein bisschen den Entscheidungshut aufhaben, explizit überlegen: Was müssen wir jetzt machen? Ich glaube, das passt einfach sehr gut in ein strukturiertes Vorgehen, dass wir Dinge vorqualifizieren, wo wir auch überlegen, wer könnte das überhaupt machen? Und dass ich nicht die Anforderung autonomes Fahren irgendwie dem Junior gebe, sondern dass wir das vielleicht mal… Ich glaube, ihr wisst, was ich meine, aber dieses explizite Überlegen, wie gehe ich mit Dingen um? Ich wusste nicht, dass das Architekturbrezel heißt.

Sven Johann: Also, er hat es, glaube ich, auch gar nicht so genannt, aber so ein Kunde von ihm hat gesagt, sieh ja aus wie eine Brezel. Und der kam aus Nürnberg oder so. Der hat wahrscheinlich alles nicht verstanden. Alright.

Gernot Starke: Danke für die Antwort, Sven.

Sven Johann: Danke für die Antwort. Explizit würde ich jetzt sagen:

Gernot Starke: Explizit vielen Dank an euch fürs Zuhören und Zuschauen und bis demnächst.

Sven Johann: Genau. Bis dann. Ciao.