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.

Nos times ágeis, é comum nos depararmos com comportamentos que, mesmo não intencionais, acabam prejudicando a colaboração e os resultados. alguns deles foram agrupados no chamado Reino Animal das Disfunções na Agilidade. Cada disfunção é representada por um acrônimo em…

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

Na última segunda-feira, publiquei o artigo sobre critérios relevantes para avaliar e melhorar a saúde das histórias de usuário. Recebi bons feedbacks sobre o assunto. Entretanto surgiram dúvidas e algumas reclamações sobre a definição da Necessidade. No artigo, escrevi “A…

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

Quando falamos de Histórias de Usuário, estamos falando de um meio simples e prático para descrevermos as necessidades das pessoas que utilizam nosso produto / serviço. Em diversos treinamentos as pessoas perguntam qual a melhor forma de escrever uma história….

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

Você é o Product Owner e está diante do seu product backlog, que precisa ser priorizado. No entanto, ainda não sabe por onde começar. A Técnica MoSCoW te ajuda a fazer isso de forma rápida. Vamos vê-lo. MoSCoW A classificação…