e podemos ser ageis....Sim, depois de alguns anos atuando fortemente com o processo iterativo e incremental, com ciclos cada vez mais curtos e feedbacks cada vez mais continuo, dentro de ambientes fortemente engessados, com processos certificados, percebi, na pratica, que podemos sim ser ageis com o escopo e prazo fechados. Talvez isso seja um dos golacos da inspecao e adaptacao dos proprios metodos ageis e das praticas encontradas nos milhares de contextos pelo mundo, que optou por processos mais enxutos, eliminio de desperdicio, foco no valor e mapeamento de fluxo.Os contextos que comecaram uma mudanca para o mindset Lean, perceberam que as praticas poderiam emergir do proprio contexto e direcionados, segundo os principios e valores deste tipo de gestao. Com uma serie de praticas identificadas, podemos avaliar o contexto e, pela nossa experiencia, identificar rapidamente sugestoes que possam melhorar aquele contexto particular. Continuamente, aplicando a inspecao e adaptacao, identificamos e eliminamos praticas que nao agregaram valor ou nao serviu para reduzir os desperdicios, e inserimos novas, para mais um ciclo de avaliacao de hipoteses.Qualquer semelhanca com o metodo cientifico, nao e mera coincidencia.Mas como fazemos praticamente?Quando mapeamos o fluxo e facilitamos a conversa do time de desenvolvimento com quem conhece do negocio, comecamos a perceber algo muito interessante. A informacao flui bidirecionalmente entre as duas partes e o aprendizado e aproveitado pelos dois.Mas em que momento?Bem, temos um documento biblia de escopo com 250 paginas onde, Analistas de Negocio (AN) cascata, acham que conseguiram cumprir uma missao bem complicada e que durou longos 3 meses de muito trabalho, com muitas horas extras. Ao terminar, o AN acredita que gerou um artefato de muito valor e nao "sera mais incomodado" pelos desenvolvedores e pode ir feliz para mais 3 meses para escrever outra biblia.E o ciclo continua.Quando rodamos este modelo sob a otica da inspecao e adaptacao continuas, observando a teoria dos sistemas, olhando para o todo e com as atividades mapeadas, percebemos que a coisa nao funciona desta forma.Em equipes de alto indice de qualidade, com processos bem definidos que garantem esta qualidade, 99.9% dos bugs em homologacao e producao, tem origem em um mal entendimento de uma regra, que poderia estar mal escrita. Quando analistas de negocios e desenvolvedores analisam este bug, a informacao esta tao envelhecida, que ambos levam dias e as vezes semanas para entender e resolver. Este processo so piora quando quem analisa e corrige sao outras pessoas, o que acontece em quase todos os contextos tradicionais.So para evitar este desperdicio, o trabalho do AN dedicado ja se paga.Nao e so isso. Algo mais interessante acontecera.Quando sugerimos uma nova proposta, aumentando a disponibilidade do AN para o time durante o processo inteiro e, conseguimos um tempo diario do AN para realizar um breakdown do documento biblia de escopo em epicos e historias pequenas, autocontidas, testaveis..., nao e raro o proprio AN encontrar problemas de entendimento e regras mal definidas por ele mesmo.Nao e incomum o AN afirmar que este breakdown e o mapeamento das historias sobre a mesa, com post-its, absolutamente low tech, lhe deu uma visao que