Faz um tempo que estou querendo parar para escrever sobre uma experiência que tivemos na JUST e que acho que vale compartilhar. Não é novidade, ou melhor não deveria ser, mas na JUST todos os nossos times são ágeis, trabalhamos com SCRUM nos projetos e com KANBAN para times que atendem demandas não planejadas.
A dúvida sobre qual o tamanho de time ideal no SCRUM chega até a ser polêmico, me lembro de no início, ainda timidamente ler sobre este assunto e pensar que quanto mais pessoas no time melhor. Sabe como é, quando se está acostumado a tocar projetos com apenas uma pessoa, você nunca verá um limite produtivo pra isso até se deparar com os problemas.
Bom, projetos e produtos com apenas uma pessoa, é coisa do passado, de um passado distante. Esta não é e não mais será minha realidade e nem a da JUST. São muito óbvios os efeitos colaterais de tocar projetos e desenvolvimento de produto com apenas uma pessoa. É muito comum ainda ver empresas, produtoras web ou agências desenvolvendo produtos desta forma. O tão conhecido método eXtreme Go Horse. Costumo chamar este método carinhosamente de UPA UPA CAVALINHO… Ele consiste em um conceito básico… sai fazendo… fazendo… e fazendo… é bem simples e intuitivo. Após alguns anos usando este método poderá sentir o estrago que ele pode causar.
Vale dizer que não é que eu não conhecia PMI e não gostava de muitas coisas do PMBok, mas só quem nasceu na internet vai me entender. Você aprende no seu primeiro dia em uma agência, mesmo que ela seja uma agência digital, que PMI é uma “merda”. É isso que nos ensinam, é isso que se escuta nos corredores, enquanto no mesmo corredor se escuta frases como: o projeto está muito atrasado, o fornecedor não entregou, aquele freela que contratamos não entrega, o cliente está puto, está cheio de bug.
Bom é isso aí… foi assim que aprendi lá em meados de 2000. No auge dos meus 17 anos! Mesmo assim fui estudar… comecei por PMI, que vale lembrar hoje tem até certificação para Agile, depois ví XP, Rup… Mas aplicar metodologias em agências é como estar no lugar errado na época errada. Hey! Não sou contra agências! Amo publicidade, acredito que fazem coisas incríveis, conhecem do mundo de tecnologia, estão antenados, porém infelizmente passam longe de saber desenvolver software, apesar de muitas vezes terem grandes profissionais de tecnologia trabalhando para elas. Mais uma vez, pessoa errada no lugar errado. Lugar de desenvolvedor, programador é em empresa de tecnologia, que respira tecnologia e investe em tecnologia e não em uma empresa que vende design, arte, publicidade, idéias, marketing. Estes dois mundos precisam se falar, mas não dá para estar lá dentro. São universos completamente diferentes.
Ok… vamos voltar para o centro da questão. Após toda esta vasta experiência com XGH (eXtreme Go Horse), passei a estudar Agile. Fui atrás de Scrum, Kanban, Lean, Beyond Budgeting, Management 3.0, Design Thinking, Lean Sturtup… todos estes nomes que hoje são mais conhecidos. Passei os últimos 4 anos lendo de tudo um muito, estudando para certificações e mesmo assim ainda tinha a dúvida: Afinal, qual é o tamanho ideal para um time de desenvolvimento SCRUM.
A resposta que o SCRUM dá e muitos os grandes nomes da agilidade e do SCRUM pregam é de que o número fica entre 3 e 9. É aí que concordo e não concordo. Com o primeiro número estou de pleno acordo. Está mais do que testado na JUST. Para nós o número mágico é entre 3 e 5 pessoas + PO.
Epa epa epa… onde está o Scrum Master… bom esta é uma discussão longa e que costuma ser polêmica. Prometo voltar nela em breve.
Voltando… a parte que não concordo é o segundo número. Tivemos uma experiência recente com um time de 9 em um projeto. As coisas não estavam avançando como gostaríamos, eu via outros times menores rodando tão bem, avançando mais do que um time de nove pessoas e isso acabou ficando muito claro após rodarmos algumas sprints. A decisão de quebrar os times na segunda sprint começou a surtir efeito e estávamos produzindo 3 vezes mais.
Os problemas com o time de 9 pessoas não eram de relacionamento, colaboração, comunicação… eram problemas menos visíveis, que demoramos um pouco para entender onde estava o problema. Começava com as reuniões, 9 devs + PO + Scrum Master + Stakeholders (PO cliente + outros envolvidos no negócio). A proximidade e alinhamento entre o time e todos os envolvidos na visão de negócio estava caminhando muito bem, sem atritos, mas inspecionar e adaptar se tornou um lema pra mim, pra JUST.
Colocar muitas pessoas em uma reunião não é uma boa idéia na maioria das vezes. Raramente são reuniões produtivas. Ou melhor, podem ser muito produtivas para alinhar algo, porém em quantidade do que se irá alinhar é pequena. As discussões são intermináveis.
Imagine 9 desenvolvedores para chegar em um consenso sobre cada uma das User Storys.
E na fase 2 do planning para escrever as tasks de cada uma das stories.
Com as divergências nas User Stories o grau de incerteza aumentava, isso fazia com que o time assumisse poucas stories para aquela interação. Isso por sí já estava começando a parecer um problema. Durante a SPRINT, também apareciam alguns problemas de ociosidade, pois como eram trazidos poucos itens do backlog para a sprint, era difícil paralelizar o desenvolvimento dentro da SPRINT. Também causado por esta difícil divisão, vimos trabalhos serem segmentados dentro do time. Um só fazendo teste, apenas um responsável pelo Deploy…
Com isso aprendemos que o número de 9 para nós não funciona. 8 também já testamos neste mesmo projeto e não funciona. 7 e 6 também não funcionaram tão bem.
O que melhor tem funcionado são times de 3 ou 4.
No caso deste time de 9 pessoas, hoje temos 3 times. O PO é o mesmo para os 3 times, senta junto com o time e a Daily é feita com os 3 times. Cada time ataca áreas distintas do produto, porém precisam estar minimamente alinhados. Os 3 times sentam próximos o que facilita a comunicação constante entre os times.
Após as mudanças os resultados começaram a aparecer, as pessoas nos times sentiram a melhora, os stakeholders e Product Owner, também sentiram a melhora. Agora para este mesmo produto estamos montando mais um time. O produto passará a contar com um time de 12 pessoas + PO. O backlog é único, porém dividido por épicos o que facilita dividir o trabalho entre os times e atacar mais frentes do produto.
Esta foi uma experiência recente que achei interessante compartilhar, pois times grandes nem sempre são comuns e no nosso caso não funcionou.
Vale lembrar que ter apenas um Product Owner para os 3 times tem funcionado muito bem e não consigo ver neste caso Product Owners diferentes para cada time e nem mesmo a Daily sem esta interação entre os times.
Ao meu ver foi um aprendizado interessante, que pode não ser a regra, mas vale para refletir.
