Der ideale war room in der agilen Software Entwicklung

Als Die andere Seite der Realität habe ich in der Zeit, als es im August sehr selten geregnet hat und ich nicht mit allerlei Menschen darüber diskutieren musste, dass es geregnet hat, den Zustand beschrieben, der es uns ermöglicht, in eine warme Sommernacht zu blicken und es als gegeben hinzunehmen, dass die Sterne im Nachthimmel das Produkt eines seltsamen Riesen sind, der am Stock geht und der mit diesem Stock Schritt für Schritt kleine Löcher in die Schädeldecke dessen bohrt (ohne es wohl zu ahnen), was wir Himmel nennen. Unseren Himmel. Es beschreibt den Zustand, in dem es belanglos ist, ob es so einen Riesen geben könnte. Bei aller Liebe zum Detail ist doch letztlich die Unverfrorenheit dieses Subjekts wichtig, das mit einem Gehstock Fakten schafft, die meinen Kosmos berühren. Ob ich es wollte oder nicht.

Ich mag es mit einem agilen Environment vergleichen, in dem alles von der Lehre vorgegeben ist, uns bei der Arbeit aber auch wieder nicht weiter bringt, weil wir Teilaspekte nur deswegen ertragen können, in dem wir so tun, als gäbe es keine Sterne.

Meine subjektive Beobachtung schreit seit einigen Jahren, dass mit einer immernenten Faktenfixierung durch die Webangebote im Internet eine Inversion der Fragekultur stattfindet: Wer Fragen hat kann mit Google nicht richtig umgehen. Und wer Fragen auf Antworten stellt, kann mit Wikipedia nicht arbeiten. Das ist aber vielleicht nur mein Eindruck. Ich habe in diesem Jahr mit zahllose Menschen im ICE zwischen München und Würzburg über dieses Thema geredet und war überrascht, dass doch so viele genau auf diesen Punkt hingewiesen haben.

Wie komme ich eigentlich drauf? Einfach: Fragekultur ist ein integraler Bestandteil von Zusammenarbeit. Und wenn wir uns nun ein beliebiges agiles Environment ansehen, ist leicht nachvollziehbar, wie wichtig richtiges Fragen einerseits und Fragelernkultur andererseits ist.

Der Ort des Dreh- und Angelpunkts in agilen Environments ist der war room, den man manchmal besser hätte Projektraum nennen dürfen. Nicht der meeting room, die box oder wie es in einem unserer Standorte üblich ist, in dem Kollegen im Serverraum übernachten, bis sie ihren Sprint feature ready haben: dark room.

Der war room ist der Raum, an dem die Sau geschlachtet und die Wurst gemacht wird. Die Teamarbeit statt findet. In dem sowohl kreativ gearbeitet wird als auch Finger abgeschnitten werden müssen, wenn Kommits nach einem kritischen Build kommen. Manchmal wird es eben blutig.

Wie sind die Randbedingungen an einen war room?

1. Es kann laut werden, sollte also aus Rücksicht zu Wasserfall-Teams am Ende vom Gang liegen.
2. Es kann heiß hergehen. Elektrische Kühlung vermindert hier unnötigen Abrieb.
3. Es kann blutig zugehen. Der Raum sollte gekachelt sein, sodass bei kurzfristig angesetzten Projekt-Audits keine unschönen Flecken bleiben.
4. Es kann sehr osmotisch zugehen. Ein gewisses Maß an Echo ist besonders bei einem jungen Team highly recomended.
5. Es kann zu einer sexuell aufgeladenen Arbeitsatmosphäre kommen. Da sexuelle Spannungen schnell abgebaut werden müssen, ist es erprobte Praxis, wenn man unter die Tische kriechen kann oder im Ernstfall viel Beinfreiheit hat.
6. Es wird eine immense Menge an Drogen und frei verkäuflichen Schmerzmitteln benötigt. Diese müssen geeignet gelagert werden.
7. Es kann auf Grund gewerkschaftlich organisiertem Reinigungspersonal und gelegentlicher Gliedmaß-Amputationen von Nöten sein, Blutabfluss-Rinnen zu installieren.
8. Es kann von Bedeutung sein, dass die Tische mit den Workstations stabil sind. Kriege kann man nur mit optimalem Material ohne Ausreden gut führen.
9. Es kann schnell nach Fisch riechen. Das darf nicht passieren. Der Raum muss binnen kürzester Zeit desinfiziert werden können.

Sollte ich jemals wieder auf ein Team losgelassen werden, so müsste der von mir vorgeschlagene war room etwa so aussehen:




In diesem Sinne: Gib dem Kaninchen eine Möhre extra, es hat uns das Leben gerettet!

Weitermachen.