Scrum ruoli mescolati

The line manager simultaneously embraces Scrum and has a hard time "letting go"; he has the Product Backlog in his head and also prioritizes it.

Suppongo che il tuo line manager stia completando il ruolo di Scrum Master. In questo esempio, non sta abbracciando i tradizionali ruoli Scrum.

Uno degli aspetti chiave di qualsiasi metodologia agile è l'alta visibilità. Ciò significa che i prodotti di lavoro sono visibili al cliente su base regolare (come visto attraverso frequenti rilasci di prodotti potenzialmente spedibili), ma anche che lo stato interno e le metriche sono visibili al team. Il backlog del prodotto e il suo stato attuale non dovrebbero essere alla testa di nessuno, ma visibili all'intero team (e alcuni potrebbero anche discutere con il cliente, se lo desiderano).

Inoltre, il Product Owner dovrebbe essere il proprietario del Product Backlog. È compito del Product Owner scrivere storie di utenti, dare la priorità a quelle storie nel Product Backlog e assicurarsi che le storie siano correttamente completate (verificate e convalidate).

The Product Owner has been in the company for about 2 years and seems to have a clear vision of the product, but he is underpowered by our line manager (who in fact is held responsible for this and other projects).

Il tuo Product Owner deve avere la capacità di parlare per il cliente, altrimenti, questo ruolo è inutile. Avere una visione chiara è importante, ma se non può agire su questa visione e creare e dare priorità alle storie per consentire al software di raggiungere il valore massimo, allora non può adempiere alle responsabilità del Product Owner.

What do you think are disadvantages of this structure we find ourselves into? What could be improved? How would you improve?

Gli svantaggi sono che non stai utilizzando la tua gente. È inutile avere un visionario o un campione se non possono fare nulla per agire sulle loro visioni o obiettivi. Tutto torna alla conclusione: cosa stai pagando queste persone e sono in grado di farlo? Sembra che non siano in grado di adempiere alle loro responsabilità, quindi qualcosa deve essere risolto.

L'unico modo per migliorare è rivalutare i ruoli e assicurarsi che tutti conoscano le loro responsabilità nei confronti del progetto e del prodotto. Dovresti anche concentrarti sulla qualità del prodotto e del processo piuttosto che seguire un processo per lettera. Forse Scrum non è ciò di cui hai bisogno, quindi personalizza il processo per adattarlo al funzionamento della tua squadra e organizzazione.

Other than this, our implementation of Scrum is “by the book”.

Seguendo il mio ultimo pensiero, qualsiasi implementazione del processo "dal libro" mi preoccupa. Scrum è un framework per la gestione dei progetti. Esistono esempi concreti di implementazione e storie di successo, ma quelli sono rivolti a gruppi particolari all'interno di particolari organizzazioni che lavorano su progetti particolari. Scrum è un framework perfetto, purché lo si adatti per soddisfare le esigenze del proprio team all'interno della propria organizzazione che lavora al progetto.

Non mi sembra che tu abbia mescolato i tuoi ruoli Scrum. Sembra che tu abbia un individuo che non è sicuro di quale sia il suo ruolo e sta annullando il ruolo di qualcun altro nel processo di provare a dimostrare il suo valore continuo.

Siediti, come una squadra, e scopri cosa ti serve dal tuo team leader. Hai bisogno che lui sia un guru tecnico? O un guru del dominio? O hai bisogno di qualcuno che sarà un "ninja del collo di bottiglia", rimuovendo ogni problema che rallenta il team di sviluppo? O se non ne hai bisogno, come team Agile maturo, hai bisogno di reintegrarlo nello sviluppo?

Coinvolgilo in questa conversazione. Guarda cosa vuole dalla situazione. Potrebbe essere che preferirebbe tornare allo sviluppo. Potrebbe essere che sta assumendo il ruolo di Product Owner perché non ritiene che l'attuale PO sia abbastanza buono.

La comunicazione onesta è sempre la chiave in queste situazioni.

@Thomas Owens ha identificato i tuoi problemi e fornito soluzioni , ma vorrei aggiungere qualche altro suggerimento.

I 4 membri del team devono impegnarsi su PivotTracker o qualsiasi altra cosa tu preferisca. Se il direttore di linea vuole tutto ciò che ha in testa, questa è la sua pergola, ma il resto di voi deve metterlo per iscritto. Mi siedo in molti incontri e costringo i gestori a rallentare perché sto prendendo appunti. Assumiti la responsabilità di una squadra per organizzarti.

Il Product Owner deve essere in grado di stare in piedi per i clienti e non lasciare che i tecnologi ne traggano vantaggio perché sanno di più sulla programmazione. Il Product Owner potrebbe non conoscere tanto i clienti quanto il tuo line manager. Questa è una vergogna e un'indicazione che non possono fare il loro lavoro e qualcun altro sta riprendendo il gioco. Ci sono situazioni in cui qualcuno ha creato l'applicazione e forse ha avuto un sacco di contatti con clienti / utenti e sta operando con informazioni e presupposti obsoleti. Sette anni fa, la maggior parte degli utenti non era interessata a un'interfaccia di Facebook. I tempi sono cambiati. Il tuo team potrebbe aver bisogno di fare uno sforzo per ottenere le esigenze del cliente dal proprietario del progetto, se lui / lei viene sovrascritto dal gestore di linea per le ragioni sbagliate.

Le parti interessate si lamentano di meno quando si prendono cura dei propri clienti. Rendi tale una priorità e aggira i tuoi dirigenti disfunzionali.

The line manager ... has the Product Backlog in his head and also prioritizes it.

prendi in considerazione la possibilità di stampare un poster di grandi dimensioni e posizionarlo sul muro proprio dove il tuo SCRUmanager può vederlo chiaramente: Manifesto per lo sviluppo del software Agile a metà campo ... mentre gli elementi a sinistra suonano bene in teoria, siamo un'azienda aziendale e non c'è modo di lasciar andare gli articoli sulla destra.