Penso che altri abbiano già fornito buone risposte, ma aggiungerò la mia solo perché penso che la tua squadra sia appena passata a Scrum e ora voi ragazzi siete in una posizione molto simile a quella che avevamo quando abbiamo iniziato.
Prima di tutto, la nostra introduzione ad Agile e più specificamente Scrum non è stata molto semplice. Fondamentalmente la direzione è scesa e ha detto, da questo giorno in poi dovrai fare Scrum e questo è un processo che seguirai tutti. Questo per quanto riguarda People over Process .
Il processo che inizialmente abbiamo seguito (alla cieca, potrei aggiungere) è finito molto simile a come hai descritto. Le persone ricevono compiti assegnati, tutti vengono prenotati e tutti torniamo ai nostri banchi e ci colleghiamo. Quindi abbiamo una noiosa riunione stand-up ogni giorno.
La chiave per rendersi conto è che Agile, e Scrum inclusi, riguarda in realtà le persone. Quando il team inizia la pianificazione dell'iterazione, non lasciare che il tuo Scrum master (che è probabilmente il tuo manager) ti assegni ore, storie e attività. Dipende completamente dalla squadra. Penso che per molte persone questo sia un concetto molto difficile da superare perché per anni prima sarebbero venuti al lavoro e avrebbero avuto un capo (manager, responsabile tecnico ...) che semplicemente avrebbe assegnato il lavoro. Si immergono in Scrum ma tutti (incluso lo stesso Scrum Master) continuano a funzionare nella stessa modalità.
Un giorno ti stancherai di questo, quindi inizierai a leggere libri, blog e continuerai a fare domande come questa sullo scambio di stack. La realizzazione che otterrai è che tu come sviluppatore e i tuoi compagni di squadra dovresti essere la forza trainante dietro l'impegno nelle storie e nell'assegnare compiti. Se pensate che trarrete beneficio dalla programmazione di coppia, create in ogni caso un 2 compiti per ciascuno degli ingegneri e assegnate entrambe le ore. L'unica cosa che Scrum Master dovrebbe fare è misurare la velocità rispetto alle storie completate che hai fornito come TEAM nella precedente iterazione.
Anche un'altra cosa che mi infastidisce è il modo in cui viene detto alle persone che la loro capacità è SEMPRE il 75% delle ore totali, quindi è quello che si impegnano e quindi per l'intera durata dell'iterazione si lamentano che a) non possono aiutarti o b) non possono fare la cosa giusta perché sono state assegnate troppe ore. Alla gente non dovrebbe essere detto quante ore impegnarsi e certamente dovrebbero respingere se lo Scrum Master sta tentando di tirare qualcosa del genere! Tutti dovrebbero impegnarsi esattamente in ciò che si sentono a proprio agio. Ad esempio, sono a capo di un team e spesso finirei in una discussione casuale non pianificata sul progetto o aiutando qualcuno con il codice o con la risoluzione di problemi strani, quindi la mia capacità non è mai superiore al 50%.
Il nostro team ha impiegato 4 cicli di rilascio per imparare a non fare le cose che ho appena menzionato e anche se siamo decisamente migliorati, se chiedi agli esperti non siamo nemmeno mezzo agili. Quindi ancora molto da imparare.
Aggiornamento 1: Risposta al commento di Cliff
Beh, hai offerto le tue orecchie, quindi eccolo ...
Hai ragione, il cambiamento culturale è la chiave, ma questo spostamento non deve avvenire a livello esecutivo. Il tuo manager di gruppo può cambiare la cultura all'interno del tuo team e isolarti da BS aziendali che deve affrontare. Quello che stai descrivendo è stato ESATTAMENTE di noi dal 2007 al 2010. Il nostro team (e anche altri team) ha fallito il rilascio dopo il rilascio. In una delle versioni che utilizzano il "processo per essere agili" del management, riusciamo a far produrre a 9 persone il lavoro che normalmente verrebbe svolto da una sola persona e ci è voluto il doppio del tempo. Ho avuto così tanto tempo libero che ho persino aggiornato il mio curriculum.
Poi, ho avuto una conversazione con il mio capo e gli ho spiegato tutte queste cose quanto agile riguarda le persone e che se vuoi che ci prendiamo cura del prodotto, prendiamo decisioni che influenzano il modo in cui lavoriamo e consegniamo il prodotto. Penso che abbia deciso di farne un esperimento, ha fatto ogni singolo cambiamento che ... beh, soprattutto me stesso, ma parlo molto con il resto della squadra, quindi con una capacità del 50% :) ... proposto. È possibile che abbia pensato che se apporta tutti i cambiamenti che stiamo chiedendo e continuiamo a fallire, tornerà con un vittorioso "Te l'avevo detto".
Quindi negli ultimi 12 mesi, abbiamo eliminato così tanto "stupido" che non è nemmeno divertente. Le nostre riunioni stand-up in realtà hanno senso ora perché lavoriamo insieme, non in modo isolato. Abbiamo ancora la proprietà (almeno per ora) di parti specifiche del prodotto, ma incrociamo anche molto frequentemente nel codice degli altri. Facciamo costantemente revisioni del codice in modo che non solo i membri del team imparino altro codice, ma imparino anche tecniche di codifica e progettazione migliori. Abbiamo diviso il gruppo monolitico e gigantesco "agile" in 3 diversi team, quindi la pianificazione e le altre riunioni sono molto più brevi e le persone si preoccupano davvero di loro perché non si siedono intorno e ascoltano cose che non gli interessano. IO' abbiamo visto serate in cui 4 su 5 dei nostri ragazzi (uno dei team) sarebbero stati online alle 23:00 di notte e nessuno ci ha effettivamente detto che dobbiamo lavorare sodo o ci ha mai costretti a lavorare per oltre 40 ore. Le persone a cui non è importato meno di un anno e mezzo fa, all'improvviso sono impegnate ed entusiaste del lavoro che stanno facendo. E tutto ciò che è stato necessario per il nostro manager è stato dire: "voi ragazzi decidete cosa è giusto e fate quello che dovete fare e terrò il BS aziendale fuori dalla squadra il più possibile."
È iniziato come un esperimento (il mio sospetto, non me lo ha mai detto), ma ora il nostro gruppo sta prendendo a calci in culo rispetto ad altri gruppi di sviluppo nel dipartimento e abbiamo anche altri sviluppatori che stanno ora cercando di venire e unirsi a noi.
Il più grande ostacolo per noi da quando è avvenuto questo cambiamento (e ancora oggi è un problema) è stato il fatto che gli ingegneri in un normale ambiente aziendale sono come topi sperimentali in una gabbia. Anche quando il tuo manager decide di diventare veramente "agile" e rimuove la gabbia, tutti sono stati in quella gabbia per così tanto tempo, non si rendono nemmeno conto di essere liberi. Quindi, anche con tutta la libertà, continuano a comportarsi come se fossero ancora vincolati. Penso che ciò che aiuterebbe sarebbe avere almeno poche persone nella squadra (come te), che vanno oltre i confini del gruppo e cercano modi migliori di fare le cose. Quindi torna in quel gruppo e mescola un po '.
Nel tuo caso, forse la programmazione abbinata non è una soluzione se stai cercando un'altra forza esterna per entrare nel team e dire loro come lavorare. Invece, buttare via le regole, sedersi con loro, senza gestione, e chiedere loro cosa vogliono fare? Cosa li renderà felici? Produttivo? Individua i maggiori problemi e chiedi a THE TEAM quale soluzione dovrebbe essere.