Startup – ist es an der Zeit, sich in zwei Teams aufzuteilen?

Ich arbeite bei einem Startup, wo ich vor 3 Jahren als einziger Entwickler angefangen habe, und jetzt leite ich das Entwicklerteam. Es gibt insgesamt 15 Mitarbeiter, davon 8 Ingenieure:

  • 5 iOS-Entwickler
  • 3 Backend-Entwickler

Wir bauen gerade eine iOS-Anwendung.

Wir werden langsam ein bisschen erwachsen und haben jetzt einen UX Designer, einen Head of Product, einen Head of Marketing und so weiter. Nach einer langen Phase der Produktfindung und einigen sehr langen Veröffentlichungszyklen möchten wir schneller mit der Iteration beginnen.

Meine Ziele sind:

  1. in der Lage zu sein, das Team parallel an 2 oder 3 vertikalen Slices von Features arbeiten zu lassen.

  2. um diese Funktionen in jedem Sprint veröffentlichen zu können

  3. um die Verantwortung und Verantwortlichkeit innerhalb des Teams zu erhöhen

Probleme, die ich sehe:

  1. Fühlt sich „von oben nach unten“ an – ein Großteil der Teamkommunikation scheint durch mich zu erfolgen. dh. Wenn ein Backend-Entwickler ein Problem mit einer iOS-Komponente hat, fragt er mich vielleicht, und dann spreche ich mit dem iOS-Entwickler und leite dann Informationen zurück

  2. Standups fühlen sich unkonzentriert an – da wir 8 Entwickler haben, die alle an verschiedenen „Teilen“ von Dingen arbeiten, scheinen Standups nicht besonders nützlich zu sein, da es keine wirklich einheitliche Anstrengung im gesamten Team gibt.

  3. Es über den Zaun werfen – Nach dem Sprint Planning neigt jeder dazu, in seine Silos zu gehen. Wir haben besprochen, was erledigt werden muss, aber die Entwickler tendieren dazu, in ihre eigenen Welten einzutauchen und zum Beispiel nicht die Initiative zu ergreifen, um Schnittstellen zwischen Front- und Backend zu diskutieren, und werfen Dinge für QA (was normalerweise zu mir kommt unser Produkt Eigentümer) usw.

Frage: Ich frage mich, ob es an dieser Stelle sinnvoll ist, das Team in zwei funktionsübergreifende Gruppen aufzuteilen? Ich hoffe, dass dies Folgendes erreichen wird:

  1. Jedes „Team“ hat ein Sprintziel, das aus 1 oder 2 vertikalen Teilstücken bestehen kann, die es zu erreichen gilt. Ich denke, es ist vielleicht einfacher, sich im Kontext einer kleineren Gruppe selbst zu organisieren und herauszufinden, was passieren muss, um die Ziele zu erreichen. Darüber hinaus denke ich, dass dies bei der Verantwortlichkeit helfen könnte, da das Team sehr spezifische Ziele haben wird.
  2. Standups können in jedem Team stattfinden und konzentrieren sich daher darauf, die Blockierung aufzuheben und den Fortschritt in Bezug auf ihre spezifischen Sprintziele voranzutreiben.
  3. Da jedes Team spezifische Ziele und Verantwortlichkeiten hat, sind sie stärker für Dinge wie QA, Mockup-Genauigkeit, funktionale Edge-Cases usw. verantwortlich, bevor sie an den Product Owner für Endabnahmetests geliefert werden.

Ich nehme an, das Obige kann im Kontext eines einzelnen größeren Teams erreicht werden, aber ich habe noch keinen guten Weg gefunden, dies zu erreichen.

Es scheint, als hätten Sie ein agiles Adoptionsproblem, kein Problem mit der Teamgröße. Wenn Sie Ihr Team aufteilen, bevor Sie die zugrunde liegenden Probleme beheben, werden Ihre Integrationsprobleme wahrscheinlich eher verdoppelt als verringert.
Sind die Nicht-Entwickler (UX-Designer, Produktleiter, Marketingleiter usw.) ebenfalls Teil des Teams oder arbeiten sie getrennt? Verfügt das Team über eine Definition of Done , die Tests und Integration umfasst? Wie würde das Team reagieren, wenn Sie sagen würden: „Das wird in einer Stunde live gehen“, wenn es eine Story als erledigt meldet?

Antworten (2)

Ein paar Dinge heben sich von deiner Frage ab:

in der Lage zu sein, das Team parallel an 2 oder 3 vertikalen Slices von Features arbeiten zu lassen

Warum sehen Sie das parallele Arbeiten als Ziel? In der Regel kostet Sie die parallele Arbeit aufgrund des Overheads des Kontextwechsels an Effizienz.

Wenn ein Backend-Entwickler ein Problem mit einer iOS-Komponente hat, fragt er mich vielleicht, und dann spreche ich mit dem iOS-Entwickler und leite dann Informationen zurück

Dies ist ein Kommunikationsproblem. Hat das Team darüber gesprochen?

Standups fühlen sich unkonzentriert an

Hat das Team darüber gesprochen? Haben sie irgendetwas versucht, um die Stand-Ups besser zu machen?

Nach dem Sprint Planning neigt jeder dazu, in seine Silos zu gehen

Das Beheben der Probleme mit dem Aufstehen sollte hier helfen.

Ich würde vorschlagen, dass die größte Verbesserung, die Sie jetzt machen können, darin besteht, Dinge im Team zu diskutieren.

Es kann sein, dass die Aufteilung in zwei Teams sinnvoll ist, aber diese Entscheidung wird am besten vom Team selbst und nicht von einer Einzelperson getroffen.

Wir besprechen die Dinge derzeit im Team während der Planungssitzungen und so weiter. Aber danach tendieren die Menschen dazu, in ihre eigenen Welten einzutauchen
Ähnlich wie bei dem Kommentar, den ich zur obigen Antwort gepostet habe, wie würde ein 8-köpfiges Team an einem einzelnen Feature arbeiten? Meine bisherige Erfahrung ist, dass es etwas eng ist. Mein Gedanke war also, dass, wenn wir an 2 oder 3 Slices gleichzeitig arbeiten, weniger davon vorhanden wäre und im Wesentlichen 2 oder 3 Entwickler für jeden verantwortlich wären.
Ich verstehe absolut, dass es manchmal praktisch ist, an mehr als einer Sache gleichzeitig zu arbeiten. Aber ich würde mir das nicht zum Ziel setzen, es ist einfach etwas, das natürlich aus der Planung herausfallen sollte. Das Team wird die vorgeschlagene Arbeit besprechen und dann entscheiden, wie sie am besten aufgeteilt werden kann. Es geht darum, das Team dazu zu bringen, diese Entscheidungen zu treffen, damit es weniger geneigt ist, in Silos zu arbeiten.
Ja ich verstehe. Das Team ist derjenige, der die Entscheidungen darüber trifft, was zu übernehmen ist, was Grenzfälle sind, mögliche Umfangsfragen, aber dann finde ich, dass jede Person mehr oder weniger ihre Tickets nimmt und ihre Arbeit erledigt. Nach der Planung scheint es also immer noch eine Unterbrechung des fortgesetzten teambasierten Betriebs zu geben
Dann ist das das Gespräch, das Sie mit dem Team führen sollten. Warum wollen sie so arbeiten? Sie könnten auch einige Vorschläge machen, vielleicht versuchen sie es zum Beispiel mit Pair Programming? Der Schlüssel ist, dass das Team die Dinge anders machen will. Bringen Sie sie dazu, darüber zu sprechen, finden Sie heraus, was ihre Motivation ist.

Von dem, was Sie beschreiben, glaube ich nicht, dass Sie ein Problem mit Ihrer Teamgröße haben. 5 + 3 scheint ganz ok zu sein. Vielleicht sollte ich einige Kommentare zu Ihren Punkten hinzufügen, damit Sie verstehen, warum ich denke, dass Ihr Problem etwas anderes ist:

Ziel 1 und 2: Warum müssen Sie Ihrer Meinung nach 2-3 vertikale Schnitte gleichzeitig bearbeiten? Wenn Ihre Veröffentlichungszyklen derzeit zu lang sind, können Sie den Zyklus beschleunigen, indem Sie weniger Threads gleichzeitig verarbeiten. Es ist auch eine gute Praxis, einen Thread nicht von einer Person zu bearbeiten.

Ich denke, es ist ein häufiges und weit verbreitetes Problem, zu viele Geschichten gleichzeitig zu verarbeiten und zu hoffen, dass die Dinge dadurch schneller werden. Es tut nicht. Es wird dazu führen, dass Ihr Team in einzelne Entwickler aufgeteilt wird, jeder macht seine eigenen Sachen.

Problem 1 : Sind Ihre Entwickler in einem Team? Wenn ja, warum sollte ein Backend-Typ Sie nach etwas fragen, das der iOS-Entwickler getan hat? Haben sie ein gemeinsames Ziel? Sie sollten versuchen, ihr gemeinsames Ziel gemeinsam zu erreichen. Wenn sie dann feststellen, dass etwas nicht klar ist und sie Feedback vom PO benötigen, sollten sie Sie fragen. Zusammen.

Problem 2 : Siehe Kommentar zu Ziel 1 und 2. Wenn jeder an etwas anderem arbeitet, haben Sie nicht wirklich ein Team-Setup. Wir haben hier auch ein Team , das es so macht, es fehlt an Teamarbeit und dem Aufbau einer technischen Abteilung, weil sie "schnell" sein müssen.

Punkt 3 : Ja, auch der Teamgeist fehlt. Es sieht aus wie das typische Restaurantproblem. Service und Köche arbeiten nicht zusammen, kämpfen im schlimmsten Fall ihre kleinen Kriege und finden heraus, wer schuldig ist, und treiben die Arbeit auf der anderen Seite voran.

Ich hoffe, dass meine Ausführungen deutlich machen, dass eine Aufteilung des Teams nicht die Lösung ist. Von dem, was Sie beschreiben, kann ich Ihnen hier keine einfache Lösung geben. Normalerweise sollten iOS- und Backend-Entwickler sich gemeinsam einer Geschichte widmen . Und wenn sie das nicht erreichen, scheitern beide zusammen.

Darüber hinaus kann es auch ein Problem persönlicher Vorlieben und Abneigungen sein, wenn Ihre Arbeit aufgeteilt ist, sodass jeder seine eigene kleine Geschichte schreibt. Nach einer Runde Schuldgefühle werden die Menschen gegeneinander voreingenommen. Dies wird noch schlimmer, wenn dieselben Personen immer wieder dasselbe Thema behandeln.

Vielen Dank für Ihre Antwort. Ich nehme an, ich bin neugierig: Wenn wir 8 Entwickler haben und sie nicht gemeinsam an 2 oder 3 vertikalen Slices arbeiten und nur an einem 1 Feature arbeiten, wie würde das funktionieren?
@djt Dies hängt von der zu implementierenden Funktion ab. In manchen Situationen kann es sinnvoll sein, an 2-3 Schichten zu arbeiten. Aber wenn möglich, sollte sich das Team auf ein Feature konzentrieren (das mehrere Geschichten haben kann). Was ich sagen möchte, dass das Arbeiten an verschiedenen Slices sinnvoll sein kann, aber kein Ziel sein sollte.
Startup – ist es an der Zeit, sich in zwei Teams aufzuteilen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v