Sempre que participo de treinamentos agile percebo as pessoas com os olhos brilhando ao serem apresentadas a um ambiente colaborativo motivado, produzindo o que realmente é preciso, com qualidade, sem horas extras e estando aberto à mudanças. Porém, o paraíso se desfaz quando é dito: "Equipes Scrum são formadas por 7 +/- 2 pessoas". A frustração é clara com frases semelhantes a "Como vou adotar agilidade? Tenho uns 50 funcionários só no desenvolvimento". Hoje a resposta para mim está na ponta da língua: Scrum of Scrums. O que pode parecer "A" resposta para uns, para outros só complicou.

Como diz Mike Cohn"Ser ágil é difícil mas vale a pena!". É uma mudança pouco técnica e muito comportamental. Mudar o paradigma de umas 7 pessoas até vai, mas de um monte de programadores, especificadores, designers, testadores e todos os profissionais imersos em seu mundo particular da informática é praticamente deixá-los catatônicos por alguns dias.

A primeira dica seria começar com um test-drive em uma equipe piloto utilizando o Scrum.

Há quem diga que essa pode não ser uma boa opção já que se der errado acabou tudo. Porém, como eu disse antes, é comportamental. Eu acredito que o sucesso está nas pessoas. A primeira formação deve ser composta por aqueles que já se conscientizaram que o atual não está trazendo bons resultados e possuem o desejo de mudar.

Meu primeiro contato com o Scrum foi o mais amador possível. Minha área não tinha nenhum processo formal de trabalho e acreditávamos que, no novo projeto, adotar uma metodologia ágil nos tornaria mais organizados. Lenda urbana, considerando que Scrum pressupõe as equipes já auto-gerenciáveis. Mas nada como uma boa melhoria contínua para nos transformar ao longo da vida e da carreira.

O fato é que funcionou e o test-drive feito por 2 anos foi transferido para toda a área de TI. "Mas 2 anos?" Erros e acertos, aprender a ouvir e falar, a ajudar e pedir ajuda, a criticar e ser criticado, a cobrar e ser cobrado, desistir e persistir. Enfim, ninguém disse que seria fácil, só disse que daria bons resultados.

"Nós temos mais umas 40 pessoas, e agora?" Bom, existem duas alternativas a serem consideradas:

       1. Uma mais lenta, que seria crescer a equipe piloto e depois dividir em duas equipes que iriam crescer aos poucos, depois se dividir e assim por diante.

       2. Uma mais rápida, que seria dividir a equipe piloto por completo formando 7 novas equipes. Cada equipe nova com uma pessoa do time piloto e mais 6 pessoas.

"Qual é a melhor?" A resposta é aquela que quem diz adora e quem ouve odeia: "Depende!". Cada organização é uma e tem seu objetivo próprio. É preciso olhar para dentro de casa, se auto-avaliar e conhecer:

• Analisar se sua equipe piloto é formada por bons semeadores de Scrum;
• Identificar se existe uma grande resistência a novas práticas;
• Observar o entrosamento das pessoas;
• Avaliar o impacto;
• Definir a velocidade que a mudança deve ocorrer e etc.

A minha tendência é gostar da mudança mais rápida. Ela, inicialmente, provoca maior susto, mas a evolução é bem visível e evita os "sabotadores" que não estão no processo e sempre tentam puxar para trás.

"Mas como dividir as equipes?""

Para quem tem equipes trabalhando com projetos diferentes de porte controlado é simples: separar por projeto. Mas se todos trabalham no mesmo projeto de porte grande, ai é que o bicho pega. A dica é separar as equipes com base em módulos, assuntos, negócios ou qualquer perímetro que seja nítido no seu sistema.

"E o Scrum Master?"

Cada equipe tem seu Scrum Master e a recomendação padrão é que o Scrum Master seja fixo. Porém, tenho tido experiências bem interessantes ao passar esse papel pelos membros do time. Com o rodízio de Scrum Master tenho visto um melhor e maior comprometimento e divulgação do conhecimento desse papel por todos.

"E o PO?"

O PO deve ser um para cada projeto e deve dominar os requisitos do negócio. Ele pode atender a mais de uma equipe contanto que consiga dar conta do recado. Para o caso de um mesmo projeto possuir muitas equipes, se houver mais de um PO, eles precisam estar alinhados entre si.

"Como ficam os cerimônias com o Scrum of Scrums?"

Esse é um grande desafio, pois envolve quebrar qualquer barreira que atrapalhe a comunicação entre membros e equipes.

A Reunião Diária e o quadro, cada equipe possui os seus. Além disso, existe a Reunião SOS Diária, somente com os Scrum Masters, para compartilhar impedimentos e soluções entre equipes mas de forma atenta ao time slice reservado.

A Reunião de Retrospectiva cada equipe tem a sua e posteriormente ocorre a Retrospectiva SOS para a troca de experiência.

As pontuações das histórias devem ser interpretadas pelas equipes individualmente e cada uma define qual a velocidade do seu time. Como cada equipe possui seu critério próprio de mensurar histórias, é um desafio para a organização normalizar as pontuações para um acompanhamento gerencial. Entretanto, é  importante que a empresa não faça comparações entre equipes para não criar a sensação de competitividade. O objetivo final é de todos, de forma colaborativa e não competitiva.

“Ok, entendi! Se eu fizer isso tudo é sucesso garantido?”

Ai vai outro "Depende!"… porque não existe fórmula mágica e nem bala de prata. Os erros vão existir já que é sempre possível melhorar.

O sucesso está nas pessoas que precisam ter maturidade e comprometimento, o que vai desde o estagiário ao grande chefão patrocinador de todos, passando até pela equipe de RH com políticas de reconhecimento em grupo. Agora o sucesso não é só de um e sim de todos.
 

Luciana Nascimento é Analista de Software na Módulo Solutions for GRC.

The post SOS: Como adotar agilidade em grandes equipes appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.