Funzioni multiple team più prodotti

CI/CD overhead will be too much.

Sarà molto. Il sovraccarico di assorbire nuovi membri del team sarebbe ancora più difficile da rintracciare. Non solo stai andando contro il libro aggiungendo i membri del team in ritardo, sei già sopra la dimensione della squadra con 11 persone in una squadra.

La regola della pizza non dice più in una squadra, quindi due pizze possono sfamare. La mia regola è se girarti sulla sedia e parlare con la tua squadra sembra parlare in pubblico è troppo grande. Se parlare con la tua squadra richiede effettivamente di trascinare tutti in una sala conferenze, sei solo una squadra su carta.

Con team di queste dimensioni (11, sheesh) non sarebbe solo una buona idea formare una terza squadra, sarebbe una buona idea tirare due esperti sviluppatori da ciascuno dei due team esistenti per formare la terza squadra con 4 altri nuovi sviluppatori.

Questo significa che le nuove squadre saranno 9, 9 e 10, rendendo la nuova squadra la più grande che è dal libro. Le squadre hanno lo scopo di restringere non crescere.

Quando sono costretti ad assorbire nuovi membri del team incoraggiarli ad associare gli sviluppatori junior con gli sviluppatori senior. Non fare compiti difficili ma permetterlo. Ciò mantiene la comunicazione in fase di accelerazione dal travolgente team. Anche con questo rallenterà la squadra.

Potrebbero esitare a questo piano perché mostra chiaramente quanto questo inciderà sulla produttività dei team esistenti ma è proprio per questo che lo favorisco. Questo rende chiaro l'impatto di questa mossa. Se non sono disposti a rallentare così tanto ora per aumentare i mesi di capacità in fondo alla strada, dovrebbero smettere di fare scherzi con te.

Se ti lasciano in pace, prova questo: non preoccuparti di ridimensionare le priorità del lavoro che è stato de-priorizzato. Non avrai alcun merito per questo. Esprimi il rischio di posticiparlo e andare avanti. Qualche lavoro deve essere fatto indipendentemente da cosa. Fallo solo fino a quando non ti dispiace non ottenere credito.

Penso che potrebbero esserci altri problemi con un terzo team che sta lavorando su entrambi i prodotti:

• Chi esamina le modifiche al codice? Membri del terzo team o membri del team dedicato ai prodotti?
• Chi prende le decisioni di progettazione per ciascun prodotto?

Perché queste altre funzionalità non sono appena prioritarie negli arretrati esistenti? Penso che la mossa giusta sia quella di mantenere due squadre e dare la massima priorità a queste "altre" funzionalità nel backlog o creare un bucket dedicato di punti storia per ogni sprint su cui lavorare su queste "altre" funzionalità. Se una funzione tocca entrambi i prodotti e richiede lavoro da entrambi i team, quindi utilizza storie tra team .

Ha l'odore di una cosa storica politica che hai due PM (= PO) in primo luogo. Ovviamente dovresti averne uno con un unico backlog, c'è solo un prodotto con accesso multicanale, giusto?

Hai 22 sviluppatori e ancora, "non stai andando abbastanza veloce", quindi stai cercando dei modi per scalare.

Qui c'è qualcosa di sbagliato. Faresti meglio ad avere un potente prodotto per tenere conto di questa situazione.

Supponendo che tu lo faccia, sembrerebbe più appropriato tornare a un PO e un backlog e sicuramente non più di un SM. Quindi potresti avere 4 o 5 team di sviluppo e avere uno staff senior che coordina le squadre, prendersi cura delle questioni inter-team. Ogni team avrebbe le proprie sessioni di pianificazione con lo stesso SM e PO.

Ma dato il modo in cui sono organizzate le cose ora, sospetto che questo tipo di cambiamento non sia fattibile nella tua organizzazione.