Focus Flow: die Developer-Perspektive
Wie wir wissen, hat die Produktivität viel zu viele Feinde. Perfektion, Komplexität, Komfort, Unbehagen, sogar die Keksdose in der Küche. Wenn unser Held „Produktivität“ aus der Masse an Gegnern einen Einzigen herausfordern könnte, würde ich den „Kontextwechsel“ vorschlagen.
Die Kosten für den “Kontextwechsel” sind Informatikern von Anfang an bekannt. Wir haben viele Strategien erfunden, um diese nicht zu bezahlen (Interrupt Coalescing, Batch-Verarbeitung usw.). Einige Informatiker gehen sogar bis ins Extrem, wie z. B. der legendäre Programmierer Donald Knuth, der am 1. Januar 2014 alle Fehler in seiner berühmten Software TeX behoben hat, die in den letzten sechs Jahren gemeldet wurden. Schließlich loggte er sich mit der Nachricht „Bleib dran für das TeX Tuneup von 2021!“ aus (Ref_1).
Der Kontextwechsel gehört zu unserem täglichen Geschäft. Wir müssen zwischen Kontextwechsel und Reaktionsfähigkeit abwägen. Wir lösen Probleme und Fehler, schreiben neue Funktionen, nehmen an Besprechungen teil, beantworten Fragen und erhalten Informationen aus verschiedenen Quellen. Wäre es nicht schön, wenn sich manchmal alle diese Aktivitäten auf nur ein Thema beschränken würden? Wenn wir unsere Energie dediziert für ein längeres Zeitintervall in nur eine Richtung konzentrieren können?
Eine Idee wird geboren
Es gibt bestimmte Themen, die regelmäßig in unserem Retrospektive-Board erscheinen. Nicht auf der positiven Seite. Eine davon hat mit Kontextwechsel zu tun. Wir, die DEVs, beschweren uns am häufigsten über zu viele Themen pro Person, verstreute Besprechungen und Unterbrechungen sowie einen eingeschränkten Einfluss auf eingehende Features.
Doch wie löst man das?
Gar nicht, weil es nicht kaputt ist. Es liegt in der Natur unserer täglichen Arbeit. Aber hin und wieder können wir in einen anderen Modus wechseln, in dem sich unsere Energie auf ein einziges Thema konzentriert. Wir haben es „Focus Flow“ genannt.
Was ist der Focus Flow?
Beginnen wir zunächst mit der Erklärung, was ein “Flow” ist. Wir lieben und leben die agile Entwicklung bei Chrono24. Natürlich haben wir das SCRUM-Framework an unsere Bedürfnisse angepasst. Unsere „Sprints“ werden als „Flows“ bezeichnet (Ref_2) und dauern zwei Wochen.
Wir haben zentrale Elemente des Design Sprint verwendet, um diesen Flow durchzuführen. Eine Reihe von Experten in verschiedenen Bereichen wie z. B. Data Science und Marketing standen uns für Fragen und zur Beratung zur Verfügung.
Focus Flow ist einfach ausgedrückt, ein Sprint mit nur einem großen Thema: ein Problem, das gelöst werden muss oder eine Idee, die Gestalt annehmen muss. Ja, es klingt wie ein Game Jam und es fühlt sich sehr nach einem an ;-).
Die Komponenten eines Focus Flow sind:
- Die Idee oder das Problem sollte groß genug, aber lösbar innerhalb eines Focus Flows sein. Eine gute Wahl ist etwas Experimentelles oder Innovatives. Das gewünschte Ergebnis ist im besten Fall ein Prototyp oder Tracer-Code (Ref_3), kann aber auch ein “Proof of Concept” sein oder sogar die Idee als nicht realisierbar, nicht sinnvoll zu beweisen.
- Die Zusammensetzung der FF-Teammitglieder (Focus Flow Teammitglieder) hängt von der Idee oder dem Problem ab. Manchmal ist die Idee von Anfang an nicht klar und sollte während des Focus Flows entwickelt werden. So war es bei unserem Focus Flow. Deswegen haben wir ein interdisziplinäres Team zusammengestellt, das aus einem Produktmanager, einem Grafik- / UX-Designer, einem Scrum-Master und schließlich vier Entwicklern (zwei Personen pro Plattform iOS/Android) besteht. Wenn die Natur des zu lösenden Problems unterschiedlich ist, z. B. ein Vergleich technischer Lösungen, kann ein Team nur aus Entwicklern ausreichend sein.
- Das Backup-Team: Sie sind diejenigen, die sich um alle täglichen Ablenkungen kümmern und somit die Rücken der Mitglieder des FF-Teams frei halten. Ich kann nicht genug betonen, wie wichtig das Backup-Team für den Focus Flow ist. Man muss sich auf jeden Fall darum kümmern. Alle Fragen, das tägliche Geschäft und die Bugs werden nicht verschwinden, nur weil die Aufmerksamkeit dafür nicht verfügbar ist. Also sei vorbereitet.
- Die Stakeholder: Sie sind die Personen, die anfangs die Einschränkungen des Projekts definieren und den Erfolg des Ergebnisses beurteilen sowie über seine Zukunft entscheiden. Die Stakeholder werden anfangs interviewt, um die Bedürfnisse klar zu kommunizieren und ein gemeinsames Verständnis sicherzustellen. Sie haben auch die Wireframes gesehen,auf denen deutlich wurde, was der geplante Projektumfang ist und uns grünes Licht gegeben.
Das Setup eines Focus Flows ist daher recht einfach. Eine Gruppe von Menschen arbeitet in einer Umgebung ohne Ablenkung auf ein gemeinsames Ziel hin. Der Schwerpunkt liegt natürlich auf der Geschwindigkeit. Wir wollen am Ende ein Ergebnis haben, das sonst aufgrund von Kontextwechsel oder Ping Pong zwischen Abteilungen und Personen viel mehr Zeit in Anspruch genommen hätte. Das FF-Team muss an keinen Meetings außerhalb des Focus Flows teilnehmen, was Platz für schnelle Iterationen und Tests schafft. Wir haben uns auch dazu entschieden, keine Scrum-Stories zu schreiben, da die Kommunikationswege sowieso kurz und problemlos waren.
Unsere Erfahrung…
… war allgemein sehr positiv. Wir haben z. B. den Watch Scanner zum Leben erweckt. Es war eine sehr spannende Aufgabe. Einfach erklärt, er ermöglicht es unseren Benutzern, Fotos von Uhren aufzunehmen und versucht, die Uhr zu erkennen. Die zugrunde liegende Technologie wurde als Experiment an einem Flow Free Friday* entwickelt und ist im Grunde ein Convolutional Neural Network (CNN), was mit Daten aus unserer internen Uhrendatenbank trainiert wird.
* Flow Free Friday: der letzte Freitag jedes Flows. An diesem Tag dürfen wir an allem arbeiten, was wir spannend finden.
Neben einfachen Fakten über die gescannte Uhr wie Marke, Modell, Referenz-ID, Gehäusematerial usw. zeigt der Watch Scanner auch den aktuellen Marktwert der Uhr an und kann helfen, ähnliche Angebote zu finden und diese der Uhrensammlung hinzuzufügen.
Selbstverständlich hatten wir im Focus Flow mehr Ideen für Features im Produkt, als wir Zeit zur Umsetzung hatten. Daher haben wir uns für wenige umsetzbare Features in der Zeit entscheiden müssen. Einige der Ideen wurden im Nachgang umgesetzt, andere wurden in unser Backlog aufgenommen. Zurzeit verfügt unser Watch Scanner über ein zusätzliches Feedback-Modul, damit man das zugrunde liegende Modell verbessern kann.
Sehr spezifisch für unseren Focus Flow war die Tatsache, dass es keine einzige Person gab, die die endgültigen Entscheidungen während des Flows autoritativ genehmigen musste. Alle Entscheidungen wurden vom gesamten Team während den Diskussionsrunden getroffen. Ich muss zugeben, es fühlte sich seltsam an, als Entwickler Produkt- und Designentscheidungen zu treffen. All dies ist jedoch eine brillante Lernerfahrung, da man die Dinge aus einer neuen Perspektive betrachten kann. Ich werde niemals die Bemühungen des Projektmanagements unterschätzen, so viele verschiedene Menschen und Meinungen zusammenzubringen. Das erfordert eine große Menge an Energie, Geduld und Kompromisse.
Zum Schluss…
… probiert es ab und zu als Team aus. Ein Focus Flow kann einen starken Motivationsschub geben und ist manchmal der beste Weg, um ein Thema voranzutreiben. Wichtig ist, dass es nicht um Perfektion geht, sondern ums Spiel. Lasst deswegen nicht zu, dass „besser“ zum Feind des Guten wird. (Ref_4). Sichtbare Fortschritte zu machen und sofortige Ergebnisse zu sehen, ist herrlich (Ref_5). Unsere Arbeit als Softwareentwickler hat einen riesengroßen Vorteil – wir müssen fast nie warten. Wir bauen keine Brücken, planen keine Infrastruktur, pflanzen keine Bäume an. Die Früchte unserer Bemühungen können fast sofort gesehen und konsumiert werden. Nutzt diesen Vorteil, genießt die unmittelbaren Belohnungen und seid dankbar.
Referenzen
(Ref_1) Brian Christian & Tom Griffiths “Algorithms to live by”
Perhaps the patron saint of the minimal-context-switching lifestyle is the legendary programmer Donald Knuth. “I do one thing at a time,” he says. “This is what computer scientists call batch processing – the alternative is swapping in an out. I don’t swap in and out.” Knuth isn’t kidding. On January 1, 2014, he embarked on “The TeX Tuneup of 2014”, in which he fixed all of the bugs that had been reported in his TeX typesetting software over the previous six years. His report ends with the cheery sign-off “Stay tuned for The TeX Tuneup of 2021!
(Ref_2) James Clear “Atomic Habits”
Flow is the mental state you enter when you are so focused on the task at hand that the rest of the world fades away. This blend of happiness and peak performance is what athletes and performers experience when they are ‘in the zone’. It is nearly impossible to experience a flow state and not find the task satisfying at least to some degree.
(Ref_3) David Thomas & Andrew Hunt “The Pragmatic Programmer”
Tracer Bullets show what you’re hitting. This may not always be the target. You then adjust your aim until they’re on target. That’s the point.
It’s the same with tracer code. You use the technique in situations where you’re not 100% certain of where you’re going. You shouldn’t be surprised if your first couple of attempts miss: the user says “that’s not what I meant,” or data you need isn’t available when you need it, or performance problems seem likely. So change what you’ve got to bring it nearer the target, and be thankful that you’ve used a lean development methodology; a small body of code has low inertia – it is easy and quick to change.
Perfect is the enemy of good
(Ref_5) David Thomas & Andrew Hunt “The Pragmatic Programmer”
Often you’ll be in a situation where trade-offs are involved. Surprisingly, many users would rather use software with some rough edges today than wait a year for the shiny, bells-and-whistles version (and in fact what they will need a year from now may be completely different anyway). Many IT departments with tight budgets would agree. Great software today is often preferable to the fantasy of perfect software tomorrow.