Silos: visualizando e tratando as dependências do time

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

Este post não tem tags.

Compartilhe:

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 Gestão de Conflitos ou 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 segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Sobre o autor(a)

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.

Imagine que você resolveu tirar um dia para dar aquela geral na casa. Você decidiu que vai varrer e limpar todos os cômodos, dar aquela embelezada no carro e arrumar o jardim. A princípio tudo faz parte do grande serviço:…

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

Muitos não sabem, mas kanban não é o quadro de mapeamento de fluxo de trabalho. Na verdade, traduzindo do japonês, 看板 (kanban) significa placa de sinalização. Se fossemos muito puritanos, ao invés de dizer que temos um quadro kanban, o…

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

Muitas empresas que passam por transformações ágeis já querem começar utilizando Métodos Ágeis em escala. Para tal, adotam frameworks como SAFe e outros. Entretanto, trabalhar em escala pode ser difícil e complexo, pois todos os problemas que ainda não foram…

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

Todos nós recebemos demandas que têm um prazo exato para ser entregue. Quando isso acontece, uma das ações acaba sendo tomadas. A primeira é parar tudo e começar a fazer a demanda com prazo. Outra, caso o prazo esteja distante,…