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.

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.

Políticas explícitas são o alicerce invisível que mantém times ágeis funcionando com eficiência e harmonia. No contexto do Kanban, elas são mais do que simples regras: são acordos claros que orientam decisões, promovem transparência e evitam confusões. Apesar disso, muitas…

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

Há algum tempo escrevemos o artigo sobre o Cemitério Mexicano. Ele fala sobre a importância de comemorar quando descartamos ideias ruins antes que elas entrem no nosso fluxo de trabalho como projetos, iniciativas, novos produtos ou serviços. Naquele artigo citamos…

Introdução Muitas empresas confundem a Gestão de Objetivos Estratégicos (OKR) com as operações diárias, conhecidas como (BAU), gerando desalinhamento de expectativas, excesso de Objetivos e KRs e iniciativas que na verdade são tarefas do dia a dia. Em parceria com…

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

Mapa de Empatia Quando estamos tentando criar produtos e serviços é importantíssimo entender quem são os nossos potenciais consumidores. Existem diversas formas de fazer isso, mas eu gostaria de apresentar o Mapa de Empatia criada por Dave Gray, A ideia…