quarta-feira, 21 de março de 2012

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.

    12 comentários:

    1. Celso, muito legal o relato de sua experiência com agilidade nesse "ambiente cascata". Sem dúvida os conceitos ágeis estão sendo utilizados com mais nomes diferentes : )

      ResponderExcluir
    2. Grande Celso, ótimo post. Você está notando que Kanban não é um processo, é um change management system. Poucos aqui no BR compreenderam isso. Parabéns!

      ResponderExcluir
    3. Dr Celso, não tenho palavras para expressar a alegria de ver que uma pequena ideia possa ser socializada e contribuir tão grandemente para o seu contexto.
      Parabéns pelo post e como o Rodrigo mencionou, isso indica uma maturidade singular na compreensão do seu ecossistema.

      Parabéns e continue sua brilhante luta pela melhoria em seu ambiente.

      Abs,

      Manoel

      ResponderExcluir
      Respostas
      1. Grande mestre! Eu que agradeço, pois desde que conheci você e o Yoshi tenho aprendido bastante através dos seus pensamentos e experiencias.

        Obrigado!

        Excluir
    4. Muito bom artigo Celso.

      Mas, me tira uma dúvida: você citou as especificações. Certo? Como isso está sendo feito? Quanto tempo isso está tomando?

      Marcelo Neves

      ResponderExcluir
      Respostas
      1. Valeu Marcelo.

        Bem, podemos usar duas abordagens e as duas tem se mostrado satisfatórias: ou elas entram na definição de pronto, criadas de forma incremental e versionada ou podem ser uma atividade no kanban. Prefiro a primeira abordagem pois assim, de fato, somos iterativos. Mas as vezes essa abordagem não cabe em um cronograma apertado (no modelo cascata o milestone da especificação vem antes da "construção"). Então ela precisa ser uma atividade mesmo. Em cronogramas mais folgados tem se mostrado possível desenvolver dentro da definição de pronto.

        Não sei se era essa exatamente a sua dúvida.

        Excluir
    5. Parabéns cara! Parabéns mesmo! Eu estava me organizando (ou auto-organizando! ;-) ) para ler com calma seu post, que está fazendo o maior sucesso! São relatos como o seu que demonstram que é possível implementar mudanças efetivas em ambientes mais tradicionais.

      O Manoel é um cara realmente extraordinário. Depois de participar de um curso com ele no ano passado passei a ficar muito mais Zen! (Eu diria até meta-zen! ;) )

      Como também estamos passando por um processo de mudança aqui (e estamos sedentos por cases como o seu), você poderia compartilhar mais algumas informações?
      - Qual o tamanho da equipe?
      - Quanto tempo foi da "carta branca da gerência" até o dia de hoje?
      - A equipe de vcs atende a um projeto específico ou vários? Ou seja, o fluxo que vcs mapearam foi de "demandas" de um projeto/sistema ou de vários?

      Forte abraço! Continuem firmes na empreitada, pois os resultados compensam a jornada!

      ResponderExcluir
    6. Obrigado Rafael!

      Vamos lá:

      - Não tenho certeza se posso abrir o tamanho exato da equipe, mas posso te dar uma ideia... somando as 3 bases, temos menos de 10 pessoas (sem contar liderança e gerencia);

      - Recebi a carta branca quando entrei na equipe, isto é, em outubro do ano passado.

      - Atendemos vários projetos, mas cada pessoa fica alocada em um de cada vez. Pelo menos é essa a cultura que queremos que impere. Cada projeto tem o seu kanban e temos um específico para sustentação.

      abs!

      ResponderExcluir
    7. Mais uma informação que achei interessante em compartilhar é que em termos de projetos, temos dois em andamento, um pequeno e outro médio. Temos alguns outros que ainda precisam ser aprovados. O legal desta iniciativa com o Kanban como sistema principal é que, por exemplo, já foi detectada a necessidade de mais pessoas na equipe, ANTES de começar estes novos projetos (leu The Mythical Man-Month? Pois é, também acredito no Brooks).

      Até o nível da liderança, também somos devs. Eu (líder técnico) desenvolvo constantemente e a liderança "geral", também. Assim temos mais dois devs no time.

      ResponderExcluir
    8. Massa! Obrigado por compartilhar.
      Sucesso na empreitada!

      ResponderExcluir