Von Fackeln und Forken – wie der Mob remote zusammenkommt

Die aktuelle Situation verlangt von uns, im Home-Office zu arbeiten. Dadurch fehlt vielen Teams der direkte persönliche Kontakt; im Alltag kommt es bei uns zum Beispiel sehr häufig vor, dass ein Teammitglied in den Raum hinein ruft, wie ein Problem zu lösen wäre. Schon alleine das verbale Auseinandersetzen mit dem Problem führt häufig zur Lösung.

Damit wir nicht bald alle nur noch mit unseren Gummienten reden, möchte ich hier eine mögliche Lösung aufzeigen. Denn es gilt: Entwicklerteams können auch remote hervorragend zusammenarbeiten.

Weiterlesen

Retrospektive Schulden

In meinem Lieblings-Slack zu agilen Themen, dem Slack-Kanal von Mein Scrum ist kaputt, wurde wieder einmal eine spannende Frage gestellt:

Wie wirkt sich die Frequenz einer Retrospektive auf die Dynamik und die Inhalte aus? Ich habe das Gefühl, dass bei Retrospektiven, die man eher unregelmäßig macht, man einen großen Raum geben muss, um sich „auskotzen“ zu können. Ich fänd es spannend, wenn wir da ihr hierüber von euren Erfahrungen berichtet

• Wie ist dieser Zusammenhang
• Wie entwickelt sich auch eine Retro innerhalb eines Teams im Zeitverlauf

Oft ist das Problem ja nicht die richtige Antwort, sondern die richtige Frage. Und ich glaube, dass hier ist genau so eine „richtige Frage“.

Weiterlesen

Architectural Decision Records

Architecture is abstract until operationalized, when it becomes a living thing.

Patrick Kua

Das agile Manifest für Software-Entwicklung hat die Dokumentation nicht ohne Grund auf die rechte Seite gestellt: „Working software over comprehensive documentation.“

Eine leichtgewichtige und daher schnelle Dokumentation ermöglicht die agile Praxis der Architectural Decisions Records.

Weiterlesen

Die 10 Commandments of Egoless Leadership

In der Softwareentwicklung gibt es die 10 Commandments of egoless programming aus The Psychology of Computer Programming schon lange. 

Das Grundmotiv dieser Gebote ist die Akzeptanz der eigenen Schwächen und Fehler. Bei der Erstellung von Software spielen sie eine so große Rolle, dass wir das ganze mit Test-driven Development sogar zur Arbeitsweise erhoben haben:

Wir beginnen mit dem Test, der mangels Code einen Fehler anzeigt; unser eigentlicher Auftrag ist nur die Reparatur des Fehlers. Unser Normalnull ist also der Fehlerzustand.

Weiterlesen