Estruturando equipes de produto desorganizadas

Como muitos consultores e gerentes Cory Foy, um Consultor Ágil, está lidando com uma estrutura organizacional que cresceu através de aquisições e evolução se transformando em um pequeno monstro. Os times eram:

A "maquiagem" do time é um VP (Vice Presidente) no topo que era um dos desenvolvedores originais. Temos logo após QA (Quality Assurance - Garantia de qualidade), Desenvolvimento, Analistas de negócios e Suporte. Suporte é basicamente uma entidade independente – nós trabalhamos próximos a eles e atendemos suas requisições, mas eles são auto-sustentáveis.

Nós temos 18 pessoas nos EUA e itoroutras 30 em um time terceirzado que está dentro do mesmo fuso-horário. Temos ainda dois analistas de negócios, que logo aumentarão para 4, 3 QA e os demais são desenvolvimento. No time terceirizado, temos aproximadamente 20 desenvolvedores e 10 QA – apesar de seus trabalhos serem mais fluidos. Nós temos ainda dois contratantes nos EUA para desenvolvimento.

Como foi observado, as equipes estavam fazendo pouco trabalho fora do seu projeto em grande parte devido a falta de tempo. Como se não bastasse, os ciclos para cada release ocorriam em cascata demorando de 12 a 18 meses. No lado bom, QA e Desenvolvimento já trabalhavam bem juntos e não existia a mentalidade “não jogue isto pelo muro“. Ele também notou que havia alguns desafios na média gerência – eles não estavam acostumados a ser parte da "oficina" do produto.

Robin Dymond, Sócio-Gerente na Innovel, recomendou e eles "Desenvolvimento Ágil e Lean" (Larman e Vodde), particularmente as sugestões para "Equipes de feature" e "Product Owners". Ele também identificou o ciclo de releases como o maior problema aparente.

Cory explicou que o problema com ciclos de release menores era o número de línguas em que o produto deve ser traduzido. Não apenas Francês, Espanhol e Alemão, mas também Russo, Hebreu, etc.

Dave Rooney, Consultor Ágil pela Mayford Technologies, sugeriu releases internas a cada 3 meses e relases públicas tão frequente quanto as necessidades do negócio.

Hillel Glazer observou problemas de gerência em potencial aqui notando que Cory foi requisitado pela Gerência Sênior e que ele pode reportar seu progresso atual dando ênfase aos riscos e impedimentos que permanecem no caminho. Hillel enfatizou a importância de fazer esses relatórios o mais impessoal possível. "Não "culpe" a média gerência. Você pode ir atrás de "prioridades conflitantes" ou "informações inconsistentes" ou algo do tipo."

Cory diz que a organização começará implementar algumas destas mudanças em Agosto após o término do ciclo de release atual.