Sto iniziando da questa nuova compagnia come scrum master, e vogliono immergersi in Scrum, che è bello e tutto, ma hanno solo abbastanza persone (4) per una squadra.
La road map include la consegna di un nuovo prodotto e il mantenimento di quello vecchio, quindi cosa dovremmo fare?
In precedenza ero lo Scrum Master per un team che stava sviluppando due prodotti. Il coperto lo stesso spazio di mercato quindi era comprensibile che avremmo lavorato su entrambi.
Abbiamo creato roadmap e sviluppato storie in modo indipendente e poi le abbiamo combinate in un unico backlog. In questo modo abbiamo sempre saputo quale prodotto aveva la priorità e poteva selezionare gli elementi su cui lavorare in modo appropriato. Era molto più lavoro per lo Scrum Master e il Product Owner, ma rendeva più semplice il resto del team visto che considerava ogni storia come un po 'di lavoro e non ci pensava molto quale prodotto era più importante.
La più grande sfida per il Product Owner è stata la priorità tra le storie. Un prodotto aveva una base di clienti installata più grande, ma era al tramonto a causa di limitazioni tecniche e l'altro aveva una lunga lista di funzionalità "must have". È stato un atto di bilanciamento continuare a far uscire nuove versioni del vecchio da appendere ai clienti esistenti, fornendo al contempo nuove funzionalità nel nuovo per attirare nuovi clienti e (cosa più importante) far migrare i clienti esistenti. Alla fine l'aveva elaborato in modo che l'arretrato fosse un modello di 4 prodotti A storie seguite da 1 prodotto B story. Avevamo giocato molto a questo punto e so che da quando me ne sono andato stanno ancora facendo degli aggiustamenti in base alle esigenze del business.
La sua altra grande sfida è stata determinare quale frequenza avrebbe voluto rilasciare gli aggiornamenti. Sebbene entrambi i prodotti siano stati resi disponibili alla fine delle iterazioni, è diventata una decisione tanto strategica quanto il rilascio dei rilasci al cliente. Alla fine si accontentò delle versioni trimestrali del nuovo e del vecchio, con il vecchio che usciva una o due settimane dopo. Non posso dire se fosse la decisione migliore o meno.
Nel mio ruolo di Scrum Master, l'esecuzione delle interferenze per la squadra da forze esterne era più complicata in quanto le persone esterne al team avevano spesso un'influenza positiva su un prodotto, ma una negativa sull'altra. Ad esempio, le persone con le quali dovevamo consultarci riguardo alla tecnologia del vecchio prodotto a volte cercavano e facevano richieste di modifiche al nuovo prodotto nel bel mezzo di un'iterazione. Quindi avevo bisogno che fossero con gli sviluppatori, ma rimaniamo concentrati sul perché li abbiamo avuti lì.
C'era anche molto lavoro per convincere la squadra a vedere il valore nel lavorare su entrambi i progetti. Mentre all'interno di un progetto ci sono sempre migliori e peggiori incarichi, convincere qualcuno a riprendere un'attività noiosa in un progetto morente per un'iterazione significa che è davvero necessario vendere il valore del lavoro. A volte hai dovuto evidenziare i dollari coinvolti nel cambiamento.
Un altro problema che è emerso ogni pochi mesi era un suggerimento del management superiore che divideva il team in team di "visione" e "manutenzione". Questo era un gruppo in cui le persone erano membri da 3-10 anni e suggerivano di suddividerla solo per rendere l'assegnazione delle risorse migliore sulla carta. In realtà, avrebbe fatto male a togliere definitivamente a qualcuno la manutenzione e, per lo stesso motivo, non rendere qualcuno parte della visione avrebbe lasciato loro sfiniti o peggio. Stavo vendendo costantemente il valore della squadra nel suo complesso era maggiore della somma delle sue parti.
Stimare le storie era difficile ogni volta che stavamo raccogliendo un'area che non era stata toccata da molto tempo. È diventato difficile per la squadra ricordare facilmente quale altro lavoro era stato fatto lì e come lo avevano dimensionato in precedenza. Questo voleva dire che prima delle riunioni di stima dovevo passare alcune ore a scavare attraverso le nostre vecchie iterazioni per trovare storie simili, così potevo ricordare loro cos'altro avevamo fatto in quell'area. Come era stato dimensionato e come la storia aveva funzionato nella realtà.
Un altro problema meccanico con lo Scrum era quello di eseguire stand-up giornalieri in un modo che rendesse chiaro il prodotto di cui stavamo parlando. Abbiamo adottato l'approccio di parlare attraverso le storie piuttosto che intorno alla stanza per tenerlo chiaro. Questo era particolarmente importante quando entrambi i prodotti aggiornavano la stessa tecnologia nella stessa iterazione.
Con le stesse persone che lavorano su entrambi i progetti le tue scelte sono limitate:
Due backlog del prodotto per un team.
Altrimenti, se mai dovessi crescere con due team di scrum, il costo di "ordinare" dai backlog del prodotto ti impedirà in modo efficace di dividere il lavoro.
La prima cosa da tenere a mente è che Scrum richiede una squadra di 4-11 persone. Con un team di 4 persone, sei alla soglia inferiore per vedere i vantaggi degli artefatti e degli eventi di Scrum, ma mettere in atto la struttura sarebbe probabilmente di aiuto se il team crescesse.
Cose come il backlog del prodotto, lo sprint backlog e varie misurazioni e metriche (come velocità e burndown) devono essere gestite in base al progetto. Avresti svolto tutte le attività normalmente. È inoltre necessario tenere traccia del tempo trascorso da ciascun individuo su ciascun progetto, in modo da sapere quanti punti della storia devono essere abbattuti per ogni progetto. Invece di basare la velocità su solo punti storia per iterazione, considera anche il tempo trascorso su ciascun progetto.
In base al commento, non porterei affatto il supporto del prodotto esistente di Scrum. Scrum va bene per lo sviluppo in cui è possibile definire il backlog ma la manutenzione di solito non può definirlo. Sembra che lo sforzo maggiore debba essere inserito nel nuovo progetto, quindi gestiamo con Scrum e riduciamo la capacità del team in base al tempo prestabilito assegnato per gestire i problemi nel vecchio prodotto. Se non ci saranno difetti per fissare il tempo verrà utilizzato per un nuovo prodotto e il team sarà probabilmente in grado di fornire un po 'di più rispetto al commit. Se la nuova funzione per il vecchio prodotto sarà pianificata, puoi contare su di essa nella pianificazione dello sprint successivo per il nuovo prodotto e ridurre ulteriormente la capacità del team per far sì che le persone abbiano abbastanza tempo per implementare una nuova funzionalità per il vecchio prodotto.