Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Heute wieder mit einer Folge von der OOP Konferenz 2023 in München. Bei mir zu Gast Max Aulinger und Melanie Brunbauer, die sich sehr intensiv mit dem Thema Architekturen beschäftigen. Im Besonderen nämlich Architekturen gemeinsam gestalten, denn sie sehen da einen ganz
wesentlichen Hebel, um gute Architekturen zu entwickeln. Was das bringt und welche Methodiken man nutzen kann, um gemeinsam eine Softwarearchitektur entstehen zu lassen, das verraten sie uns in der heutigen Folge. Viel Spaß beim Hören. Hallo, ich freue mich, dass ihr da seid. Hallo Rüchi, vielen Dank für die Einladung. Ja, sehr gerne. Das ist kein Schwachpunkt unsererseits. Wir sind ja hier auf der OOP, der Spezial-Sommer-OOP, wie ich gelernt habe. Das ist meine erste.
Und normalerweise ist die ja immer so im Anfang des Jahres, aber dieses Mal ist diese Live-OOP im Sommer, also ein ganz ein besonderes Format und das erste Mal mit dem Podcast hier auch vor Ort. Ihr habt gerade euren Vortrag auch gehabt. Ich sehe die Entspannung in euren Gesichtern, das ist ganz toll. Und ja, wir wollen uns ein bisschen über das Thema Architekturen unterhalten. Das ist ein Herzensthema von euch, oder quasi was euch ganz massiv beschäftigt, auch wie man da gemeinsam
daran arbeitet und so. Und ja, da würde ich einfach mal euch auch den Ball geben. Was ist denn so euer Thema da dabei? Was bringt ihr da so mit? Also ja, wir haben ja den Titel gewählt "Architektur gemeinsam bestalten". Und tatsächlich hat der Artikel eine gewisse, oder der Vortrag, eine gewisse Geschichte. Wir haben zusammen letztes Jahr einen Fachartikel geschrieben im
IT-Spektrum. Da ging es um Selbstorganisation, einfach mal ausprobieren. Und wir haben da Experimente in den Fokus gestellt, die die Zusammenarbeit so als gestaltbares Ding in einem Team in den Vordergrund stellen und zum Ausprobieren animieren. Und unsere Überzeugung aus der Arbeit mit Softwareentwicklungsteams, und ich sage da ganz bewusst "unsere", weil ich bin
da immer der Quacksalber, der außen steht als HR-Coach oder Scrum-Master. Melanie ist dann wirklich mit beiden Armen im Code, und das ist ja auch nochmal eine andere Perspektive einbringen. Wir sind der Überzeugung, dass eine intensive Zusammenarbeit, die auch dafür sorgt, dass jeder gehört wird, Ideen von allen Beteiligten aus Teams, auch von den Introvertierten, einfach einen Beitrag zu einer besseren technischen und fachlichen Lösung liefert. Und aus diesem Fachartikel kam
dann eben auch aus dem Review das Feedback zu Architekturthemen. Das war an der Stelle noch eher kritisch und hat uns aber zum Denken gebracht und gesagt "Mensch, die Architektur ist eigentlich sowas, was der Architekturbegriff schlecht definiert." Oder es gibt viele verschiedene Definitionen. Jeder fühlt sich mit einer anderen wohl, aber letztendlich scheint es was Wichtiges zu sein. Und das sind irgendwie harte Entscheidungen, die in der Softwareentwicklung getroffen werden
müssen. Und da wollen wir helfen, weil da an der Stelle ist ganz stark die Zusammenarbeit und auch das gemeinsame, das wir hinarbeiten auf Qualität, auf eine richtig coole Software, unser Steckenpferd. Wusstet ihr noch was, was ich dazu sagen soll? Das ist schon so angesetzt. Genau, also Architekturentscheidungen oder Architektur bringt ja immer dieses bisschen Schwere mit, dass man sich da bewusst ist, okay, wir haben gerade eine Entscheidung zu treffen,
die relativ weitreichend ist. Also es ist keine Änderung, die man nachher einfach wieder revidieren kann. Und deswegen ist es gerade für uns an der Stelle eben wichtig, zu ermöglichen, dass man eine möglichst gute, breite Business-Basis hat, um diese Entscheidung zu treffen. Und deswegen auch dieser Vortragstitel "Mit Architektur gemeinsam gestalten", dass man dann eben diese Basis auch
schafft. Es ist ja, also ich kenne es ja aus meiner Testing-Historie, es gibt dann immer so diese Momente, wenn man dann getestet hat und dann merkt man, oh, lasst es zum Performance, das funktioniert irgendwie nicht, was ist schuld? Die Architektur. Hätte man sich da mal bloß darum gekümmert und dann ist es meistens zu spät, weil sowas im Nachhinein zu ändern, ist, wie sage ich dann auch immer, das kann man machen, aber das ist jetzt auch echt noch
einmal ein Kraftakt. Genau. Ja, die Schwierigkeit ist ja, wenn du es in so einem späten Zyklus feststellst, ist der Schmerzdruck wirklich groß genug, damit irgendjemand gewillt ist, noch mal so viel Geld in die Hand zu nehmen, um diese architekturelle Änderung zu bezahlen. Weil erst mal kannst du von außen ja auch nicht genau feststellen, woran liegt es, diesen Beweis zu
erbringen und ich investiere jetzt das und dann wird es besser. Und tatsächlich adressieren wir in dem, was wir im Vortrag erzählen, mit verschiedenen Team-Experimenten in der Zusammenarbeit, genau solche Dinge. Ich greife jetzt an der Stelle gleich mal in die Mitte rein. Ein Experiment, das wir vorstellen, nennt sich Double Pairs. Was wir an der Stelle machen, ist, wenn ein Software- entwicklungsteam vor zwei unterschiedlichen Lösungsalternativen steht und verunsichert ist,
okay, was ist jetzt besser? Die Hypothesen sagen das, die Hypothesen sagen das, bringen wir Teams dazu, mit zum Beispiel zwei Pairs, deshalb Double Pairs, zwei Pärchen, nebeneinander einen Durchstich zu bauen. Der zu messbaren Kriterien, wenn du jetzt sagst Performance, wenn ich harte Performance Kriterien habe, das muss ich erreichen, damit es die Qualität für meinen Endnutzer ausreichend
abbildet. Dass ich tatsächlich einen Durchstich baue, zwei Durchstiche baue, die ich vergleichbar habe oder zumindest mit den messbaren Kriterien mir einen Rückschluss ermöglichen, was eignet sich jetzt besser. Was sind denn da noch so für Kriterien? Weil ich denke, das ist oft, also wenn ich jetzt so gerade nicht funktionale Sachen annehme, das ist in Unternehmen oft schwierig. Die wissen gar nicht, was sie machen sollen. Ich weiß nicht, wie schnell und wie
schön. Könnt ihr da irgendwie so ein bisschen was an die Hand mitgeben, was das für Beispiele sind, die ihr vielleicht noch habt? Das ist tatsächlich die spannende Frage, weil die einfache Antwort darauf ist, es kommt ganz drauf an. Und uns hat tatsächlich im Vortrag, im Anschluss an den Vortrag auch ein anderer Teilnehmer, die Frage gestellt, ja was sind
denn da Kriterien? Und Pauschalkriterien sind schwierig. Was aber hilft, Kriterien zu finden, ist ganz klar dieser Schritt zurück, was möchte ich mit meiner Lösung erreichen und besser machen? Also ich bin gewillt, viel Geld dafür auszugeben, etwas in meiner Software zu erweitern. Wozu? Und wenn ich diese Frage als Organisation, als Produktverantwortlicher gut beantworten kann, dann kann ich von dort aus auch messbare Kriterien definieren, wann ich mich in der Nähe bewege oder
diese Kriterien erreiche. Das ist ja jetzt, also das ist ja jetzt schon ein intensiver Weg, auch ein Double Pairing. Also muss man schon, das kostet ja, die machen ja dann vier. Also wie läuft das dann? Machen dann immer zwei Pärchen? Muss nicht, kann. Also letztendlich, so fange ich mit Teams gern an, dass es zwei Pärchen sind. Es können aber auch zweimal drei sein. Es hängt auch ein bisschen von den Menschen ab, die da zusammenarbeiten, von der Gesamteamkonstellation
auf was lassen die sich ein. In welcher Größenordnung klappt auch so eine enge Zusammenarbeit, sodass ein lebendiger Austausch da auch stattfindet. Also das ist auch viel Vertrauenssache. Das klappt üblicherweise zu zweit erst mal besser, als wenn man die Gruppe größer macht. Deshalb Double und dann sind es zwei Lösungsansätze, weil den dritten, vierten, fünften hat man vielleicht tatsächlich
vorher in der Diskussion schon verworfen. Und wie lange dauert dann so ein Experiment, wenn ich das jetzt, was habt ihr da so Referenzwerte, wie lange man sowas laufen lassen kann, ohne dass es schon so vielleicht in den Alltag rein sickert und dann hat man zwei Lösungen? Also da empfiehlt es sich vorher einfach im Team ganz klar auszumachen, wann brechen wir dieses Experiment ab. Das kann, wenn man jetzt vielleicht nicht unbedingt ein ganz hart
messbares Kriterium hat, eine Timebox sein. Okay, lasst uns einfach mal jetzt einen Tag investieren. Ihr lauft in Richtung A, wir laufen in Richtung B und dann lasst uns mal morgen früh gucken, wie weit wir gekommen sind und wie sich die beiden Ansätze gestalten. Dann kann das eine Möglichkeit sein. Oder wenn man halt eben ein belastbares, messbares Kriterium hat, dann würde man sozusagen so lange entwickeln, bis man sagt, okay, das können wir jetzt belastbar
testen und dann eben abbrechen. Aber es gibt auch sozusagen verschiedene Varianten, also je nachdem, in welcher Situation man dieses Experiment einsetzen will. Eines zum Beispiel, auch wenn man als Team, sagen wir, zum Beispiel zwei Ansätze gegeneinander abwägt, von denen man den einen relativ gut kennt und der andere aber technologisch eher unbekannt. Dass man sagt, okay, eigentlich würden wir gerne ausprobieren, das anders zu machen, aber wir wissen nicht genau,
wie. Dann lasst uns einfach mal die Zeit investieren und diesen zweiten Ansatz durchstichartig mal antesten, wie sich der anfühlt. Und dann das Bekannte kennt man dann, sagen wir, da einfach die Möglichkeit zu haben, einfach mal da reinzuschnuppern, wie das sozusagen sich gestaltet und dann diese beiden Sachen gegeneinander zu stellen. Also es ist gar nicht unbedingt zwingend, dass man immer zwei Ansätze baut, wenn man den einen gut genug kennt.
Jetzt hast du ja, also das Thema ja Architektur und du hast ja vorher gesagt, das ist total schwierig zu definieren. Habt ihr mal ein Beispiel für zwei so Pärchen, die da so zwei Lösungen machen? Die einen machen was und die anderen machen was? Also eine Variante, die ich erlebt habe, ging stark in Frontend-Technologien und auch letztendlich Frontend, ja setzen wir A, B, eine Frontend-Technologie ein, was eignet sich besser. Also tatsächlich eher so eine
Framework-Bibliotheksentscheidung wäre ein gutes Beispiel. Du hattest auch ein Beispiel mitgebracht in unserem Vortrag. Da ging es tatsächlich auch um Frontend. Richtig, genau. Da hatten wir die Aufgabe, dass wir eine digitale Unterschrift in einen Geschäftsprozess einbinden. Also der Kunde sollte in einem laufenden Geschäftsprozess, da wurde irgendwo ein Vertrag erstellt, der sollte den digital unterschreiben können,
um diesen Prozess dann abschließen zu können. Und jetzt lag dieser Geschäftsprozess aber nicht bei uns im Team, sondern wir waren nur für diese digitale Unterschriftenkomponente zuständig. Und an der Stelle war uns eben, hatten wir fachlich jetzt nicht eine harte Vorgabe, sondern es war nur klar, okay, wir müssen diese Unterschrift leisten. Und dann hatten wir zwei Varianten. Entweder wir leiten den Kunden raus aus dem Prozess auf eine eigene Seite oder wir versuchen
eine integrierte Lösung. Also sprich, wir bauen eine Webkomponente, die wir dann in den laufenden Geschäftsprozess einbinden können und die natürlich dann auch wiederverwendbar wäre für andere Geschäftsprozesse. Und das war so ein Beispiel. Das haben wir noch nie gemacht gehabt, einfach so eine Komponente zu bauen, die dann andere bei sich einbinden. Das war mit einer großen Unsicherheit behaftet, ob das funktioniert, wie das genau funktioniert, wie viel Aufwand das
ist. Und da haben wir uns als Team dann mal entschieden, okay, dann lass uns mal versuchen, das zu bauen, einfach nur als Mock. So wie würde man das integrieren? Kriegen wir das hin in endlicher Zeit? Erfüllt es dieses Wiederverwendbare, das wir uns davon versprechen? Und da haben wir uns, glaube ich, muss ich nicht lügen, eineinhalb, zwei Tage Zeit genommen, um das mal zu verproben. Genau.
Ich überlege gerade zwei weitere Stoßrichtungen. Eins wäre eine Querschnittsfunktion wie Einbindung eines Loggings, wo ich den Ansatz schon gesehen habe, wo man natürlich auch ein Ergebnis kriegt, das man anfassen kann. Wie können wir mit diesem Ergebnis arbeiten? Können wir uns vorstellen, einen Produktionsbetrieb mit diesem Ergebnis zu begleiten? Der andere Ansatz ist mir jetzt entfallen. Muss ich nochmal. Also das Späne nochmal vorbeikommen.
Genau. Gefühl bekommen. Also der springende Punkt ist, es sind, wir bewegen uns auf der Ebene, wo einzelne Teams oder wenige Teams im Code, tief im Code arbeiten und auch häufig unterwegs Architekturentscheidungen entweder manifestieren, indem sie coden und sie gar nicht bewusst treffen oder eben dorthin kommen, dass sie sich bewusst treffen. Das andere Beispiel, wir haben zum Beispiel Anwendungen von externen APIs. Blockieren, nicht blockieren, synchron, asynchron. Wie fühlt
sich das dann auch an der Oberfläche an? Solche Dinge, die hands-on im Code tatsächlich erst sichtbar werden. Ja. Ich glaube, das ist ja, also ich kann mir das total gut vorstellen, dass man, wenn man die zwei Lösungen hat und die auch dann inhaltlich, sagen wir mal so, vergleichen kann gegen die Kriterien. Jetzt hat man vielleicht im besten Fall beide erfüllt, sind die erfüllbar. Da muss man immer noch entscheiden und es gibt ja in diesen Prozessen ja häufig auch, sagen wir mal so,
Vorlieben. Und so der eine sagt, wenn das mein Ding ist und da bilden sich ja, das ist ja auch, glaube ich, eine gewisse Art der Moderation notwendig, damit man da nicht sagt, okay, das war jetzt nett, aber wir machen dann doch das andere. Wir haben tatsächlich das auch im Vortrag als Konfliktpotenzial aufgezogen. Also von, auch ein Team, das ich begleiten durfte, die das als Team Kultur gelebt haben, das als sportlichen
Wettbewerb zu verstehen. Also wenn sich zu einem Zeitpunkt X keine Lösung besser oder schlechter anfühlt, dann gewinnen die, die schneller ein belastbares Ergebnis haben. Und dann auch zu sagen, hey, okay, cool, das heißt, wir haben jetzt was und müssen an der Stelle nicht weiter nachdenken, wir sind schneller, cool. Aber das braucht sehr viel Vertrauen und auch Menschen, die im Zweifelsfall zurückstecken und sagen, sonst brauchst du eine Moderation und auch eine
bewusste Entscheidungsfindung. Also immer einen vollen Konsens auszuhandeln, ist auch nicht immer sinnvoll, sondern auch ein "ist gut genug für mich, für uns" ist dann oft ein hilfreiches Mittel. Ich glaube, es muss halt dann auch bewusst werden. Es muss bewusst und klar gemacht werden, weil sonst hat man so eine Larifari-Lösung, wo die zwei nicht da mitziehen und dann sagen, jetzt aber echt Käse. Und dann hat man immer so einen latenten Grabenkampf dann auch.
Also du hast dann schnell, im Endeffekt, wenn du die Kriterien wählst und an der Stelle als Team West stellst, die sind sehr gleich auf die Lösungen. Ich meine, möglicherweise wird man dann das Experiment verwerfen, weil lohnt es sich dann, diesen Doppel-Invest zu gehen? Wenn man es sich aber lohnt, an der Stelle dann letztendlich sich auch klar zu verständigen, wie treffen wir dann die Entscheidung? Werfen wir dann eine Münze oder machen wir Best of Five? Letztendlich bewusst
zu entscheiden, ist dann das, worauf wir auch hinführen wollen. Das ist ja jetzt eine Variante, wenn man so gemeinsam Architektur abfährt. Aber ihr habt ja wahrscheinlich noch was dabei, oder? Wir haben vorne und hinten noch ein anderes Experiment. Also letztendlich sind wir eingestiegen, vorneweg, das war jetzt schon mittendrin und ganz tief drin, eben die Architektur entsteht und wird oder die Entscheidung steht und wird durch, ich habe was zum Anfassen. Wir haben vorneweg gesagt,
was oft hilfreich ist, ist auch ein klares Wozu zu haben. Wir sind ja bei den messbaren Kriterien schon vorbeigekommen. Teams, die wir begleiten, arbeiten meistens iterativ inkrementell. Das heißt, sie haben in irgendeiner Form eine priorisierte Liste von Themen, die als nächstes kommen. Und was wir an der Stelle feststellen, ist meistens mit dem in der operativen Grasnarbe so bei, kommt morgen, kommt morgen, kommt vielleicht in zwei Wochen, kommt in vier und aber nicht mehr
weiter bis hin zu von der Hand in den Mund. So wir gehen jetzt in ein Sprintplanning und die drei
Sachen kommen und die müssen jetzt klar genug sein. Und was wir an der Stelle gerne tun, ist in diesem regelmäßigen Kultur, in der man plant, auch in einer regelmäßigen Kultur zusammenzukommen, zu sagen, was kommt als nächstes und nicht nur die nächsten drei Sprints, sondern jetzt lasst uns mal in dieser Stunde, die wir darüber diskutieren, uns austauschen, den Schritt zurück zu gehen und zu sagen, wo wollen wir mit unserem Softwareprodukt in einem
halben Jahr sein? Was wollen wir dann erreicht haben? Und das aber ganz bewusst in einer kurzen Timebox, um diesen Blickwinkel herzustellen und aber nicht bis ins letzte Detail auszuleben, sondern einfach mal so einen Überblick herzustellen. Das ist vorne weg. So, dann könnte man sagen, gibt es vielleicht hinterher auch noch was. Letzten Endes ist ja jede Architekturentscheidung nur so gut,
wie dann die Umsetzung ist. Also das heißt, man kann zwar vorne weg was entscheiden, aber wenn dann das nicht im Code zum Leben erweckt wird, dann ist diese Entscheidung letzten Endes hinfällig. Und erfahrungsgemäß sind die Umsetzungen meistens so gut, wie das Verständnis der Leute von dieser Entscheidung ist, die dann tatsächlich auch Code schreiben. Das heißt, es kommt ganz arg darauf an, diese Entscheidung klar zu kommunizieren, verständlich
zu machen und auch zu zeigen, wie das dann in der Realität aussieht. Und da haben wir eben als mögliches Experiment Mob Programming vorgeschlagen. Das heißt, das Team hat jetzt eine Entscheidung, die liegt auf dem Tisch. Sagen wir mal, die ist über Double Pairs zustande gekommen. Dann haben zwei Leute diesen Durchstich erarbeitet und die anderen zwei kennen den aber ja von der Umsetzung her noch nicht. Und das heißt, da muss einfach ein gewisser Wissenstransfer dann auch stattfinden.
Und das klappt ganz gut im Mob Programming. Ja, und wie sieht das aus? Also gibt es ganz unterschiedliche Formen. Jetzt mit Corona ist es auch remote ganz stark natürlich gewesen. Und das hat tatsächlich große Vorteile, weil man, also früher war Mob Programming, ja man trifft sich in einem Raum, man hat einen Bildschirm und die einen sitzen weiter vorne, die anderen sitzen weiter hinten. Man sieht vielleicht gar nicht so gut auf die Entfernung.
Und in dieser Remote Situation ist es halt so, jeder sitzt vor seinem Rechner. Der Driver übernimmt das Schreiben vom Code und alle anderen sehen aber direkt auf ihrem Bildschirm, was da passiert. Und der Trick ist dann, dass der Driver vielleicht möglichst wenig kommentiert, was er tut, dieses Kommentieren, aber dann die anderen übernehmen. Und das kann dann ganz lebendiger Austausch werden. Das kann dann reichen von bis zu "Ah, guck mal, da fehlt noch ein Strichpunkt",
also ganz trivial bis zu "Ah, guck mal, nee, so war das eigentlich nicht gedacht. Wir wollten die ganzen Sachen doch in dem Paket haben oder wir wollten es doch anders strukturieren." Und da kann ganz lebendiges Miteinander-Coden passieren. Der Witz ist dabei, oder der Trick ist dabei auch, dass man dann wirklich regelmäßig wechseln muss, damit wirklich jeder mit am Ball bleibt. Also super lernende Erfahrung, ne? Ja, genau.
Ja, also ich kann mir das gut vorstellen, dass da die Entwickler dann auch mehr Gefühl und Verständnis vor allem auch für die Architektur bekommen, für die Entscheidung, die das ist, wenn man das einfach auch wirklich einmal on the fly in der Gruppe ausprobiert und dann auch eben Fragen stellen kann oder auch darüber diskutiert, ne? Ja, beziehungsweise eben dann auch der Blick, wenn man leitenden und implementieren anfängt,
festzustellen, da hakt es, da verstehe ich es nicht. Ich komme da jetzt nicht hin. Woher kriege ich jetzt einen Zugriff auf gewisse Komponenten? Woher kriege ich gewisse Werte, Daten? Und das
Spannende ist, diese Fragen stellt man sich ja beim Coden alle allein. Aber wenn um einen anderen Menschen herumsitzen, zum Teil auch stellen, aber gleichzeitig vielleicht auch Antworten haben bis hin zu, ich habe dir per Copy and Paste mal einen Schlipsel Code in den Chat geschmissen, nimm das mal und man bewegt sich von dort aus weiter, dann kann das ja fruchtbar sein und durchaus auch die Entwicklung, obwohl man das ganze Team an einem Thema zusammen hat,
auch ein Stück weit beschleunigen, weil man weniger selten dann in einem nachgelagerten Review oder in einem Vier-Augen-Prinzip feststellen, nee, so ist die Architektur nicht gemeint, wenn man es überhaupt feststellt. Ich glaube, was du da ansprichst,
also oder was ihr da anspricht, ist auch noch ein ganz anderer spannender Faktor. Es gibt ja in meiner Welt, wenn ich zum Kunden komme, sehr häufig die Architekten, das sind so ein bisschen die Key-Götter, die nie Zeit haben für irgendwas und dann gerade solche Einzelreviews machen und sagen, nee, so geht das nicht, musst du anders machen. Aber da ist ja keine Lernerfahrung dabei und das Wissen bleibt bei diesen Architekten. Da gibt es dann zwei, drei davon, die sind seit 20 Jahren
im Unternehmen und bringen da eher so Dinge rein. Und mit sowas kriegt man das ja auch mal vielleicht ein bisschen gelöst, dass dieses Architekturwissen auch wirklich in die Teams reingeht und nicht nur bei einzelnen Personen dann hängt. Also wenn man solche Leute hat, die dann sich auch einlassen drauf, die Ärmel hochzukrempfen und mitzukoden, ist das wirkungsvollste, die in so einen Mob mal
eine Runde mit dazu zu nehmen. Dass sie einmal mitdenken, mit Fragen stellen, mit Impulse geben, aber auch mal mittippen und sagen, ey, pass auf, ist so nicht, aber zudem so nicht ein, so ist es gedacht, eben auch liefern. Das dann einfach zum Anfassen ist. Und andersherum selber das Feedback auch haben, boah, das ist anspruchsvoll, das ist vielleicht nicht gut zu verstehen, da muss ich vielleicht meine Kommunikation ändern. Im Extremfall könnte es so weit gehen,
oh, da passt es auf das Problem nicht, dass ich mir so High Level so zurechtgelegt habe. Wobei das an der Stelle natürlich schon relativ teuer ist, sollte ich vielleicht etwas früher feststellen. Habt ihr denn da auch Erfahrung jetzt, also es gibt ja noch Projekte, da ist es ein bisschen mehr getrennt, der Entwickler und der Tester, da gibt es ja die, wo das schon zusammenwächst, aber habt ihr jetzt gerade in so einer Phase auch bei der Umsetzung Erfahrung, wie das mit Testern
ist, was machen die dann da und wie kann das funktionieren? Also tatsächlich haben wir sogar Mob-Testing-Sessions, das ist auch ganz spannend. Also wir versuchen unsere Tester auch immer möglichst gut mitzunehmen und auch schon eigentlich im Refinement das zu hören, auf was sie vielleicht dann speziell gucken würden, weil man dann einfach schon ganz früh,
sagen wir mal, zumindest die Sachen im Bewusstsein hat, auf was es ankommt. Und bei unseren Mob-Testing-Sessions gehen wir dann so vor, dass wir uns wirklich auch als Team in, sagen wir mal, treffen, auch eigentlich in der gleichen Konstellation und überlegen uns dann, okay, auf welchen Aspekt wollen wir unsere Anwendung heute testen. Also vielleicht ist es, okay, lass uns mal alle Masken anschauen, ob das sozusagen konsistent ist, bis hin zu, jetzt versuchen wir es mal möglichst
kaputt zu machen. Und genau da versuchen wir eigentlich schon immer als Team möglichst zu agieren. Also das ist sehr vielschichtig, was man zum einen sieht schon bei den Unternehmen, die wir begleiten, an Kultur, was da ist. Zum anderen, was ich an der Stelle, je nachdem, wie das Testen gelebt wird oder auch wie, wenn es unklar ist, wie ist das gedacht? Es gibt Tester, es gibt Entwickler, wir arbeiten zusammen, die Frage in den Raum zu stellen, die Leute damit
zu konfrontieren, was wollt ihr beim Testen? Was sollte auf das Testen erreicht werden? Braucht ihr schnelles Feedback für die Entwicklung oder braucht ihr einen TÜV, weil ihr vielleicht in einem regulierten Umfeld unterwegs seid? Das sind zwei ganz, ganz unterschiedliche Paar Stiefe und häufig ist das gar nicht gut beantwortet. Und das überhaupt mal klar auf dem Tisch zu haben,
bringt einen dann weiter. Und gerade wenn es um so Mob-Sessions geht, dann sind wir wieder ganz am Anfang die Tester als diejenigen, die eigentlich die beste Quelle sind für, was sind denn die Kriterien, nach denen wir jetzt, was sind die messbaren Kriterien, nach denen die eine oder andere Lösung besser ist, die in diesen Dialog mit einzubeziehen? Also wir waren in Double Pairs und in so einer Session sind Leute, die stark auf diese Qualitätskriterien achten, auch sehr,
sehr gute Navigatoren, die mitschauen. Ja, das denke ich. Ja, das ist schön. Also ich glaube, gerade dieser integrative Ansatz, dass da auch einfach dann auch alle Bescheid wissen und sich alle einbringen können, ist dadurch natürlich schön gegeben. Jetzt gibt es so die eine Hörerin, den einen Hörer, der jetzt gerade sagt, ich will das in meinem Team auch haben. Ich bin jetzt aber nur so ein kleiner Entwickler oder eine kleine Entwicklerin. Wie kriege ich das jetzt mal
angestoßen? Also mein HR-Coach hört mir nicht zu, mein Projektleiter hört mir nicht zu. Was kann ich denn machen? Also letztendlich animiere ich immer gerne direkt mal auszuprobieren und von der Seite zu denken, was würde mir, was kann ich mir vorstellen, welches kleine Experiment kann mein Entwicklungsalltag besser machen? Und irgendeinen Wittstreiter, einen Wittstreiterin dafür zu finden, lass uns das mal auszuprobieren. Irgendwelche kleinen Dinge kann man im Alltag sehr
einfach und sofort umstellen. Vielleicht hast du aus der Perspektive der Entwicklung da auch einen guten Ansatz. Das ist ein kleiner erster Schritt, um ins Laufen zu kommen. Also ich würde auch sagen, vielleicht einen Kollegen suchen, wo man denkt,
okay, der könnte vielleicht aufgeschlossen sein, das auszuprobieren. Und dann kann man das mal im kleinen Rahmen, vielleicht auch zu zweit mal sagen, okay, oder vielleicht auch zu dritt, lass uns das doch mal im Mob ausprobieren, was wir da jetzt uns sozusagen theoretisch überlegt haben. Und dann, die meisten Teams arbeiten ja heute agil oder haben so etwas
wie eine Retro. Und das ist dann eigentlich auch mal eine ganz gute Zeit, wo man sagen kann, komm, im letzten Sprint haben wir das doch irgendwie ausprobiert und da kann man gut Feedback geben, so okay, das fanden wir gut, weil. Und dann, glaube ich, kann man das eigentlich sozusagen von unten her ganz gut anstoßen, so eine Veränderung. Der spannende andere Punkt ist
die Sprechweise. Wenn ich, und da bringe ich jetzt wieder den Blickwinkel des Agile Coaches mit ran, wenn ich in die Zusammenarbeit von Menschen da reingreife und sage, wir machen das
jetzt so oder so oder so, dann führt das meistens erstmal zu Widerständen. Und wenn aber klar erkennbar ist, lasst uns ausprobieren, das ist ein Experiment und wir arbeiten nicht bis zum kleinen Klimaleinstag so, sondern lasst uns das so ausprobieren und in 19 Minuten oder in einem Tag oder in zwei Wochen bewerten wir das nochmal, ob uns das geholfen hat und ob es Spaß macht,
ob es zu besseren Ergebnissen führt und dann rocken wir uns von dort aus vor. Also tatsächlich auch ein Ausprobieren und Experimentieren als solches zu kennzeichnen, macht meistens die Hürde sehr viel kleiner, um anzufangen, ins Team zu kommen. Ja, sehr schön. Also wenn jetzt jemand so hört, du bist nicht allein, es gibt jemanden, mit dem du das machen kannst und einmal einen kleinen Schritt machen kannst und das dann auch mit reinzubringen in die Retrospektiven, in die
Reviews, dort mal die Erfolge dann auch zu zeigen und das wachsen zu lassen. Ja, der andere Punkt ist, wenn du etwas vorlebst, also wenn sich zwei in einem Team finden, die das einfach mal machen und der andere steht daneben und sagt, hey, das ist ja doch ganz cool. Dann hat das einen ganz anderen Zug, als wenn man das rein theoretisch irgendwie erstmal durchexerziert hat. Und so wird plötzlich nicht nur die Software, die man gestaltet, gestaltbar, sondern auch die Zusammenarbeit
im Zusammenhang mit, was soll denn rauskommen. Und das ist eigentlich so eine wichtige Quintessenz dieser Experimente, auch die Zusammenarbeit als gestaltbares Gut eines Teams zu verstehen, weil unterschiedliche Anforderungen erfordern auch eine unterschiedliche Teamzusammenarbeit, um gute Lösungen zu produzieren. Und unterschiedliche Menschen sind es ja auch noch. Ja, das stimmt, das sehen wir ja alle. Also was für das eine Team funktioniert, funktioniert dem anderen vielleicht
nicht. Da funktioniert aber dafür dann was anderes. Ja, also so die Unterschiedlichkeit, auch durchaus zu leben und bewusst zu machen und auch zu nutzen. Ja, wertzuschätzen, positiv zu sehen. Also nicht, der ist doch immer der und macht doch immer, sondern wenn es in die Ecke kommt, dann nehmen wir genau den dazu. Also den Tester, der dann da quälende Fragen stellt, habt ihr da auch angeschaut? Also das Ganze sich bewusst zu machen, auch diese Eigenschaften.
Die würde ich ja gerne mal als negativ und stören, konnotieren und überlegen, wo sind Stärken, in welchem Kontext. Da hilft das Ausprobieren in der Zusammenarbeit, die überhaupt kennenzulernen. Weil gerade so in dieser Corona Remote Personenvereinzelungssituation ist das schnell mal ziemlich weit ausgeklammert. Ja, klar. Sehr schön. Ich danke euch herzlich für diesen Einblick, für diese drei Ansätze, da mal zu experimentieren, das mal auszuprobieren. Melanie,
Max, vielen Dank, dass ihr da wart und ich wünsche euch noch eine tolle Konferenz. Viel Spaß hier und bis zum nächsten Mal. Vielen Dank für das schöne Gespräch. Danke für die Einladung. Gerne. Ciao. Ciao. Ciao.