Auftakt
Wie das so ist in Projekten: Man trifft auf Dinge, oder man tut sie gleich selber. Einige davon funktionieren super, einige nicht so gut, und einige sind wirklich, wirklich problematisch. Und das alles mit bestechender Zuverlässigkeit.
Wir sammeln Beobachtungen und Erfahrungen, die wir über die Jahre gemacht haben, hier als Gedächtnisstütze, ohne Anspruch auf einen roten Faden, Umfang und Komplettheit. Wenn sich etwas davon ergibt, ist das natürlich umso besser. Und wenn diese Notizen für jemanden hilfreich sind, dann ist das super.
Das einzige, woran wir uns halten, ist das Format: The Good, The Bad, The Ugly. Positivismus alleine hilft nicht: Es ist auch immer wichtig, dass wir wissen, was wir nicht tun sollten, und wieso nicht.
The Good
Direkte und unbürokratische Kommunikationswege
Klingt selbstverständlich, wird aber gerne unterschätzt: Wenn Leute, die miteinander arbeiten, im gleichen Gebäude, oder - noch besser - auf dem gleichen Stockwerk sitzen, und sich ohne Dienstweg spontan austauschen können, hilft das enorm.
Gute Dienstleistungen, gute Software, gute Produkte bestehen aus hunderten gut gemachten Details. Diese Details müssen wir aufeinander abstimmen, und das geht nur, indem wir uns miteinander austauschen, so unkompliziert wie möglich.
Das heisst nicht, dass wir dabei auf strukturierte Zusammenarbeit verzichten. Spontane und strukturierte Zusammenarbeit müssen nebeneinander möglich sein. Und es bedeutet auch nicht, dass wir immer vor Ort sein müssen: Solange man eine gute Mischung aus strukturierter und spontaner Kommunikation hinbekommt, funktioniert es auch remote. Insbesondere auch, weil die Remote-Arbeit für Ruhe und Fokus sorgen kann.
Kleine, kompetente Teams, oder: Small Groups of Smart People
Teams, mit denen wir gearbeitet haben, waren in der Regel klein (ca. 5 Leute) oder mittelgross (ca. 20 Leute), aber bisher glücklicherweise nicht grösser (SAFe, anyone?). Unsere Wahrnehmung: Kleine, kompetente Teams mit klaren Verantwortlichkeiten bringen die besten Lösungen am schnellsten auf die Beine.
Woran das liegt? Wir können nur Vermutungen anstellen: Jeder weiss, wer woran ist; Alle kennen alle; Wenig Overhead. Es scheint aber durchaus auch eine empirische Basis dafür zu geben, dass kleine Teams bessere Arbeit leisten. Auch Steve Jobs hatte gemäss einer seiner Biografien den Grundsatz Small Groups of Smart People, womit er wohl nicht falsch lag.
The Bad
Zu viele Köche versalzen tatsächlich den Brei
Auch wenn kleine Teams gut sind: Manchmal braucht es ein grosses Team, einfach weil die Aufgabe gross ist. Erfahrungsgemäss kann auch ein grösseres Team funktionieren - aber nur, wenn die Verantwortlichkeiten klar verteilt sind. Bei genauem Hinsehen erkennt man denn auch, dass das Sprichwort "zu viele Köche" als Problem nennt, also zu viele Leute in derselben Rolle.
Ein Beispiel: Wenn man zu viele UXler im gleichen Projekt hat, und nicht festlegt, wer wofür zuständig ist, ergeben sich schnell auseinanderlaufende Konzepte, Doppelspurigkeiten, konzeptionelle Löcher und wesentlich mehr Aufwand als eigentlich notwendig.
The Ugly
Komplett auf Dokumentation verzichten
Eines vorweg: Dokumentation ist im Projektumfeld mit Vorsicht zu geniessen. Das gilt ganz besonders für lange Prosa-Texte, die als Spezifikation einer Nutzerschnittstelle herhalten sollten. Das funktioniert in der Regel nicht.
Trotzdem ist es erfahrungsgemäss sehr riskant, wenn man nicht zumindest ein Minimum an Zielen, Herleitungen und Entscheidungen schriftlich festhält. Idealerweise tut man dies gemeinsam und mit dem Ziel, dass das Dokument/Ticket/User Story eine Gedächtnisstütze für das gemeinsame Verständnis bildet - und nicht als "ich schreib's, schmeiss es zu dir rüber, und du musst es lesen und verstehen."
Ähnliches gilt für Anleitungen und How-Tos: Nicht überborden, nicht das Offensichtliche Dokumentieren. Aberein Minimum an Führung und Kontaktpunkten braucht's.
Und ein Nebeneffekt des Schreibens sollte nicht unterschätzt werden: Schreiben macht uns Dinge bewusst.