Ter uma só abordagem para tudo é como ter o Mjölnir … que inveja!

Uma amiga sempre diz que NÃO somos o Thor e o método ou técnica que dominamos NÃO é o Mjölnir. Há quinze anos o Gartner propôs uma modelo simbiótico entre Design, Lean Startup e Agile, depois mais Growth Hacking. Foi o estopim para a retirada do foco dos métodos e a valorização da busca e experimentação dentre tantas técnicas, métodos, modelos e abordagens que podem melhor nos levar às soluções pelo melhor caminho e destino.

Há diferentes escalas de problemas, domínio e soluções, sobretudo há pessoas e grupos, cada qual singular em suas caracteristicas, somente a experimentação nos dará a expertise para saber usá-las da melhor forma.

É preciso acreditar em melhoria contínua, auto-organização, em empirismo, na importância de entender o problema, estar aberto a opções, experimentar, co-criar a solução. Pensar em comunidade e ecossistema é bom, mas evite ser a criatura Gólum, falar “my precious” método ou técnica, menos ainda ser Sauron, o “Sr da cocada preta”.

Apaixone-se pelo problema (Uri Levine – Waze)

O quanto temos uma visão mínima do problema – 5w2h – para podermos compreender o valor, domínio, seu custo x benefício, pareto e contexto. Seu porte, amplitude, ciclo, os interessados e envolvidos, onde usaremos Effectuation, Design Thinking, Lean startup, Lean inception, Scrum, Kanban, Escala, Growth Hacking, Go to market, Getting Things Done, …

• Qual o seu problema? E sua latência?
• Quanto ‘vale’ sua solução? Qual sua prioridade?
• Quem são as pessoas envolvidas?
• Que porte e complexidade tem?
• Quem possui domínio sobre o assunto?
• Como é o seu ciclo de vida?
• Quando já tentamos, quanto aprendemos?
• O que já existe, qual o benchmarking?

Nas estatísticas do Standish Group dentro do Chaos Report, disponíveis na rede, eles apontam que a taxa de sucesso em pequenos projetos é quase idêntica entre diferentes metodologias, posto que em algumas semanas, mitigam riscos e evitam bolas de neve, todas tendem a dar certo. Isto nos leva a valorizar mais a interação, iteração, comunicação, participação de todas as partes … do que o método utilizado.

Reflexões despretensiosas

A seguir algumas frases que já usei em palestras, consultorias e debates, que corroboram meu desapego a pré-conceitos, pacotes únicos e enlatados, a favor da necessidade de avaliarmos as opções:

• _{Agile é valores e princípios mais que métodos e ferramentas, mesmo havendo algum valor a direita;}
• _{Método não é religião, não quer dizer que você vai para o céu e os demais vão para o inferno;}
• _{Design Thinking é um estado mental aberto a todos, não é um método, profissão ou especialidade;}
• _{Lean startup é pensar grande, executar ciclos pequenos, validar rápido e retroalimentar imediatamente;}
• _{Cada problema possui uma amplitude e profundidade que determinará como será abordado;}
• _{Você é ágil, mas vê os que pensam diferente como inimigos, você não entendeu absolutamente nada;}
• _{Usar um canhão para matar um mosquito pode ser visto como desperdício de tempo e dinheiro;}
• _{Uma lixa de unha para limar um canhão tende a ser absolutamente inócuo, mesmo com baixo custo;}
• _{Verdades absolutas inquestionáveis, frequentemente geram estoques intermediários e desperdícios;}
• _{Quem tem justificativas intensas para tudo o que faz, normalmente não está aberto à mudanças;}
• _{Quem cita demais gringos para confirmar suas certezas peremptórias, não está aberto a discussão;}
• _{Quem discute método ou técnica apenas atacando as outras é porque tem outros intere$$e$;}
• _{Cada grupo humano tem sua singularidade, nenhum processo ou métrica é maior que isso.}

O case dos Design Sprints e Inceptions padronizadas

Quem me conhece, sabe que cada caso é um caso, o contexto falará por si, em mais de 10 anos de atuação desde os “Marolas de Agilidade” em 2007, assumindo uma área de produtos digitais em 2008, do Agile Brazil de 2011 em Fortaleza, jamais insisti que um método ou técnica estaria acima do grupo e suas características. Sempre recomendei tentar a partir de um modelo reconhecido, para progressivamente ajustá-lo.

Um exemplo categórico é que raramente usei 5 dias para um planejamento, não mais que 5 vezes em 10 anos. Cito por exemplo Knapp ao justificar a versão II de sua proposta, reduzida de 5 para 3 dias, dado o domínio em soluções organizacionais onde os envolvidos estão imersos e conhecem profundamente dores, ganhos, além de conhecerem e prospectarem alternativas e possibilidades cotidianamente.

Sou fã da Profª Saras e sua Effectuation! O bom é inimigo do ótimo, disse o MVP para a Release, disse o primeiro dia para os quatro restantes, estou acostumado a gerar uma primeira versão de planejamento, que subsidia a geração de um primeiro RoadMap e o desenvolvimento de uma primeira entrega, usando 1 ou 2 dias, 3 dias são raros, 5 excepcionais. Depois, é empirismo, execução, aprendizado e melhoria.

É claro que esta é minha opinião, fragil como de outros tantos frente a outras opiniões, posto que serve para mim em meu contexto e realidade. Boa sorte na sua!

Em uma disciplina de inovação, uma amiga diz que recebeu uma nota baixa porque não seguiu o roteiro de INOVAÇÃO proposto … ela cometeu um erro comum, querer inovar em contextos e com pessoas que tem vários ótimos martelos na sua caixa de ferramentas, o problema não é deles se há parafusos e porcas que teimam a não se adaptar a seus martelos.