BED-Con 2019: Remote Arbeiten in agilen Teams
Nachdem wir bereits im letzten Jahr viele positive Impulse auf der BED-Con einsammeln konnten, waren wir auch 2019 wieder mit an Bord – diesmal erstmals auch als offizieller Sponsor der zweitägigen Konferenz.
Die Berlin Expert Days umfassen eine breite Themenpalette: von der Software Entwicklung über Software Craftmanship, Erfahrungsaustausch mit unterschiedlichen Technologien und Technologiestacks als auch agiles Arbeiten im IT-Umfeld. Technologisch liegt der Fokus auf Java und javabasierten Technologien wie Kotlin.
Herausforderungen und Chancen von Remote-Kommunikation
Ein interessantes Thema war dieses Mal die Zusammenarbeit in Zeiten von Homeoffice und Remote-Kommunikation. Die Möglichkeit, von zuhause oder unterwegs zu arbeiten, hat eine Reihe an Vor- und Nachteilen, mit denen sich gerade viele aktiv zu beschäftigen scheinen. Auf der Konferenz war das Thema unter anderem auch Gegenstand des Panels am ersten Abend und wurde zudem in einigen Vorträgen behandelt.
Besonders spannend fand ich dabei den Talk "Remote Mob Programming: Team-Work im Home-Office" von Jochen Christ, Senior Consultant bei innoQ. Inhaltlich war es vor allem eine kurze Einführung in Remote Mob Programming ergänzt durch die Herausforderungen, die das Remote Arbeiten an sich ebenso mit sich bringt.
Wenn der Gesprächspartner physisch nicht anwesend ist, stehen einem viele Informationen nicht zur Verfügung, welche in der Face-to-Face-Kommunikation (zum Teil unbewusst) wahrgenommen und verarbeitet werden. Diese Reize helfen uns bisweilen die gegenwärtige Situation besser einzuschätzen, da wir auch die Stimmung und den emotionalen Zustand unseres Gegenübers besser evaluieren und damit berücksichtigen können. Unser Gehirn füllt diese Informationslücken bisweilen unbewusst mit Annahmen, was letztlich zu Missverständnissen führen und empathische Reaktionen unsererseits erschweren kann.
Kompensiert werden kann das mit mehr Kommunikation und indem eine Kommunikation etabliert wird, in welcher möglichst viele Informationen übertragen werden, beispielsweise indem permanent die Kamera angeschaltet ist.
Es war durchaus interessant, einmal ausführlich die Sichtweise von anderen Unternehmen mitzubekommen und von deren Learning zu profitieren. Auch bei ETECTURE setzen wir schon lange Zeit auf Remote Kommunikation und auf standortübergreifende Zusammenarbeit. Wichtig ist hierbei vor allem das gegenseitige Verständnis und die Berücksichtigung von Remote-Teilnehmern etwa in größeren Meetings sowie der Einsatz von richtigen Arbeitstechniken, wie beispielsweise in unserem Fall Remote SCRUM.
3-Personen-Regel für Technologieentscheidungen
Ein weiterer interessanter Vortrag kam von Konstantin Diener, CTO bei cosee, welcher sich mit "Technologieentscheidungen in selbstorganisierten Teams" befasste. In seinem kurzweiligen Praxiseinblick thematisierte er das Mysterium des "einsamen Wolfs", welcher Technologieentscheidungen im Team alleine trifft und (nachvollziehbarerweise) dazu neigt Technologien, die er bereits kennt, in Projekte zu integrieren. Frei nach dem "Bring your own Pet Technology-Prinzip“. Häufig ist das einer der erfahreneren Kollegen in einem Projekt. In manchen Fällen werden Technologieentscheidungen aber auch auf Managementebene, zum Beispiel durch CTOs, vorgegeben. Der Nachteil: Der CTO hat gegenüber dem Team ein viel größeren Abstand zum Produkt und im Zweifelsfall, muss er sich auch nicht mit den Nachteilen falscher Entscheidungen herumärgern. Das Team wiederum wird nur bereit sein, Verantwortung für seine eigenen Entscheidungen zu übernehmen.
Neue oder junge Entwickler neigen hingegen gerne dazu Innovationen durch neue Technologien einführen zu wollen. Aber auch die Herangehensweise, nur unbekannte oder neue Technologien einzusetzen, birgt große Risiken aufgrund zu vieler Unbekannten.
Konstantin Diener schlägt daher für die Technologienentscheidungen in agilen Teams die 3-Personen-Regel vor. Diese besagt, dass sich mindestens drei Personen zur Technologie bekennen, die erstens in der Lage und zweitens willens sind, Probleme in Produktion damit zu lösen. Es entscheidet, wer nachts aufsteht, wenn was kaputt geht.
Autonomie und Selbstorganisation in agilen Teams
Gerne wird auch das Argument von vermeintlichen projektübergreifenden Synergien ins Feld geführt, wenn Entwickler die Teams wechseln, um immer gleiche Technologien oder ganze Technologiestacks anzugleichen. Allerdings sind diese Synergien eher fiktiv. Wer neu ins Team kommt kennt den Code nicht, nur weil er dieselben Frameworks einsetzt. Er muss sich also einarbeiten, um zu verstehen, wie alles in diesem konkreten Projekt zusammenspielt. Dafür wird aber in Kauf genommen, die Autonomie und Selbstorganisation des Teams zu beschneiden. Die Kernelemente der agilen Arbeitsweise. Es sorgt dafür, dass Teams tatsächlich Verantwortung für das übernehmen was sie tun und nicht das "not invented here"-Syndrom einkehrt, bei dem Verantwortung für Probleme innerhalb des Teams oder der Organisation hin und her gereicht wird.
Meines Erachtens lassen sich die Schlüsse nahtlos auf Architekturentscheidungen übertragen. Im Zweifel gehört auch Fehler machen zur empirischen Vorgehensweise. Wichtig ist, schnell auf Fehler zu reagieren und zu reflektieren, um gegensteuern zu können. Im Gesamten erhält man so einen reichen Erfahrungsschatz über Technologien, Methoden und den gemeinsamen Weg Entscheidungen zu treffen ohne agile Werte zu untergraben.
Alles in allem war die BED-Con wieder mit interessanten Themen gespickt. Wir freuen uns bereits jetzt gemeinsam auf die zehnte Ausgabe 2020. Ein Dank an dieser Stelle nochmal an das gesamte Orga-Team der Berlin Expert Days e.V.: Ihr macht einen Klasse Job!
