Silos: visualizando e tratando as dependências do time

Recentemente, enquanto estávamos facilitando um EVDnC, um dos times estava com dificuldade para decidir quais tarefas deveriam ser feitas por quem e quais aquelas deveriam ser feitas em conjunto. Toda hora surgia algo como: “mas eu não sabia que você precisava disso”, “eu fiquei esperando o Back end fazer tal coisa e eles nem olharam para isso”, “Tenho algumas dependências contigo, mas ainda não falei”. Muita discussão e pouco alinhamento.

Era um time com as seguintes especialidades: User Experience (UX) e User Interface (UI), Back end, Front end e Quality Assurance (QA). O quadro Kanban não traduzia as dependências e a história não andava. Bolamos então um quadro diferente.

O Quadro de dependências

Utilizando uma folha de Flipchart, colocamos um círculo para cada especialidade no seu canto.

Em seguida, desenhamos linhas ligando cada especialidade.

Pegamos a história de usuário mais prioritária do Product Backlog, a que estava dando muita discussão e passamos o seguinte desafio: Pessoal, listem em post-its todas as tarefas técnicas que cada especialista precisa fazer para que a história cumpra nossa Definição de Pronto (Definition of Done). Cada especialidade tem a sua cor de post-it.

As tarefas que dependem do especialista e só do especialista ficam dentro do círculo. Todas as tarefas que dependem do trabalho em conjunto com outro especialista devem ficar sobre a linha. Qualquer tarefa que dependa de 3 ou mais especialistas deve ficar no centro do quadro.

A Figura abaixo apresenta o quadro preenchido.

O Quadro de dependências
O Quadro de dependências

A leitura que podemos fazer dela é:

  • UX/UI tem 2 tarefas e não dependem de ninguém;
  • Front end tem 6 tarefas, 2 dependem de UX/UI e 1 depende do Back end;
  • Back end também tem 6 tarefas, 1 depende do UX/UI;
  • QA tem 5 tarefas, 1 depende do Back end e 1 depende de todos os outros.

As movimentações

Quando a dependência for removida, a tarefa poderá ser movida para dentro do círculo do especialista.

Quando a tarefa for concluída, ela deve ser removida do quadro. A História de Usuário está pronta quando todo o quadro estiver vazio.

Tarefas podem surgir ao longo do desenvolvimento ou o time pode descobrir alguma dependência. Todavia cuidado para que isso não se torne uma bengala para o planejamento apressado e mal feito. Novas dependências sempre devem ser comunicadas e combinadas entre as partes.

Acordos

Alguns acordos são necessários

1 – Devemos procurar resolver primeiro as dependências maiores (centro do quadro), depois as dependências menores (retas) e por último as tarefas dos especialistas (dentro do círculo.

2 – Não posso atribuir uma tarefa a outra pessoa. Posso indicar a dependência, mas não escrevo post-its de cores que não são da minha especialidade.

3 – Combine bem o momento em que as dependências serão tratadas. Não espere a Daily Meeting para tal.

E se eu tiver mais especialistas no meu time?

Você pode criar outros formatos de quadro (pentágonos, hexágonos, etc.), mas tenha muito cuidado com tanta especialização no time. Lembre-se da Lei de Brook. A quantidade de interconexões de comunicação é uma explosão combinatória dada pela fórmula.

Fórmula da Lei de Brooks

Lei de Brooks

Trazendo para uma imagem

Exemplificando a Lei de Brooks
Exemplificando a Lei de Brooks

A cada nó de especialista que você acrescenta no time, você acrescenta um overhead de comunicação, aumenta o custo de coordenação, acrescenta complexidade de handoff de histórias e dificulta práticas ágeis importantes como limitação de WIP (Work In Progress, Trabalho em Andamento) e Swarming.

Quer conhecer outras técnicas de facilitação? Inscreva-se no nosso curso de Técnicas Ágeis de Facilitação.
Quer levar a facilitação para dentro da sua empresa? Conheça os modelos de Coaching da K21.

Mais sobre o problema de dependências

Avelino Ferreira Gomes Filho
Sobre o autor

Avelino Ferreira Gomes Filho

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Quando uma transformação organizacional começa a falhar, a explicação mais comum é que surgem rapidamente frases de guerra perdida: “Isso é cultural.”Infelizmente, a nossa cultura não permite a evolução” e logo alguém saca do bolso o “Complexo de Gabriela”: Eu…

Marcos Garrido, Sócio-fundador e Trainer na K21

Não é saber programar. Não é dominar prompts. Não é acompanhar o último modelo que saiu na semana passada. É saber tomar decisões. Quanto mais converso com as pessoas aqui na Nower/K21 e com os nossos clientes, mais tenho certeza…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

No texto “O caos invisível”, falei um pouco sobre a cultura do herói/heroína. Também já escrevi outros textos sobre o tema. Um deles com o meu colega Raphael Montenegro: “Paradoxo do Gestor Capitão Planeta”, que publicamos no final de 2020….

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Clique aqui para baixar PDF do Test Card 2.0 formato retrato PDF do Test Card 2.0 formato paisagem Imagem do Test Card 2.0 no formato retrato Imagem do Test Card 2.0 no formato paisagem Você trabalha com desenvolvimento de produtos….