L'approche agile est-elle compatible avec la présence de sous-traitants parmi le personnel?

D'une part, l'approche agile met l'accent sur une équipe soudée qui se tient mutuellement responsable et accepte la propriété collective du projet.

D'autre part, les entreprises utilisent des programmeurs contractuels pour gérer les pics et les creux de financement sans licencier de véritables employés. S'il y a un manque de financement, les entrepreneurs sont les premiers à partir, même s'ils sont des membres pleinement intégrés de l'équipe (et il n'y a pas d'employés). Les entreprises n'aiment également garder les entrepreneurs que pour une durée limitée. Cela est quelque peu atténué par la possibilité que certains sous-traitants puissent être recrutés comme employés réguliers.

Ainsi ma question de savoir s'il y a une contradiction fondamentale d'avoir une équipe agile avec un mélange d'employés et de sous-traitants, et les statuts très différents que cela implique?

EDIT: Les réponses indiquent que je n'ai peut-être pas bien exprimé la tension à laquelle je fais face, alors laissez-moi prendre une autre photo.

Je suis un employé permanent. L'approche agile (au moins telle qu'elle est mise en œuvre ici) m'encourage à voir tous les membres de l'équipe, à la fois les employés permanents et les sous-traitants, comme des membres égaux d'une équipe soudée. L'approche corporative des entrepreneurs m'encourage à les considérer comme des ressources consommables auxquelles nous ne devons pas nous attacher trop.

Je suis curieux de voir comment d'autres ont résolu cette tension.

De nombreuses équipes travaillent uniquement avec des entrepreneurs agiles. Certaines entreprises comme ThoughtWorks sont basées sur l'idée de «vendre» des équipes agiles. Nous sommes une équipe de 10 entrepreneurs travaillant pour une grande compagnie de téléphone, tous issus de la même entreprise contractante.

Là où j'ai vu des problèmes, c'est quand il y avait 2 sociétés de location de corps dans la même équipe ... après un certain temps, l'équipe est devenue problématique (rien à voir avec l'agilité de toute façon).

Oui, cela peut définitivement fonctionner. L'astuce consiste à:

a) Structurez convenablement le contrat - si vous payez pour le travail à la pièce, alors les entrepreneurs ont peu d'intérêt à faire bien plus que de tout mettre ensemble pour consacrer moins d'heures à la «pièce»
b) Vendez à votre direction que chaque centime qu'ils paient va directement dans le produit - il y aura une formation / planification / discussion en cours qui sera sur l'horloge et améliore finalement ledit produit. Ce fut la partie la plus difficile pour moi.
c) Choisissez les bons entrepreneurs - tout ce qui est agile commence à porter ses fruits si vous pouvez continuellement embaucher le même équipage.

Je dirais également que ce type de scénario est grandement aidé par les pratiques agiles - si vous avez des gens qui viennent et quittent l'équipe tout le temps, pouvoir vérifier, déclencher et commencer à coder est encore plus important qu'il ne l'est autrement. .

En réponse à votre montage, il existe différentes paires d'yeux pour regarder la situation. Donc, pour aider à clarifier toute confusion potentielle, cela aide à comprendre quelles perspectives s'appliquent.

Du point de vue de l'équipe de développement, il n'y a aucune différence entre l'entrepreneur et l'employé. Nous sommes tous dans la même équipe et nous avons tous le même objectif. L'ajout et la suppression de membres de l'équipe auront la même interruption, qu'ils soient employés ou sous-traitants. Tous les membres de l'équipe ont les mêmes responsabilités.

Du point de vue de la gestion, il y a une différence. L'entreprise essaie de protéger sa ressource la plus précieuse - les employés. Pour cette raison, l'entreprise préférera garder ses employés plutôt que ses sous-traitants. Si un entrepreneur s'avère inestimable pour l'équipe, l'entreprise tentera probablement de le convertir en employé. Ces types de décisions vivent en dehors du processus de développement quotidien.

Les processus agiles sont davantage concernés par les activités de développement quotidiennes et la gestion de la façon dont vous livrez un produit de qualité. Les processus agiles sont moins concernés par les responsabilités de gestion telles que les décisions d'embauche / licenciement / contrat et plus par la façon dont nous utilisons les ressources disponibles.

Réponse précédente

Ce n'est pas une contradiction fondamentale, mais cela présente des défis de formation. Les processus agiles favorisent un environnement de mentorat très naturel. Essentiellement, les programmeurs du personnel finiraient toujours par être la voix de l'expérience - du moins en ce qui concerne la culture d'entreprise et les détails de la façon dont l'équipe est agile.

Avoir un flux et un reflux réguliers de programmeurs sous contrat va présenter les mêmes défis, que vous soyez agile ou non. Vous devez éduquer l'employé contractuel sur la façon dont vous faites des affaires - cela comprend les processus de développement et la facturation. Vous devez éduquer le programmeur contractuel sur la conception actuelle du système afin qu'il puisse commencer à contribuer le plus rapidement possible. L' espoir est que les employés contractuels sont des études rapides et peuvent commencer à contribuer très rapidement au projet. La formation en cours d'emploi (OJT) fonctionne plutôt bien ici.

Cela revient à dire que vous obtiendrez un premier coup de productivité lorsque vous embaucherez de nouveaux développeurs et entrepreneurs jusqu'à ce qu'ils soient à jour. Plus vous le faites, plus cela impacte négativement les performances de votre équipe. Hense, le vieil adage "Ajouter plus de développeurs à un projet déjà en retard le fait plus tard". (Je crois que c'était Fred Brooks, à moins qu'il ne cite quelqu'un d'autre).

En tant qu'entrepreneur qui se soucie beaucoup d'Agile et de la production d'excellents logiciels, je peux promettre qu'il y a des entrepreneurs qui ne produiront jamais de code slap-dash s'ils peuvent l'aider et qui mettent toujours leur cœur dans tout ce sur quoi ils travaillent.

L'astuce consiste à trouver ces entrepreneurs. Recherchez des preuves qu'ils sont prêts à aller un peu plus loin - blogs, allocutions, contributions open source, ateliers, recommandations, etc. Renseignez-vous sur leur expérience Agile précédente et recherchez des preuves qu'ils aiment leur travail. Dans l'ensemble, nous comprenons que nous sommes des embauches temporaires, et certains d'entre nous aiment cela, en utilisant notre temps entre les contrats pour affiner nos compétences et élargir nos connaissances.

Si vous pouvez trouver de très bons entrepreneurs, ils amélioreront la cohésion de votre équipe plutôt que de la nuire. Gardez-nous en place pendant la durée du projet, puis laissez-nous partir alors que l'équipe ralentit. Nous prendrons des vacances et serons là pour le coup d'envoi du prochain projet, si vous avez besoin de nous.

Vous avez parfaitement raison lorsque vous dites que les contrats temporaires affectent négativement l'équipe. En fait, la vitesse est liée à une configuration d'équipe particulière. Toute nouvelle arrivée ou départ invalide le calcul de vitesse que vous avez fait pendant des mois.

Cependant, cela peut fonctionner lorsque les entrepreneurs ne sont pas temporaires. J'ai travaillé sur un projet où l'équipe était constituée à 95% d'entrepreneurs avec un ou deux employés. Les entrepreneurs étaient là pendant 2 ou 3 ans jusqu'à la publication du projet. Après la libération, les employés effectuent la maintenance. Cette façon de travailler est très courante.

Résumer:

Agile, et surtout Scrum offrira tous ses avantages au sein d'une équipe stable .