Fluxo de Trabalho: o upstream, midstream e downstream

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

Compartilhe:

Todo trabalho do conhecimento pode ser mapeado em um fluxo de trabalho, também chamado de fluxo de valor ou cadeia de valor (em inglês: value stream, value flow ou value chain). Seja em uma campanha de marketing, contratos, desenvolvimento de software, aquisição, etc., um fluxo é uma sequência de etapas necessárias para que uma ideia torne-se um produto, serviço ou aperfeiçoamento de ambos. Ao final de cada etapa, espera-se que o item que estamos trabalhando esteja mais perto de ficar pronto e ser entregue para o cliente.

Figura com uma cadeia de valor. Ela começa com uma pessoa pedindo um carro. A próxima etapa é um plano, pois o carro está desenhado em um papel. A próxima etapa são peças de carro espalhadas: porta, radiador, motor, caixa, correias. Na etapa subsequente temos o conjunto das 4 rodas no eixo e a carenagem do carro sendo montada por um robô. Em seguida, um carro com rodas, um robô encerrando a montagem. O capô do carro está aberto. A próxima etapa já é o carro montado, visto de cima com todas as 4 portas abertas. A última etapa é uma prancheta com testes do carro e essa etapa encerra o fluxo de trabalho. A última imagem é um carro andando.
Figura de uma cadeia de valor de construção de um carro. Cada etapa deixa o carro mais pronto desde o pedido até a entrega para o cliente.

Fluxo de Trabalho x Fluxograma

É importante diferenciar um fluxo de trabalho de um fluxograma. O primeiro é composto apenas por macro etapas com entradas e saídas bem definidas. Ao final de cada etapa vemos a evolução do item de trabalho (agregação de valor). Já o fluxograma é composto por cada atividade, opção, ação e atores envolvidos no processo que está sendo mapeado. Ele possui muito mais detalhes e consequentemente é um tanto mais complexo do que o fluxo de trabalho.

Um fluxo de trabalho de um processo licitatório composto por 8 etapas: Solicitação, Preparação do Edital, Divulgação do Edital, Julgamento (Licitação), Habilitação, Recursos, Homologação e Adjudicação. Abaixo temos o fluxograma detalhando o processo de trabalho com quase 30 atividades, 4 eventos, 3 atores, 3 decisões e 15 artefatos.
Fluxo de Trabalho de um processo licitatório. Abaixo um fluxograma com parte do processo licitatório do Hospital das Clínicas da Universidade Federal do Triângulo Mineiro

Por que preciso de um fluxo de trabalho? 

Se você já trabalha há algum tempo, você deve perceber que há problemas no dia a dia da sua organização. Um erro comum que cometemos é tentar resolver problemas sem compreendermos o que realmente está acontecendo. Tendemos a dar soluções para problemas inexistentes ou, como gostamos de falar, responder perguntas que não foram perguntadas.

Há um nome para essa forma de agir: Viés da Ação (Action Bias). Ele acontece quando estamos em frente a um cenário ambíguo, comum ao trabalho do conhecimento, e partimos para alguma ação sem fazermos nenhum tipo de avaliação sobre o problema. Inclusive, nesses casos, investir tempo para compreender o cenário em que estamos é visto como contraproducente. O resultado é que acabamos criando mais problemas do que tínhamos anteriormente.

Obviamente, há o extremo oposto a isso, fazer uma super análise de cada variável possível no trabalho do conhecimento e só dar uma solução quando tudo estiver devidamente verificado. Nesse caso temos a Parálise por Análise também conhecida como Big Design Up Front (BDUF). Ela acontece quando estamos com tanto medo de tomar uma ação que ficamos analisando, analisando, analisando, criando um plano “infalível” que jamais será executado.

O mapeamento do fluxo de trabalho é o primeiro passo de um bom caminho para visualizar o que estamos fazendo. Aliás, quando estudamos o método Kanban, essa deve ser uma das primeiras práticas antes de tentarmos soluções mirabolantes. Esse desenho parte da forma atual como trabalhamos. 

Muita atenção à forma atual . Não comece a desenhar o fluxo como hipotéticamente seu time / empresa gostaria de trabalhar. A partir dessa visualização, podemos identificar onde estão os problemas e atuar para resolvê-los, seja algo pontual ou sistêmico.

Como mapear um Fluxo de Trabalho?

Existem diversas abordagens sobre como mapear um fluxo de trabalho. Desde os mais tradicionais como o Mapofluxograma ou, como é mais conhecido, Mapeamento do Fluxo de Valor (MFV, também muito conhecido pela sigla inglesa VSM – Value Stream Mapping), uma das disciplinas de Lean Manufacturing, até o empirismo, quando o fluxo é montado de forma desestruturada. 

Particularmente, gosto muito do Systems Thinking Approach to Implementing Kanban (Statik, utilizando tradução livre, Abordagem de Pensamento Sistêmico para Implementação de Kanban). É uma forma estruturada e ágil para compreender e visualizar o fluxo de trabalho do seu time / squad e organização. Não discutirei muito esse assunto, mas deixo este, este e este links que falam bastante sobre o Statik. Tem também o nosso treinamento de Kanban System Improvement (KSI) que pode te ajudar nesse tema.

Independente da forma, imagine que você está olhando para o Rio do Fluxo de Trabalho. O fluxo começa na chuva de hipóteses (piscina de opções), vai para a nascente (upstream) é construído no leito (midstream) e sai do fluxo pela foz do rio (downstream) e produz um resultado financeiro. A alegria do seu cliente com o uso do produto ou serviço é como se fosse o sol. Ele esquenta a água (itens entregues) ela se transforma em vapor (feedback do cliente) e isso forma novas hipóteses que irão descer o rio em breve. Esse é o ciclo do True Agile (Verdadeiramente Ágil).

Imagem de um rio. Na cabeceira dele temos montanhas marrons. Sobre elas há sinais de interrogação no formato de chuva. Eles estão vindo de uma nuvem onde lê-se hipóteses. Saindo das montanhas temos um rio azul. Ele é dividido nas seções com traços. As seções são: Stakeholders, Business e Product. Acima desses três temos a palavra upstream. Abaixo dessas três seções há uma lâmpada amarela acesa com a palavra concept. Ainda no rio temos uma divisão mais grossa com três subdivisões e nelas lemos: to do, doing e done. Abaixo dessas três temos a palavra Team. Depois temos mais três seções e nelas estão as palavras: validation, production e User. Acima delas a palavra Downstream. Após esse fluxo, mais especificamente, a palavra User, temos um cifrão verde e a palavra Cash. Acima dela a palavra feedback, acima do feedback setas simulando um vapor e acima dessas setas uma pequena nuvem. Acima dessa nuvem há um sol com a palavra happiness. Entre a pequena nuvem de feedback e a nuvem de hipóteses na cabeceira do rio, há duas nuvens que vão crescendo e estão como se fosse o retorno do feedback para a nuvem grande de hipótese na cabeceira do rio. Olhando para o rio novamente na seção product há uma pequena seta pontilhada que vai até o To do. Ligada a ela há uma seta contínua que vai do to do até o done. Nesta parte, lemos: Agile Team. Ligando a lâmpada do concept até o cifrão do cash há uma seta contínua e nela está escrito: Lean Organization. Por fim, Ligando a nuvem de hipótese até o sol de Happiness a outra linha contínua, mais grossa do que as antecessoras e nela lê-se: True Agile.
Imagem apresentando o True Agile (Verdadeiramente Ágil) indo desde a hipótese até a felicidade de seus clientes.

O seu fluxo deve mapear o rio do True agile que está contido ou contém o trabalho do seu time.

É a imagem do rio anterior, porém ela está escurecida. Está destacado um fluxo de trabalho dividido em três partes. A primeira é o Upstream que tem as etapas Análise, Estudo de Viabilidade e Proposta de solução. Todos na cor amarela. Depois temos três etapas no Midstream pintadas na cor branca. São elas: Priorização, Construção e Avaliação. Por fim, na cor azul, temos duas etapas no Downstream: Entrega e Liberação.
Fluxo de trabalho mapeando o ciclo do True Agile com as divisões da etapa

O final desse mapeamento é o desenrolar (roll out) quando o fluxo se transforma em um quadro e conseguimos torná-lo palpável tanto para o nosso time quanto para os clientes e stakeholders.

A imagem do rio descrita anteriormente. Com o fluxo de trabalho também descrito anteriormente, porém posicionado na parte superior do quadro. Abaixo do fluxo, um quadro kanban com as mesmas etapas e post its espalhados em cada etapa. Abaixo de cada etapa continuam as palavras Upstream, Midstream e Downstream. Entre a etapa de proposta de construção, encerrando o upstream e começando o downstream há uma coluna roxa com o título: Ponto de Comprometimento. Entre a etapa Liberação e a Itens disponíveis para o cliente utilizar, há uma coluna vermelha com o título: ponto de entrega.
O fluxo de trabalho “desenrolado” em um quadro de itens de trabalho (costumeiramente chamado de Quadro kanban).

Esteja atento

Independente do método adotado para dar visibilidade ao fluxo de trabalho, é importante se atentar para alguns pontos importantes.

Como as coisas são feitas hoje.

Um erro comum é tentar definir um fluxo incompatível com o trabalho realizado. Algo que é muito desejado, porém não é conforme feita hoje. Por exemplo, Vicente acredita que antes de entregar o serviço para um cliente, seria importantíssimo ter uma etapa de avaliação da alta administração. Ele é um cara influente e consegue angariar adeptos para a sua ideia. Todos concordam que a etapa Aprovação da Alta administração deve fazer parte do fluxo.

Um quadro com etapas e post its representando itens de trabalho: Piscina de Opções com três itens, Avaliação com um item. O ponto de comprometimento em roxo, priorizados com três itens, Construção com dois itens, aprovação que representa a etapa desejada, porém inexistente já demonstrando um gargalo com dez itens. Mais uma etapa de entrega, o ponto de entrega e a entrega. Essas duas últimas etapas estão totalmente vazias.
Quadro com o fluxo “perfeito” incluindo o desejo da “aprovação pela alta administração”

“Você combinou com os russos?” Foi a pergunta feita pelo Garrincha, atacante da seleção brasileira na Copa de 1958, ao técnico Vicente Feola após este apresentar um esquema tático “brilhante” que funcionaria somente se a seleção da União Soviética fizesse exatamente o que estava no plano do técnico brasileiro. O Vicente do nosso exemplo tem o mesmo problema. Não combinou com a alta administração e agora o fluxo de trabalho visualiza algo que inexiste. 

Se o time resolver obedecer à etapa desejada, porém inexistente, nada andará. Eles deixarão de ver sentido no quadro já que ele não é uma representação do trabalho deles. 

O mesmo quadro anterior, porém agora todos os itens estão na etapa Aprovação da Alta Administração, porém os itens estão amarelados, como papel velho. Na coluna de avaliação há uma mosca voando, na priorizados há dois grilos coaxando, na entrega há uma teia de aranha com uma aranha e na entregue há uma teia de aranha vazia.
7 meses depois do fluxo imaginário, o quadro se tornou inútil. Não reflete o fluxo de trabalho real está fadado a ser “largado” pelo time.

Você pode trocar essa aprovação da alta administração por qualquer etapa imaginária do fluxo que seja apenas um desejo ao invés de um fato.

Para fugir disso, utilize um princípio básico do Kanban. Comece com o que você faz hoje. Faça mudanças evolucionárias de forma colaborativa. O seu fluxo de trabalho é um reflexo da realidade e nunca o contrário.

Nomenclatura no Fluxo

Opções

Quando um stakeholder (cliente, gestores, product owner, product manager) apresenta um desejo, não saímos correndo para fazê-lo de forma atabalhoada. Antes, essa manifestação de desejo deve ser capturada, sintetizada e analisada até chegar o Ponto de Comprometimento quando ela passa a ser chamada de item de trabalho. Antes disso, no Upstream são apenas opções.

Item de Trabalho

Uma vez que a opção foi aceita e passou pelo Ponto de Comprometimento, ela recebe o nome de item de trabalho e são eles que navegam no Midstream e no Downstream. Eles são uma parte do produto ou serviço que eu consigo disponibilizar para o cliente. Por exemplo, uma História de Usuário

  • Hospital: um paciente
  • Pizzaria: Uma pizza
  • Software: uma funcionalidade ou modificação em uma funcionalidade existente
  • Jurídico: A petição ou o andamento do processo.
  • Marketing: Campanha em uma rede social ou um item de papelaria que será enviado para a gráfica.

Tarefas

Atenção, pois o item de trabalho pode ser “quebrado” em tarefas técnicas. Tarefas não são itens de trabalho, pois isoladamente não podem ser utilizadas pelo cliente. São exemplos de tarefas:

  • Hospital: aplicação de um remédio
  • Pizzaria: mussarela, tomate, massa (ingredientes isolados)
  • Software: criação de uma tabela no banco de dados, criação da interface (front end).
  • Jurídico: As partes de um documento peticional, uma ida ao fórum.
  • Marketing: Texto, imagem, wireframe (itens isolados)

Cada tarefa pode ser algo importante para compor um item de trabalho, porém eu não consigo entregar para o meu cliente essas tarefas isoladas.

Ponto de Recebimento da Demanda

Esse é um acréscimo ao artigo original, pois houve uma alteração na definição do Customer Lead Time. A partir de abril de 2023, ele passou a ser computado desde o Ponto de Recebimento da Demanda até o Ponto de Entrega. Esse primeiro é o momento em que o cliente manifesta a necessidade de ser atendido por um serviço que prestamos. Resumidamente é o momento em que ele faz o pedido e este pedido entra no nosso fluxo de trabalho.

Ponto de comprometimento

Aqui há um conceito importantíssimo. Em qual etapa do fluxo, você e seu time se comprometem a prestar o serviço para o seu consumidor (cliente, outros times ou outro stakeholder)? A partir de quando vocês dizem: “Ei, cliente, chefe, outro time, podem contar conosco para entregar este item de trabalho!”

O ponto de comprimento é uma forma de gerir expectativas do cliente ou stakeholders que consomem os serviços fornecidos pelo seu time. Pense nas seguintes situações: A) Qual é o ponto de comprometimento quando você entra em um hospital? B) Qual o momento de comprometimento quando você pede um serviço na TI da sua empresa? C) Qual é o ponto de comprimento quando você pede uma pizza por telefone?

Se você respondeu: A) Quando eu entrei no hospital; B) Quando eu abri um ticket; C) Quando a telefonista atendeu a ligação. Você errou. Essas são apenas manifestações da vontade do consumidor, são os pontos de recebimento da demanda, mas não indicam que o fornecedor do serviço se comprometeu com ele. Na verdade, os pontos seriam: A) após a triagem do paciente;  B) após análise, classificação e priorização do ticket; C) após combinar o pedido, forma de pagamento e endereço de entrega.

O ponto de comprometido é algo que deve ser definido pelo time (ou squad) em conjunto com clientes e stakeholders. Da mesma forma que não há casamento solo e o noivo tem que combinar com a noiva tudo antes e ambos devem estar de acordo para assumir o compromisso. O ponto de comprometimento entre o time e quem precisa do time deve ser um acordo.

Ponto de Entrega

Quando você entrega seu serviço? Isso também precisa ser definido com clareza. Quando o produto do seu trabalho sai da sua mão e chega na mão do seu cliente? Muitas das vezes não é você que realiza a entrega, mas seu mapeamento deve visualizar as etapas necessárias para tal para que você não fique com um monte de trabalho processado, sem que ele seja entregue ao cliente. Imagine que essa é a passagem de bastão (handoff) do seu produto entre sua organização para o seu cliente. 

Cuidado quando você presta serviços internos à organização. Por exemplo: infraestrutura de TI, manutenção predial, Gestão de Pessoas / Recursos Humanos etc. Nesses casos, seus clientes tendem a ser internos. Não caia na falácia dos resultados indiretos. Por exemplo, dizer que a nova fachada do prédio ajudou a aumentar o lucro da empresa em 5%. Pode até ser verdade, mas como você provaria isso? Se não tem uma relação direta, não invente.

Upstream

Uma vez que compreendemos o fluxo de trabalho, o ponto de comprometimento e o ponto de entrega, podemos ver os conceitos que facilitam o mapeamento e avaliação do fluxo.

Todas as etapas que estão antes do ponto de comprometimento compõem o Upstream (nascente do rio). Nela temos opções (ideias e pedidos) que estamos avaliando para ver se iremos ou não nos comprometer com as ideias. É comum que essas etapas compreendam as fases de captura de opções, síntese e análise. No upstream estamos preocupados em descartar as ideias ruins e detalhar as boas para que elas se tornem compromissos. As opções podem ser facilmente desconsideradas, pois ainda não há esforço e investimento de construção sobre elas.

Infelizmente ainda é comum essa parte do fluxo ser ignorada e as opções saírem de uma piscina de ideias e viajarem direto para o comprometimento. Acabamos com um monte de penduricalhos em nossos produtos e serviços que pouco ajudam a atender às necessidades dos clientes ou, até mesmo, atrapalham. Fora o refluxo (retorno do item) para esclarecimento porque é necessário mais compreensão sobre o mesmo.

Quando o Upstream é ignorado os itens tendem a viajar direto da Piscina de Opções (Product Backlog)

Quando os times (squads) não são ponta a ponta (responsáveis pelos itens de trabalho desde o upstream até o downstream) é possível que tenhamos times diferentes no upstream fornecendo serviço para o downstream. Por exemplo: o time de experiência do consumidor define o fluxo de uma aplicação que será construída por um time de desenvolvimento. O mesmo acontece no downstream quando o time de construção não é o mesmo responsável por fazer a entrega. Esse é um caso de dependência externa que trataremos um pouco mais a frente.

Midstream

Na literatura do Kanban não há um midstream. Para esse método, tudo que vem após o ponto de comprometimento é o downstream. Entretanto, nós da K21 preferimos separar este em dois. O midstream (leito do rio) é onde acontece o trabalho de construção. O Upstream transforma a ideia (opção) em um item de trabalho. O Midstream começa no Ponto de Comprometimento e transforma primeiro o item em um item de trabalho comprometido. Ao final do midstream temos um produto, serviço ou incremento de ambos.

Para exemplificar, quando estamos  desenvolvendo um software é o momento em que o item de trabalho (pode ou não estar no formato de história de usuário) se transforma em incremento do produto. No caso da pizzaria, é a pizza pronta, assada e embalada, no hospital é o paciente tratado e pronto para receber alta. Em contratos é o contrato escrito e pronto para ser assinado. Ou ainda, uma campanha de marketing é quando ela está pronta, só falta a publicação.

Downstream

Finalmente chegamos na foz do fluxo. É o momento em que o item é entregue (delivery) para o cliente. O software é disponibilizado para os consumidores, a pizza é entregue pelo motoboy ou motogirl, o paciente recebe alta e se despede na portaria do hospital, o contrato é apresentado para a assinatura do cliente e a campanha de marketing vai para o público. 

Nós preferimos separar essa parte do midstream porque ela, tradicionalmente, requer conhecimentos e processos específicos que não estão relacionados à construção. Embora não seja a melhor solução, em muitas empresas, esse serviço de entrega (delivery) é feito por um time diferente do de construção (midstream).

O problema da dependência externa

O ideal de um time / squad é que ele possua pessoas com conhecimentos, acessos e autorizações necessários para navegar do upstream até o downstream. O chamado time ponta a ponta. Quando isso não acontece, temos a dependência externa. Ela se caracteriza pela necessidade do item de valor ter que ir para uma pessoa, grupo ou unidade que não está contido no time que está construindo o produto. Eles são externos ao time.

Ficamos com vontade de encerrar o fluxo quando atingimos essa dependência. Em uma pegada no estilo: “se não há nada que eu possa fazer, logo não farei nada.”

Cena do filme mexicano Santa Claus de 1959 convertido em Meme. Nela vemos o diabo aparece atrás de uma criança de aproximadamente cinco anos parecendo sussurrar algo para ela. Acima vemos o texto como se fosse o diabo falando: “Não precisa mapear o downstream. Confia!”.
Não caia nessa armadilha

Não ver o problema não resolve o problema. Enquanto o seu cliente não tiver a possibilidade de utilizar o seu produto ou serviço, ele não produziu resultado (métricas de eficácia). Um produto ou serviço sem valor é um produto ou serviço sem valor. É apenas esforço e custo sem retorno. Sendo assim, as dependências externas devem ser mapeadas para que possamos visualizar problemas, gargalos e pontos de melhoria.

E no Scrum?

Você viu esse texto e pode estar se perguntando. Isso é bem Kanban. Não aparece enxerguei no meu Scrum. Todavia, isso também faz parte do Scrum. Está lá, porém normalmente exclusivo. Mesmo que você utilize um quadro básico com: A Fazer, Fazendo e Feito. Lembrando que o Scrum não te obriga a ter um quadro com apenas essas três etapas. Você pode e deve especializar o seu fluxo.

É o mesmo quadro visto anteriormente, porém com as colunas comuns em muitos Times Scrum. O detalhamento do quadro está no texto.
Quadro exemplificando o Upstream, Midstream e Downstream com o Kanban

Esse seria um exemplo de Fluxo do Trabalho do Scrum. As ideias surgem como uma piscina de opções e são armazenadas de forma despriorizada no backlog. A reunião de refinamento é justamente a etapa do fluxo em que as ideias (opções) são verificadas e avaliadas e ficam disponíveis para serem “puxadas” para dentro da Sprint durante a Sprint Planning. Se o time utilizar a Definição de Preparado (Definition of Ready – DoR), ao final do refinamento, o item de trabalho deve estar de acordo com ela.

O ponto de Comprometimento do Scrum é costumeiramente a Sprint Planning (Planejamento da Sprint). O ponto de entrega continua sendo quando o item se torna disponível para o cliente.

A pergunta que vem é: Quando posso considerar pronto? Há times que são ponta a ponta e o pronto deles é entregue para o cliente. Muitas vezes durante a execução da Sprint, assim que o item de trabalho se torna compatível com a Definição de Pronto (Definition of Done – DoD). É bom lembrar que o Scrum não diz que é necessário esperar a Sprint Review (Revisão da Sprint) para entregar um item de trabalho para o cliente. Se o item ficar pronto no primeiro dia da Sprint e não houver objeção do Product Owner (PO), o item pode ser entregue para o cliente.

Infelizmente o mais comum são times que não conseguem entregar seus itens de trabalho ao final da Sprint. O Definition of Done fica em algum lugar entre o Feito (construído) e a entrega para o cliente. A Sprint acaba, porém a entrega (downstream) continua até chegar na mão do cliente.

Curiosidade

Essa analogia do Fluxo de Valor como um rio foi criada pelo Rodrigo de Toledo, sócio fundador da K21, em 2011. A primeira versão foi feita no Power Point e ganhou o carinhoso apelido de: “Imagem do Riozinho”. Alguns a chamam de “Rio Nilo” porque as montanhas pareciam pirâmides. Tal observação agrada muito o criador da imagem 😀 #sqn. 

Parecido com o Fluxo do rio citado anteriormente, porém ao invés de Lean Organization temos a Palavra Kanban e abaixo da linha de Team temos o Scrum.
Imagem original do Fluxo de Valor desenhada em 2011.

Quer saber mais sobre Fluxo de Trabalho? Então assista à palestra Porque do Scrum ao Kanban!

Outros artigos dessa série

1 – Métricas Ágeis comuns ao upstream, midstream e downstream

2 – Métricas Ágeis: Upstream

3 – Métricas Ágeis: Midstream e Downstream

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.

Data storytelling. Se você acompanha o nosso blog, já deve ter percebido que eu gosto muito de trabalhar com métricas, dados e gráficos. É interessante, mas esses artefatos, apesar de serem interessantes, sozinhos eles não vão dizer muitas coisas. Você…

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

A criação de personas é um dos passos mais importantes no desenvolvimento de produtos, mas pode ser um desafio quando se trata de reunir dados e representá-los de forma precisa. Neste artigo, vou mostrar como usamos a inteligência artificial para…

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…