Garantiert Team Ramp Up eine erhöhte Funktionsgeschwindigkeit?
Veröffentlicht: 2020-03-28Eine der wichtigsten Voraussetzungen beim Hochfahren von Teams zur Erhöhung der Release-Geschwindigkeit ist die Übertragung von Klarheit von den Produktteams auf die Sprint-Teams
Eine reibungslose Sprint-Ausführung ist das Ergebnis bemerkenswerter Beiträge, die sowohl vom Produkt- als auch vom Sprint-Team stammen
Die Philosophie des „First-Time-Right (FTR)“ hilft allen Teammitgliedern, sich auf ein gemeinsames Ziel auszurichten
Wenn Startups von der frühen Phase in die Wachstumsphase wechseln, ändern sich ihre Prioritäten erheblich. Unter allen anderen sticht die Feature-Geschwindigkeit als Priorität hervor und spielt eine entscheidende Rolle bei ihrem Streben nach Wachstum.
Der Gründer eines Seed-finanzierten Startups, mit dem ich zusammengearbeitet habe und das kürzlich seine Serie-A-Runde erhöht hat, hat mich gebeten, das Engineering-Team zu verdoppeln, um neue Funktionalitäten in sechs Monaten zu veröffentlichen. Aber ist das der einzige relevante Faktor, um die Zykluszeit zu reduzieren? Um darauf zu antworten, beschloss ich, die ignorierten Aspekte hinter diesem weit verbreiteten „Missverständnis“ anzusprechen.
Obwohl die Ressourcenkapazität einer der kritischen Faktoren für häufige Freigaben für die Produktion ist, kann dies allein keine verkürzte Zykluszeit garantieren. Während ich Produkte für mehr als 16 Startups entwickle, habe ich mehrfach den Übergang von der Früh- zur Wachstumsphase miterlebt. Aus dieser Erfahrung heraus möchte ich einige entscheidende Faktoren aufzeigen, die Startup-Gründer berücksichtigen sollten.
Klarheit weitergeben: Das Top-Down-Essential
Eine der wichtigsten Voraussetzungen beim Hochfahren von Teams zur Erhöhung der Release-Geschwindigkeit ist die Übertragung von Klarheit von den Produktteams auf die Sprint-Teams. Wenn ein Sprint mit Mehrdeutigkeit beginnt oder nicht genug Geschichten für den Anfang hat, wird die Sprint-Lieferquote negativ beeinflusst. Vage definierte Storys oder die Aufnahme von Aufgaben mitten im Sprint verlangsamen das Tempo, was dazu führt, dass die Sprint-Teams nicht wie geplant liefern.
Eine reibungslose Sprint-Ausführung ist das Ergebnis bemerkenswerter Beiträge, die sowohl vom Produkt- als auch vom Sprint-Team stammen. Das Produktteam kann seinen Teil dazu beitragen, indem es die Roadmap vorbereitet und zumindest für das Quartal mit dem Sprint-Team teilt, damit das Team seine Ergebnisse entsprechend planen kann.
Auf der anderen Seite sollte das Sprint-Team das Produktteam weiterhin dazu drängen, ein Produkt-Backlog zu erstellen und es wöchentlich/zweiwöchentlich zu pflegen, um eine zielgerichtete Lieferung sicherzustellen.
Automatisieren, um „fehlerfrei“ zu veröffentlichen
„Effizienz bedeutet, die Dinge richtig zu machen; Effektivität bedeutet, die richtigen Dinge zu tun.“ – Peter Drucker
Wenn Sie an Automatisierung denken, ist dies ein Beispiel für die letztere Kategorie. In dem Moment, in dem die Feature-Entwicklung Fahrt aufnimmt, ist es sehr wahrscheinlich, dass die Produktion zusammenbricht, wenn nicht die richtigen Prozesse vorhanden sind. Wenn das Produkt nicht stabil genug ist, um neue Funktionsentwicklungen zu bewältigen, verbringt Ihr Team mehr Zeit mit der Behebung von Problemen als mit der Entwicklung neuer Funktionen. Folglich sinkt Ihre Engineering-Geschwindigkeit.
Hier kommt CI/CD (Continuous Integration and Continuous Deployment) ins Spiel. Hier stellen umfassende Unit-, Integrations- und Automatisierungstests sicher, dass alles, was geliefert wird, das System nicht beschädigt.
Für dich empfohlen:
Bauen Sie nicht einfach mehr, sonst machen Sie mehr kaputt
Nacharbeit ist ein großer Produktivitätskiller und kann das Ergebnis verschiedener Faktoren sein, wie z. B. vage definierte Geschichten, fehlende Entwicklungstests, mangelnde Testabdeckung und so weiter. Nacharbeiten können die Produktivität auffressen, da sie die Zeit und den Aufwand von QA-Ingenieuren beim Testen und Regressieren, Entwicklern beim Debuggen und Release-Managern beim erneuten Veröffentlichen verbrauchen würden.
Etwas langsamer zu werden, kann Ihrem Team helfen, schneller zu liefern und einen Mehrwert zu schaffen, da die effektive Geschwindigkeit immer sehr lohnend ist und nicht nur die Geschwindigkeit.
Die Philosophie des „First-Time-Right (FTR)“ hilft allen Teammitgliedern, sich auf ein gemeinsames Ziel auszurichten – die Bereitstellung von robustem und stabilem Code beim ersten Mal selbst. Es ist immer gesund, etwas mehr Zeit aufzuwenden, um die Qualität des Codes zu bestimmen, anstatt sich zu beeilen und sich dann mit Nacharbeiten aufzuhalten.
Einige der erprobten Methoden zur Verbesserung der FTR-Quote sind regelmäßiges Backlog-Grooming, eine Wiederholung von Geschichten, regelmäßige Demos für Produktmanager. Anstatt nur Anforderungen zu sammeln, sollte sich das Sprint-Team mehr darauf konzentrieren, diese zu erläutern, um das FTR-Verhältnis zu verbessern.
Strukturieren Sie Ihr Team für parallele Sprints
Wenn Ihr Startup ein kleines Produktteam hat, arbeiten alle meistens gleichzeitig an einem oder zwei Features (allgemein anwendbar für ein Team von 4-6 Mitgliedern). Da jedoch die Erwartung steigt, mehrere Funktionen bereitzustellen, wird dringend empfohlen, dass Sie mehrere Unterteams mit unterschiedlichen Schwerpunktbereichen bilden. Auf diese Weise kann jedes Unterteam seinen Sprint durchführen und seine Roadmap definieren.
Im Vergleich zu einem großen Team sind kleinere Teams, die aus einer „logischen Trennung“ hervorgegangen sind, effektiver und erzielen bessere Ergebnisse. Einzelne Teams für Microservices, verschiedene Produktlinien und verschiedene Komponenten sind einige Beispiele für den Ansatz der „logischen Trennung“.
Bei der Umstrukturierung ist es immer wichtig, in jedes dieser Subteams mindestens ein Mitglied aus dem früheren Kernteam aufzunehmen, um die DNA zu erhalten. Obwohl die teamübergreifende Koordination für Lieferungen einen zusätzlichen Overhead mit sich bringt, ist dies ein gerechtfertigter Kompromiss.
Verfolgen Sie die Nutzung von Funktionen zusammen mit der Geschwindigkeit
Die Benutzererfahrung ist die wichtigste Metrik, um den Erfolg einer neuen Funktionsversion zu messen. Wenn Sie beginnen, mehrere Funktionen schnell bereitzustellen, tritt die Benutzererfahrung oft in den Hintergrund. Wenn Ihr Produkt über eingeschränkte Funktionen verfügt, ist die Benutzerinteraktion weiterhin eine glatte, ununterbrochene Kurve.
Wenn Sie jedoch mit der Veröffentlichung neuer Funktionen beginnen, besteht eine hohe Wahrscheinlichkeit, dass Benutzer überfordert werden und ihre Erfahrung beeinträchtigt wird.
Um eine bessere Benutzerakzeptanz zu erreichen, ist die Verfolgung des Benutzerengagements zusammen mit der Funktionsgeschwindigkeit weiterhin der beste Weg nach vorne. Während umfassende Benutzerforschung ein bewährter Weg ist, werden andere wichtige nach jeder neuen Version zunächst für ausgewählte Benutzer über Feature-Flags, AB-Tests und die Verfolgung der Benutzerreise (über Amplitude oder ähnliche Analysetools) eingeführt.
Verlieren Sie nicht Ihre Stammmitglieder
Dies mag ein sehr häufig ignorierter Aspekt sein, steht jedoch fest als ein sehr entscheidender. Kleine Teams brauchen nicht unbedingt Prozesse und haben eine flinke Struktur, und jede Stimme wird gehört. Wenn diese Teams in einen Zustand aufsteigen, in dem Prozesse eingerichtet und neue technische und funktionale Mitglieder hinzugefügt werden, ist ein gesundes Management der einzige Weg, um Chaos zu vermeiden.
Wenn Ihr Engineering-Team erfolgreich skaliert, ist ein gut fähiges Produktteam unerlässlich, um das Engineering-Team kontinuierlich zu versorgen. Eine Abwanderung wird unvermeidlich, wenn die Teammitglieder keine nennenswerte Arbeit haben, aber kein Startup jemals seine Kernmitglieder verlieren möchte. In diesem Fall ist die Geschäftsleitung der Schlüssel, um gute Beziehungen zu den Menschen zu gewährleisten und die Dynamik gut zu verstehen.
Die Erkenntnisse, die ich hier geteilt habe, stammen aus der Erfahrung mit mehreren Startups im Laufe der Jahre. Ich erwarte, dass es Startup-Gründern, die schon viel um die Ohren haben, nützlich sein wird, damit sie nicht das Rad neu erfinden.