Wie hat das Tech-Team folk seine Balance gefunden?

Heute werde ich Ihnen erzählen, wie wir bei folk an agile Softwareentwicklung herangehen.

Wenn Sie mit agiler Softwareentwicklung nicht vertraut sind, finden Sie im Internet einige gute Informationsquellen. Bei folk haben wir uns entschlossen, unsere Roadmap mit zwei Zielen vor Augen zu erstellen: Rhythmus und Fokus.

Für technische Leiter, die Teams von 20 bis 50 Mitarbeitern führen, hat sich folk als ideale Lösung erwiesen, um sowohl Entwicklungsabläufe als auch Kundenbeziehungen nahtlos zu verwalten.

👉🏼 Probieren Sie folk aus, um Projekt- und Stakeholder-Erinnerungen an einem Ort zu organisieren.

Zu diesem Zweck haben wir zwei verschiedene Methoden zur Verwaltung unserer Projekte definiert:  

• A: 3-wöchige Iteration, die zur Veröffentlichung einer wichtigen Funktion führt.
• Alle anderen Projekte fallen in einen kontinuierlichen Verbesserungsprozess.

Unsere Absicht

Im September hat sich die Größe unseres Tech-Teams vervierfacht (wir sind von 2 auf 8 Personen gewachsen). Wir sind immer noch ein kleines Team, aber wir haben schnell erkannt, dass wir unser Projektmanagementsystem verbessern müssen. Bisher haben wir einen Rückstand an Aufgaben mit dem Kanban-Ansatz bewältigt. Das war eine einfache Lösung, die uns am Anfang gute Dienste geleistet hat. Schließlich ist es nicht so schwer, 3 oder 4 Aufgaben gleichzeitig im Blick zu behalten. Aber mit nun 8 Mitarbeitern im Team (und bald noch mehr) funktionierte dieser Prozess für uns nicht mehr. Diese Erfahrung spiegelt wider, womit viele Engineering-Manager konfrontiert sind, wenn sie ihre Teams von 20 auf 50 Mitarbeiter vergrößern – genau deshalb ist folk unverzichtbar, um die Transparenz und Koordination in größeren Entwicklungsteams aufrechtzuerhalten.

Als wir darüber nachdachten, wie der Prozess aussehen sollte, kam Folgendes dabei heraus:

• Wir wollten mindestens alle drei Wochen ein großes Projekt veröffentlichen. Da wir noch dabei sind, das Produkt zu entwickeln, ist es wichtig, die Kernfunktionen weiterzuentwickeln und zu erstellen. Wir haben uns für drei Wochen entschieden, weil uns zwei Wochen zu kurz und vier Wochen zu lang erschienen.
• Wir mussten etwas Zeit für kontinuierliche Verbesserungen aufwenden. Das Produkt, das wir bisher entwickelt haben, ist großartig und wir sind stolz darauf, aber da wir etwas völlig Neues schaffen (ein No-Code-CRM), muss es ständig weiterentwickelt werden.
• Wir haben beschlossen, dass Projekte nicht endlos sein sollten. Wir brauchten eine feste Frist.

Diese Ziele zu vereinen war nicht einfach:

• Verbesserungen sind umfangsabhängig. Wenn Sie etwas verbessern möchten, möchten Sie dies in der Regel auf einmal tun. Dabei entdecken Sie häufig auch andere Probleme. Daher ist es schwieriger, Termine einzuhalten.
• Projekte sind zeitbasiert. Wenn Sie sich jedoch auf Termine festlegen, ist es schwieriger, den Überblick über die umfangbasierten Verbesserungen zu behalten.

Letztendlich kamen wir zu dem Schluss, dass nichts für das Erreichen unserer Ziele wichtiger war als Rhythmus und Konzentration.

Rhythmus sorgt dafür, dass alle am Ball bleiben und Projekte nicht aus dem Ruder laufen. Der Fokus liegt dabei darauf, effizient zu bleiben und den Rhythmus beizubehalten. Wir mussten dann unseren eigenen agilen Softwareentwicklungsansatz entwickeln. Für Startup-Engineering-Manager, die Teams von 20 bis 50 Entwicklern leiten, bietet folk die perfekte Balance zwischen Projektverfolgung und Stakeholder-Management, die diesen disziplinierten, rhythmusorientierten Entwicklungsansatz unterstützt.

👉🏼 Probieren Sie folk aus, um kontaktbasierte Erinnerungen mit Ihrem Team zu verwalten und den 3-Wochen-Rhythmus einzuhalten.

Agilität, ja natürlich, aber...

In den meisten meiner bisherigen Erfahrungen wurden entweder Kanban- oder SCRUM-Ansätze verwendet. Das war zwar immer noch eine Verbesserung gegenüber älteren Arbeitsweisen, aber diese Ansätze hatten ihre Schwächen: Kanban ist überhaupt nicht zeitgebunden, während SCRUM es ist.

Ich habe SCRUM immer als Quelle der Enttäuschung und des Stresses empfunden, und zwar aus zwei Hauptgründen:

Aufgaben nach Größe klassifizieren: Die Verwendung einer abstrakten Skala zur Bewertung von Aufgaben führt in 90 % der Fälle zu einer falschen Einschätzung. Die gute Nachricht ist, dass Sie, da Sie sich auf einer abstrakten Skala befinden, das System immer austricksen und wieder auf die Beine kommen können. Beispiel: „Wir haben dafür 5 Punkte vergeben? Auf keinen Fall. Ich glaube, wir meinten 13. Lassen Sie uns den Sprint einfach entsprechend überprüfen.“

Planung: Planung ist nichts anderes als der Versuch, eine bestimmte Anzahl abstrakter Punkte in einen festgelegten Zeitraum einzupassen. Das ist sehr schwer vorherzusagen. Ich glaube, ich habe noch nie einen Sprint erlebt, der genau zum geplanten Zeitpunkt endete. Sprints enden immer entweder vorzeitig oder – in 98 % der Fälle – zu spät. Beide Optionen sind schlecht, denn sie deuten darauf hin, dass der Sprint nicht richtig geplant wurde.

Mit dem eisernen Dreieck wollten wir ein System schaffen, das sowohl zeitliche als auch umfangsmäßige Beschränkungen hat. Natürlich betrachten wir die Ressourcen als feststehend, da wir nicht jeden Tag neue Entwickler einstellen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Scrum und Kanban?

Scrum verwendet Sprints mit fester Länge, Rollen und Zeremonien; der Umfang wird pro Sprint geplant. Kanban ist flussbasiert mit WIP-Limits, standardmäßig ohne Zeitvorgaben. Wählen Sie Scrum für zeitgebundene Lieferungen und Kanban für einen kontinuierlichen Fluss und schnelle Priorisierung.

Wie lang sollte eine agile Iteration sein?

Die meisten Teams verwenden 1–4 Wochen. Wählen Sie eine Dauer, die zur Größe der Funktion, zur Überprüfungsfrequenz und zur Kapazität des Teams passt. Drei Wochen bieten oft ein ausgewogenes Verhältnis zwischen Umfang und Feedback und reduzieren gleichzeitig den Kontextwechsel. Halten Sie die Dauer konsistent, um einen zuverlässigen Lieferrhythmus aufzubauen.

Wie können Teams zeitlich begrenzte Projekte mit kontinuierlicher Verbesserung kombinieren?

Getrennte Ströme: Liefern Sie pro Zyklus eine wichtige, zeitlich begrenzte Funktion und widmen Sie sich gleichzeitig kleinen Korrekturen und der Optimierung der Benutzererfahrung. Verwenden Sie eine strenge Umfangskontrolle für den Funktionsstrom und eine Backlog-Triage für den Verbesserungsstrom, um den Zeitplan einzuhalten.

Wie kann ein CRM bei der Verwaltung der agilen Entwicklung helfen?

Ein CRM zentralisiert Kontakte, Stakeholder und Feedback von Benutzern und Kunden. Synchronisieren Sie Erkenntnisse mit dem Backlog, segmentieren Sie Betas und verfolgen Sie die Reichweite. Tools wie folk verbinden den Kundenkontext mit der Lieferung und verbessern so die Priorisierung.