Arquivo da tag: metodologia

0

Registros de uma montanha nevada

|

Em Fevereiro de 2001, em uma estação de esqui em Salt Lake City, Utah, dezessete profissionais que vinham praticando desde a década de 80, publicando e divulgando metodologias rotuladas como lightwaves, se reunindo para declarar seus pontos em comum que vinham chamando a atenção do mercado pela disrupção e bons resultados conquistados.

Seguindo Lavoisier, inspiraram-se no Japão da década de 50, no visionário Taichi Ohno que preocupava-se com o desperdício e implementava gatilhos que desligavam teares no caso de defeitos, que na Toyota entraria para a história com o paradigma de produção enxuta junto a ícones como Toyoda, Sakichi, Deming, Juran e outros.

A partir de então, vários deles assumiram um status de referência, viajando o mundo, palestrando, criando institutos e certificações, resignificando o desenvolvimento de SW, aproximando-o do negócio e partes interessadas, quebrando o paradigma do “nós” (TI) e “eles” (usuários). Os métodos envolvidos e o Manifesto batizaram um novo mindset para a TI.

Aquilo que passou a ser conhecido como “Manifesto Ágil para Desenvolvimento de Software”, baseados em 4 artigos e 12 princípios, se consolidou como um marco divisório, providencialmente no primeiro ano do século XXI, um marco na virada do milênio. De lá para cá, o mindset proposto tornou-se um fato ou meta para a maioria das empresas.

Aqueles experimentos que iniciaram na década de 80, consolidaram-se nos 90, foram batizados em 2001 em uma montanha nevada. Desde então vimos um sincretismo cada vez maior entre diferentes metodologias, frameworks e conceitos, a partir da TI irradiando-os para toda a organização, em conceitos de Digital Transformation, Organizações Exponenciais, Fábrica 4.0, etc.

. 1992 – Crystal Clear Method – Cockburn
. 1993 – Scrum – Shuterland, Schwaber e Beedle
. 1994 – Analysis Patterns, UML Distilled, XP – Fowler
. 1996 – XP – Kent Beck, Cunningham e Jeffries
. 1997 – DSDM (Dynamic Syst. Dev) – Bennekum e outros
. 1997 – FDD – Feature-Driven Dev. – Jeff De Luca e Peter Coad
. 1997 – ASD – Adaptive SW Dev.. – Jim Highsmith e Alistair Cockburn
. 1999 – The Pragmatic Programmer – Andrew Hunt e Dave Thomas

Depois do manifesto vieram o casal Poppendick (Lean Development), Kanban, Agile escalado como Nexus e SAFe, além de muitas disciplinas que vieram a somar e potencializar seus resultados, como Lean Startup, Design Thinking, Gamefication, Lean Business Analysis, com outras dezenas ou centenas de técnicas e boas práticas alinhadas aos seus princípios.

O mercado busca Agile Transformation, empresas ágeis respondendo rapidamente ao mercado e tecnologia, não mais equipes e projetos, mas empresas criativas que aprendem. Desde 2008, me envolvi com SCRUM, Kanban e XP, mas também com Scrum of Scrum, SAFe, DSDM, Lean Office, também com Business Model Generation, Design Thinking … que formam hoje minha toolbox.

Nos últimos anos vimos um sincretismo cada vez maior entre diferentes metodologias, frameworks e conceitos, quer tradicionais ou ágeis, vide o PMBOK e seu Guia de Boas Práticas Ágeis, bem como o modelo abaixo proposto pelo Gartner na direção de proporcionar maior empatia, agilidade, equidade, eliminação de desperdícios, antecipando resultados e melhores taxas de sucesso.

Temos muito o que andar, mas a história nos inspira e dá a entender que estamos no caminho certo!

0

28/03/18 as 19:00 tem TecnoTalks sobre Bi-Modal

|

Vamos debater o conceito, o contexto e a evolução da TI Bi-Modal do Gartner com uma mesa e tanto, inclusive você, porque vamos reservar um tempo para as perguntas mais relevantes propostas pela galera.

Qual o papel desempenhado até aqui pela Bi-Modal, qual o status quo hoje, cenários e quais os próximos passos. Uma visão 360º de mercado, das organizações e profissionais envolvidos em projetos e equipes.

Inscrições em http://bit.ly/tecnotalks-bimodal

Em 2016 questionei um provável equívoco, consciente ou inconsciente – https://jorgeaudy.com/2016/07/27/pulo-do-gato-ou-equivoco-da-ti-bi-modal-do-gartner/, mas isso é passado, hoje temos mais, creio que seja um Agile Multimodal \o/ Porque independente do seu processo de trabalho, Lean Thinking, com ciclos iterativo-incrementais-articulados, auto-organização, gemba, kaizen, poka-yoke, etc.

Agile Multimodal remetendo não a método ou framework, mas a princípios. A meu ver estamos imersos em conceitos de Transformação Digital, de Organizações Exponenciais, Indústria 4.0, Management 3.0, Agile Transformation, neste contexto sobra pouco espaço para um Modo #1 ainda em waterfall (sem iterações), centrado na TI e convencionalmente hierárquico … correto?

0

Planejar sem um bom briefing é sabotagem

|

Não acredito em iniciar com paredes vazias, fosse assim e Lavoisier não teria entrado para a história, começo aproveitando o que se tem, mesmo querendo inovar, mesmo querendo ser disruptivo. Uma fonte para reflexão é a aprendizagem significativa de Ausubel.

Ausubel indicou o uso de subsunçores para a ancoragem do novo, facilitando a nova aprendizagem, segundo o autor o nosso cérebro identifica e entende o novo ou a inovação ancorando-os em algo conhecido, ou seja, a quebra de paradigmas precisa do paradigma a ser quebrado.

Sempre quero iniciar com um bom briefing de negócio, driver, ROI, status quo, personas, expectativas, jornadas, estabelecendo um debate sobre tudo aquilo que é relevante saber sobre tudo o que temos até chegar àquele momento, o que nos trouxe é a chave para seguir adiante.

Domínio e responsabilidade, é nossa obrigação em desafios de ideação ou planejamento primeiro aportar tudo o que já temos, não sonegar nada, jamais começar com uma parede vazia. Negar waterfall quer dizer não investir semanas se preparando, mas não é sonegar o que já temos.

Não interessa se é Modo 1 ou Modo 2, ambos podem ou não contar com a disponibilidade de mapas mentais, processos, dados de pesquisa, benchmarking, sistemas atuais ou concorrentes com seus mapas de funcionalidades, isso não é antecipar, isso é assertividade.

Dica: Jamais sonegue ou sabote seu próprio time das informações disponíveis, elas atuarão como substrato, como acelerador de sinapses, ponto de partida e provocação. Se não quer usar o que tem porque isso pode influenciar negativamente, seu problema é muito maior que esse.

Cada um de nós, precisamos ter em conjunto uma Toolbox proporcional ao nosso tempo, uma grande caixa de ferramenta com técnicas, frameworks, boas práticas, … para mim é inadmissível em 2018 achar que podemos somente ter um martelo, porque pro martelo tudo é prego!

Cada vez mais vejo empresas adaptando seus projetos, sustentação e processos de trabalho para ajustar-se a um framework ou técnica apenas porque alguém disse que é assim que tem que ser, por ser óbvio, lembra a fábula da roupa do rei, era de ouro mas só o rei poderia ver.

Repito o que tem sido meu mantra nos últimos três anos: Qual é a sua Toolbox? Quais as opções que você se permite para uma reunião de concepção, design sprint, ideação, modelagem, planejamento, … o seu uso é compulsório ou há uma escolha consciente dentre boas opções?

Se quiser saber mais sobre o conceito ToolBox 360°, o game pedagógico Desafio Toolbox e a técnica Toolbox Wall, são mais de 100 boas práticas, um grande buffet, recomendo um dos posts que fiz em 2017 com esta provocação ou o blog http://toolbox360graus.wordpress.com.

0

Toolbox 360° com a galera da Umbler e RedeHost

|

Uma lightningtalk pegada, uma rodada do game Desafio Toolbox, a construção de um Toolbox Wall. Foi um final de tarde agitado em Gravataí com trinta profissionais em um espaço muito bacana … me senti em casa 🙂

Quando cheguei estava rolando uma sprint review na sala ao lado, enquanto eu montava os kits e material em uma sala enorme que mais parecia um playground para adultos, que agora tem mais alguns livros, jogos e mural.

Foi um prazer montar mais um Toolbox Wall, compartilhar e interagir com uma galera pilhada. Como eram apenas 90 minutos, todo o material ficou para que pudessem fazer mais rodadas adiante … espero que compartilhem fotos \o/

Uma definição que encontrei na web para apresentar a Umbler diz: “É uma startup do ramo de hospedagem de sites e aplicações, possui atualmente unidades em Gravataí/RS e Orlando/EUA, tendo como filosofia a globalização do negócio.”

Sobre a RedeHost encontrei esta apresentação: “Com mais de 14 anos, está entre as maiores empresas de hospedagem do Brasil, conta com dois data centers em São Paulo, cerca de 400 mil domínios registrados e mais de 60 mil clientes.”

 

0

Mais Agile Bi-Modal

|

Mais um pouco, para que fique claro, eu acredito que projetos em que a probabilidade é não ser tipo #2, vale a pena e faço um planejamento em que todos participam e colaboram em um entendimento amplo de suas fases, épicos e/ou histórias, estimativas e sprints. Fazer o que, talvez eu seja um romântico saudosista e não consiga desapegar das Inceptions com User Story Mappings e Releases Plans.

Voltando a questão do modo 1 e modo 2, quando vamos planejar o primeiro MVP de um projeto de inovação, vamos de Design Sprint e mãos a obra, sabemos que precisamos de quatro rodinhas e uma prancha, parafusos e porcas. O futuro só saberemos a cada validação, usualmente o que queremos saber é quanto vai demorar e custar para fazer o primeiro passo para validar e seguir adiante, com ou sem pivots.

Mas se o projeto é de um carro, eu proponho alguns dias no processo de debate e mapeamento amplo de releases com suas sprints e histórias. O primeiro é o banco e a direção, o segundo tem o painel analógico contendo velocímetro, tanque, temperatura e contagiro, no terceiro incluiremos o chassi, rodas e tanque, no quarto o motor, no quinto a carenagem, no décimo-sexto o ar condicionado e rádio. Abstrair o conhecido da margem para múltiplas interpretações, na dúvida estabelecemos acordos e premissas … e seguimos adiante.

No modo 1, discutirmos histórias com foco em coletivo e senso de pertença, é garantir que todos sabem onde estão metidos, já facilitei dezenas, talvez uma centena para organizações – jurídico, RH, exportação, cartões, caixa, gestão, cobrança, atendimento, … – creio que o percentual de mudança de histórias fica entre 10% e alguns 20%. Há movimentação ou o DoR acaba demonstrando ser mais ou menos. No modo 2 é Lean Startup, o planejamento nunca é maior que algumas semanas, quase a cada dia ou semanalmente há debates e tomadas de decisão.

Com o passar do tempo nosso Release Plan muda, algumas coisas se antecipam, outras se postergam, algumas entram e outras saem. O Planejamento é um guia, fica registrado em selos nos postits o que mudou, cores, novidades, eu até valorizo isso, mas o mais importante é uma visão holística por todos, nada é só o hoje, porque o desafio do tempo, custo e escopo de negócio é de todos. Sem uma visão ampla o suficiente, o time não poderá criar uma visão ampla e colaborar a cada passo.

Na maior parte das vezes, pouco muda, mesmo mudando é interessante termos esta visão … na maior parte das vezes seremos cobrados pela produtividade, por exemplo eu acredito que a solução mockada é um artifício estratégico, cada mock e cada contorno tem um custo adicional, da mesma forma cada desenvolvimento que terá fase II e III, é preciso ter conhecimento e visão do todo para realmente poder ter argumentos, contra-argumentos e efetividade, redução de custo e tempo também é nossa meta … um ponto de equilíbrio.

A média dos projetos tem poucos meses de duração, de 4 a 8 meses, as vezes é o todo, muitas vezes é parte de um programa de 3 a 5 fases, etapas ou módulos, mas há um bom tanto, creio que algo em torno de 20% que são projetos que o sponsor quer planejamento com orçamento, entregas e escopo de negócio. O Definition Of Ready entrará no detalhe, mas temos um Norte muito claro, definindo se o banco é de couro ou veludo, se o tanque será de 40 ou 60 litros, se não estava previsto mas o negócio precisa de uma central multimídia, etc.

MODO 1

Em projetos do modo 1 eu recomendo levar para o planejamento tudo o que tivermos, tomar um dia demonstrando como o mercado resolve é na maioria das vezes mais que influenciar (há quem ache isso), não sendo disruptivo e o primeiro de sua espécie, é responsabilidade saber o que os players existentes fazem, o que é bom e o que é ruim, partir de um desenho de processo, são aceleradores, começar com uma parede em branco e muito debate e criatividade é abrir mão de tudo o que o mercado já sabe, é reinventar a roda.

15 sprints – 8 meses – quatro MVP e releases – 2 sprint de buffer a confirmar no 05 e 10

21 sprints – 11 meses – dois MVP e mais 7 releases incrementais

10 sprints – 5 meses – três MVP e release – 5 equipes – Uruguay, BH e POA – core, BPM, web, serviços

AGILE MULTIMODAL IV

3

Agile Bi-Modal

|

Não é um post sobre a TI Bi-Modal do Gartner, é uma reflexão sobre agilistas que tentam planejar e executar projetos conhecidos como se fossem inovação, disrupção, negando o que já sabem para poder encaixar no Lean Startup, MVP e Pivots, mas nem todo planejamento é inovação. Nestes muitos casos, fazem um planejamento sem benchmark ou mapa de funcionalidades, porque é mais “ágil” não fazer, é mais chique e divertido fazer o patinete, mas tratar como disrupção algo conhecido é desperdício, gera custo, mesmo sendo muito Up!

A maioria dos projetos que participo possuem mínima variação na sua essência, o que muda é no timing de cada DoR, desde o início do projeto temos as histórias do usuário, que eventualmente são antecipadas ou postergadas. Na maior parte dos projetos, não fazemos patins ou bikes, trabalhamos para fazer um sedan desde o primeiro sprint. Não sabemos se o banco vai ser de couro ou tecido, mas vai ter os bancos, sabemos que teremos quatro rodas, pode ser que surja uma central multimídia imprevista, mas daí sai o rádio e diminuem o número de falantes …

Existe a TI Bi-Modal do Gartner, propondo projetos mais tradicionais (modo 1) e ágeis (modo 2), onde teríamos no 1 gestão convencional e cascata, enquanto no 2 deveríamos ir mais para a auto-organização e ciclos iterativo-incrementais. Mas, a TI Bi-Modal do Gartner deve evoluir para Agile Bi-Modal. Modo 1 e 2 são ágeis, o 1 em contexto mais conhecido, no 2 algo desconhecido, disruptivo, imprevisível.

AGILE BI-MODAL

Se por um lado tem amantes do Modo 1 da antiga TI Bi-Modal, por outro há muitos agilistas que tudo é Lean Startup, repetindo mantras do Ash Maurya como se eles tivessem sido feitos para sistemas conhecidos, passíveis de serem planejados e executados. Muitas vezes, fazer um planejamento de 18 sprints de algo previsível é oportunidade de gerar um conhecimento coletivo que balizará muitas decisões da qui em diante.

Agile Bi-Modal

No Modo 1 da Agile Bi-Modal tem amplitude e entendimento, tem histórias do usuário e técnicas, planejáveis, cada sprint considerando entregas de valor com senso de urgência e prioridade. No Modo 2 do Agile Bi-Modal temos inovação, dinamismo, é o patinete, depois a bicicleta, para chegar no que parecia ser um carro, quadriciclo ou um ????? após n MVP e pivots.

Na prática, repensando a TI Bi-Modal do Gartner, inexiste o Modo 1 lá proposto, ele é uma barreira a décadas de evolução em gestão de projetos, dizer que é possível ter uma opção em waterfall, hierarquica com ciclos de vários meses é um contra-senso.

Modo 1 – Desafio conhecido na sua essência

É preciso evoluir o Modo 1, minha visão é que o “antigo” Modo 2 do Gartner é o Modo 1 do Agile Bi-Modal, são projetos com ciclos iterativo-incrementais-articulados, centrados no negócio, próximos do cliente, evolutivo, usando métodos ágeis.

A tônica é conhecimento, saber o que usamos hoje, concorrentes, opções, benchmarking, mapas comparativos entre soluções atuais, customer journey map buscando entender pontos quentes, com melhorias necessárias ou desejáveis.

Se o que vou fazer, mesmo em um projeto com um ano de duração com múltiplos releases, tem um escopo geral conhecido, com uma taxa de variação mínima a nível de planejamento de releases, porque não antevê-lo, planejá-lo?

Pode se tratar de lei, compliance, mudanças de tecnologia, troca de fornecedores e serviços, funcionalidades mínimas previstas e deadline, projetos com escopo exigido. Dedicar um dia a cada seis meses para todos olharem para o todo e suas partes é benéfico e produtivo.

Modo 2 – Desafio desconhecido, inovador, disruptivo

Se o Modo 2 da TI Bi-Modal do Gartner virou Modo 1 no Agile Bi-Modal, é porque o Modo 2 é um passo adiante, imprevisto pela consultoria em sua proposta conservadora. É preciso ser mais Lean Startup, voltado a projetos mais inovadores, desconhecidos, incertos.

Inovação, ideação, pesquisa desk e de campo, se eu não sei bem o que é, não vamos tentar planejar muita coisa, apenas o primeiro passo a partir de onde estamos, cada passo poderá vir a ser mais um primeiro passo.

É para ser mais Lean, mais Kanban, menos planos, releases, sprints ou histórias, pois quase não existem certezas, temos muitas hipóteses a serem validadas, base instável exigida para o uso intensivo de MVPs e Pivots.

Neste caso faz sentido evitar prever mais que um primeiro passo, porque o segundo pode ser completamente diferente do que inicialmente imaginamos. Façamos então o patinete para validar se é por aí, experimentar movimento, velocidade, para então seguir adiante conforme forem os feedbacks e confirmações de que o problema percebido realmente é um problema, se a solução imaginada realmente é relevante.

 

 

0

Stop The Line – Se tiver que apertar, aperte, mas só se for o caso :)

|

Há uma técnica adaptada do Lean Toyota que se chama “Stop The Line”, destacando algo que já passou por todo o processo de desenvolvimento e precisa priorização de ajustes (bug, impedimento, mudança) para ser entregue e não ficar com status de “quase pronto, mas com problemas”.

Diz a lenda que na Toyota havia botões vermelhos escritos “Stop The Line”, o custo ao apertá-lo era o de parar a linha de produção com um alto custo por minuto, mas mesmo assim evitando que defeitos persistissem e gerassem um ônus ainda maior adiante.

Em projetos de software, é um selo para chamar a atenção de que algo já consumiu os recursos, mas que exige algo mais para ser considerado pronto. Se ele era mais valoroso que os demais para iniciar, provavelmente é algo de valor que precisa atenção adicional para não ficar parado.

Uma técnica com foco em entrega antecipada de valor, que assim como o WIP (work in progress), responsável por limitar o número de atividades em cada status do fluxo de trabalho, nos induz a privilegiar primeiro acabar algo iniciado ao invés de ficar empilhando semi-acabados.

Gosto muito da frase do Juan Bernabó no final do Agile Brazil de 2016 – “Esperamos que as retrospectivas façam o seu trabalho!”. Tomo a liberdade de colocar a frase logo acima de um fictício botão de “Stop The Line”, com uma matriz que sempre uso para indicar o ciclo de vida de um sprint … quase tudo tem um momento ideal:

Stop The Line é um modelo mental

Se a descrição acima faz sentido, expanda além das funcionalidades, tarefas e defeitos, use este modelo mental para tudo, uma vez planejado o Sprint Backlog, quanto maior o foco e dedicação, melhor, pois haverão imprevistos, então deixe para depois o que não faz diferença ser agora.

Uma sprint possui uma estrutura pensada para foco em valor e resultado, adaptação sempre que necessário, com apresentação e aprendizados ao final, gerando um moto-contínuo equilibrado entre liberdade e responsabilidade, cerne da auto-organização.

Tem muito a ver com Pareto, não tem receita de bolo, mas o melhor é ver o todo e priorizar aquilo que gera mais valor e aparentemente fará diferença, o restante deixe para as retrospectivas fazerem o seu trabalho (mesmo em retrôs eu não imponho a pauta, ela é do time).

Tanto o WIP quanto o STL são padrões mentais relativo a sistemas puxados que vão se construindo em um time ágil, não por poder garantir só acertos, mas principalmente saber lidar com experimentação e erros, afinal, a cada novo insight ou percepção é preciso refletir:

  • Manter o time focado durante 8 dias na sprint tem seu valor.
  • É necessário “stop the line” para discutir isso agora?
  • Se sobre critérios DoR, não dá para aguardar a Grooming?
  • Se sobre critérios DoD, não dá para aguardar a Review/Retrô?
  • Alguns impasses urgentes vão surgir, esse merece ser um deles?

Os primeiros Sprints de um Projeto

Há uma ampla gama de aprendizados, alguns ajustes em tempo real são vitais para estabelecer um patamar de confiança entre equipe, PO e stakeholders, baseado em entregas de valor e qualidade, outras questões podem esperar a retrospectiva.

Sem esquecer de Tuckman, da curva de aprendizado, de alguns sprints com riscos adicionais pertinentes a certo grau de tensão e desconhecimento do projeto, dos colegas, da tecnologia, modelo de dados, que a cada sprint vão-se mitigando e criando raízes fortes.

Ainda na minha opinião, que não vale nada, por isso é de graça, querer acelerar e garantir todos os aprendizados o mais rápido possível nos empurra para comando-controle ou tensão desnecessária, eu acredito em tempo ao tempo, equipes fortalecem-se e encontram seu ritmo.

As vezes não consigo deixar de lembrar o episódio do “Dino Da Silva Sauro” da família Dinossauro, quando assina uma TV a cabo com 150 canais … ele faz um cálculo e concluiu que a cada hora deveria assistir 24 segundos em cada canal para aproveitar ao máximo o investimento. Via de regra, menos é mais!