Scrum Teams Vs Human Resources

Recentemente estive em Redmond no evento ALM Summit, onde na agenda do evento tinhamos o "Birds of Feather", uma espécie de mesa redonda com os mais diversos assuntos. E um deles, que acabei participando tinha o tema desta postagem como assunto (SkyDrive com fotos do BOF).

Inicialmente, o assunto nos remete a questão do perfil do time, especialmente no nível de qualificação dos membros e da especialização dos mesmos. Não existe uma resposta certa, mas no concenso geral, times ágeis necessitam versatilidade, pois não podemos depender de uma determinada pessoa para a realização de tarefas, criando gargalos e atrasos. Outro ponto é, como a propriedade é coletiva e exige extrema interação entre os membros, o melhor é que tenham níveis próximos de qualificação para não criar atrito ou subdivisões internas de tarefas ("isso é do fulano pois só ele sabe resolver").

Outro tema interessante é referente a remuneração e avaliação de desempenho, sendo que este assunto levou a um conjunto enorme de divergências entre os participantes. Em linhas gerais, duas linhas de ação:
 - Comunismo: Todo mundo no time (Devs, é discutível a remuneração de POs e SMs) ganha a mesma coisa e a avaliação deles é apenas um reflexo do progresso do time. Em um modelo de aplicação, eles são donos de um produto e o sucesso do produto (em termos de lucro do mesmo) é revertido em remuneração equanime entre os participantes. Logicamente, em regimes trabalhistas complexos como o brasileiro é difícil aplicar este modelo, exceção nos casos em que cada membro é representado por sua empresa (o famoso PJ), mesmo assim, o contrato de serviço é de difícil concepção.
 - Recursos Humanos: Não existe divisão equanime no grupo, sendo que a área de recursos humanos é um pilar no apoio da avaliação e remuneração dos membros. A área por sua vez deve ser apoiada por alguém para que saiba como está o desempenho individual dos membros, até porque a metodologia não fortalece muito o aspecto de métricas individuais. Sugeri até mesmo que o Scrum Master fosse este cara, pois além de apoiar na adaptação do time as práticas, teriamos o mesmo como um "olheiro" dos trabalhos do time, observando a interação e questões individuais.

O tema de remuneração está intimamente ligado a visão que temos dos papéis e responsabilidades dos indivíduos nos times, assim como, em ambientes que estão migrando do modelo clássico de gestão para práticas como o Scrum, tem a necessidade de entender que o PO não é o gestor das pessoas, mas sim, um membro do time cuja responsabilidade é promover o crescimento sustentável do produto. É muito mais fácil imaginar o Analista de Negócio como PO do que o Gerente de Projeto.

Outro assunto que eu me lembro foi a questão da contratação, onde discutimos se isto seria uma responsabilidade do time, ou alguém teria esta competência, como um departamento de RH. Não tenho uma posição clara sobre o assunto, acho que se o time é orientado por resultados, os mesmos podem escolher qual membro trazer para agregar mais, caso contrário, corremos o risco do time trazer gente que não agrega apenas por que o cara é um camarada de alguém. Mesmo com times de alto comprometimento, concordo com o que foi discutido que em grandes empresas, precisamos olhar outros aspectos como reaproveitamento do profissional em outros times, alinhamento com a cultura organizacional e plano de carreira. Citei até o caso da Valve que dava esta responsabilidade para cada pessoa da empresa, e essa era a coisa mais importante que você poderia fazer, trazer bons profissionais para a empresa.

Acho que diferentes perfis de empresa e de produtos sucitam diferentes abordagens sobre a coordenação de esforços. Modelos como o Scaled Agile Framework proposto por Dean Leffingwell são mais aderentes em times grandes e complexos, ou mesmo organizações com muitos produtos, do que o Scrum, que é leve e simples para aplicar em Startups com produtos simples, ou empresas com um único produto.

Comentários