A organização dos times é uma questão central quando se expande a adoção de metodologias ágeis em escala organizacional. É muito comum que se faça menção a “feature teams", mas com frequência se esquece do verdadeiro significado dessas duas palavras.

Você está disposto a mudar a organização dos seus times e a entender a diferença entre times cross-funcionais e feature teams? Este artigo propõe algumas abordagens para entender esses modelos de organização, e mais importante: saber qual deve-se adotar.

1) Identifique os problemas que motivam uma mudança organizacional

Uma mudança organizacional é um processo humano complexo. Leva tempo e apresenta desafios que não devem ser subestimados.

O primeiro passo antes de considerar qualquer solução é analisar as causas-raiz e assegurar-se de que uma mudança é a solução.

-> Quais dores motivam o desejo de mudança da organização dos times? -> Uma mudança organizacional desse tipo é a solução efetiva para essas dores?

A seguir mencionaremos algumas dificuldades típicas que encontramos em empresas que estavam organizados em silos tradicionais:

• Um time-to-market considerado lento demais
• Dificuldade recorrente em sincronizar projetos grandes que requerem a coordenação de vários times
• Dificuldade em inovar eficientemente e a em trabalhar de novas maneiras
• Problemas de qualidade devidos à segmentação das equipes de TI (ex. Quem gerencia a qualidade? O time de desenvolvimento ou o time de QA?)
• Dificuldades de comunicação entre times / silos (ex. TI versus Negócios)

Nesses contextos faz sentido reorganizar os times, com o objetivo de reunir múltiplas competências nos times.

2) Crie times cross-funcionais

Um time cross-funcional é aquele que possui todos os skills necessários para conceber e colocar em produção um produto. A metodologia Scrum entre outras promove esse modelo. Neste tipo de time não há mais silos: todos trabalham juntos e no mesmo local para viabilizar uma comunicação ótima. Por essa razão prefere-se times pequenos com 6 a 12 pessoas (pizza-team, times com o número certo de pessoas para comer de 1 a 2 pizzas).

Esses times possuem a quantidade de pessoas necessárias para realizar o projeto. Portanto, deve-se concedera a autonomia na tomada de decisões, desde que estejam alinhadas com a estratégia da empresa, e a responsabilidade de alcançar os objetivos (os quais devem ser factíveis)

Podemos desenhar estrutura de times cross-funcionais e os atores com quem interagem frequentemente da seguinte maneira:

Algumas questões interessantes surgem aqui:

-> A empresa está pronta para criar pequenos times“co-alocados”que misturam pessoas de negócios e de TI (desenvolvedores, testes, e ops) para trabalhem juntos todos os dias? -> Os membros desses times estão motivados com os benefícios da comunicação direta que o novo modelo proporciona? Dependendo da cultura organizacional pode ser difícil implantar uma estrutura de time assim. Especialmente em relação a questão de comunicação. Pois antes a comunicação que era indireta e regrada por documentação e depois passa a ser direta. Outra mudança é que a resolução de problemas passa a ser uma responsabilidade do time. Sendo assim os integrante do time pode ser obrigados a reavaliar (reaprender?) seus hábitos de trabalho.

Outra questão que também surge: Como compartilhar conhecimento entre pessoas com mesmo perfil mas que estão distribuídos entre times diferentes. Uma boa solução é criar de comunidades de prática que promoverão reuniões periódicas para compartilhar experiência e boas práticas.

Por ultimo um assunto delicado para qualquer transformação: a (re)definição dos papeis dentro dos times, incluindo o novo papel gerencia intermediaria, a qual costumava facilitar o tráfego da informação... Segundo nossa experiência melhor maneira de lidar com todas transformações e mudanças é experimentar começando com 2 times cross-funcionais. Esse times devem ser formados com pessoas que estejam interessadas em participar nesse tipo de equipe. O experimento deve ser feito por alguns meses (no mínimo 6 meses). Ao final desse estágio piloto, os integrantes do time terão aprendido e adaptado os papéis para o contexto da empresa. Além disso, depois da experiência prática todos estão capacitados para fornecer feedback sobre o experimento.

3) Crie times orientados a “Feature” ou Componentes

Feature team - time orientado a feature

Com objetivo de diminuir as dependências entre times, algumas organizações criam times dedicados ao desenvolvimento e suporte de um escopo funcional claramente definido. Estes são conhecidos como times orientados a funcionalidades, ou Feature teams.

Segue um exemplo por Henrik Kniberg de como os Feature teams estão organizados no Spotify:

-> A empresa consegue identificar quais funcionalidades independentes poderiam ser cuidadas por times com pouca interdependência? -> A arquitetura de software é compatível com essa forma de organização?

Vale a pena enfatizar que entre os feature teams deve haver o máximo de independência possível. Tanto no nível organizacional como no nível de arquitetura. Um feature team deve ser capaz de entregar uma nova versão de seu escopo sem causar impactos outros times. Isso incentiva um ótimo time-to-market (TTM).

Component team - time orientado a componente

Times orientados a componentes:

• Possuem uma forte especialização tecnológica (especialidade por linguagem, pacote de software...) conhecida por um pequeno grupo de pessoas
• São responsáveis por gerenciar um “serviço” utilizado por vários times (ferramenta de billing, serviço de email...). Devem garantir a integridade para manter SLA consistente.

Dean Leffingwell, autor do framework SAFe, apresenta aqui a diferença entre feature teams e componente teams:

-> Na empresa já existem "times orientados a componente" que podem ser mantidos?

Vale a pena enfatizar que Component e feature teams não são incompatíveis. No entanto, Component teams pode enfrentar algumas dificuldades e limitações:

• • Component teams possuem TTM significativamente mais longo do que Feature teams porque precisam atender solicitações de vários stakeholders. Portanto, precisam organizar seu desenvolvimento para entregar funcionalidades distribuídas igualmente para os solicitantes;
• • Para atender todos os times solicitantes possuam a tendência de solicitar requisitos e projetar soluções prematuramente;
• Finalmente, como um silo de capacitação, podem desacelerar a inovação uma vez que qualquer ideia lançado por outro time deve passar por uma solicitação “administrativa” que deve ser adicionada ao backlog.

Por essas razões e para preserva o TTM geral da organização recomenda-se manter uma proporção de component teams menor do que a quantidade de feature teams. Acreditamos que a proporção correta é 70% a 80% de feature teams para 20 a 30% de component teams.

Conclusão

Organizações com times cross-funcionais especializados são capazes de solucionar mais desafios do que empresas organizadas em silos.

Pode-se encontrar muitos exemplos e referencias sobre este assunto na web (A começar com este artigo sobre Feature teams de Craig Larman, ou este vídeo sobre como Spotify implementa seu modelo ágil). De qualquer forma, além da escolha da estrutura organizacional teórica o verdadeiro desafio está na implantação deste novo modelo de comunicação entre atores chaves. Uma grande maneira de iniciar esse tipo de transformação é começar por com uma fase de experimentação com colaboradores que tenham entusiasmo com esse tipo de mudança.

E você? Que tipo de organização de times você impletaria?