A abordagem ágil é compatível com ter contratados na equipe?

Por um lado, a abordagem ágil enfatiza uma equipe unida que se responsabiliza e aceita a propriedade coletiva do projeto.

Por outro lado, as empresas usam programadores contratados para gerenciar os altos e baixos do financiamento sem demitir funcionários reais. Se houver um déficit de financiamento, os contratados serão os primeiros a sair, mesmo se forem membros totalmente integrados da equipe (e não houver funcionários). As empresas também gostam de manter os contratados por um período limitado de tempo. Isso é atenuado pela possibilidade de alguns contratados serem contratados como funcionários regulares.

Assim, minha pergunta sobre se existe uma contradição fundamental de ter uma equipe ágil com uma mistura de funcionários e contratados e os status muito diferentes que isso implica?

EDIT: As respostas estão indicando que eu posso não ter expressado bem a tensão que estou enfrentando, então deixe-me tentar outra vez.

Eu sou um funcionário permanente. A abordagem ágil (pelo menos como implementada aqui) me incentiva a ver todos os membros da equipe, funcionários permanentes e contratados, como membros iguais de uma equipe coesa. A abordagem corporativa dos contratados me incentiva a vê-los como recursos dispensáveis ​​aos quais não devemos nos apegar demais.

Estou curioso para saber como outros resolveram essa tensão.

Muitas equipes trabalham apenas com prestadores de serviços ágeis. Algumas empresas como a ThoughtWorks são baseadas na idéia de "vender" equipes ágeis. Somos uma equipe de 10 contratados que trabalham para uma grande empresa de telecomunicações, todos da mesma empresa contratante.

O ponto em que vi problemas foi quando havia duas empresas de aluguel de corpos na mesma equipe ... depois de um tempo, a equipe se tornou problemática (nada a ver com o ágil).

Sim, isso definitivamente pode funcionar. O truque é:

a) Estruture o contrato adequadamente - se você está pagando por peças por peça, os contratados têm pouco interesse em fazer muito mais do que colocar as coisas em conjunto para dedicar menos horas à "peça"
b) Vender sua gerência que nem todo centavo pago vai diretamente para o produto - haverá algum treinamento / planejamento / discussão em andamento que estará no relógio e, finalmente, melhorará o produto. Essa foi a parte mais difícil para mim.
c) Escolha os contratados certos - a coisa toda ágil começará a valer a pena se você puder contratar continuamente a mesma equipe.

Eu também geralmente sustentaria que esse tipo de cenário é muito ajudado por práticas ágeis - se você tem pessoas entrando e saindo da equipe o tempo todo, sendo capaz de verificar, iniciar e iniciar a codificação é ainda mais importante do que seria .

Em resposta à sua edição, existem diferentes conjuntos de olhos para analisar a situação. Portanto, para ajudar a esclarecer qualquer confusão em potencial, é útil entender quais perspectivas se aplicam.

Da perspectiva da equipe de desenvolvimento, não há diferença entre contratado e funcionário. Estamos todos no mesmo time e todos temos o mesmo objetivo. Adicionar e remover membros da equipe terá a mesma interrupção, sejam eles funcionários ou contratados. Todos os membros da equipe têm as mesmas responsabilidades.

Do ponto de vista gerencial, há uma diferença. A empresa está tentando proteger seu recurso mais precioso - os funcionários. Por esse motivo, a empresa preferirá manter seus funcionários em detrimento de seus contratados. Se um contratado se mostrar inestimável para a equipe, a empresa provavelmente tentará converter o contratado em funcionário. Esses tipos de decisões vivem fora do processo de desenvolvimento do dia a dia.

Os processos ágeis estão mais preocupados com as atividades de desenvolvimento do dia a dia e com o gerenciamento de como você entrega um produto de qualidade. Os processos ágeis estão menos preocupados com as responsabilidades de gerenciamento, como decisões de contratação / incêndio / contrato, e mais preocupados com a maneira como usamos os recursos disponíveis.

Resposta anterior

Não é uma contradição fundamental, mas apresenta alguns desafios de treinamento. Os processos ágeis promovem um ambiente de mentoria muito natural. Essencialmente, os programadores da equipe acabariam sempre sendo a voz da experiência - pelo menos no que diz respeito à cultura corporativa e às especificidades de como a equipe é ágil.

Ter um fluxo e refluxo regulares de programadores contratados apresentará os mesmos desafios, seja você ágil ou não. Você precisa educar o funcionário contratado sobre como você faz negócios - isso inclui processos de desenvolvimento e cobrança. Você precisa instruir o programador do contrato sobre o design atual do sistema para que ele possa começar a contribuir o mais rápido possível. A esperança é que os funcionários contratados façam estudos rápidos e possam começar a contribuir com o projeto rapidamente. O treinamento no trabalho (OJT) funciona muito bem aqui.

O que se resume é que você terá um impacto inicial na produtividade ao contratar novos desenvolvedores e contratados até que eles atinjam a velocidade. Quanto mais você faz, mais isso afeta negativamente o desempenho da sua equipe. Hense, o velho ditado "Adicionando mais desenvolvedores a um projeto já atrasado chega mais tarde". (Eu acredito que era Fred Brooks, a menos que ele estivesse citando outra pessoa).

Como um contratado que se preocupa muito com o Agile e produz um software excelente, posso prometer que existem contratados por aí que nunca produzirão código slap-dash se puderem ajudá-lo, e sempre colocarão seu coração no que estão trabalhando.

O truque é encontrar esses contratantes. Procure evidências de que eles estão preparados para ir um pouco mais além - blogs, palestras, contribuições de código aberto, workshops, recomendações etc. Pergunte sobre a experiência anterior em Agile e procure evidências de que eles amam seu trabalho. Em geral, entendemos que somos contratados temporariamente, e alguns de nós assim, usando nosso tempo entre contratos para aprimorar nossas habilidades e expandir nosso conhecimento.

Se você puder encontrar ótimos contratados, eles aumentarão a coesão da sua equipe em vez de prejudicá-la. Mantenha-nos no lugar durante todo o projeto e, em seguida, deixe-nos ir enquanto a equipe diminui. Tiraremos férias e estaremos prontos para o início do próximo projeto, se você precisar.

Você está perfeitamente certo quando disse que contratos temporários afetam negativamente a equipe. De fato, a velocidade está vinculada a uma configuração de equipe específica. Qualquer nova chegada ou partida invalida o cálculo de velocidade que você fez durante meses.

No entanto, ele pode funcionar quando os contratados não são temporários. Trabalhei no projeto em que a equipe era formada por 95% de contratados com um ou dois funcionários. Os contratantes estavam lá por 2 ou 3 anos até o lançamento do projeto. Após a liberação, os funcionários fazem a manutenção. Essa maneira de trabalhar é muito comum.

Para resumir:

O Agile e, especialmente, o Scrum fornecerão todos os seus benefícios em uma equipe estável .