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

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!

0

Fibonacci, User Story Points e Frutas

Um time de profissionais com alguma experiência em desenvolvimento de software tem plenas condições de planejar sprints em algumas horas ou dias, a única premissa é desapegar dos detalhes e discutir apenas a complexidade, o suficiente para comparar e inferir o seu tamanho.

É claro que precisamos ter antes um tanto de auto-conhecimento e clareza no fluxo de trabalho necessário, responsabilidades, DoR e DoD, o restante é básico, como profissionalismo, empatia, senso de pertença e evitar erros conhecidos.

Na chincha, o tipo de estimativa é irrelevante, quer seja T-Shirt Size, User Story Points, Dias Ideais ou Jujubas, … a técnica usada para estimar não muda em nada a quantidade de software que uma equipe é capaz de construir em uma sprint de 10 dias.

Independente de ter sido estimado com tamanho M ou ter 5 pontos, ser 4 dias ideais ou precisar de 7 jujubas, não mudará o fato mais importante que é saber se ele junto de algumas outras histórias cabem ou não em um sprint de 10 dias úteis.

User Story Points

User Story Points usa a série de Fibonacci, uma sequência de números inteiros, começando por 1 e 1, com os subsequentes correspondendo à soma dos dois anteriores [1, 1, 2, 3, 5, 8, 13, 21, …], que em estimativas de software é usual fixar um teto, com frequencia 13 ou 21.

O uso desta série para estimativas de histórias tem o objetivo de desapegar dos detalhes e nos preocuparmos apenas com aspectos que determinem a mudança de patamar. Desta forma, quanto maior a incerteza, maior a história e maior a distância entre os números da escala.

Salada de frutas

Vejamos uma boa analogia sobre a arte de estimar usando Fibonacci e o estabelecimento de referências e comparações. Para visualizar o que estou afirmando proponho um exercício com a imagem abaixo, uma mesa com vários tipos de frutas.

Se o nosso projeto é desenhar e colorir frutas, posso estimar a partir do tamanho em área, perímetro, volume, mas existe também a existência de detalhes, número de cores, a abstração disso tudo podemos chamar de complexidade.

Complexidade diz respeito ao todo, shape, diâmetro, cores, mas se antigamente estimávamos listando cada um e todos estes detalhes, em metologias ágeis uma breve discussão sobre suas peculiaridades é suficiente para perceber se é mais ou menos complexo que outros.

Após discutir sobre as frutas, é possível estabelecer o que seria a menor fruta em sua complexidade geral, para desenhar, pintar e entregar. Feito isso, vamos estimando comparativamente cada uma das outras.

Na prática, não há uma regra óbvia, cada time poderá estabelecer uma base e comparação para a sua estimativa, semelhante mas não necessariamente igual. Mesmo assim, se realizada de forma adequada e consciente, responsável, é provável que tudo dê certo.

Usando pontos sob o paradigma de complexidade relativa, a estimativa não é pelo tamanho da fruta, nem número de côres, mas pela complexidade comparativa, na percepção de esforço que teremos quando tivermos que desenha-las e colori-las.

Talvez o limão fosse o tamanho 1, será nossa referência de unidade, porque é liso, todo amarelo, o morango é menor, mas mais difícil de desenhar e colorir, por isso o 3, o abacaxi se equivale a abóbora grandona, bem maior, mas com shape menos complexo.

Isso não é muito diferente de software, as principais informações são as integrações, excepcionalidades inerentes a regras de negócio, sofisticação diferenciada, não queremos saber detalhes daquilo que é comuns, apenas do incomum.

Parafraseando Pareto e Juran, entre tantos detalhes triviais em cada tela de um sistema, haverá poucos detalhes vitais que as diferenciem em complexidade … uma percepção que se apura a cada experiência, porque afinal, estimativa se aprende estimando.

Já participei de projetos em que o time tinha alçada e decidiu não mais estimar, apenas discutir, entender e decidir quais caberiam em cada sprint. conforme prioridade e valor. Não é muito diferente dos outros tipos de estimativas, porque no final queremos apreender o que cabe ou não.

Mas por hora não entrarei muito nesta discussão, porque números, métricas, PxR e outras matemáticas ainda são necessárias para a maioria aprender, crescer e aperfeiçoar-se como profissionais … com números tudo fica um tanto mais explícito.

2

No TDC POA 2017 falei sobre o SSC e DJM

No dia 11/11/17 tive o prazer de participar novamente da trilha Agile do TDC Porto Alegre, ano passado da abertura e este ano com o encerramento. No ano passado fiz uma palestra provocativa sobre Agile Transformation, este ano sobre a necessidade de materializar nossa estratégia e tática, metodológica, tecnológica e humana.

TDC POA 2017 – SSC & DJM

Scrum Setup Canvas – Antes de entrar em um planejamento de releases e suas sprints é preciso materializar aquelas informações que o excelente Project Model Canvas do Prof Finocchio nos oferece como termo de abertura. É essencial estabelecermos parâmetros como pontos de atenção do mapa de tecnologia, formato, DoR e DoD, sprints e etc:

Doc Journey Map – Pesquise e analise as boas práticas sobre artefatos e documentação, mas faça isso para subsidiar uma análise crítica sobre a sua realidade, cultura, tecnologia e pessoas. Para cada documentação utilizada ou desejada é possível fazer um canvas A3 discutindo a origem, sustentação e destinação, seu custo x valor x benefício:

Sobre estes artefatos, tenho outros posts, vídeos e manual de uso:

02/04/17 – Spoiler da minha palestra para o Agile Trends
13/04/17 – Vídeo de  25 min no Agile Trends
07/06/17 – Versão pdf tamanho A3 para impressão
31/07/17 – Agile Trends Gov – Relato do evento
30/08/17 – Guia de uso para o SSC
06/09/17 – Aprenda com sua documentação

Tenho uma foto logo após minha palestra com parte da galera que assistiu com os coordenadores da trilha:

0

Tem o 5W2H, Managing Dojo, Learning 3.0, mas não esqueçam do A3 Report

É fundamental ter diferentes técnicas que orientem e organizem discussões para resolução de problemas, aproveitamento de oportunidades, desafios de inovação e superação. Eu chamo de Toolbox 360º, lancei um livro e um jogo de tabuleiro com este objetivo, provocar profissionais a refletirem sobre o mix de técnicas que domina e lança mão conforme necessidade.

Tenha e amplie sua toolbox permanentemente, lembre-se da alegoria da caverna de Platão e do ditado popular, porque para alguém que só conhece o martelo, todo problema parecerá um prego:

O uso de técnicas de gestão visual, mapas mentais, 5w2h, managing dojo, learning 3.0, entre outras, conta também com a dinâmica Lean conhecida como A3 Report. Trata-se do instanciamento dos princípios básicos do Lean – fracionar, descentralizar, antecipar mais valor, alta performance, eliminar desperdícios, aprender e melhorar continuamente, ver o todo, …

PDCA – Estabelecido um desafio, o tema da discussão, direcionamos a discussão a resultados, iniciando pelo entendimento, efeitos e causas, alternativas e plano de ação, como monitorar sua evolução e resultados, de forma iterativo-incremental, aprendendo e melhorando a cada ciclo.

Plan – Qual o desafio e sua relevância, valor; histórico, se algo já foi feito e se há contingenciamento; se possível incluindo algo explícito e visual como dados diagramáticos, números; com exercício de análise causal, 5W2H, CSD, Ishikawa ou Pareto;

Do – Frente as causas e efeitos analisados, qual o plano de ação, contando com aquelas informações necessárias para entendimento mínimo ne planejamento, como tempo, recursos e responsável, qual o resultado esperado a cada passo e final;

Chek – Quais as métricas e indicadores a serem utilizados para monitoramento e controle, com que frequência serão medidos, preferencialmente de forma auto-organizada pelo próprio time; favorecendo percepção de riscos e correções de rumo;

Act ou Learn – Aproximando participantes e stakeholders, com comunicação explícita e assertiva frente a objetivos de valor, com gestão do conhecimento (tácito-explícito) e conversão em aprendizado e correções para um novo ciclo de sucesso;

Ao procurar na internet por A3 report, explicitamente recebemos centenas de páginas sobre o uso desta técnica e assemelhadas, não só no contexto Lean fabril, mas até mesmo em referências ágeis como na Scrum Inc em um exercício sobre a não entrega de valor por sprint:

Uma página me chamou a atenção, com múltiplos exemplos e boa didática, impossível ler este post do Edson Miranda da Silva e não entender a técnica em sua plenitude – https://qualityway.wordpress.com/2017/05/04/a3-passo-a-passo-com-exemplos-reais-por-edson-miranda-da-silva/