Como ser ágil em um ambiente cascata?

Em primeiro lugar, gostaria de pedir desculpas aos meus leitores, pois há muito não coloco um conteúdo mais técnico e tenho falado muito em processos, sistemas, gerenciamento e assuntos nessa linha.Vou me redimir, uma dia.

Neste post, vou informar como estamos transformando uma equipe para observar os valores da agilidade, dentro de um ambiente, até certa forma, hostil ao movimento ágil. Como os leitores mais antigos já devem desconfiar, o sistema principal escolhido foi o Kanban. Entretanto, neste contexto complexo, decidimos aplicar um conceito mais amplo, o AgileMMA, termo cunhado pelo grande pensador Manoel Pimentel.
Bem, vamos lá:

• Como foi planejado?

A primeira coisa que procurei identificar foi a necessidade. Por que era necessário mudar?

Certo dia, perguntei à algumas das pessoas envolvidas nos nossos processos o que estava em andamento. Ninguém sabia responder com precisão. Perguntei ao meu líder e ele também não conseguiu ser preciso. Pior que não saber em que fase cada necessidade estava, não sabíamos que necessidades estavam em andamento no nosso fluxo. Pronto. Este era o estopim que eu precisava.

Como eu estava terminando de ler o livro do David Anderson, e já tinha percebido a característica menos intrusiva (e menos prescritiva) do Kanban, avaliei que esta seria a melhor opção. E tirando algumas resistências não fundamentadas, o sistema foi aceito muito bem.

Como eu já havia tido uma experiencia frustrada na implantação do Scrum em uma equipe anterior, resolvi usar uma abordagem diferente. Evitei os termos característicos dos métodos ágeis e do Kanban. Em vez de Limited WiP, falei que cada coluna só poderia ter X atividades em andamento. Lead time? Não, tempo de uma atividade no fluxo. Até o nome do sistema, Kanban, troquei por "nosso sistema de controle de microatividades". A resistência foi menor. Afinal, o que se via de fora, era que eu não estava mudando o cascata, nem o Project, nem cronogramas macro, apenas estava tentando resolver um problema: pouca visiblidade do que estava acontecendo no nosso fluxo.

• Como foi comunicado a alta gerencia?

Com demonstram as pistas que já entreguei no tópico anterior, comuniquei o problema - falta de visibilidade do fluxo de atividades - e sugeri uma forma de melhorar isso, garantido que macro-cronogramas, Project, fases, etc. não seriam alterados. Não seria necessário mexer no macrogerenciamento, apenas estava querendo mudar o microgerenciamento. Falei da importancia de termos reunião quizenal, pois poderíamos verificar o que deu errado e ver onde poderíamos melhorar. Retrospectiva? Claro, mas no máximo citei o PDCA.

• Como a equipe foi treinada?

Temos uma equipe bem distribuida, com pessoas no RJ, Brasilia e Pernambuco (chegamos a ter, no início, pessoas em SP). Uma ferramenta online, de fácil manuseio era essencial. Depois de muito pesquisar com a ajuda essencial do pessoal de SP, optamos pelo kanbanize, e estamos muito felizes com a escolha até hoje.

Como eu poderia falar sobre Kanban com poucas pessoas, as pessoas não resistentes, o foco do nosso treinamento foi baseado na ferramenta e não no sistema. Eu e algumas pessoas que já conheciam o Kanban mapeamos o fluxo e somos responsáveis pelas melhorias, com feedback do time. Sei que isso não é o ideal, mas com o amadurecimento da equipe, vamos, aos poucos, falando sobre os conceitos ágeis, do Kanban e do Scrum.

• Como ser iterativo em um ambiente cascata?

Bem, essa questão, sem dúvidas, foi a que mais me tirou o sono por mais noites. Eu precisei, para parar de rodar atrás do próprio rabo, partir de uma premissa: "Com iterações curtas entregamos valor mais rápido que em cascata". Partindo desta premissa, podemos ter a abordagem que é da minha preferencia: Especificações, planos de testes e evidencias de testes fazem parte da definição de pronto. Gosto desta abordagem, porque realmente ficamos iterativos.

Em cronogramas mais apertados, criar estes documentos vira uma atividade no kanban e a iteratividade fica restrita à jardinagem do código (adoro esta expressão).

• Como nos adaptamos?

 O leitor mais atento terá notado no segundo tópico: Pera aí... restrospectiva timeboxed? Você não falou em Kanban? Fluxo contínuo? Como assim?

Verdade, mas no início deste post, também mencionei o AgileMMA do Manoel. Simplesmente, no nosso contexto, não poderíamos fazer restrospectiva on-demand. É importante uma reunião quizenal (que na verdade ainda está amadurecendo). De resto, estamos atuando com fluxo contínuo até a coluna "tested", pois não temos deploy contínuo e nossas releases também são timeboxed.

***

O pilar que tornou isso possível foi uma conversa com a gerencia, quando fui convidado a integrar a equipe. Eles pediram para eu tentar melhorar o que já tinha e que eu teria carta branca para executar estas melhorias. Bem, melhorar o que já tem, mapeamento da cadeia de valor não são os pilares do Lean e do Kanban? Então com isso, as coisas correram de forma natural. Com a experiência que eu trouxe de uma implantação de Scrum mal sucedida, o caminho ficou bem mais suave.

Tivemos problemas, é claro. Mas a gerencia lidou com eles com extrema destreza e hoje fico feliz em ver nosso fluxo rodando com pouca intervenção da minha parte. Ainda temos muito o que melhorar, pois SEMPRE temos o que melhorar. Ainda faltam conceitos, o sistema entrar no sangue das pessoas. Mas entendo que uma mudança deste tipo vai levar tempo. O que me deixa feliz é ver que estamos caminhando para frente, rumo ao kaizen.