À medida que um time ágil começa a crescer, o gerenciamento da equipe se torne cada vez mais difícil. Algumas vezes, os princípios ágeis podem até se perder em meio a tantos integrantes. No entanto, é natural que a equipe cresça conforme o software ganha novas funcionalidades e precisa de mais recursos humanos para mantê-lo.
Isso não acontece somente em uma equipe ágil, mas em qualquer tipo de equipe que envolva várias pessoas. Quando o número de integrantes começa a crescer, fica bem mais complicado manter uma comunicação uniforme com todos. Orientar uma atividade para três pessoas é bem mais fácil do que fazer o mesmo para uma equipe de vinte pessoas.
Imagem via Shutterstock
Em uma equipe muito grande, o índice da probabilidade da perda de foco e dificuldade no acompanhamento do projeto é muito alto. Além disso, novos colaboradores no projeto podem presenciar dificuldades na integração.
Pois bem, a metodologia ágil fornece uma solução para projetos que possuem várias pessoas envolvidas. Trata-se de uma prática conhecida como Scaling Agile que, em português, significa “Desenvolvimento Ágil em Escala”.
O principal objetivo do Scaling Agile é dividir a equipe ágil em células de trabalho de alta performance e aplicar os princípios ágeis nessas células. Essa prática proporciona uma flexibilidade para estabelecer tarefas entre equipes onde cada uma seja gerenciada de forma independente, mas que sejam integradas entre si.
Pra facilitar a compreensão, imagine o Scaling Agile como uma linha de produção industrial de um guarda-roupas, por exemplo. Cada setor é responsável por uma fase de preparação do produto, como corte, lixa, massa, pintura e acabamento. No contexto, podemos chamar esses setores de células. A diferença é que no Scaling Agile uma fase não depende da outra pra ser finalizada, ou seja, todas acontecem ao mesmo tempo. Afinal, se uma fase dependesse da outra estaríamos caindo no conceito de Cascata.
Ao invés de fases de produção, no Scaling Agile temos módulos do software que são delegados para cada célula de trabalho. Por exemplo, em um software de automação comercial, uma equipe poderia ser alocada para o software de frente-de-caixa, enquanto a outra equipe assumiria o módulo de retaguarda. Pense que cada equipe estará trabalhando em um “subsistema” que posteriormente será agregado ao sistema final.
A princípio, o Scaling Agile pode ser combinado, respectivamente, com Lean e Kanban para definição das células de trabalho e gerenciamento da interação entre as equipes. Na prática, as técnicas do Lean podem auxiliar a reduzir a complexidade do acompanhamento das células ágeis através de três ideias em especial:
- Controle Visual: utilizar objetos visuais (como quadros, marcadores e outros adjetos físicos) para indicar o status da equipe, fluxo de trabalho e nível de conclusão das funcionalidades.
- Métricas de produtividade (Throughput): técnica para medir o tempo gasto no ciclo de vida de uma história, desde a sua inclusão no Sprint até a conclusão.
- Mapeamento da cadeia de valor (Value-stream Mapping): recurso muito útil para identificar pontos que causam atrasos e descobrir melhorias contínuas para a produtividade.
Uma das características importantes do Scaling Agile é a presença de um responsável por cada célula. Este profissional recebe a denominação de Agile Mentor ou Agile Coach, respondendo imediatamente ao coordenador de desenvolvimento ou ao Product Owner. Na verdade, o Agile Mentor executa as mesmas funções de um Scrum Master, salvo algumas responsabilidades mais específicas, como disciplinar a equipe, reportar interrupções e manter contato com os Agile Mentors de outras células.
Cada equipe possui um backlog que, como dito anteriormente, deve ser limitado ao módulo de atuação no qual a equipe foi alocada. Em outras palavras, o Scaling Agile procura minimizar a dependência entre as equipes. Uma equipe não pode assumir requisitos direcionados a outra, ao menos que isso seja definido para evitar o atraso da Sprint.
Embora o conceito do Scaling Agile pareça claro, há vários fatores que devem ser considerados mediante a sua aplicação. Por exemplo, é necessário saber como dividir as equipes e qual módulo delegar para cada uma delas, de forma que haja um equilíbrio de capacidades. De nada adianta definir células de trabalho se os integrantes da equipe serão remanejados constantemente. Deve-se realizar uma medição do nível de experiência dos integrantes e alocar os mais experientes na regra de negócio em diferentes equipes.
Aproveitando o artigo, vale ressaltar uma passagem interessante sobre Desenvolvimento Ágil. Algumas empresas afirmam que não adotaram o Desenvolvimento Ágil pelo motivo de que essa metodologia não é apropriada para projetos grandes. Aos que alegam isso, procurem conhecer melhor as soluções ágeis, como o próprio Scaling Agile.
Obrigado pela leitura!
Publicado originalmente no blog SubRotina
