Un maestro di mischia può rimproverare la sua squadra?

Uno Scrum master non rimprovera. Lui o lei vede problemi e facilita la squadra per affrontarli.
Se la squadra lotta, è compito suo articolare i problemi e cercare di indurre il team a fare un'analisi delle cause alla radice su questi problemi.
Per approfondire il tuo esempio: passare il tempo sui siti di social network non è una causa principale. Se la squadra sta spendendo troppo tempo su quei siti (e questo è ancora un "se"), probabilmente c'è una ragione per questo. Forse hanno bisogno di un sollievo, forse il loro lavoro è troppo noioso perché non riescono a farsi carico di architettare la soluzione, forse ...
Il primo passo è parlare con la squadra. Lascia che capiscano cosa non va.

Certamente possono. Non tutto ciò che fa una squadra è perfetto o accettabile in tutti i sensi.

I maestri di mischia dovrebbero abilitare una cultura della comunicazione aperta, e i maestri di mischia ... fanno parte del team! Quindi, perché dovrebbero not segnalare problemi con il team?

Alcuni team sono eccellenti, auto-organizzanti, laboriosi ed efficaci. Alcune altre squadre sono mediocri, incapaci di organizzazione, pigri o inefficaci. Perché non dovrebbe essere così?

Detto questo, c'è una grande differenza tra avere una cultura della colpa e segnalare problemi evidenti con il team in modo che possano essere affrontati.

Inoltre, uno scrum master è un facilitatore, o un aiutante, un ruolo, non un leader in alcun senso. Quindi non hanno alcun diritto particolare di rimproverare letteralmente le persone. Possono certamente influenzare la squadra e segnalare problemi o persino chiamare le persone se necessario.

In sintesi, questo è ciò che vogliamo:

• Apri comunicazione
• Una squadra che include lo scrum-master
• Quando sorgono problemi, sono chiaramente comunicati e indirizzati
• Quando le persone si comportano chiaramente male, l'atteggiamento cattivo (mai la persona!) è rivolto apertamente e in modo equo
• Persone che accettano responsabilità

Questo è ciò che non vogliamo:

• Le persone mantengono segreti o coltivano il risentimento, mentre fingono di essere felici nel team
• Scrum master vs. atteggiamento di squadra
• Puntamento del dito
• Cultura della colpa / della colpa
• Le persone riducono la responsabilità

Finché l'SM punta al primo ed evita quest'ultimo, non c'è alcun problema a comunicare negativamente con il resto della squadra.

Il maestro di misericordia difende la squadra dal management e dal cliente. Il proprietario del prodotto consiglia il cliente al team. Il manager difende l'azienda dai singoli membri del team.

Questa è una semplificazione eccessiva perché i buoni leader cercano di bilanciare tutte le preoccupazioni, ma quelle sono le loro principali responsabilità. Sono suddivisi in persone separate per semplificare la separazione dei conflitti di interesse.

Quindi i problemi di produttività personale, come l'eccessivo uso del web, dovrebbero essere gestiti dal gestore. Tuttavia, i problemi della produttività del gruppo che non sono un risultato diretto delle prestazioni personali possono certamente essere risolti dal mischia.

Prendi il tuo esempio di perdere tempo su questioni meno importanti. Un maestro di mischia può scoprire perché i membri del team sentono di aver bisogno di dedicare del tempo a quelle cose e sostengono che la squadra risolva il problema. Ecco perché abbiamo retrospettive. Forse il tempo ha davvero bisogno di essere ritagliato per quelle cose. Forse altri gruppi come la gestione del prodotto stanno facendo pressione per lavorare su compiti che non rientrano nel piano e tale pressione deve essere rimossa. Forse i membri del team semplicemente non sono consapevoli di quanto tempo passa in quelle attività. Forse le priorità non vengono comunicate chiaramente. Forse la tua squadra si impegna a lavorare troppo, quindi i membri del team cercano di finire tutto invece di concentrarsi sulle massime priorità. Questi sono i tipi di cose che un mischia dovrebbe risolvere.

Il rimprovero è una parola molto strong. E non è una questione di puoi farlo. Ovviamente puoi rimproverare chiunque tu voglia. Ma dovresti farlo? Trovo che quando il management / leadership prende questo tipo di approccio, generalmente demoralizza la squadra e non migliora veramente nulla. Quindi dimmi che non posso essere su P.SE durante l'orario di lavoro. Come si tradurrebbe in ciò dandoti un output più elevato?

Come altri hanno già menzionato, i risultati bassi e le persone che navigano su Internet sono un effetto. La tua domanda è come aggiustare questo sintomo, ma è necessario approfondire la causa principale.

E prima che tu guardi troppo in profondità (e il motivo per cui voglio aggiungere i miei 2 centesimi qui) tu (e forse qualcuno della tua gestione) dovresti familiarizzare con le idee fondamentali dietro Agile e le motivazioni per avere quelle idee nel primo posto.

In sostanza, Agile sostiene una forma di controllo decentralizzata, in cui la direzione imposta una direzione generale ma lascia tutto il resto al team. Decisioni come il modo in cui forniremo, quanto tempo impiegherà, quale tecnologia usare, chi lavorerà su cosa. La squadra dovrebbe decidere da sola. La ragione è che le persone che fanno il lavoro hanno davvero la maggior conoscenza su come fare quel lavoro e quando si tratta di orari, se il mio capo mi dice che ho 5 giorni per finire un compito, torno alla mia scrivania e continua a lavorare come al solito. Se ci vogliono 10 giorni, deve essere una cattiva pianificazione sulla parte del mio capo. Se ci vogliono 4 giorni, passerò l'altro giorno a fare chissà cosa. Mentre quando i tuoi sviluppatori prendono le decisioni, e lo sviluppatore è colui che dice, non dovrebbero impiegarmi più di 5 giorni, che lo sviluppatore ha una maggiore pressione personale per esprimere la sua parola, ma funziona solo se quei 5 giorni non sono spinto giù per la gola dall'alto.

Mentre continui a fare i tuoi sprint, parte del tuo processo dovrebbe essere la ricerca continua di miglioramenti, che sono le retrospettive. E ancora, il tutto è completamente focalizzato sugli sviluppatori. "Ragazzi, discutiamo su cosa ti ha rallentato e cosa ti ha frustrato." Identifica le più grandi frustrazioni ed elimina quelle prima e ripeti. Le persone si sentiranno più stimolate e motivate a consegnare se vedono che la struttura aziendale è progettata per aiutarli e semplificare la loro vita.

Se lo fai bene, tutta la tua squadra dovrebbe entrare nella mentalità (ci vorrà un po 'di tempo ma non per tutto il tempo che penseresti, l'ho visto fare in 3 mesi) di come ci troviamo insieme. Controlliamo il nostro programma. Vogliamo costruire un grande prodotto. La chiave è "noi". Quando arrivi a quel punto, a) se qualcuno non porta il proprio peso, i suoi stessi compagni di squadra lo chiameranno e chiedono, Bob "noi" stiamo aspettando che tu finisca questo, come va? e b) le persone si sentiranno più forti nel consegnare perché i loro compagni di squadra, non la direzione, dipendono da loro. Quindi quando arrivi a quel punto, non ci sarà assolutamente bisogno di rimproverare nessuno.

Questa risposta è basata parzialmente su Agile, in parte sulle teorie di gestione che insegnano nella scuola MBA (sì, sono tornato a scuola per prendere un master nel lato oscuro) e parzialmente sulla mia esperienza nella mia precedente azienda. Ho avuto un grande capo che mi ha permesso di provare ogni genere di cose con il nostro team. Abbiamo implementato molte delle idee che i "veri" agili sostenitori, e anche se non ci siamo riusciti completamente (non ci sono state periodicamente retrospettive e test unitari sono stati significativamente carenti) ma in termini di attitudini, motivazioni ed etica generale, il nostro team davvero ha girato intorno a 180 gradi in 3 mesi. E mentre lavoravamo sodo, e spesso ci collegavamo di notte o in altri momenti casuali solo per completare le cose qua e là, a) nessuno ci chiedeva mai o ci costringeva a lavorare ore extra eb) eravamo probabilmente il team di sviluppo più felice del intera organizzazione perché un sacco di BS aziendali si sono fermate al nostro manager.

Non essere troppo schizzinoso, ma i doveri dello Scrum Master riguardano tutto Scrum e non dare promozioni, controllare i fogli di presenza, tenere traccia dei giorni di ferie ecc. Ciò non significa che la stessa persona non possa essere la SM e il responsabile di reparto.

Non conosco il rimprovero, ma i ruoli dello Scrum Master riguardano: assicurarsi che Scrum sia fatto correttamente, bilanciare il carico di lavoro con le aspettative degli stakeholder, aiutare la squadra ad esibirsi ad un livello superiore, ecc. Alcuni Scrum Masters vengono da una posizione di lead / manager di team, quindi potrebbero esserci ulteriori compiti di gestione in cui la SM svolge un ruolo diverso come fare una valutazione annuale (non molto simile a Scrim).

L'SM è obbligato a far sapere a una squadra che c'è un problema. I team devono essere ritenuti responsabili ed è molto difficile per un SM dire a tutti al di fuori del team che stanno lavorando a pieno regime quando non lo sono. Potrebbe non essere accurato e / o corretto, ma se un manager esterno vede la squadra rallentare, sarà molto più difficile per l'SM difendere la squadra quando non riesce a consegnare.

Se è una persona in particolare che la squadra non è riuscita a motivare, quella persona potrebbe aver bisogno di un rimprovero non da parte dell'SM ma di un altro manager che potrebbe di fatto essere la stessa persona.