1. Framework LeSS
  2. Coordenação & Integração

Coordenação & Integração

O Scrum prega a coordenação e a integração descentralizada e auto organizada ao invés da coordenação centralizada e controlada utilizada na gestão tradicional de projetos. A coordenação e a integração no LeSS se concentram em suportar a coordenação descentralizada, proporcionando limites e estruturas suficientes para evitar o caos.

Apenas Converse

Provavelmente a melhor maneira de coordenar as equipes é coordenando entre as equipes. Qualquer membro de uma equipe auto organizada deve procurar a(s) outra(s) equipe(s) se se houver um problema a ser discutido. Quando há uma necessidade de coordenação então “apenas converse”, indo até a outra equipe, pegando o telefone ou, na pior das hipóteses, enviando um e-mail. Você não precisa de um mecanismo de coordenação formal, oficial e geralmente lento. Levante-se e vá conversar com as pessoas.

Comunique Através do Código

Grupos LeSS adotam integração contínua, o que significa que todo mundo tem seu código de checado no repositório central (branches são uma complicação desnecessária que deve ser evitada). Todos nas equipes de produto sincronizam com o repositório várias vezes por dia e terão todas as mudanças que outras pessoas fizeram.

Então, quando você atualizar, gaste dois minutos analisando rapidamente as alterações que foram feitas pelos outros e veja se elas se relacionam com o que você está trabalhando agora. Caso afirmativo, sinta-se livre para se levantar e “apenas conversar”, a fim de sincronizar o seu trabalho com os outros!

Envie Observadores na Daily Scrum

Um método simples de coordenação entre as equipes é enviar um representante -não o Scrum Master-como um observador silencioso na Daily Scrum de outras equipes que estão fazendo trabalhos relacionados. Os observadores, em seguida, informam suas equipes para que elas possam tomar ações futuras.

Comunidades e Mentores de Componentes

As pessoas que trabalham nos mesmos componentes ao mesmo tempo precisam saber umas das outras para que elas possam fazer perguntas e revisarem o código das outras. Faça isso através da criação Comunidades de Prática (CoPs) de componente, cuja comunicação deve ser feita através de listas de discussão, bate-papo, reuniões ocasionais e outros canais de colaboração remota.

Estas comunidades são frequentemente organizadas por um “mentor de componente”, que é geralmente um membro de uma equipe de funcionalidades que assumiu algumas responsabilidades adicionais, tais como (1) ensinar como funciona um componente, (2) monitorar a saúde a longo prazo de um componente, (3) organizar uma comunidade de componente, (4) organizar oficinas de design, e (5) revisar código.

Um mentor de componente não revisa o código para aprová-lo antes do commit. Ele é um professor e administrador do componente, e não um portal de aprovação.

Um componente pode ter vários mentores que compartilham o trabalho e, assim, reduzem dependência de uma pessoa-chave.

Importante! … Além de ajudar a coordenação, estas práticas ajudam a manter ou a melhorar a qualidade do código e o design de um componente, além de aumentar o aprendizado.

Scrum of Scrums

A reunião Scrum of Scrums é uma reunião do estilo Daily-Scrum entre as equipes, normalmente realizada entre duas a três vezes por semana.

Normalmente, o formato é de três perguntas, semelhante a uma Daily Scrum:

  • O que minha equipe fez de relevante para outras equipes?
  • O que a minha equipe fará de relevante?
  • Quais são os impedimentos da minha equipe que as outras equipes devem saber ou ajudar a resolver?

Naturalmente, utilize quaisquer perguntas que o seu grupo ache útil.

Cuidado: O desejo de realizar Scrum of Scrums pode ser um sinal de dependências desnecessárias ou problemas de coordenação causados por grupos de uma única funcionalidade, ou equipes de componentes, ou por equipes que não conseguem identificar dependências e realizar um trabalho compartilhado.

Scrum of Scrums não faz parte do LeSS e, como uma técnica de coordenação centralizada e mais formal, também não é recomendado. Mas, se ele está funcionando, por favor não pare de fazer isso … ainda que você sinta que não deva fazê-lo por causa da adoção do LeSS.

Cerimônias Multi-Equipes

É comum que algumas equipes sintam a necessidade de trabalhar em conjunto, enquanto outras podem não sentir essa necessidade. Para as equipes que trabalham em conjunto, é comum realizar cerimônias multi-equipe no LeSS. Alguns exemplos seriam:

Viajantes para explorarem, quebrarem os gargalos e criarem habilidades

Às vezes, um grupo de produtos é baseado em conjunto de especialistas técnicos experientes. Como o conhecimento (escasso) desses especialistas pode ser mantido à disposição para todas as equipes? Eles podem se tornar viajantes. Em cada Sprint eles se juntam a uma equipe diferente, treinando através de sessões de pareamento, workshops e sessões de ensino.

Embora o conceito de ‘viajantes’ não tenha sido criado especificamente para a coordenação, juntando diferentes equipes eles criam ou reforçam uma rede ampla, que é exatamente o necessário para os canais de coordenação informais. E aumentam a consistência do conhecimento ou prática entre as equipes, garantindo um objetivo da coordenação.

Equipe Líder

Em alguns casos, as funcionalidades são monstruosamente grandes. Ao dividir estas gigantes funcionalidades em pequenos itens do Product Backlog, isto requer muitas equipes trabalhando em conjunto, cada uma separadamente com seus próprios PBIs, para criarem uma única e gigantesca funcionalidade.

Outra técnica para coordenar equipes trabalhando em conjunto nos itens de divisão de uma grande funcionalidade é ter uma equipe líder. Uma equipe líder é apenas uma equipe de funcionalidades comum que tem um papel de liderança perante a funcionalidade gigante. Além de fazer o trabalho de desenvolvimento, ela é responsável ​​por manter o controle do que as outras equipes estão fazendo e ajudá-las a sincronizar. Em suma, ela organiza a coordenação entre as equipes relacionadas com a funcionalidade gigante, além também atuarem no desenvolvimento.

Às vezes, várias equipes começam a implementar a funcionalidade gigante ao mesmo tempo. Em outras ocasiões, a equipe líder começa sozinha para focar na rápida transferência de conhecimento e simplificar a criação de um design coeso. Depois de algumas Sprints, mais equipes se juntam. Neste caso, a equipe líder também tem a responsabilidade de ensino para ajudar as equipes que chegaram, repassando o conhecimento já obtido.