Upstream e downstream no Kanban
Olhar, mapear e agir sobre os processos do time de desenvolvimento sem dúvidas pode proporcionar uma série de benefícios. Alguns exemplos destes benefícios são o ganho de previsibilidade, a otimização do tempo utilizado para execução das demandas e etc.
No entanto ter uma visão sistêmica, que vai além do fluxo de trabalho do time de desenvolvimento, pode revelar oportunidades ainda maiores de otimização dos processos.
Seguindo esta linha, upstream e downstream são conceitos importantíssimos para quem deseja entender o mundo além do fluxo de desenvolvimento.
O que é?
Upstream são as etapas do fluxo de trabalho que tem o objetivo de amadurecer e validar ideias antes de aplicá-las no mundo real.
Já o downstream se refere à todas as etapas seguintes do fluxo de trabalho a partir do backlog de itens gerados no upstream.
Podemos considerar um quadro kanban end-to-end, que contempla tanto o upstream como o downstream, como algo semelhante ao exemplo abaixo.
Obs: o quadro que representa o fluxo de downstream costuma ser chamado também de delivery kanban.
Pra que serve?
Considerando que a visão sistêmica não costuma ser algo inerente aos membros de um time de projetos e que por vezes precisa ser trabalhada, é comum encontrar equipes onde a gestão de processos visa somente a otimização de fluxo do downstream.
Um exemplo são times onde o controle de métricas tem como objetivo somente redução de Lead Time, visando encurtar o tempo entre as entregas.
Entretanto, olhar para o upstream pode proporcionar oportunidades de otimização de fluxo muito maiores.
É possível trabalhar em processos de “triagem” de ideias que podem eliminar demandas antes de irem para o time. Isso gera economia de tempo e consequentemente de custo.
Além disso trabalhar tanto o upstream quanto o downstream permite balancear a capacidade de produção com o ritmo das solicitações, prevenindo desperdícios.
Como funciona esta triagem de ideias?
Avalia-se o valor da ideia para o negócio e qual objetivo ela pretende atingir. No caso de ideias ou objetivos onde se tem muitas dúvidas sobre o que precisar ser construído, criam-se opções de solução.
O objetivo é que estas opções recebam mais especificações enquanto são apenas hipóteses e evoluam junto com o conhecimento do produto, técnico e de negócio envolvido. Enquanto é apenas uma hipótese, esta opção pode voltar etapas do fluxo ou até mesmo ser cancelada.
É mais barato trabalhar estas incertezas enquanto a demanda é apenas uma hipótese, pois assim que algo começa a ser construído a mudança de direção ou descarte se torna mais caro. Por isso, uma vez no downstream, deve-se entregar o que foi solicitado o quanto antes dando espaço apenas para refinamento da proposta inicial.
Limitando as opções
É comum encontrar nos quadros de upstream limites mínimos para a quantidade de opções, diferente dos quadros de downstream que costumam utilizar um limite máximo em suas colunas.
Este limite mínimo serve para garantir que existam opções suficientes para serem validadas. Algumas das opções serão descartadas durante o processo e outras permanecerão por fazerem mais sentido na solução do problema proposto.
Neste nível de maturação, torna-se menos custoso realizar ações de prototipagem e detalhamento de requisitos das opções já que algumas delas já foram descartadas.
Em resumo, faz-se um pequeno esforço inicial para validar as opções disponíveis e posteriormente um esforço maior para validar as opções que se provaram mais interessantes.
Balanceando a capacidade entre upstream e downstream
É provável que inicialmente a quantidade de opções criadas no upstream e a vazão do time no downstream não estejam alinhadas. Eis alguns dos problemas no desbalanceamento entre eles:
- Um upstream que entrega opções além da capacidade de vazão do downstream, acaba por gerar um backlog muito extenso onde algumas demandas se tornam obsoletas enquanto aguardam serem atendidas (Big Design Up Front / BDUF);
- Contrário ao cenário anterior, pode ocorrer também do time no downstream conseguir dar vazão as demandas além da capacidade de gerar novas opções do time no upstream. Isso gera variação no ritmo de entrega, já que normalmente o time no downstream interrompe sua operação para dar apoio ao upstream, resultando em falta de previsibilidade.
Para evitar estas situações, é interessante definir o número mínimo e máximo de opções para o upstream da mesma forma como se implementa a limitação de WIP no downstream, experimentando opções e ajustando conforme necessário.
Assim, o time e/ou o cliente envolvidos no upstream saberão o mínimo a ser produzido para evitar starvation do time de desenvolvimento (falta de demandas para serem trabalhadas) e o máximo a ser produzido para garantir que não estão gerando desperdício.
A relação time de desenvolvimento x design de solução
Como apresentado no tópico anterior, a falta de balanceamento nas capacidades do upstream e downstream pode ser prejudicial para a cadeia de valor como um todo.
Além da limitação na quantidade de opções e itens de trabalho, é necessária também uma abordagem diferente em relação as pessoas envolvidas.
O time de desenvolvimento
Num sistema Kanban end-to-end, considera-se que o time de desenvolvimento pode ser mais do que um executor de tarefas e trabalhar pro-ativamente nas solicitações que atende.
É importante que o time esteja alinhado aos objetivos de negócio e possa colaborar com o design da solução. Principalmente quando o upstream apresenta um delay na criação de opções em relação a vazão do time de desenvolvimento e portanto precisa de apoio.
Design de solução
Neste perfil cabem, além dos colaboradores responsáveis por idealizar as soluções que serão desenvolvidas, os clientes.
Torna-se papel deles passar a puxar valor ao invés de empurrar demandas para o time. Isso é alcançado validando hipóteses e aplicando somente o esforço necessário as que se mostrarem mais propensas a atingir o objetivo proposto.
Cabe a eles entender que respeitar as definições propostas irá gerar menos desperdício e um ritmo mais estável de entregas.
Conclusão
Um sistema de Kanban que enxerga somente o downstream, reduz o lead time e proporciona melhoria na previsibilidade. Isto deve ser visto como um benefício interno.
A utilização de um sistema Kanban end-to-end, que considera tanto o upstream quanto o downstream, tem como objetivo promover tanto benefícios internos como externos. Além da visão do time, a ideia é priorizar a integração com o cliente e o time de design de solução para promover um fluxo sustentável.
Este fluxo só consegue ser sustentado a longo prazo quando o cliente puxa valor ao invés de empurrar solicitações.
Um fluxo estável de demandas junto de um fluxo estável de trabalho, gera um fluxo estável de entrega.
Agradecimentos
Agradecimento especial ao Cleiton (Caco) Luis Mafra que me ajudou com exemplos de integração entre upstream e downstream do seu dia-a-dia e me apresentou o termo Big Design Up Front e ao Celso Martins pelas informações e discussões no Slack da agilidade.org. Gratidão!
Fontes
https://www.significados.com.br/upstream/
Essential Upstream Kanban — STEYAERT, Patrick