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)

KI-Assistenten ändern das Berufsbild von Entwicklerinnen und Entwicklern, reines Coden wird unwichtiger, während konzeptionelle Kompetenzen an Bedeutung gewinnen. Das hat Auswirkungen sowohl auf die Arbeit des einzelnen Coders als auch auf das Team und den agilen Prozess. heise developer spricht mit Facundo Giuliani, Teamleiter für den Bereich Solutions Engineering bei Storyblok, über die Zukunft von Developer-Teams im KI-Zeitalter.

Wie wirkt sich der vermehrte Einsatz von Coding-Assistenten auf die Struktur von Entwicklungsteams aus?

Entwicklungsteams bewegen sich zunehmend hin zu hybriden Kompetenzprofilen, bei denen das reine Programmieren nur noch ein Teil des Mehrwerts ist. Konzeptuelles Denken, die Einordnung von Problemen und Integrations-Know-how werden ebenso entscheidend sein wie das Schreiben von Code. Dadurch entstehen häufiger crossfunktionale Teams, in denen Entwicklerinnen, Designer und Product Owner immer früher und enger zusammenarbeiten. Unternehmen werden ihre Teams zunehmend um Problemfelder und angestrebte Ergebnisse herum organisieren und weniger um die reine Code-Delivery.

Was bedeutet das in der Praxis?

Teams werden rund um konkrete Kunden- oder Geschäftsherausforderungen aufgebaut. Etwa zur Optimierung der Onboarding-Conversion oder der Verkürzung der Content-Veröffentlichungszeit, statt für eine bestimmte Codebasis verantwortlich zu sein. Entwicklerinnen, Designer, Analystinnen und KI-Spezialisten arbeiten von Beginn an gemeinsam, definieren das Problem, testen Hypothesen und iterieren schnell. Der Erfolg wird dabei nicht mehr an Story Points oder Code Commits gemessen, sondern an echten Wirkungskriterien wie Nutzungsraten, Performance-Steigerungen oder reduzierter manueller Arbeit.

Es gibt ja Vermutungen, dass KI die Jobchancen von jungen Entwicklern verschlechtert. Wird sich künftig die Altersstruktur in Teams ändern?

Einstiegsrollen werden durch KI nicht wegfallen, aber die Bedeutung von Einstiegsjobs wird sich verschieben: Neueinsteigerinnen und -einsteiger werden sich künftig eher KI-gestützt mit komplexeren Aufgaben beschäftigen, anstatt primär Code auszuführen oder generieren zu lassen. Dadurch kann der Einstieg in den Tech-Bereich sogar zugänglicher werden, weil die Hürde zum Experimentieren sinkt und so vielfältigere Einstiegsmöglichkeiten erlaubt. Innerhalb der Teams wird es voraussichtlich eine ausgewogene Mischung aus erfahrenen Fachkräften geben, die die strategische Richtung vorgeben, und jüngeren Talenten, die mithilfe von KI schneller lernen und Ergebnisse erzielen können.

Damit verbessern sich ja auch die Chancen für Quereinsteiger?

Absolut! KI-Assistenten und Low-Code-Tools senken die technische Einstiegshürde und ermöglichen es damit Menschen mit Design-, Content- oder Data-Backgrounds, sich sinnvoll an Softwareprojekten zu beteiligen. Der Fokus auf Problemlösung, Kreativität und Kommunikation eröffnet Quereinsteigerinnen und Quereinsteigern neue Wege, Mehrwert zu schaffen, auch ohne von Beginn an tiefgehende Programmierkenntnisse mitzubringen.

Wie werden Teams in der KI-Zukunft arbeiten?

Teams übernehmen zunehmend die Orchestrierung von Systemen, statt selbst Zeile für Zeile zu coden. Sie kuratieren und validieren KI-generierte Komponenten. Der Arbeitsalltag wird menschliches Urteilsvermögen mit automatisierten Tests, Sicherheitsscans und von KI-Assistenten gespeisten Continuous-Delivery-Pipelines verbinden. Entwicklerinnen und Entwickler werden sich stärker auf Architekturentscheidungen, Qualitätssicherung und plattformübergreifende Integrationen konzentrieren, um zuverlässige Ergebnisse aus maschinell erzeugtem Code sicherzustellen.

Werden auch neue Rollen in Entwicklungsteams entstehen?

Wir sehen bereits neue hybride Rollen entstehen, die innerhalb von Produkt- und Plattform-Teams angesiedelt sind – beispielsweise die Rolle des Prompt Engineers oder System Orchestrators. Diese Positionen verbinden menschliche Intention mit maschineller Ausführung und gestalten, wie verschiedene Agenten, APIs und Content-Systeme miteinander interagieren.

Hat der verbreitete Einsatz von KI-Assistenten auch Auswirkungen auf den agilen Prozess?

KI-Assistenten verkürzen den Iterationszyklus und beschleunigen damit Planung, Backlog-Pflege und Prototyping deutlich. Stand-ups und Retrospektiven werden sich künftig weniger auf den Status einzelner Tasks konzentrieren und mehr darauf, Annahmen zu überprüfen und KI-Ergebnisse zu steuern. Agile Prozesse werden sich weiterentwickeln, um dabei Experimentieren, Metriken und kontinuierliche Validierung in den Vordergrund zu rücken, anstatt nur den Durchsatz von Sprints.

Welche Überlegungen sollten Teams jetzt anstellen, um zukunftsfähig zu bleiben?

Teams sollten verstärkt in Kompetenzentwicklung rund um Architektur, Integration und Orchestrierung investieren, da diese die Grundlage für langfristigen Erfolg bilden. Das Aufstellen und Testen von Standards sowie eine robuste Observability sind entscheidend, um KI sicher und in großem Maßstab einzubinden. Am wichtigsten ist jedoch, dass Teams eine Kultur der Flexibilität fördern, in der Entwicklerinnen und Entwickler ermutigt werden, neue Tools zu lernen, disziplinübergreifend zusammenzuarbeiten und KI eher als Partner statt als Ersatz zu begreifen.

(who)