Synchronisierter Ameisenhaufen

Gestern hatte ich in Hamburg mit Cem und Sven ein spannendes Gespräch über das StartupWeekend und dessen Organisation. Unter anderem haben wir die Frage diskutiert, wie bei dieser Großveranstaltung Prozesse, die für gewöhnlich nacheinander stattfinden und teilweise aufeinander aufbauen, parallel bearbeitet werden können.

Juristen, Designer, Coder usw. werden in jeweils eigenen Kompetenzgruppen zusammenarbeiten, alle an ihren Baustellen, aber am selben Projekt mit dem gleichen großen Ziel: Sonntagabend gibt es nicht nur eine Firma, sondern auch ein Produkt. Aber natürlich reicht es nicht, wenn nach einem kurzen Briefing alle auseinanderströmen und alleine ihr Ding machen. Andererseits sollen sich nicht alle fortwährend in die Parade fahren.

Ich habe – unbelastet von jeglicher Sachkenntnis – den Vorschlag gemacht, „Agile Businessentwicklung“ zu betreiben. Das stelle ich mir so vor:

Sobald die Businessidee feststeht werden für jede Gruppe Ziele definiert und weiter untergliedert. Jede Gruppe priorisiert die Ziele und definiert die Voraussetzungen zur Verwirklichung, die von anderen Gruppen zunächst erfüllt sein müssen. Das Wochenende wird in kurze „Sprints“ unterteilt, die in meiner Vorstellung zwei Stunden dauern. Am Ende jedes Sprints treffen sich, während die anderen Gruppenmitglieder weiterarbeiten, Vertreter der Teams, um den Fortgang, neue Ergebnisse und Voraussetzungen zu besprechen – und natürlich die neuen Ziele abzugleichen. Das sollten m.E. NICHT die Teamleiter sein. Die haben anderes zu tun.

Eine Art „Sprint-Koordinator“ müsste sich um die Synchronisation und Koordination der Sprints kümmern, Aufgaben priorisieren, die Treffen leiten und die Gruppen ins Bild setzen. Hört sich noch kompliziert an, wird aber noch Struktur gewinnen.

Ich werde mich in den nächsten vier Wochen mit der Organisation auseinandersetzen und versuchen, Wege zu finden, wie man die Arbeit von 100-200 sehr unterschiedlichen und einander unbekannten Leuten synchronisiert. Ein paar Ideen dazu werde ich aus der Softwareentwicklung entlehnen, andere aus der Kommunikationswissenschaft. Konstruktive Kritik und Vorschläge sind sehr willkommen.