Si noti che nella maggior parte degli articoli, la dedizione significa che la persona è impegnata per il successo del progetto, non che il team è dedicato in senso manageriale.
Esempio dall'articolo a cui sei collegato, enfasi il mio:
[...] are dedicated to continuously improving their ability to deliver software
Un altro esempio, da I team di successo sono piccoli e dedicati , il mio enfasi:
And it gets worse: dedicated team members aren’t so understanding of these “fence straddlers”. Frustration at their lack of commitment quickly escalates into open conflict and, when no remedy is found, casting that person out of the team.
La dedizione al successo del team è davvero un fattore critico di successo. Se alcuni membri del team non ritengono di dover fare tutto ciò di cui hanno bisogno per il successo del progetto, non sono dei buoni candidati per i team agili.
Ad esempio, uno dei comportamenti attesi da ciascun membro in un team agile è quello di svolgere compiti più ampi delle competenze fondamentali della persona: uno sviluppatore Python dovrebbe essere in grado di andare e correggere una query SQL se necessario, e uno sviluppatore JavaScript può esplorare e correggere il codice Python, se necessario.
In questa situazione, una persona non dedicata si aspetta semplicemente che gli altri facciano i loro lavori. Uno sviluppatore Python darà la colpa al DBA per essere in ritardo, e uno sviluppatore JavaScript incolperà gli sviluppatori lato server. Con questo tipo di relazioni tra i compagni di squadra, è probabile che qualsiasi forma di agile fallirà.
La dedizione al tipo di gestione , d'altra parte, può essere cruciale o meno, a seconda delle circostanze. Se alcuni membri non sanno quanto spenderanno lavorando al progetto per il prossimo sprint, potrebbe diventare difficile gestire il progetto.
Dall'articolo a cui sei collegato:
Each team member is fully dedicated to the team and works intensely during a responsible workweek.
D'altra parte, nulla costringe una persona a lavorare su un singolo progetto. Alcune persone possono avere competenze molto specifiche e molto importanti, e diversi progetti alla volta possono beneficiare di tali competenze. Ad esempio, qualcuno che è molto abile in termini di sicurezza o ottimizzazione potrebbe non essere necessariamente necessario a tempo pieno su un progetto.