Não, esse não é mais um texto sobre agilidade e seus princípios. Percebi que muito barulho foi feito em cima dessa nova forma de desenvolver software, muitas empresas nasceram ágeis, mas muito pouco foi falado sobre como realizar uma transição do modelo tradicional para o modelo ágil.
Não, não tenho uma formula ou uma receita infalível, além de não ter inventado nada. Sem a pretensão de ser um David Anderson ou um Jurgen Appelo, notei que, com experiencia prática e algumas leituras de livros que considero chave, consegui consolidar, para as realidades onde estive inserido, uma forma interessante de levar a cabo uma transição.
Como o que veremos aqui não é uma receita prática, mas uma forma de comportamento baseada nos princípios mais fundamentais do Lean, não vejo o tamanho da empresa como um restrição a esse modelo de comportamento.
As teorias que ajudaram na consolidação deste modelo se intercalam, sendo as principais: A Teoria dos Sistemas, Pensamento Complexo, o Lean e Teoria das Restrições. As secundárias, mas não menos importantes: Management 3.0 e o Kanban. As chamo de secundárias para este contexto, pois as considero também como consolidações de ideias e teorias anteriores.
Quando iniciamos uma transição, dia 1, hora 1, minuto 1, precisamos de uma conversa franca mostrando que estamos lidando com um sistema. A empresa, a corporação é um sistema: um conjunto de partes que interagem entre si para atingir um determinado objetivo. Mais que um sistema, ela é um sistema complexo, ou tende para ser. Quando eu digo que algumas "tendem" se dá por se situarem no caos e, o primeiro passo, é migrar, no Cynefin Model, para um sistema complexo. Não pretendo me estender demais nesse assunto, tendo em vista que muitas pessoas já falaram sobre isso. Uma pequena busca na WEB elucidará as suas dúvidas.
O próximo passo, depois dessa conversa, é iniciar a observação do sistema. Você não pode sugerir mudanças em um sistema sem antes observar o comportamento do mesmo. Nunca! Não importa se estamos falando de uma empresa de 5 pessoas ou de uma multinacional com 50.000 funcionarios. Não apareça com formulas práticas prontas, dizendo que a forma atual está toda errada, que os funcionarios não prestam. Isso vai gerar resistencia emocional e o sistema vai reagir e, inclusive quem comprava a ideia da transição no início, pode mudar de lado. Qualquer descuido nesse aspecto pode ser fatal para o objetivo final. O sistema é elástico e sempre está tentando voltar ao seu estado "natural", sua zona de conforto.
Dividi a transição em 3 etapas e estas podem ser mapeadas para os 3 estágios mencionados exaustivamente no livro Theory of Constraints (ToC) do Eliyahu M. Goldratt: Classification, Correlation e Effect-Cause-Effect. Ter feito essa divisão, não implica no fato de que elas não se sobrepõem ou que não precisamos revisitar cada etapa constantemente. Na verdade, é isso que acontece. O processo é cíclico.
Dependendo do tamanho da empresa, essa observação pode durar dias, semanas ou até meses. Não negligencie essa etapa, pois ela fornecerá grande parte dos insumos para a criação da estratégia para a mudança.
Podemos dividir essa etapa, que mapeei na ToC para a etapa de "classificação", em duas fases:
1) O Gemba Walk, onde deveremos andar por toda linha produtiva, observando e tomando notas/fotografando como, em alto nível, o sistema se comporta. Como os times interagem? Como o middle management interage com os times? Como os times são demandados? Como os times entregam? Podem ser necessárias algumas caminhadas pelo gemba para uma boa observação destes comportamentos;
2) Sentar em uma baia próximo a cada time por vez. Alguns dias de trabalho perto dos times podem ser suficientes para observarmos como o sistema se comporta em baixo nível. Lembrando que a organização (o sistema) muda quando é observado. Não é como observar a Lua ou as estrelas, mas a organização é um organismo vivo, que detecta que está sendo observado e reage, muitas vezes mudando o seu comportamento.
Com os dados colhidos da observação, identifique o que é(são) valor(es) para a organização. Verbalize e deixe claro e exposto para todos, do topo à base da pirâmide. Mapeie todos os fluxos identificados da organização. "Você não consegue melhorar o que você não vê." Nestes fluxos, tente identificar o que não agrega valor para o(s) resultado(s) final(is). Mapeie, destes desperdícios, o que é necessário e o que não é necessário. Comece eliminando o que não é necessário, depois reduza ao máximo o desperdício que é necessário e não pode ser eliminado. Esta etapa, mapeei na ToC para a correlação
Com o fluxo mapeado e os principais desperdícios eliminados, observe o sistema rodando. 1)Surgirá um gargalo importante. 2)Submeta os esforços no estudo deste gargalo, 3)resolva-o. 1)Este gargalo migrará para outro ponto do fluxo. Repita o passo 2 em diante. Isso se chama kaizen. Isso é a tão falada melhoria contínua. Isso é a busca pela perfeição, um dos princípios do Lean. Quanto mais rodar o kaizen, seu(s) processo(s) ficará(ão) melhor(es) e, consequentemente, você estará entregando muito mais valor para o seu cliente, com menos desperdícios. Finalmente, mapeei esta etapa para o Efeito-Causa-Efeito.
Não é o foco deste artigo, mas nada disso é possível sem o pilar principal do Lean/Agilidade que é o respeito às pessoas. Sem esse pilar principal em mente, podemos jogar todas as nossas tentativas no lixo, sempre! São as pessoas e as interações entre elas que compõem a parte principal do sistema. Você pode argumentar: "Mas na minha fábrica, já tenho quase todo o operacional automatizado." Sim, mas as maquinas precisam de pessoas para operar.
Este é o resumo e o encadeamento da sopa de princípios que vemos hoje por aí. Não existe fórmula prática. Como observar melhor o sistema? Fazendo perguntas. Mas que perguntas? Depende. Cada organização tem a sua identidade e quem transportar praticas/formulas magicas de um contexto para outro, na maioria das vezes, vai falhar. As perguntas certas derivam sempre da sua observação daquele sistema. Confronte o que você vê com os princípios do Lean, com os valores ágeis.
Por fim, mes passado, conversei com o Sidney Lima, no fórum RioAgile, se a denominação de "transição" seria a mais correta. Ele prefere chamar de evolução, pois entende que é um processo sem fim, uma vez que você adotou a agilidade.
Como agente de mudança, na minha visão, o processo de transição tem sim um fim. Esse momento é definido pelo completo conhecimento da organização de que ela é um sistema complexo e, portanto é preciso que ela saiba identificar e trabalhar com a variabilidade e imprevisibilidade, e de que o kaizen é necessário. Uma vez que essa realidade é entendida e existem pessoas capazes de rodar o kaizen eu, como change agent, não sou mais necessário e vou pousar minhas asas sobre outras paragens, noutro contexto, noutra realidade e iniciar outra transição.
Esse é o meu mindset ao iniciar uma transição.
Edit: Eu preciso concordar com o Yoshima, pois a questão de falar sobre sistemas complexos ou não para as pessoas da organização não ficou clara. A primeira reunião (mencionada no parágrafo onde falo sobre isso) normalmente acontece com change agents locais. São pessoas que te chamaram para um determinado objetivo. Essas pessoas se tornarão suas aliadas e apontarão outros aliados dentro da organização. Esses aliados são extremamente importantes na disseminação das ideias que guiam o processo de transição. Estas pessoas precisam ter atenção especial e ajudadas no entendimento do contexto que está sofrendo essa transição.
As demais pessoas, como o Yoshima bem disse, perceberão a importancia do pensamento sistêmico naturalmente, talvez até sem perceberem isso como a metáfora, que tenho usado bastante, do boiled frog.
Esse texto, também precisa ficar claro, diz respeito a uma transição auxiliada por agentes externos, normalmente em sistema de consultoria. Para mudanças internas, de dentro para fora, eu escrevi aqui e aqui.
