Equipes multifuncionais x auto-organizadas x recursos x componentes no Agile

Tradicionalmente, um projeto é organizado em torno de  equipes de componentes  (ou seja, UX, Dev, Business, Testador e…), qualquer versão que exija uma variedade de conhecimentos de componentes precisará envolver várias equipes de componentes. Normalmente, equipes diferentes terão conjuntos de prioridades diferentes, o que inevitavelmente leva a gargalos no ciclo de lançamento do produto.

De acordo com a Wikipedia, uma equipe multifuncional é um grupo de pessoas com diferentes conhecimentos funcionais trabalhando em direção a um objetivo comum. Uma das melhores maneiras de melhorar a qualidade de sua equipe é torná-la multifuncional. Uma equipe multifuncional tem todas as habilidades necessárias para transformar uma ideia em um produto funcional.

“ Uma  equipe multifuncional  tem todas as competências necessárias para realizar o trabalho sem depender de outros que não fazem parte da equipe ” — Guia Scrum

Em contraste com a abordagem de equipe de componentes,  as equipes multifuncionais  são grupos formados por pessoas de diferentes áreas funcionais da empresa. — deve ser formado não apenas por especialistas técnicos (back-end, desenvolvedores front-end, engenheiros de controle de qualidade, etc.), mas também por membros como analistas de negócios, especialistas em marketing e UX ou qualquer outra pessoa que participe ativamente do projeto.

Uma  equipe auto-organizada  é uma equipe que tem autonomia para escolher a melhor forma de realizar seu trabalho, em vez de ser dirigida por outras pessoas de fora da equipe. Ao contrário dos princípios tradicionais de gestão, as equipes auto-organizadas não são dirigidas e controladas a partir do topo; em vez disso, eles evoluem de membros da equipe participando ativamente e coletivamente em todas as práticas e eventos do Scrum.

Equipe tradicional x equipe ágil

“Uma  equipe de auto-organização  consiste em um grupo de trabalhadores do conhecimento que precisam gerenciar a si mesmos. Eles precisam ter autonomia” –  Peter Drucker.

O Guia do Scrum indica que “O Time Scrum consiste em um Product Owner, o Time de Desenvolvimento e um Scrum Master. Eles estão:

“ Times Scrum  são  auto-organizados  e  multifuncionais ” —  Guia Scrum:

Equipe de componentes vs equipe de recursos

A abordagem tradicional é dividir o produto de forma mais ou menos lógica e significativa em componentes e atribuir equipes de componentes a eles. No entanto, esses componentes são completamente irrelevantes para o ponto de vista do cliente.

Uma abordagem de equipe de recursos agora é uma maneira quase universalmente aceita para organizar suas equipes, em oposição à equipe de pilha de tecnologia, especialmente, na abordagem de entrega contínua, ela enfatiza recursos (ou seja, uma fatia vertical do sistema) que resolvem as necessidades do usuário que normalmente podem acelerar entrega de valor de qualquer recurso ou software em funcionamento e encurtar o ciclo de feedback dos usuários reais. Uma equipe de recursos teria todas as habilidades para executar o trabalho em nível de tarefa necessário para realizar o trabalho. Em particular, assumindo uma arquitetura de três camadas, os membros da equipe trabalhariam em tarefas relacionadas à GUI, camada intermediária e partes do banco de dados desta história.

A grande desvantagem da organização de componentes é óbvia: ela retarda o fluxo de valor. A maioria dos recursos do sistema cria dependências que exigem cooperação entre as equipes de componentes para construir, implantar e, finalmente, liberar. As equipes passam muito tempo discutindo as dependências entre as equipes e testando o comportamento entre os componentes, em vez de serem capazes de fornecer valor ao usuário final.