L'approccio agile è compatibile con la presenza di appaltatori nel personale?

Da un lato, l'approccio agile sottolinea una squadra affiatata che si ritiene responsabile e accetta la proprietà collettiva del progetto.

D'altra parte, le aziende utilizzano programmatori a contratto in modo da poter gestire i picchi e le valli dei finanziamenti senza licenziare i dipendenti effettivi. In caso di carenza di finanziamenti, gli appaltatori sono i primi ad andare, anche se sono membri del team completamente integrati (e non ci sono dipendenti). Alle aziende piace anche mantenere gli appaltatori in giro per un periodo di tempo limitato. Ciò è in qualche modo mitigato dalla possibilità che alcuni appaltatori possano essere assunti come dipendenti regolari.

Quindi la mia domanda se ci sia una contraddizione fondamentale di avere un team agile con un mix di dipendenti e appaltatori, e gli stati ampiamente diversi che comporta?

EDIT: Le risposte indicano che forse non ho espresso la tensione che sto affrontando bene, quindi lasciami fare un altro tentativo.

Sono un dipendente a tempo indeterminato. L'approccio agile (almeno come implementato qui) mi incoraggia a vedere tutti i membri del team, sia dipendenti permanenti che appaltatori, come membri uguali di un team coeso. L'approccio aziendale agli appaltatori mi incoraggia a vederli come risorse sacrificabili a cui non dovremmo essere eccessivamente attaccati.

Sono curioso di sapere come altri hanno risolto questa tensione.

Molte squadre lavorano solo con imprenditori agili. Alcune aziende come ThoughtWorks si basano sull'idea di "vendere" team agili. Siamo un team di 10 appaltatori che lavorano per una grande compagnia telefonica, tutti della stessa società appaltatrice.

Il punto in cui ho visto i problemi è stato quando c'erano 2 compagnie di noleggio di body nella stessa squadra ... dopo un po 'la squadra è diventata problematica (niente a che vedere con l'agile).

Sì, sicuramente può funzionare. Il trucco è:

a) Strutturare correttamente l'accordo contrattuale - se si paga per lavoro a pezzo, gli appaltatori hanno poco interesse a fare molto di più che a schiaffeggiare le cose per mettere meno ore nel "pezzo"
b) Vendere alla propria direzione che non tutti i centesimi per cui pagano entra direttamente nel prodotto - ci sarà un po 'di formazione / pianificazione / discussione in corso che sarà ininterrotta e alla fine migliorerà tale prodotto. Questa è stata la parte più difficile per me.
c) Scegli gli appaltatori giusti: l'intera cosa agile inizia a ripagare se puoi assumere continuamente lo stesso equipaggio.

In generale, direi anche che questo tipo di scenario è notevolmente aiutato da pratiche agili: se hai persone che vanno e vengono sempre dal team, essere in grado di controllare, accendere e iniziare a scrivere codice è ancora più importante di quanto non sia altrimenti .

In risposta alla tua modifica, ci sono diversi occhi per guardare la situazione. Quindi, per aiutare a chiarire ogni potenziale confusione, aiuta a capire quali prospettive si applicano.

Dal punto di vista del team di sviluppo, non vi è alcuna differenza tra appaltatore e dipendente. Siamo tutti nella stessa squadra e tutti abbiamo lo stesso obiettivo. L'aggiunta e la rimozione di membri del team avranno la stessa interruzione, siano essi dipendenti o appaltatori. Tutti i membri del team hanno le stesse responsabilità.

Dal punto di vista gestionale, c'è una differenza. La società sta cercando di proteggere la sua risorsa più preziosa: i dipendenti. Per questo motivo, la società preferirà mantenere i propri dipendenti rispetto ai suoi appaltatori. Se un appaltatore si rivela prezioso per il team, la società probabilmente tenterà di convertire l'appaltatore in dipendente. Questi tipi di decisioni vivono al di fuori del processo di sviluppo quotidiano.

I processi agili si occupano maggiormente delle attività di sviluppo quotidiane e della gestione della consegna di un prodotto di qualità. I processi agili riguardano meno le responsabilità di gestione come le decisioni di assunzione / incendio / contratto e più il modo in cui utilizziamo le risorse a portata di mano.

Risposta precedente

Non è una contraddizione fondamentale, ma presenta alcune sfide di allenamento. I processi agili favoriscono un ambiente di mentoring molto naturale. In sostanza, i programmatori del personale finiscono per essere sempre la voce dell'esperienza - almeno per quanto riguarda la cultura aziendale e le specifiche di come agile il team.

Avere un flusso e riflusso regolare di programmatori a contratto presenterà le stesse sfide, agili o meno. Devi educare il dipendente a contratto su come fai affari - questo include i processi di sviluppo e la fatturazione. Devi educare il programmatore a contratto sull'attuale progettazione del sistema in modo che possano iniziare a contribuire il più rapidamente possibile. La speranza è che i dipendenti a contratto siano studi rapidi e possano iniziare a contribuire al progetto molto rapidamente. On-the-Job-Training (OJT) funziona abbastanza bene qui.

Ciò che si riduce è che subirai un colpo di produttività iniziale quando assumerai nuovi sviluppatori e appaltatori fino a quando non saranno pronti. Più lo fai, più influisce negativamente sulle prestazioni della tua squadra. Hense, il vecchio adagio "L'aggiunta di più sviluppatori a un progetto già in ritardo lo rende più tardi". (Credo che fosse Fred Brooks, a meno che non stesse citando qualcun altro).

Come appaltatore che si preoccupa moltissimo di Agile e produce software eccellente, posso promettere che ci sono appaltatori là fuori che non produrranno mai codice schiaffo se possono aiutarlo e mettono sempre il cuore in tutto ciò su cui stanno lavorando.

Il trucco è trovare quegli appaltatori. Cerca le prove che sono pronti ad andare oltre - blog, impegni vocali, contributi open source, workshop, raccomandazioni, ecc. Chiedi informazioni sulla loro precedente esperienza Agile e cerca prove che amano il loro lavoro. In linea di massima comprendiamo che siamo assunzioni temporanee e ad alcuni di noi piace questo, usando il nostro tempo tra i contratti per affinare le nostre competenze ed espandere le nostre conoscenze.

Se riesci a trovare appaltatori davvero fantastici, miglioreranno la coesione della tua squadra anziché toglierla. Tienici in posizione per tutta la durata del progetto, quindi lasciaci andare mentre il team scende. Faremo una vacanza e saremo in giro per il calcio d'inizio del prossimo progetto, se hai bisogno di noi.

Hai perfettamente ragione quando hai detto che i contratti temporanei influiscono negativamente sulla squadra. In effetti, la velocità è legata a una particolare configurazione del team. Qualsiasi nuovo arrivo o partenza invalida il calcolo della velocità che hai fatto per mesi.

Tuttavia, può funzionare quando gli appaltatori non sono temporanei. Ho lavorato su un progetto in cui il team era composto da collaboratori del 95% con uno o due dipendenti. Gli appaltatori erano lì per 2 o 3 anni fino al rilascio del progetto. Dopo il rilascio, i dipendenti eseguono la manutenzione. Questo modo di lavorare è molto comune.

Riassumere:

Agile e soprattutto Scrum fornirà tutti i suoi vantaggi in un team stabile .