2

Em busca da agilidade

Nos últimos anos temos acompanhado um movimento grande no Brasil de organizações adotando framework ágeis, principalmente na área de Tecnologia da Informação. Algumas motivadas por mudanças no mercado onde estão inseridas, impactadas pela volatilidade, incerteza, complexidade e ambiguidade, do tão falado mundo VUCA, outras buscando maior eficiência na condução dos seus projetos, tendo em vista diversos cases de sucesso de projetos que utilizaram framework ágil. Empresas como Google, Spotify, Nubank, Apple e Facebook utilizam ágil em seus projetos, tornando-se referência para outras empresas, que buscam entregar projetos de valor ao negócio de maneira incremental evolutiva.

Nessa busca de obter diferencial competitivo na entrega dos seus produtos, as empresas estão adotando frameworks ágeis nas suas equipes de desenvolvimento, entretanto, para obter ganhos reais com a utilização de um framework ágil, é preciso ir além. É necessário revisar processos com o objetivo de simplificá-los para reduzir desperdícios e ganhar agilidade. Outro fator de extrema relevância é mudar a cultura da organização, para tornar o ambiente mais colaborativo e mais aberto a inspeção e adaptação. Nessa mudança o apoio da alta gestão é imprescindível para o sucesso da transformação ágil, uma vez que mudanças estruturais dificilmente obterão sucesso, quando apenas uma área está imbuída do propósito. A transformação ágil não deve ser responsabilidade apenas de uma área.

Antes de iniciar a transformação ágil, a empresa precisa identificar qual o propósito que ela busca com a agilidade, e traçar o seu próprio plano para chegar ao ponto que ela identifica ser necessário. Se ela não tem um propósito, são grandes as chances de fracasso na transformação ágil ou não obter ganhos reais. Como não existe uma fórmula pronta para essa transformação, a empresa precisa estar disposta a iniciar pequeno, ter transparência, realizar inspeção e adaptação para encontrar o seu caminho na agilidade. 

Em grandes empresas é muito comum ser necessário impactar várias áreas para fazer um projeto de desenvolvimento de software. Podemos ter envolvidas uma ou mais áreas de negócios e várias áreas de Tecnologia da Informação. No caso de uma empresa que esteja em transição na sua transformação ágil, utilizando o Scrum, e por exemplo, se estruturou em times por especialidade (Segurança, Infraestrutura, Integração, User Experience, Operações, diversos times para cada sistema, dentre outros), podemos ter todo o desenvolvimento do projeto feito em ágil, ou parte em ágil e outras em cascata. No ágil os times devem ser multidisciplinares,  pequenos o suficiente para se manterem ágeis e grandes o suficiente para que consigam realizar incrementos potencialmente utilizáveis de maneira auto-organizada. 

Considerando o tamanho recomendável de 3 a 9 pessoas no time de desenvolvimento, é normal ter o envolvimento de vários times para entregar um projeto grande numa organização que tenha um ambiente complexo de sistemas ou que se estruturou por especialidades. Darei como exemplo uma possível maneira que uma grande empresa em fase de transição na transformação ágil, pode se estruturar. Esse exemplo não é forma ideal de se trabalhar com ágil, mas foi a maneira que a empresa se estruturou para iniciar sua transformação ágil.

Nesse exemplo de transição da transformação ágil, a empresa definiu que o Gerente de Projetos seria o responsável por priorizar os desenvolvimentos com cada Product Owner dos times Scrum. É possível ter sucesso no projeto dessa forma? Sim, mas essa estrutura pode gerar os problemas mencionados a seguir, que trazem um aumento considerável no risco de fracasso ou atrasos no projeto.

Exemplo de uma possível formação de times ágeis para atender um projeto complexo
(Ícones feitos por Freepik disponibilizados no site www.flaticon.com – Imagem criada por Kelly Caldas)

A forma de estruturar os times ágeis, conforme a imagem acima, pode trazer as seguintes consequências: 

  • Product Backlogs diferentes para o mesmo produto: como pode ser visto na imagem acima, nas setas de cor vermelha, o GP é o responsável por priorizar em cada Squad o que precisa ser desenvolvido para o projeto. Cada Squad tem seu Product Backlog e um PO responsável por priorizar o que será desenvolvido. 
  • Squads possuem prioridades diferentes para atender um mesmo projeto: cada Squad pode ser de área diferente, com prioridades diferentes. Apesar do GP alinhar com cada PO a priorização, ele pode ser surpreendido por uma mudança de prioridade, que foi solicitada gerencialmente ao PO de uma das Squads, comprometendo o prazo de entrega esperado pelo projeto. Todos trabalhando na mesma prioridade, traz agilidade nas entregas e reduz o desperdício.
  • Cada time trabalha de maneira isolada: nessa forma de trabalhar a comunicação entre os times praticamente só ocorre quando cada Squad finalizou seu trabalho, e dificilmente todas terminarão seus entregáveis juntas, uma vez que as prioridades não são as mesmas. Provavelmente será necessário ficar aguardando a entrega de alguma Squad para que a entrega final esteja pronta para ser validada de maneira integrada. Nesse ponto podemos ter retrabalho, pois cada time trabalha de maneira isolada, testa de forma isolada apenas o que estava no seu escopo, e ao juntar todas as partes para produzir a entrega final, podem ser identificados gaps que surgem quando os testes são feitos com todas as partes integradas.
  • Comunicação entre os times não flui de maneira facilitada: a comunicação entre os times não flui muito bem nesse tipo de formação. Cada Squad tem o seu planejamento isolado e trabalha de maneira isolada.
  • Definição de pronto dentre as Squads não é a mesma: como todas as Squads estão trabalhando num mesmo produto, o recomendado é que elas definam juntas quais critérios de pronto devem ser comuns para minimizar riscos que comprometam a entrega final. Não é obrigatório que todas as Squads tenham as mesmas definições de pronto, mas é necessário mapear quais critérios precisam ser comuns. O objetivo aqui é poder antecipar e evitar ao máximo divergências no que está sendo desenvolvido. Lembrando que não adianta ter apenas uma parte isolada funcionando, todas as partes juntas devem compor um incremento potencialmente entregável.
  • Gerar a entrega final se torna complexo: como pode ser visto nos itens anteriores, apesar dessa forma de trabalho estar utilizando um framework ágil para o desenvolvimento, ela não flui com agilidade. Gerar uma entrega final se torna complexo, com riscos de atrasos e gaps.

Você já passou por essas dificuldades numa transformação ágil? 

O que poderia ser feito para resolver os problemas citados acima?

Please follow and like us:
error

Kelly Caldas

Atuo há 14 anos em gerenciamento de projetos de TI. Passei por experiências em transformação ágil atuando como Scrum Master e acredito que a agilidade pode trazer excelentes resultados tanto em grandes como em pequenas empresas a partir de muita colaboração, transparência, inspeção e adaptação.

2 Comments

  1. Kelly, muito bom o texto!!! Existem vários framework para escalar o agil (safe, nexus, less) que pode ajudar justamente nessas questões, atualmente utilizamos o SAFE que acho muito bom e mesmo sem querer escalar, você pode utilizar essas conceitos para apoiar no dia a dia, então vamos a explicação do SAFE:
    Tudo se inicia com uma cerimonia chamada de PI Planning, onde é definido o objetivo de cada squad, porem é guiada pelo BO da cadeia de valor, ou seja, todas as squads estão alinhadas com o objetivo estratégico. Durante a PI os times ja tem as features previamente mapeada e priorizada (discovery que foi feito juntamente com os BOs) e então os times discutem as features ja quebram em histórias (ainda de forma macro) e realizam a pontuação, em seguida eles planejam em que sprint cada história vai ser entregue e as suas respectivas dependências, como todas as squads estão na mesma sala, essas dependências são acordadas e ajustadas (entre as squads e com o BO).
    Uma vez definido o obetivo da PI (trabalhamos com um prazo de 3 meses), é realizamos semanalmente o Scrum Of Scrum e o PO Sync, para garantir que os impedimentos serão mitigados e que o planejamento está sendo mantido.
    Mas nada é cravado em pedra, se realmente acontecer de algum outro direcionamento estratégico aparecer com maior importância, podemos repactuar os objetivos e ajustas as entregas.
    No final ocorre a System Demo, que é uma apresenta fim a fim do produto que foi entregue por todas as squads, dando visibilidade de tudo que foi feito durante um quartil por exemplo.
    Acredito que com essas cerimonias a maioria dos problemas que listou é mitigado. Espero ter ajudado!

  2. No seu exemplo, Kelly, a minha sugestão seria desmembrar os times por especialidades e colocá-los em squads mistas, ou seja, dentro e uma squad ter um PO, SM, uma pessoa de UX, uma de segurança, etc… E cada squad dessas tocar um produto/vertical diferente. Acho que os ganhos seriam maiores, deixariamos de ter super especialização e teríamos times mais diversos.

Deixe uma resposta