Existe vida no escopo fechado
Autor: Celso Martins | Publicado: 2014-04-12T17:13:00-03:00

e podemos ser ágeis....

Sim, depois de alguns anos atuando fortemente com o processo iterativo e incremental, com ciclos cada vez mais curtos e feedbacks cada vez mais contínuo, dentro de ambientes fortemente engessados, com processos certificados, percebi, na prática, que podemos sim ser ágeis com o escopo e prazo fechados. Talvez isso seja um dos golaços da inspeção e adaptação dos próprios métodos ágeis e das práticas encontradas nos milhares de contextos pelo mundo, que optou por processos mais enxutos, eliminio de desperdício, foco no valor e mapeamento de fluxo.

Os contextos que começaram uma mudança para o mindset Lean, perceberam que as práticas poderiam emergir do próprio contexto e direcionados, segundo os princípios e valores deste tipo de gestão. Com uma série de práticas identificadas, podemos avaliar o contexto e, pela nossa experiência, identificar rapidamente sugestões que possam melhorar aquele contexto particular. Continuamente, aplicando a inspeção e adaptação, identificamos e eliminamos práticas que não agregaram valor ou não serviu para reduzir os desperdícios, e inserimos novas, para mais um ciclo de avaliação de hipóteses.

Qualquer semelhança com o método científico, não é mera coincidência.

Mas como fazemos praticamente?

Quando mapeamos o fluxo e facilitamos a conversa do time de desenvolvimento com quem conhece do negócio, começamos a perceber algo muito interessante. A informação flui bidirecionalmente entre as duas partes e o aprendizado é aproveitado pelos dois.

Mas em que momento?

Bem, temos um documento bíblia de escopo com 250 páginas onde, Analistas de Negócio (AN) cascata, acham que conseguiram cumprir uma missão 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 não "será mais incomodado" pelos desenvolvedores e pode ir feliz para mais 3 meses para escrever outra bíblia.

E o ciclo continua.

Quando rodamos este modelo sob a ótica da inspeção e adaptação contínuas, observando a teoria dos sistemas, olhando para o todo e com as atividades mapeadas, percebemos que a coisa não funciona desta forma.

Em equipes de alto índice de qualidade, com processos bem definidos que garantem esta qualidade, 99.9% dos bugs em homologação e produção, tem origem em um mal entendimento de uma regra, que poderia estar mal escrita. Quando analistas de negócios e desenvolvedores analisam este bug, a informação está tão envelhecida, que ambos levam dias e as vezes semanas para entender e resolver. Este processo só piora quando quem analisa e corrige são outras pessoas, o que acontece em quase todos os contextos tradicionais.

Só para evitar este desperdício, o trabalho do AN dedicado já se paga.

Não é só isso. Algo mais interessante acontecerá.

Quando sugerimos uma nova proposta, aumentando a disponibilidade do AN para o time durante o processo inteiro e, conseguimos um tempo diário do AN para realizar um breakdown do documento bíblia de escopo em épicos e histórias pequenas, autocontidas, testáveis..., não é raro o próprio AN encontrar problemas de entendimento e regras mal definidas por ele mesmo.

Não é incomum o AN afirmar que este breakdown e o mapeamento das histórias sobre a mesa, com post-its, absolutamente low tech, lhe deu uma visão que ele não conhecia até então. Neste momento, histórias são canceladas, outras aparecem, prioridades mudam. É impressionante ver o sistema ganhando vida.

Também é bastante normal percebermos este estado reflexivo do AN quando os desenvolvedores o chamam para tirar um dúvida complexa e crítica. Nestes casos, é muito comum esta reflexão ser promovida até em quem pediu aquela funcionalidade.

A causa raiz para estas historinhas é muito simples. Poderíamos chamar de grau de frescor da informação. Quanto mais fresca é a informação, mais qualidade ela tem. Como consequência temos uma alavancagem clara do processo de aprendizado e o desenvolvimento flui de uma maneira mais eficiente.

Não é o Scrum, XP, Lean, Kanban que resolvem o problema da sua corporação. O que vai resolver a maioria dos seus problemas são os ciclos curtos de inspeção e adaptação. Poderíamos chamar ciclos curtos de feedback e ação.

Neste contexto, o papel do AN é muito importante e requisitado. Visando acabar com os maiores desperdícios em um processo de desenvolvimento, não só paga a presença "full time" de um AN, como retorna lucros sobre a medida em um curto período de tempo.

O trabalho dele seria o detalhamento contínuo do backlog, fazendo de forma contínua, alimentando a entrada do fluxo, e a solução de dúvidas que possam (irão) aparecer no restante do time.

O resultado é um produto final com muito mais qualidade e, na grande maioria dos casos, mais barato e em menos tempo.

Acho que é fácil perceber o que acontecerá no mundo competitivo que vivemos....

As empresas que acordaram para este fato e estão se reinventando, olhando para dentro, entendendo os seus processos e os melhorando de forma contínua estarão anos luz a frente das empresas que ainda estarão dormindo e precisarão passar por todo processo de aprendizado.

Não acontece como uma virada de chave. Para a sua empresa deixar seus processos enxutos, exigirá um processo árduo de aprendizado e retroalimentação. Fundamental.

Isso não é verdade apenas no contexto de desenvolvimento de software. Já exemplifiquei como "leanizei" a minha criação de canários e temos estes princípios e valores aplicados nos líderes de todos os segmentos de mercado no mundo, tanto na indústria quanto na prestação de serviços.

Deixo abaixo, novamente, um vídeo da montagem final do Boeing 737, com as práticas fundamentadas na legenda.

https://www.youtube.com/watch?v=Ihtl-SZLU9o