finito

Tag: Marty Cagan

  • A Sprint Ideal tem Duas Trilhas?

    A Sprint Ideal tem Duas Trilhas?

    Já rabiscamos a estrutura de uma Sprint Ideal. Falamos sobre início e fim,  cerimônias, duração e a necessidade de folgas. O papo de hoje é sobre o que acontece dentro de uma sprint. Gente muito boa¹, como Marty Cagan e Jeff Patton, sugeriu o trabalho em duas trilhas (dual track). Há controvérsias, claro. Além de ideias que merecem dois ou três giros experimentais. 

    Não estamos em uma corrida de revezamento, como aquele quadro kanban/scrum parece sugerir de vez em quando. Esse jeito de ver o desenvolvimento de produtos e soluções deveria ter sido definitivamente escanteado lá em meados dos anos 1980, quando Takeuchi e Nonaka nos apresentaram o jeito scrum de pensar – ou, melhor dizendo, o jeito japonês de desenvolver produtos².Outro trabalho seminal da dupla, Gestão do Conhecimento (Bookman, 2008), inspirou a matriz ao lado. No eixo horizontal navegamos do entendimento de um problema (análise) até a criação da solução (síntese). Na vertical diferenciamos a natureza de nossas fontes, matérias-primas e artefatos. Eles podem ser concretos (gentes, fatos, problemas) ou abstratos (hipóteses, personas, planos).  É uma bela coincidência o encaixe sem gambiarras do ciclo OODA (Observe, Oriente, Decida, Aja) nesta matriz. Observação e Ação ocorrem aqui, no mundo real, concreto. Elas lidam com fatos e envolvem e afetam gente de carne e osso. Do outro lado, lá em cima, estão os trabalhos baseados em ideias e possibilidades. Na Orientação nós criamos opções para, logo depois, tomarmos Decisões. Os termos originais falavam com pilotos de combate. A partir deste ponto vamos chamar os trabalhos de Descoberta, Exploração, Desenvolvimento e Entrega. 

    Aos Trabalhos

    Os proponentes do modelo Dual Track falam em dois tipos de trabalho: descoberta (discovery) e desenvolvimento (development). Veja o desenho sugerido por Jeff Patton:Patton, no mesmo artigo, reconhece a existência de um terceiro tipo de trabalho, o design tático. Ele defende que os trabalhos são diferentes porque requerem um jeito de pensar diferente. Vamos retomar a matriz sugerida anteriormente? Não são dois ou três tipos de trabalho. São quatro! Em cada quadrante temos fontes e materiais distintos. Mais que isso, temos objetivos bastante diferentes:

    • Descobrir: revelar, jogar luz, tomar conhecimento, fazer conhecer.
      É neste momento que delineamos o problema ou parte dele. É aqui que conhecemos as pessoas envolvidas (holders) e temos o primeiro contato com seus interesses (stakes) e dores. É aqui, no mundo real, que descobrimos o que precisa ser feito.
    • Explorar: percorrer (região, território) para estudar, pesquisar, conhecer.
      O entendimento do problema continua e se enriquece quando começamos a cogitar alternativas de solução. Brincamos com hipóteses, rabiscamos arquiteturas e validamos protótipos. É no campo das ideias que exploramos o como fazer. 

    Aquilo que Patton e Cagan apresentam como a trilha discovery é a combinação de dois trabalhos. Pense no OODA original. Observação e Orientação são trabalhos distintos. Complementares, com certeza, mas muito diferentes. Fechando a matriz:

    • Desenvolver: elaborar, criar. No OODA original, é o momento das tomadas de decisão. Dentre as diversas opções sugeridas durante a Exploração, algumas começarão a ganhar vida neste quadrante. Para encontrar o mundo real logo depois. 
    • Entregar: para muita gente seria apenas uma questão de “colocar em produção”, “subir pra nuvem”, “mudar de assunto”… É claro que a entrega é muito mais que isso. Pode envolver a preparação das pessoas que receberão aquela mudança. Deveria incluir o monitoramento de indicadores que vão comprovar ou não a solução do problema dado. Enfim, é botando para rodar e quebrar que nós aprendemos e justificamos nossos ganhos e choros. É aqui, no mundo concreto, que encerramos e começamos tudo de novo.

    Patton e Cagan tratam os dois trabalhos acima na trilha de desenvolvimento. Nossa matriz, mais colorida abaixo, mostra como Desenvolvimento e Entrega são movimentos/momentos diferentes:

    Quatro Trabalhos / Duas Trilhas

    Durante muito tempo convivemos com o ciclo PDCA (Plan/Do/Check/Act) como se ele fosse o único ou o melhor molde para todos os nossos métodos. Apesar do berço esplêndido e de teimosos ilustres³, faz tempo que o PDCA deu o que tinha que dar. Os problemas que merecem a nossa atenção pedem por novos modelos mentais.

    O ciclo OODA nasceu da necessidade de fazer com que pilotos de caça voltassem para casa sãos e salvos. O ciclo, naquele contexto, poderia girar dezenas de vezes em uma única missão. Tente calçar aqueles coturnos. Pense em como deve ser um combate nas alturas controlando uma máquina a, sei lá, 3.000 km/h?  Pois é, o OODA parece ser uma ideia – um jeito de pensar – bastante adequado para nossos tempos velozes e furiosos. Se você topa este entendimento, então aceita o fato de que temos quatro e não dois trabalhos. 

    Quatro trabalhos em duas trilhas: Divergente e Convergente. Surrupio os termos sugeridos por Tim Brown em Design Thinking (Alta Books, 2017). Na primeira nós criamos opções. No outra, tomamos decisões. Você prefere usar Upstream e Downstream? Fique à vontade.

    Como?

    Reclamações acerca das dificuldades de trabalhar com “ágil” – feitas por designers, analistas de negócios e afins – foram sumariamente ignoradas por muito tempo. Foi necessária a intromissão de nomes mais conhecidos – Marty Cagan, James Coplien, Peter Morville e Jeff Patton, por exemplo – para que a sugestão do trabalho em duas trilhas fosse percebida. Aceita não, percebida. 

    Confesso que ainda não vi o dual-track rodando em sua plenitude. Muitos times preferem apostar em coisas como o refinamento ou workshops de requisitos. Repare: esses eventos parecem ser espaços abertos na agenda do time – concessões? – para a realização dos trabalhos de descoberta e exploração. Como se a realização deles fosse possível em dois ou três encontros por sprint. Sei não, mas isso tem jeito e cheiro de cascata.

    Descoberta e exploração deveriam acontecer todo santo dia. É por isso que a convivência diária do time com gente do negócio é um requisito para o bom uso do XisPê, Scrum etc. 

    A gente tentou encaixotar o trabalho criativo em timeboxes que fazem muito sentido para desenvolvimento e entrega, mas nenhum sentido para descoberta e exploração. São ritmos diferentes, paradas e roteiros variados. 

    “Em vez de considerar essa característica ad hoc como um dado de inferioridade do design, creio que isso atesta a independência epistemológica da área – o design não é necessariamente científico, mas pode estabelecer diálogos muito fecundos com a ciência”.
    – Caio Adorno Vassão em Metadesign (Blucher, 2010)

    Sigo confiando na proposta das duas trilhas. Aliás, dadas as críticas mais recentes?, estou disposto a dobrar a aposta. Porque elas partem de um engano: há dois times trabalhando, um em cada trilha, cada um com seu backlog!? Não foi isso que Cagan e Patton escreveram. Caramba, basta ler os artigos: há duas trilhas, não dois times. Tá todo mundo junto, o tempo todo! O tempo todo? Veja bem…

    Notas

    1. Marty Cagan escreveu Inspired: How to Create Tech Products Customers Love (Wiley, 2018) e Patton ficou famoso por causa de User Story Mapping (O’Reilly, 2014). Cagan escreveu o artigo Dual-Track Agile há oito anos. Patton voltou ao tema logo depois.
    2. No artigo The New New Product Development Game, publicado na edição de jan-fev/1986 da Harvard Business Review.
    3. O ciclo PDCA é cria de W. Edwards Deming e defendido, na comunidade Lean-Agile, por gente grande como Mary e Tom Poppendieck. Em Implementando o Desenvolvimento Lean de Software (Bookman, 2011), por exemplo. É risível a forçada de barra dada para justificar o P (plan).
    4.  We Need One Complete Product Team, de Todd Lankford (27/ago/20).
        Time to Say Goodbye to Dual Track Agile?, de Alex Ballarin (12/set/20).
    5. Foto de Henry & Co. surrupiado no Unsplash
  • O Buraco Comum

    O Buraco Comum

    Não importa se é um bug ou característica programada. O fato é que os métodos e frameworks mais populares – particularmente Scrum e Kanban – tropeçam no mesmo buraco. Apesar de suas imensas diferenças, essas propostas são omissas ou relapsas no mesmo ponto. No distante 1986 Fred Brooks nos alertou¹:

    “A correta definição do que precisa ser feito é a etapa mais difícil do desenvolvimento de sistemas. Nenhuma outra compromete tanto um projeto quando mal executada. E nenhuma é mais difícil de ser corrigida.”

    O que fizemos de lá para cá?

    • Distorcemos todos os currículos relacionados com a formação de engenheiros e analistas de sistemas. Enfatizamos o domínio da solução – programação e mais programação – em detrimento do domínio do problema.
    • Mas a Academia, apressada, estava apenas seguindo o mercado. Um mercado que inventou, em meados dos anos 1990, um tal de analista-programador. Isso tem reflexos negativos até hoje. Basta ver a reincidência de um álibi fajuto: “o cliente/usuário nunca sabe o que quer”. Quem aprendeu a perguntar? Quanta ajuda o cliente/usuário tem merecido?
    • De repente, ganhamos Agilidade. Com muitas propostas que parecem ser “do desenvolvedor, pelo desenvolvedor, para o desenvolvedor”. A coisa só piorou.
    • E tocou o fundo do poço quando alguém acreditou que um Business Model Canvas –  uma cortina feita de papel sulfite – seria capaz de esconder aquele imenso buraco.
    • Oras, e se o buraco for apenas uma hipótese? Vamos todos fingir que o buraco não existe; Ou é parte da decoração; Ou é só a opinião de alguém.
    • Por fim, se o tal Upstream Kanban pretende, ainda que parcialmente, tratar do domínio do problema, então ele não pode começar se apresentando como um “processo de triagem”. Que vai da síntese para a análise? Fixando CONWIPs?!?²

    A Acusação Comum

    Um efeito esquisito do movimento Ágil, que contradiz sua intenção de ser Sistêmico, é a percepção generalizada de que tudo o que não é construção é desperdício. James Coplien e Gertrud Bjørnvig reclamam disso em Lean Architecture (Wiley, 2010). Peter Morville, falando de Arquitetura de Informações, relata o mesmo problema (Intertwingled, 2014). E o que dizer da Análise de Negócios? Que ela deu um tiro no pé quando publicou uma Extensão Ágil. Confessou uma culpa que não deveria ter. Pau que nasce torto…

    A acusação ficou chique e mereceu até sigla: BDUF (Big Design Up Front). É importante destacar que a acusação não é vazia. É preciso lembrar o contexto que motivou o Manifesto Ágil. Era comum, naquele tempo, um mal conhecido como Analysis Paralysis. A burocracia emperrava pacas. Projetos entregavam bulhufas.

    A diferença entre o remédio e o veneno é o tamanho da dose. Erramos a mão e criamos outro mal, a Agile Death Spiral. Sprints sem fim ou fins. Pivots mil. Um desastrado foco na eficiência que ignora o primordial: ao fazer a coisa errada do jeito certo, só estamos acelerando rumo ao desastre.

    Entre a cascata congelada no tempo e o pós-moderno ciclone da morte deve haver um caminho.

    Equilíbrio

    A sugestão do Yin-Yang é de Peter Morville, no livro já citado. A imagem combina bem com a matriz apresentada no artigo anterior. Que esteja subentendida a necessidade de iterações. O ícone também informa que há construção nos momentos iniciais. E que não é proibido rever o problema e repensar os planos nos momentos seguintes.Esse equilíbrio bem zen seria perfeito se o alerta do Brooks não continuasse verdadeiro: aquela primeira metade (escura) é a mais crítica para o sucesso de um projeto ou produto. Mas ela não existe no Scrum, por exemplo³. O que nos levou a entender que bastaria puxar para o domínio do problema o mesmo esquema utilizado no domínio da solução. Vêm daí os sprints 0, -1 etc. Essas iterações podem ser úteis para a realização de spikes (experimentos), configuração do ambiente e coisas do tipo. Mas não têm nada a ver com o domínio do problema. O que é conhecido como grooming também não.

    Sprints com duração fixa de uma, duas ou quatro semanas fazem muito sentido nos trabalhos de DESENVOLVIMENTO e ENTREGA. Mas viram camisas de força nos trabalhos de DESCOBERTA e EXPLORAÇÃO. Nesses momentos, é comum a necessidade de cinco ou dez iterações em uma única semana. Marty Cagan, em Inspired (Wiley, 2017) fala em até vinte iterações. Jake Knapp, em Sprint (Intrínseca, 2016), nos mostra um ciclo completo acontecendo em uma semana. Enfim, a variedade aqui é grande. E necessária.

    O Design Thinking nos oferece ampla variedade de métodos e ferramentas para o Domínio do Problema. Não foi por outro motivo que Jonny Schneider, da Thoughtworks, propôs a seguinte combinação:

    • Design Thinking: para explorar o problema
    • Lean: para construir a coisa certa
    • Agile: para construir do jeito certo

    Legal. Mas o Manifesto Ágil não fala em eficácia logo no seu primeiro princípio? As propostas Lean não parecem preocupadas com eficiência? O Design Thinking não tem o que contribuir para o domínio da solução? A ideia do Schneider é promissora. A mensagem “Lean E Agile” ao invés do OU é correta. Mas a divisão de responsabilidades proposta acima não faz o menor sentido. 

    Acho que nós precisamos de outro enfoque, mais amplo e inclusivo. Precisamos de um modelo que incorpore, sem puxadinhos, uma legítima preocupação com o domínio do problema. Que faça a gente “se apaixonar pelo problema, não pela solução“.  Bom tema para o próximo artigo.

    Notas

    1. No artigo No Silver Bullet, transformado em capítulo da edição comemorativa de The Mythical Man-Month (Addison-Wesley, 1995). Este trabalho, lançado originalmente em 1975 (!), acaba de ganhar nova edição em pt-br: O Mítico Homem-Mês (Alta Books, 2018). Parafraseando Brooks: “a longevidade desse livro atesta que a gente continua caindo nos mesmos buracos…”
    2. São algumas sugestões apresentadas por Patrick Steyart em Essential Upstream Kanban.
    3. Que fique claro: não se trata de um bug do Scrum. A omissão é intencional. E só vira um problema se a gente a ignorar. Ou, pior ainda, se a gente esticar o Scrum para cobrir o buraco.
    4. “Se apaixone pelo problema, não pela solução” é uma das dicas de Marty Cagan em Inspired (Wiley, 2017).
    5. hole in the wall é o título da óbvia imagem de hoje.