Wenn man die Ideen von Lean, Agile, XP etc. ernst nimmt, müsste man alles daran setzen, seine Aufgaben zu priorisieren und die wichtigste Aufgabe möglichst zügig und gut zum Kunden auszuliefern. Leider sieht die Realität oft anders aus: Die individuelle Auslastung wird maximiert, die Entwickler arbeiten an vielen Aufgaben gleichzeitig. Die Features landen halbgar beim Kunden, die dann kein Feedback zu fachlichen Experimenten liefern, sondern durch simple Fehler frustriert sind. Für fachliche Weiterentwicklung ist kaum Zeit, weil die Entwickler ständig in Feuerwehreinsätzen Bugs fixen. Als Lösung dieses Problems setzen wir auf Team-Building, arbeiten an der Kommunikation, machen Pair Programming, suchen Collective Code Ownership. In Zeiten von zunehmend komplexen oder chaotischen Problemen ist das vielleicht nicht mehr genug… Besonders wenn die Teams nicht nur das Ergebnis gemeinsam verstehen müssen, sondern auch den Weg der Problemlösung – warum ein bestimmter Weg eingeschlagen wurde, warum bestimmter Code *nicht* da ist. Vor einigen Jahren kam die Idee auf, Softwareentwicklung wirklich durch das gesamte Team durchführen zu lassen – und zwar zusammen, Aufgabe für Aufgabe. "Mob Programming" war geboren. Die Blockaden während der Entwicklung verschwinden, weil sich alle nötigen technischen und fachlichen Ansprechpartner im selben Raum befinden. Klingt verrückt? Funktioniert aber! In diesem Talk werde ich die Grundlagen von Mob Programming vorstellen, die Gemeinsamkeiten und Unterschiede zum Pair Programming und wann sich das Arbeiten als "Mob" lohnt. Dazu gibt es Tipps aus der Praxis.