Princípios do Manifesto Ágil

Os títulos são baseados na tradução do manifesto ágil, disponível em agilemanifesto.org.

O manifesto ágil foi entendido em 2001, e muitos dos princípios ainda estão sendo vivenciados por equipes e empresas que não perceberam a natureza de fazer código e processos como evolução técnica, do negócio e da nossa habilidade em construir e manter código.

Nenhum dos princípios presentes no manifesto ágil perdeu sua validade nos dias de hoje, falando em 2025, na escrita deste texto. Quando vejo alguém falando mal de algum destes princípios, pode ser uma crítica desde sempre, por perspectivas que eram problema na indústria e que seguiram assim na escrita do manifesto. Ou reconheço alguém que ainda não parou para discutir a natureza do “fazer um produto de software”.

No final do dia, queremos aprender com nossos clientes e nossa equipe, melhorar e entregar valor de forma continuada e ainda encontrar um ritmo sustentável para realizar esta entrega de valor.

Quando falo que precisamos operar sistemas e não apenas tarefas, é podermos entender e detectar ao longo do processo o que significa satisfazer clientes. A entrega contínua de valor não é apenas um fazer e entregar coisas. Envolve compreender uma mistura entre missão, métricas, modelos de funcionamento, que ajudam a entender como uma empresa está operando e o que ela está fazendo dentro do contexto de operação. Queremos gerar resultados.

Uma empresa de logística vai fazer uma série de movimentos que podem ser diferentes de uma empresa que atua no mercado de educação. Competição, métricas e oportunidades precisam estar conectadas com o contexto. Não é simplesmente usar uma tecnologia escolhida pela empresa e teremos sucesso.

Uma equipe atuando de forma multi disciplinar vai ter especialidade em negócio e também em tecnologia e também em design. Essa junção, ao invés de ter apenas pessoas desenvolvedoras tirando pedidos e construindo telas, nos habilita a pensar em jornadas de valor que podem ser avaliadas e priorizadas, baseadas nas métricas que vão nos apoiar dentro do contexto de clientes.

O que as equipes de clientes que estamos atendendo estão tentando alcançar? É uma nova linha de receita? Se aproximar da concorrência? Se diferenciar da concorrência? É um olhar puramente técnico, onde se quer mais capacidade de evolução do software? São muitas possibilidades!

A capacidade de uma equipe em dividir o problema em pedaços menores, de encontrar padrões com o que aprendemos sobre o contexto, sobre o mercado e sobre adjacências, tudo isso se encontra nesta busca na entrega de valor. Logo, não é puramente um trabalho de entender uma quantidade de horas de uma pessoa desenvolvedora focada em tela e outra pessoa focada em integrações.

Existe um cuidado, de base, com atividades de priorização e organização do direcionamento da equipe.

E sobre as métricas a serem consideradas! A melhor de todas? Entregue antes. O pensamento de entregar mais do que o cliente pediu ou espera não faz sentido. Entregar o que está combinado de forma antecipada é também parte do processo de gerar valor. E nos permitirmos entrar logo no modo de experimentação.

Responder a mudanças mais que seguir um plano. Esse é um dos valores e a conexão com este princípio reflete a nossa necessidade de estar medindo e entendendo os movimentos que estamos fazendo. Se estamos evoluindo o software, deve existir um motivo de negócio relacionado.

Quando aparecer a necessidade de mudar, deve ser natural. Por entendermos que precisamos mudar a direção com base em alguma métrica que estamos acompanhando. Ou através de feedbacks que estamos recebendo de quem está usando o produto no mundo real.

Este princípio deveria operar para a fluidez e responde um processo comum nas “fábricas de software” no final dos anos 1990 e início dos anos 2000, onde a mudança era mais cara do que um item planejado no início do projeto. Esse comportamento causava uma grande lista de funcionalidades que eram inúteis, pois não tinham sido validadas no mundo real. Uma série de funcionalidades eram desenvolvidas e nunca utilizadas, e por vezes equipes tinham que manter uma lista de funcionalidades e uma base de dados gigante, convivendo com partes do sistema que nunca eram usadas nem eram testadas por pessoas no mundo real, pois os ciclos de entrega eram muito grandes.

Queremos entregas frequentes e permitir a mudança de direção conforme o aprendizado com o mundo real acontece. Fazer o necessário e também mudar o quanto necessário seja.

E lembrar que nem sempre estamos falando sobre mudanças de requisitos funcionais. Pode ser uma questão de mudança de tecnologia ou evolução de tecnologia. Poderíamos de uma mudança interna ou não funcional. E precisamos ter racionalidade neste processo também.

Certa vez ouvi de uma pessoa que ela não via motivo para trocar uma tecnologia, por não fazer diferença para o negócio. Eu estava muito irritado com o retorno. E esta pessoa estava certa. Naquele momento, a equipe de desenvolvimento tinha permissão de fazer entregas trimestrais apenas. Não era necessário sermos capazes de fazer entregas em poucas semanas ou dias. Nem era necessário gerar alguma inovação e a dívida técnica não era um problema que indicasse a necessidade de mudança.

Esse cenário foi uma exceção da maioria das experiências que eu vivi profissionalmente desenvolvendo software e acompanhando equipes. Vivo uma necessidade de acomodar mudanças e ajustar caminhos enquanto blocos maiores de desenvolvimento estavam acontecendo.

Alguns clientes estavam esperando o resultado destes blocos maiores de trabalho, enquanto outros estavam aguardando pequenos ajustes em jornadas que estavam impactando a experiência e a produtividade de uso. Particularmente, eu prefiro viver ambientes onde sempre estamos tocando produção com atualizações de software, evoluindo pequenos pedaços em cada ajuste.

O cenário que vivi no contexto de evolução trimestral, era entregar tudo junto depois de três meses e ficar duas a três semanas olhando e analisando o impacto das mudanças em produção. O sentimento era de suspense neste contexto e de um outro lado torcendo para que todas mudanças, quando colocadas em conjunto, fossem capazes de entregar o resultado esperado.

E a mudança de tecnologia? Como ficaria neste caso de atualizações frequentes? Caso a mudança de tecnologia ajude na manutenção de software, na testabilidade e automação, na manutenção, então se ganha prioridade. Se resolver dívidas técnicas presentes e de certa forma ajuda a equipe em operar de forma mais tranquila nas suas abordagens de observabilidade e monitoramento, ganha pontos também.

A manutenção de software nos habilita em tornar as soluções mais simples e poder conduzir novas evoluções de forma mais simples. Construir software pensando em continuidade, capacidade de manutenção e extensibilidade sempre vai ser algo positivo e bem vindo em equipes que faço gestão. Melhor ainda se for um princípio da equipe presente desde o início.

Um dos motivos de eu ser um defensor do modelo de Trunk Based Development (TBD) é querer garantir que em qualquer momento podemos avançar o que temos para produção. E precisamos garantir que funcione e esteja preparado para funcionar. E o que não estiver preparado para funcionar, vai ter seu comportamento desligado por alguma estratégia da equipe de desenvolvimento, seja por configuração formal ou alguma estratégia como Feature Toggle (FT) ou Feature Flag (FF).

Reduzir o tempo que demoramos entre ter uma ideia e conectar essa ideia sendo utilizada, conectada com o mundo real. Não basta somente ter a ideia concebida, sem ninguém fazendo uso da mesma. Queremos materialidade, queremos interagir com a realidade.

O nosso processo de liberação depende muito das técnicas que estamos utilizando para defender o progresso. Teremos itens que vão demorar mais tempo para ficar pronto e itens mais rápidos. Itens que precisam de revisão ao longo do tempo, ou apenas ajustes menores que precisam de uma validação.

O importante no ciclo de liberação e entrega de software é saber quem vai validar, e saber o que significa software funcionando. Definido isso, como sabemos que estamos prontos para liberar para mais pessoas usarem?

Em alguns casos, depois da primeira validação, podemos fazer a liberação de uma funcionalidade por configuração, onde cada cliente pode ativar conforme o seu interesse. Ou ainda alguma estratégia onde a funcionalidade ou novo comportamento vai estar presente para um percentual de pessoas, e ir evoluindo ou retraindo conforme formos recebendo feedbacks positivos ou negativos do novo item em funcionamento.

Pessoas de negócio e os diferentes papéis que as pessoas desenvolvedoras podem executar dentro de projetos. Ao conhecer sobre o negócio, os papéis podem contribuir de formas bem mais efetivas:

• Pessoas gerindo o produto podem entender como escolher métricas e quais desafios são os mais importantes, seja para diferenciação em mercado ou para aproximação de concorrência. Conectar modelo de negócio com a realidade das demandas e tendências.
• Pessoas que fazem análise de negócio podem entender de clientes e trabalhar em detalhamento para o que estiver sendo priorizado. Detalhar o trabalho de descoberta e entender como fatiar o trabalho a ser realizado para gerar entregas contínuas que podem permitir validar o trabalho realizado. O trabalho de entender como lidar com critérios de aceite e preparar os cenários a serem desenvolvidos. E também priorizar quais cenários são essenciais e quais conseguem demonstrar maior valor, baseado no que está sendo priorizado com clientes.
• Pessoas com habilidades de teste podem refletir sobre cenários que vão precisar nas diferentes formas de verificar o trabalho realizado, seja em desempenho, carga, validação funcional e outras possibilidades. Até inclusive pensar em alguma jornada fim a fim, que pode ser substituída por validação de contratos e de pequenas partes da jornada. As diferentes estratégias de teste precisam ser conhecidas pela equipe.
• Que história você está transformando em mundo real com a sua ferramenta de construção? Como você garante que está implementando o que precisa ao tempo que consegue ter um cenário válido para demonstrar que existe um problema sendo resolvido no mundo real? Pessoas desenvolvedoras devem conseguir identificar o que pode ter faltado nas diferentes definições que vieram até o momento sobre uma funcionalidade, e podem trabalhar em conjunto com os outros papéis existentes para identificar o que precisa melhorar ou eventualmente cenários que não foram considerados. Estamos aprendendo continuamente?
• Como o trabalho realizado chega em produção? A primeira atividade de um projeto deveria ser uma instalação em produção. Garanta que você possui fluidez entre trabalho realizado e disponibilidade para clientes poderem validar e usar no mundo real. A validação antecipada gera mais confiança para a equipe e habilita novos fluxos, ao tempo que reduz ou remove riscos técnicos e habilita a validação de riscos de negócio.

O trabalho de desenvolvimento é cíclico, mas dentro dele existe uma grande quantidade de rabiscos, ajustes, idas e voltas pelos diferentes papéis e habilidades que se destacam. No fim, as pessoas de negócio conseguem comprovar se aquilo que foi desenvolvido gera o resultado que era esperado, através de métricas e outras estrutruas que foram estabelecidas com clientes.

Trabalhar junto com as pessoas de negócio deveria fazer deixarmos de ser pessoas orientadas a tarefas e ao simples fazer. E aí então nos permitir entender os sistemas existentes e sermos mais questionadores sobre o que acontece. Queremos o melhor uso do tempo da equipe e dos clientes. Queremos conectar com o mundo real, da forma mais antecipada possivel.

O melhor que as pessoas gestoras podem fazer? Não atrapalhar. O ideal é que elas pareçam invisíveis dentro do processo de trabalho. Devem aparecer onde existem problemas e resolvem os problemas, reabilitando equipes a seguirem seu fluxo.

Toda vez que uma pessoa gestora quer chamar mais atenção que a equipe e se colocar como indispensável ou extramamente necessária para que algum trabalho seja realizado, se falha em não lembrar que a gestão e as ações de liderança tem como objetivo principal desenvolver as pessoas. Ter pessoas motivadas não se refere a ter torcida e placas com os nomes da equipe, mas sim um ambiente que permita que as pessoas tenham o seu melhor desempenho. Equipamentos de trabalho, tempo calmo para poder focar e realizar seu trabalho. Expectativas claras sobre a missão a ser desempenhada. Tudo isso influi no dia a dia, no trabalho realizado e no potencial de realização das pessoas.

A outra questão é como a palavra confiança é trabalhada internamente. Reflete a quantidade de interferência e perguntas realizadas no caminho do trabalho. Ter conversas para validar andamento e necessidades de apoio, nada mais é do que uma cadência e combinação que é possível de se fazer.

Disso para existirem conversas específicas, microgerenciando pessoas e querendo entender em detalhe questões que não determinam se o trabalho vai ser concluído ou se o resultado esperado vai ser alcançado, existe uma grande distância. Falta de confiança será uma das maiores forças removedoras de motivação de uma equipe. A desconfiança e a falta de cuidado em entender que a equipe tem responsabilidades e capacidade de cuidar do trabalho.

Confie nas pessoas. Confie nos fluxos de entrega e na habilidade de melhoria contínua. Busque cadência e garanta que você, quando estiver no papel de gestão ou liderança de um trabalho deste tipo, esteja presente nas dificuldades indicadas pelas equipes e principalmente atuando na resolução.

Eu considero muito relevante atividades de sincronismo, mas valorizo muito a nossa capacidade de comunicação e de operação em “tempos calmos”. Eu gosto muito de trabalhar no meu tempo. Tem gente que se você chamar para um café no final de uma manhã vai surtar e questionar como você tem capacidade de funcionar pela manhã. Outras pessoas podem questionar se poderia ser mais cedo.

Aqui falo sobre a importância de entendermos os tempos das pessoas e das formas de interação. Uma conversa limpa, sem informações prévias, pode ser bem ruim. Por outro caminho, podemos ter uma estrutura de leitura e estudo antecipada, antes do encontro face a face. Ainda, podemos organizar atividades educacionais e de aprendizagem, que podem operar de forma presencial ou de forma gravada, sob demanda. Novamente, as estruturas de aprendizagem são diversas.

Entender os tempos de cada pessoa e seu funcionamento é algo relevante e vai acontecer com o processo de trabalhar e interagir com as diferentes pessoas da equipe. Encontrar os momentos onde podemos marcar atividades de pareamento e momentos onde vamos operar de forma solo. E ainda tem os momentos onde precisamos ter energia para atuar como equipe. Engajar em reuniões e discussões pode ser um trabalho que demande muita energia de algumas pessoas. Então, organizar o planejamento do dia também vai ser uma atividade de rotina tão importante quanto dormir e se alimentar.

Se atividades de grupo vão tomar a sua energia, cuide para não agendar sessões de pareamento logo depois. Prefira alguma atividade solo, de organização ou estudo, que possa ajudar você a recuperar um pouco do fôlego.

As conversas face a face ou chamadas de áudio com compartilhamento de tela são conversas que importam para o nosso progresso ou para nos colocar no mesmo ponto de outra pessoa. Precisamos valorizar estes momentos e viver eles com a maior intencionalidade possível.

Costumo indicar para as pessoas das equipe se unirem nos momentos pré início de trabalho. Considerar a definição de preparado. Um apoio para garantir que a atividade vai iniciar da melhor forma possível. Mesma coisa vale para entender a definição de pronto, e como um trabalho vai ser validado e dado como concluído.

Agora, reforço que talvez antes de fazer uma conversa síncrona, seja importante que as pessoas consumam algum material, que se preparem. Então não é o simples fato de nos encontrarmos em uma chamada de vídeo que faz a diferença. É a intencionalidade e o trabalho de preparação. E quando isso começar a fazer sentido, você vai também notar que pode existir muita potência nas interações não simultâneas. E assim vai poder entender qual modelo pode ser mais útil conforme o contexto.

Já foi algo bem difícil de ver acontecendo. Muitas vezes as entregas eram documentações e somente poderíamos usar algo de verdade bons meses depois do início.

E aí temos uma série de iniciativas que buscam a entrega de software em produção. Melhorou. Parece.

Não queremos simplesmente software colocado em produção. Queremos software em utilização. No mundo real. Muitas horas por dia. Assim temos conexão com a realidade acontecendo e noção do que acontece com o trabalho realizado e entregue.

Muitas vezes o “em funcionamento” é confundido com o “disponível para uso”. E não quer dizer que funciona como deveria funcionar.

Existia uma época em que funcionalidades eram homologadas por alguém que não usava o produto no mundo real, e depois do faturamento aceito, é hora de se movimentar para o próximo desafio. A partir daí, quando a funcionalidade era utilizada no mundo real e detectava a necessidade de mudanças, aparecia o “change request”. A requisição de mudança mais cara, em alguns casos custava o dobro, pois eram modificações depois da homologação aprovada daquilo que foi desenhado meses antes. O mundo da entrega de software pode ser cruel. E acredite, ainda existem clientes fazendo contrato assim por aí com seus fornecedores de tecnologia.

Quando estamos atuando para resolver problemas ao invés de entregar tarefas, estamos preocupados com resultado gerado com a solução em prática, e não com as tarefas projetadas. É o famoso “outcome” (resultado) mais importante que o “output” (saída).

Para isso acontecer precisamos não só saber o que deve ser feito, mas entender o problema que devemos resolver. E mais que isso, precisamos entender que métricas nos indicam que a nova funcionalidade ou a nova entrega geraram o resultado esperado. Pode ter informações subjetivas, mas precisamos ter uma conexão objetiva com o mundo real.

A tal “agilidade em negócios” era algo disponível desde o início das metodologias ágeis. Em algum momento as equipes se perderam, valorizando métricas intermediárias, como tarefas realizadas, e não mais as métricas de negócio, de geração de valor, como por exemplo faturamento, satisfação e outros resultados de negócios que podemos mapear.

Ter um ritmo sustentável não deveria ser algo opcional. Deveríamos ter trabalho consistente e consciente acontecendo. E garantir que a equipe tem uma visão da necessidade de ver vida. Em tempos onde trabalhar longas horas parece ter virado pré-requisito e demonstração de responsabilidade, esquecemos da diferença entre ser uma pessoa produtiva e ser uma pessoa simplesmente ocupada e sem gestão alguma sobre o próprio tempo.

Precisamos de perguntas, espaços para pesquisas. E também de vivências fora do objeto direto ligado ao projeto. Nossas visões criativas acontecem a partir da junção de informações que temos acesso e vivemos. Além da nossa capacidade de cuidar do que é básico, da nossa vida e dos nossos movimentos de aprendizagem e relações.

Aqui, mais importante de tudo, entra o cuidado com a fisiologia. Com a qualidade de tempo dedicado ao trabalho. Alimentação, sono, consumo de água e outras questões. Queremos fluxo de entrega e queremos encontrar isso através de padrões. Queremos padrão de produção, exemplo 4, 6 ou 8 horas por dia. Queremos entender como a nossa equipe opera nestes formatos. Que pessoas deveriam ter mais tempo disponível para produzir. Quais pessoas deveriam ter mais tempo para apoiar outras pessoas nos seus processos? Qual a capacidade de entrega que as equipes possuem? A partir disso, entendermos como podemos avançar para entregar mais valor para clientes, mais qualidade e cadência.

Em equipes que eu atuei e busquei trazer esta disciplina, se tornou um problema ter horas extras. Estas vão fazer a equipe quebrar seu padrão de trabalho. Com qual motivação? Isso não quer dizer que não iremos fazer horas extras em formatos eventuais, por alguma grande oportunidade de entrega antecipada ou algum incidente que precise de apoio e presença da equipe. De todo modo, iremos zerar esta quantidade de horas extras que foram realizadas assim que possível. Queremos cadência, minimizar variabilidade e gerar vazão constante de trabalho resultado.

Queremos entregar somente o necessário. E também queremos trabalhar o necessário para garantir o máximo de produtividade e o máximo de qualidade possível no trabalho realizado.

Não deixar a dívida técnica tomar conta, mas talvez pediram para escrever diferente.

O ponto é que todo código que não tem manutenção pode ter decisões de design que não funcionam bem ao passar do tempo. Pode ser que o produto tenha crescido, escalado, que as tecnologias mudaram, que os requisitos não funcionais de desempenho tenham ficado mais específicos.

Todo movimento com produto e clientes atendidos precisa refletir no código. Não adianta refletir em melhoria de experiência de navegação, mas ter demora em processamento e fazer pessoas ficarem esperando onde não pode ter espera. Nem faz sentido querer processamento instantâneo e falir a empresa em pontos do produto onde processamento não simultâneo (assíncrono) era mais que necessário. Isso também faz parte do processo de manutenção e atenção contínua ao produto e ao mundo real.

Para simplificar. Todo código que cresce precisa ter métricas de acompanhamento, como capacidade de extensibilidade e capacidade de manutenção. Nos dias atuais, nosso código precisa ser construído de uma forma emergente, pois não sabemos exatamente para qual lado precisaremos escalar ou criar estratégias de assincronia ou paralelismo de processamento.

Tomar estas decisões muito cedo no projeto pode funcionar se você tem um financiamento infinito ou gosta de grandes apostas. Agora, normalmente no mundo real, as equipes tem poucas pessoas e o dinheiro disponível é pequeno. Logo, a infra não poderá custar muito, nem deveríamos demorar muito tempo para fazer algo e levar para o mundo real.

A única certeza é que não vamos nos livrar da dívida técnica. Ela vai aparecer de forma acidental ou forma intencional. Acidental, quando achamos que aquela é uma boa decisão, mas um pouco a frente se torna uma decisão ruim. Ou intencional, devido alguma restrição de arquitetura ou em alguns casos, uma simples falta de tempo. E tudo com testes, lembre. Ter testes significam que você respeita o seu trabalho. Não significa que a dívida técnica se resolve. Ela pode estar controlada pelos cenários que você está garantindo.

Tudo isso nos faz criar estrtuturas que nos permitam manter a manutenção o mais leve possível, e facilitada pelo maior tempo possível.

A arte de maximizar o trabalho que não precisa ser realizado. A simplicidade se apresenta sempre que temos a chance de resolver um problema sem precisar fazer algo novo.

Se é que precisamos resolver o problema pela perspectiva sendo estabelecida até o momento.

Será que realmente precisamos mudar algo? As ferramentas atuais e métricas presentes não resolvem ou não nos indicam o que precisa ser realmente resolvido? Ou somente adaptação de algum processo?

Outra visão que gosto de trazer no contexto da simplicidade é sobre realizarmos o necessário. E somente o necessário. Existe uma conversa sobre surpreender clientes, entregar além do que foi pedido. Primeiro, entregue o que foi contratado e combinado com clientes. Quer surpreender? entregue valor de forma antecipada. Entregar antes o que foi combinado.

Muitas vezes queremos mudar “aparência”, mas a nossa essência segue quebrada. De nada vai adiantar, se os seus comportamentos como equipe seguirem tóxicos. De nada adianta conquistar um selo, premiação ou certificação, se na hora que um problema se apresenta a equipe se comporta de uma forma que nada representa um funcionamento de excelência.

Em trabalhos de priorização de funcionalidades em software, atuar na simplicidade é encontrar formas de fatiar as entregas de valor de modo a conseguir demonstrar progresso, validar hipóteses, com o mínimo necessário.

Encontrando caminhos de comunicação com clientes e usuários que são alvo do sistema em questão, podemos gerar muita informação de apoio, para tomar melhores decisões. E tornar o processo de descoberta mais simples.

Quais papéis você sabe desempenhar? Qual papel precisa da sua atuação agora? É mais visual ou mais questionador? É mais mediação ou mais mão na massa, realizando uma prova de capacidade? Removendo um risco técnico? É realizando uma entrevista para uma vaga ou trazendo uma nova reflexão ou um novo conceito?

Você pode ter uma equipe com cargos e responsabilidades exatamente definidas, mas isso pode limitar a capacidade de colaboração. Ter cargos nada tem a ver com capacidade de colaborar. A menos que as pessoas não queiram criar estes espaços. Aí você vai ter um contexto que joga nos cargos a incapacidade de colaborar.

Entender, para cada desafio, com quais habilidades você vai se responsabilizar e com quais vai apoiar e quais tem interesse em se desenvolver. Com essa combinação, pode gerar resultados melhores e habilita esse movimento de auto organizar, ao tempo que ajuda outras pessoas a se desenvolverem.

No fim do dia, queremos uma equipe mais robusta, melhor capacitada e melhor entendida sobre os diferentes aspectos de resolução de um problema de negócio com o uso da tecnologia e do trabalho em equipe.

Se organizar não significa obrigar a multi disciplina. Isso é importantíssimo. Ter limites sobre lugares onde você não vai chegar. Isso ajuda inclusive a saber quem chamar em caso de necessidade de ajuda.

Colaboração não é uma necessidade. É uma oportunidade. É dar espaço para o conhecimento coletivo. E para o desenvolvimento de habilidades e de novos conhecimentos. É um espaço de prática.

O se auto organizar é também uma oportunidade. De saber a hora de puxar a liderança e a hora de seguir alguém que também pode ser capaz de resolver o problema, mas eventualmente necessita da sua mentoria para “fazer melhor” ou ganhar uma parte de prática que antes não estava presente. E assim seguimos, voltando a questão do conhecimento, transformando conhecimento tácito em explícito.

A melhoria contínua não é opcional. E refletir sobre como podemos melhorar nossos processos e ferramentas deve ser uma responsabilidade compartilhada.

Os tempos de reflexão são diversos. Queremos análises sobre métricas de trabalho, sobre evoluções de capacidade, de produtividade, de qualidade. Por vezes é necessário priorizar o olhar de medição e de melhoria, dentro da disponibilidade de tempo, qualificação técnica da equipe e habilidade em mudar. Ter uma mistura de humildade e consciência é bem vinda nestes momentos. No fim, queremos consistência.

A partir de ações de reflexão, não temos necessariamente melhorias. Temos reflexões, hipóteses, testes, possibilidades! Não precisamos querer ter certeza de todas as melhorias a serem realizadas, nem necessariamente copiar ideias de livros e outros lugares. Diria até que estes casos, de ir pelo “by the book”, dizem mais ainda sobre a necessidade de testar e validar o que está sendo aplicado.

A partir dos aprendizados, o ideal é que os acordos sejam revistos e por vezes os acordos servem para fortalecer alguma prática que acontece de forma eventual, não somente para documentar ajustes e melhorias. Por vezes precisamos formalizar alguma prática que acontece no dia a dia, mas de forma eventual, como opções e práticas disponíveis para a equipe.