Solucionado (ver solução)
Solucionado
(ver solução)
1
resposta

Equipes ágeis em grandes empresas com estrutura baseada no modelo cascata

Em uma empresa grande de software, dividida por funções (infraestrutura, sistemas) e subfunções (por exemplo: DBA na infraestrutra; analista de sistemas, analista de qualidade, desenvolvedor, no desenvolvimento) e que está começando a adotar práticas ágeis, digamos que fosse possível alocar todo o pessoal em um único projeto ágil em tempo integral. Teríamos as seguintes questões a tratar:

a. Os envolvidos possuem especializações que já vem de anos de experiência e, por mais que se tente que, juntos eles absorvam conhecimentos uns dos outros, formando um perfil T-Shape, por um longo tempo - às vezes maior do que um projeto - eles não conseguirão fazer bem as tarefas fora de suas especialidades. Haverá sub-alocação, por aguardarem tarefas, ou então, no caso de tentarem aprender, uma grande queda de performance, além de gerar insatisfação por parte deles bem como resistência, tanto sua, quanto de suas áreas em relação a atuarem fora de suas especialidades.

b. Em caso de sub-alocação, arca-se também com o custo maior de manter todos os envolvidos em um time aguardando por suas tarefas dos demais, o que piora o cenário.

Em meio a isto, digamos que o caminho intermediário tenha sido a empresa optar por por manter no time de desenvolvimento apenas os principais envolvidos na criação do produto - digamos um software -, fazendo às vezes a interface com outras áreas, de outras especialidades apenas de maneira pontual.

Mesmo assim, permanece a situação de que a carga de trabalho de analistas de sistemas, analistas de qualidade e desenvolvedores, que formarão o time, poderá não ser igual, e, na ausência imediata das competências necessárias, podermos incorrer novamente nas duas questões que foram colocadas acima.

Digamos que como solução para este novo problema, os envolvidos no planejamento e estratégia decidam então - por uma questão de custo - definir que a participação dos envolvidos não será em tempo integral, mas pontual, porém, mantendo as reuniões diárias para manter o time sempre alinhado, para que saibam quando é o momento em que podem colaborar com algo.

Este é um cenário possível pensando em custos, em escassez de recursos, na cultura e estrutura da empresa, etc. Porém fica a dúvida: é válido? Será que outras inúmeras outras empresas já não passaram por isso? O que fizeram nesta situação.

Gostaria de pegar opiniões, cases, etc como forma de ajudar a melhorar este cenário.

1 resposta
solução!

Hudson, tudo bom?

Agile é um mindset. Sempre haverá alguns pontos de resistência à mudança, cabe a corporação lidar com isso. Se a corporação quer essa mudança e algumas pessoas não querem, temos ai uma questão a ser resolvida.

Mudanças trazem mudanças. Simples! É necessário ser transparente, pessoas que mudam de funções e precisam reaprender levam um tempo para isso. Deve ficar claro, primeiro teremos uma curva de aprendizagem para depois performar. Até mesmo a questão da formação da equipe seguindo o Modelo de Tuckman (Formação, Tempestade, Normalização e Realização).

Uma equipe Ágil não trabalhar nisso em tempo integral é bem ruim. Quando pensamos em Scrum o Development Team deve ser focado no objetivo da Sprint. Nesse contexto a melhor forma é não fazer a mudança com a equipe toda e sim com parte dela e ir escalando. Lembrando que no Scrum, por exemplo, o time de desenvolvimento deve ter entre 3 e 9 membros somados o Scrum Master e o Product Owner.

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software