In der IT müssen die meisten Softwareentwicklerinnen, -architekten und andere Rollen aus verschiedenen Gründen in Teams arbeiten. Wer überzeugt ist, dass das nicht immer einfach ist, und zudem denkt, über Teamwork sei schon alles gesagt worden, der sollte die neue Episode nicht verpassen: denn Aino Vonge Corry und Lisa Maria Schäfer werden gemeinsam nochmals die wichtigsten Aspekte beleuchten – von Team Topologies über psychologische Sicherheit, Persönlichkeitstypen, Körpersprache, Remote-Arbeit in Teams bis hin zur ganz allgemeinen Kommunikation. Aino Vonge Corry und Lisa Maria Schäfer diskutieren all diese Themen und freuen sich auf Eure Fragen.

Aino Vonge Corry wird außerdem Ende November einen Vortrag beim Software Architecture Gathering halten, mit dem Titel „Was wir aus ‚Der Herr der Ringe‘ gelernt haben (sollten)“.

Da Lisa Maria Schäfer vor der Kamera ist, wird sie dieses Mal keine Sketchnotes malen.

Livestream am 6. November

Die Ausstrahlung findet am Donnerstag, 6. November 2025, live von 13 bis 14 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat, Bluesky, Mastodon, Slack-Workspace oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zur Folge finden sich auf der Videocast-Seite.

(map)

Ein Daily, auch Stand-up oder Daily Scrum genannt, ist kein Status-Meeting. Es dient einerseits dazu, den Fortschritt in Richtung Sprint-Ziel zu hinterfragen. Das bedeutet schon mal, dass es ohne Sprint-Ziel kein Daily benötigt, oder? Der andere Zweck des Dailys besteht im Planen des bevorstehenden Arbeitstags. Wer macht was, um das Team dem Ziel näherzubringen? Aufgrund dieses Zwecks habe ich das Daily lange Zeit am frühen Vormittag verortet.

Nach und nach hat sich mein Blick verändert, und das hat vor allem damit zu tun, dass in meinen Beratungsaufträgen ein Phänomen häufiger vorkommt: In den vergangenen Jahren treten immer mehr Entwickler an mich heran, um nach persönlichem Rat zu fragen. Es geht also nicht um Teamprobleme oder Fragen der gesamten Organisation, sondern um individuelle Herausforderungen, denen die einzelnen Personen gegenüberstehen. Dazu gehören Projektdruck, fehlende Wertschätzung und daraus resultierendes mangelndes Wohlbefinden.

Die häufigsten Fragen, die Antworten und die Tipps, die meine Kollegen und ich geben, haben wir unter dem Titel „Develop Happiness in 30 Weeks“ zusammengetragen; die Nutzung ist kostenlos. Und ein Tipp in dieser Sammlung betrifft meinen Umgang mit dem Daily.

Abschalten nach der Arbeit

Es geht darum, dass es bei hohem Projektdruck nicht leicht ist, nach der Arbeit abzuschalten. Viele Menschen nehmen die unerledigten Gedanken mit nach Hause und dort führen sie zum Grübeln und Nachdenken; ausgerechnet in einer Zeit, die sogar per Gesetz eine „ununterbrochene Ruhezeit von mindestens elf Stunden“ umfassen sollte.

Um diese Last zu vermeiden, empfehlen wir den Menschen, mit denen wir arbeiten, folgendes Vorgehen: Die letzten 15 Minuten der täglichen Arbeitszeit sollte jede Person der persönlichen Planung des nächsten Tages widmen. Von den üblichen 8 Stunden Arbeitszeit dürfen maximal 6 verplant werden. Der Plan soll aus einer kurzen Liste von To-dos bestehen. Wenn jede Aufgabe geschätzte 60 Minuten erfordert, wäre das also eine Liste von sechs Punkten; natürlich sind 6 Punkte à 60 Minuten ein Default.

Für manche Tätigkeiten passt vielleicht besser ein Punkt mit 360 Minuten. Die Zahl der To-dos darf und soll sich an die eigene Situation anpassen. Mehr als sechs Stunden dürfen es aber nicht werden. Die restlichen zwei Stunden sind für Unerwartetes reserviert. Doch damit nicht genug: Wenn die sechs Punkte abgearbeitet sind, muss man die Arbeit für den Tag beenden; vorausgesetzt der Arbeitgeber spielt mit, versteht sich. Stellt man im Laufe der Zeit fest, dass sechs Punkte und sechs Stunden nicht aufgehen, ändert man die Planung entsprechend. Wer regelmäßig nach vier Stunden fertig ist, fängt langsam an, mehr einzuplanen. Gleiches gilt für den Puffer von zwei Stunden für unerwartete Dinge.

Die Methode wirkt aus zwei Gründen:

Man bekommt an einem Arbeitstag endlich mal „alles“ fertig; nicht alles, was im Backlog steht, aber alles, was der Tagesplan enthält. Gerade für Menschen, die eine „Ever-Growing To-Do List“ haben und sich damit belasten, was sie alles nicht geschafft haben, ist das sehr wertvoll. Es funktioniert aber nur, wenn man die Arbeit wirklich beendet, sobald die geplanten Dinge erledigt sind.

Sauberer Abschluss

Die Planung am Ende des Arbeitstags sorgt nicht nur für einen Abschluss. Sie vermittelt darüber hinaus das Gefühl, dass man sich auch um die nicht erledigten Dinge gekümmert hat. Diese Dinge sind zwar nicht „done“, aber man hat sie in geeigneter Weise behandelt.

Und wie passt das mit dem morgendlichen Daily zusammen?

Je mehr Leute im Team gegen Ende eines Arbeitstags mit der 6-Punkte-Planung den nächsten Tag planen, umso mehr bietet es sich an, das Team-Daily damit zu verbinden und es zum Beispiel auf den Nachmittag zu legen. Neben dem mentalen Vorteil für jedes einzelne Teammitglied kommt hinzu, dass man am nächsten Morgen ohne Regelmeeting in einen bereits geplanten Arbeitstag starten kann. Hier kann jeder die Startzeit nach seinem persönlichen Rhythmus wählen, falls nicht ein anderes Meeting die freigewordene Daily-Lücke füllt. Zusammengefasst bin ich immer mehr geneigt, meine ehemalige Best Practice „Daily am Morgen“ aufzugeben.

Was denkt Ihr darüber? Schreibt doch mal in die Kommentare, ob und gegebenenfalls zu welcher Uhrzeit Euer Team ein Daily durchführt.

Erst Lesen, dann Handeln

Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm‘ in unsere Leadership-Community für Softwareentwickler. Sie wirkt auch ohne Führungsposition. Mit dem Code „heisedev“ gibt’s den Heise-Rabatt für Interactive Members.

(rme)

Kong hat Version 12 seines Open-Source-Werkzeugs Insomnia freigegeben, ein Open-Source-Tool für die Entwicklung, das Testen und die Dokumentation von APIs. Das Update erweitert die Software um native Unterstützung für das Model Context Protocol (MCP) sowie um zwei experimentelle KI-Funktionen. Außerdem vereinfacht Kong den Zugang zu Kollaborationsfunktionen wie Git-Sync.

Ziel des Releases ist laut Ankündigungsbeitrag, API- und MCP-Entwicklung stärker zu vereinheitlichen und Routineaufgaben bei Tests und Dokumentation zu automatisieren.

MCP-Client für das Testen von Agentenschnittstellen

Das neue MCP-Feature ermöglicht es, sogenannte MCP-Server direkt aus Insomnia heraus zu testen. Diese Server stellen Werkzeuge und Prompts für KI-Agenten bereit. Über die gewohnte Oberfläche lassen sich Aufrufe ausführen, Parameter verändern und Nachrichten auf Protokollebene nachvollziehen.

Der MCP-Client soll dieselbe Art von Test- und Debugging-Workflows ermöglichen, die Insomnia bereits für klassische APIs bietet.

Automatische Mock-Server per KI

Ebenfalls neu ist die Möglichkeit, Mock-Server automatisch zu erzeugen. Nutzerinnen und Nutzer können in natürlicher Sprache beschreiben, wie die API funktionieren soll, oder eine URL, JSON-Datei oder OpenAPI-Spezifikation angeben. Auf dieser Basis erstellt Insomnia ein funktionsfähiges Mock-Setup. Der Blogbeitrag bietet hierfür anschauliche Demo-Videos.

Das Feature richtet sich an Teams, die APIs noch in der Entwurfsphase testen möchten oder keinen Zugriff auf produktive Systeme haben. Laut Kong sollen sich so einfache Simulationen in Sekunden anlegen lassen, ohne separate Skripte oder manuelle Konfiguration.

KI-Unterstützung bei Commits

Insomnia 12 schlägt außerdem Commit-Nachrichten automatisch vor. Die Software analysiert Änderungen im Repository und generiert passende Beschreibungen, die angepasst oder verworfen werden können. Ziel ist es, die Nachvollziehbarkeit von Änderungen zu verbessern, ohne zusätzliche Schreibarbeit.

Wie bei den Mock-Funktionen können Nutzer entscheiden, ob die KI-Funktion aktiviert wird und ob dafür ein externer Cloud-Anbieter oder ein lokales Sprachmodell zum Einsatz kommen soll. Kong weist darauf hin, dass KI-generierte Ergebnisse überprüft werden sollten.

Anpassungen bei Kollaborationsfunktionen

Beim Kollaborationsmodell ergänzt Kong vor allem den kostenlosen Essentials-Tarif: Git-Sync ist darin jetzt für drei Nutzende enthalten. Wer erweiterte Funktionen wie SSO, SCIM oder rollenbasierte Zugriffskontrolle testen will, kann eine 14-tägige Enterprise-Testphase starten und bis zu 50 Plätze selbst verwalten.

Mit diesen Anpassungen will Kong die Nutzung von Insomnia in kleinen Teams erleichtern, ohne dass sofort ein kostenpflichtiges Abo nötig wird.

(mdo)