finito

Tag: Pensamento Sistêmico

  • Aviso aos Navegantes Acelerados

    Aviso aos Navegantes Acelerados

    Eu sei, você está com pressa. Por isso este aviso não vai ultrapassar o limite de 250~300 palavras. Se a sua velocidade de leitura fica na média, isso significa que este post custará, mais ou menos, um minuto da sua vida. Sessenta segundos! Valerá a pena? Você dirá.

    Já me pediram para vender aulas gravadas. Assim a pessoa poderia sorver meu conteúdo de madrugada, distante dos ruídos da vida, tocando os vídeos a 1.5x. 

    Já sugeriram que eu disponibilizasse meus artigos na forma de podcasts. Seria mais um nessa cacofonia infinita. Mas, veja bem: a pessoa poderia sorver meu conteúdo enquanto cozinha, malha, se banha ou… 

    Já concluíram que a nova geração não lê. Portanto, eu deveria explorar os novos meios se não quiser ficar falando com as paredes. 

    135 palavras. As questões estão dadas. Respostas:

    Aula é interação. Aumentamos as nossas chances de troca e de aprendizagem se estivermos de fato juntos, ao vivo, síncronos. Conversando.

    A leitura não é uma habilidade inata. É algo que devemos aprender. É hábito que se desenvolve. É um exercício que movimenta o cérebro de uma forma diferente. A gente pensa diferente enquanto lê. São pensamentos potencialmente melhores porque tendem a ser mais profundos, atentos. Como se não bastasse, nossa escrita tende a melhorar também. Daqui a cem anos, se ainda estivermos por aqui, leitura e escrita continuarão sendo habilidades essenciais. 

    O que não quer dizer que podcasts, vídeos e games não tenham o seu valor. Claro que têm. Mas não ao ponto de tornar obsoletas as conversas que acontecem tête-à-tête ou através das palavras escritas.

    De qualquer maneira, sou muito grato pela sua preocupação. E pelo seu tempo. Vai lá, deve estar na hora.

  • Agile, pra que te quero?

    Agile, pra que te quero?

    Te quero para fazer o dobro do trabalho na metade do tempo. Topo tudo por eficiência$ – para fazer bem mais com muito menos. Para seguir retorcendo e esticando a corda colocada por Taylor e Ford lá no início do século passado. 

    Te quero para dar roupa e nomes novos para meus velhos hábitos e habitats. Quero tribos, guildas e esquadrões bem alinhados em minha mal disfarçada organização matricial. Assim mantenho o statu quo de um jeito SEGURo. Com certificados e atestados de maturidade. E daí se a ideia original era cancelar esse mindset de certificações e modelos de maturidade? Entenderam nada, inocentes!

    Nosso rocambole é pós-moderno. Vou provar através de uma matriz 2×2 que não pode ser chamada de matriz 2×2 com um buraco no meio – saca Magritte? – que a nossa metodologia é o única que está pronta para lidar com essa tal complexidade. Prontinha: Out-of-the-box!

    Ah, $cara agilidade, te quero como sombrinha e sombreiro. Faça chuva ou faça sol, seja qual for a pergunta, você será a resposta. Devidamente embrulhada num pacote de jargões, nomes esquisitos e anglicismos que vão separar nitidamente os fortes dos fracos, os verdadeiros agilistas dos céticos e patéticos cascateiros. Que venham os épicos!

    Terra Arrasada

    Não é por acaso que Kent Beck, um dos pais dessa ideia sem mãe, recentemente disse¹ que o Ágil “virou terra arrasada. A vida foi toda sugada para fora dele. Virou um conjunto de rituais religiosos realizado por gente que não entende o propósito original desses rituais”. 

    Não é de hoje que os signatários do Manifesto Ágil lamentam o estado deplorável de sua cria. Assim como acontece com o rock’n’roll, pela enésima vez vão anunciar a morte do Agile². Só para confirmar, pela enésima vez, sua teimosia. Apesar de todos os sopapos e mal entendidos. Apesar do marketing desastrado/desastroso que o acompanha desde o berço.

    Anarquistas, graças ao marketing

    Dezessete caras pançudos de meia idade se reuniram em um resort para “esquiar, relaxar, colocar o papo em dia e encontrar pontos comuns em suas ideias sobre o desenvolvimento de software”. O processo durou três dias e gerou um documento de duas páginas. Em agosto de 2001 a Software Development anunciou a boa nova com a capa ao lado. O artigo, de onde surrupiei as aspas anteriores, foi escrito por Jim Highsmith e Martin Fowler, dois dos dezessete barrigudos. O que nos permite entender que eles não se incomodaram com a tag anarquistas nem com a mensagem da capa. 

    Hoje, quase vinte anos depois, o manifesto segue sendo mal apresentado pra chuchu. Há poucos dias a revista EXAME colocou na conta da pandemia um crescente interesse por uma metodologia ágil. Dá a entender, por exemplo, que a adoção do modelo Spotify, algo que nem a empresa sueca faz, seria condição para a agilidade. A sucessão de mal entendidos não é exclusividade nossa. Saca só um recorte da Harvard Business Review:

    Pois é, creditam Sutherland como grande liderança por trás da “invenção” da ideia ágil. Sutherland é o mesmo que promete na capa de um livro “a arte de fazer o dobro do trabalho na metade do tempo”. O faz porque parece estar apostando corrida contra o cara que pegou um time CMMI nível 5 na Índia e aumentou sua produtividade em 200%! 

    Quem resiste a tanto apelo? Que pessoa de negócios em sã consciência pode se dar ao luxo de ignorar propostas tão ambiciosas? 

    Só tem um probleminha: o Ágil nunca prometeu nada disso. 

    Agilidade, para que serves?

    Ao priorizar a gente e as nossas conversas, o resultado concreto de nosso trabalho e respostas rápidas – ciclos bem curtos de feedback, o Manifesto Ágil aponta para uma grande inimiga: a Complicação.

    Nossos negócios ficaram 35 vezes mais complicados nos últimos cinquenta anos³. Esta foi a nossa resposta inconsequente à crescente complexidade: Inventamos departamentos, seções, funções, tribos, capítulos, guildas, escritórios disso e daquilo; Desenhamos processos cada vez mais prescritivos, minuciosos e paranóicos; Despejamos um sem número de políticas e regras que são cada vez mais efêmeras e frágeis; Impusemos uma enxurrada de indicadores que atestam um único fato: a nossa insegurança. Enfim, bagunçamos o coreto do negócio dificultando a convivência interna e comprometendo todas as relações que existem da porta para fora. 

    A “ideia Ágil” não foi a primeira nem será nossa última invenção para combater as burocracias que emperram nossas organizações e nos dão tanta canseira. Cedo ou tarde ela merecerá uma lápide bonitinha no museu de grandes novidades onde descansam a Reengenharia, TQM, BPM, SOA, KM…

    Até lá – até que se invente algo melhor – faz sentido que a gente tente tirar o melhor possível da ideia. As exigências são mínimas: 1) alinhamento: saber o que precisa ser feito e por que; e 2) autonomia: para definir a melhor maneira de realizar aquele objetivo. Repare, há apenas uma condição para a realização dos dois fatores: confiança. E como saber se podemos confiar nas pessoas? Oras, como ensinou o ágil Papa Hemingway, confiando nelas.

    PS

    Se a velha guarda pançuda estivesse mesmo abandonando sua cria, por que então se preocuparia em escrever e receber tão bem um trabalho como Clean Agile – Back to Basics (Robert Martin – Pearson, 2020)? É claro que a Ideia Ágil merece uma nova chance. Porque, quando bem entendida, ela é muito boa. 

    Curioso é vê-la muito bem entendida e aplicada numa seara que não tem nada a ver com software nem com negócios. É o que documenta Zaid Hassan no livro The Social Labs Revolution (Berrett-Koehler, 2014) sem disfarçar seu entusiasmo: “o Ágil come cisnes negros no café da manhã”. 

    Notas

    1. Nesta entrevista publicada pela Built In no último dia 18/08/2020.
    2. Há uma extensa coletânea de obituários neste artigo publicado no LinkedIn.
    3. Segundo pesquisa do Boston Consulting Group apresentada em Six Simple Rules, de Yves Morieux e Peter Tollman (HBR Press, 2014 – p. 7).
    4. Foto de Kelly Sikkema no Unsplash
  • Pra Pensar

    Pra Pensar

    Nosso cérebro gosta de organização. Ele classifica, rotula e relaciona tudo o que decide guardar. Assim, o ato de lembrar fica mais econômico. Sofisticado como ele só, o cérebro é um recurso caro. Tem apenas 2% de nosso peso,  torra 20% de nossas energias. Por isso evoluímos obedecendo, pianinhos, a lei do menor esforço. Por isso carregamos por aí um sistema bem lerdo e preguiçoso, como mostra Daniel Kahneman em Rápido e Devagar (Objetiva, 2012).

    Neurônios ligados disparam juntos¹. E quanto mais são acionados, mais ágeis e eficientes se tornam. É como aquela trilha que se destaca no gramado por ser muito usada.  O bom pensador é um colecionador de variadas trilhas. Ele cuida de sua especialidade. Mas apreende, com igual interesse, o que é essencial nas principais áreas do conhecimento.  

    O professor e psicólogo Edward De Bono – que nos deu, entre outras coisas, o Pensamento Lateral e o Método dos Seis Chapéus – vive reclamando a falta da disciplina PENSAMENTO. Ele tenta impulsionar uma área de conhecimento que nos ensine a pensar. Ela teria caráter técnico; Seria diferente da Filosofia e Psicologia. Nunca precisamos tanto de uma matéria assim: multidisciplinar, prática, sistêmica. É difícil dizer como ela seria estruturada. Mas é fácil chutar que ela nos ensinaria Modelos Mentais: ideias, padrões e heurísticas que agilizam e melhoram nossos pensamentos. 

    Modelos mentais são como apps para o nosso cérebro. Eles agregam funcionalidades. As possibilidades são tantas que é fácil criar confusão. Assim como bagunçamos nossos smartphones. Por isso é fundamental uma classificação dos modelos. Desconheço uma sugestão de taxonomia que tenha sido replicada em mais de um trabalho. Torço para que prevaleça uma organização baseada no tipo de pensamento que queremos provocar. É assim que está estruturada a aula Modelos para Pensar, com três partes: Curiosidade, Crítica e Criatividade. 

    Curiosidade

    “A curiosidade é a cura para o tédio;
    Não há cura para a curiosidade.”
    – Dorothy Parker


    A curiosidade nos empurra para novos conhecimentos. É ela que nos faz descobrir novos campos, oportunidades e ferramentas. Por isso a aula começa com um modelo sugerido por Warren Buffett², o Círculo das Competências. Proponho um autoexame enfileirando modelos. Minha intenção é mostrar como essas ideias funcionam em conjunto. Estou com Scott Page, em The Model Thinker (Basic Books, 2018): precisamos de diversos modelos para pensar melhor. Page não cita, mas está apenas respeitando a Lei de Ashby: só a variedade absorve variedade. 

    A mistura de ideias acaba virando um exemplo prático de outro modelo mental: Juros Compostos. “A maior força da natureza”, teria dito Einstein. Experimente: aplique a ideia de juros sobre juros em sua estratégia de estudos. 

    Opa! Não há uma estratégia? Você está confusa/o? Quem não está? Segundo Tom Peters, só não está um tanto perdido “quem não está prestando atenção”. Nosso cérebro, o mais complexo sistema conhecido, não está bem preparado para tanto ruído, desinformação e mentira. O que justifica o segundo bloco da aula: crítica. 

    Crítica

    “Cadê a sabedoria que perdemos com o conhecimento?
    Cadê o conhecimento que perdemos com a informação?”
    – T.S. Elliot (1934)

    Cadê a informação que perdemos com o big data? Porque “informação é a diferença que faz diferença”, avisou Gregory Bateson. Desses zilhões de bits que nos bombardeiam incessantemente, quantos de fato prestam? 

    Este hardware extraordinário que carregamos entre as orelhas tem bons filtros que vêm instalados de fábrica. Dos oito bilhões de bits que chegam aos nossos sentidos a cada segundo, ficamos com apenas algumas centenas. Todo o resto é ignorado. Depois, quando dormimos, outro filtro entra em ação. E faz uma faxina para eliminar tudo o que não deve nos fazer falta porque não lhes pagamos a devida atenção enquanto despertos. Há quem ache que a gente só dorme pra isto mesmo: limpar a cuca, rever e reforçar as boas relações entre neurônios. 

    A configuração dos filtros nos atendeu bem até pouco tempo atrás. Mas está falhando feio neste século da infobesidade. Tanto que está virando questão de saúde pública e prateleira de livros com títulos curiosos. Sim, precisamos de mais e melhores fodasses. Que não são uma arte nem precisam ser sutis. 

    Existem, por exemplo, as navalhas de Occam, Hanlon, Taleb e Caetano. O princípio de Pareto também é um tipo de navalha. Navalhas também são um tipo de modelo mental. Dos mais funcionais. Dispensam o manual de operação. O mesmo não pode ser dito do Facão de Bayes. Que não deixa de ser muito útil por causa disso. 

    Três dos nossos ativos mais valiosos são atenção, confiança e tempo. Se nós não os protegermos, ninguém o fará. Nós filtramos – nos liberamos – para ter tempo e espaço para exercer o que nos torna mais humanos: criar.

    Criatividade

    “Criatividade é a inteligência se divertindo.”
    – Albert Einstein

    Traiçoeiro terreno. Porque muita gente acha que criatividade é uma característica inata, um talento: ou você nasce com ele ou estaria condenada/o a uma vida sem sal nem graça. Outros tantos parecem defender que esse papo de criatividade é para quem faz arte; o atributo não teria muita utilidade no dia a dia nem no mundo sério – o do trabalho. Há uma frase anônima que incomoda por ilustrar bem esse preconceito: “o adulto criativo é a criança que sobreviveu”. 

    Tento driblar essas restrições lançando mão de um funil sugerido por Ken Robinson em Somos Todos Criativos (Benvirá, 2019): a inovação que todo mundo parece buscar – ainda que da boca pra fora – não é possível sem criatividade que, por sua vez, não existe sem uma imaginação bem solta. Não é mera coincidência o fato desta sequência ser muito parecida com o Funil do Conhecimento sugerido por Roger Martin em Design de Negócios (Alta Books, 2010). 

    Os modelos mentais apresentados nesta parte da aula não tentam provar a relevância da criatividade. Para isso bastam dois ou três empurrões/citações. Os modelos aqui apresentados tentam mostrar como é natural criar. Em trabalhos solitários ou em times; lidando com grandes ou pequenos problemas. A gente complicou bastante nos últimos séculos. Mas não é nada que a gente não consiga desaprender ou desfazer com um pouco de criatividade. 

    Conclusão

    Os três traços – Curiosidade, Crítica e Criatividade – foram escolhidos porque são atributos que ainda nos diferenciam das inteligências sem vida. Reforçá-los através de bons modelos pra pensar parece ser um bom investimento. 

    Notas

    1. Tradução mequetrefe de neurons that fire together wire together.
    2. Não é mera coincidência: Charlie Munger, sócio de Buffett, ajudou a impulsionar esse papo sobre Modelos Mentais. Em várias palestras e no seu Poor’s Charlie Almanack (Donning, 2005).
  • Um Almanaque para Tempos Difíceis

    Um Almanaque para Tempos Difíceis

    Tratar este trabalho como um almanaque é uma forma esperta de me isentar de certas responsabilidades. Pare por um instante e pense em como você receberia um Manual ou Guia para tempos difíceis. O que dizer das enciclopédias e bíblias? Um almanaque promete menos, muito menos. 

    Um bom almanaque é obrigatoriamente informal, prático e objetivo. Devo adiantar que sigo Kurt Lewin¹, para quem “não há nada mais prático do que uma boa teoria”. Este almanaque está cheio delas, das teorias. Se são boas ou não você dirá. É essa base teórica que justifica e viabiliza a organização deste trabalho. A mesma base vai te ajudar a desenvolver uma caixa de ferramentas para esses tempos difíceis. 

    Todos os bons almanaques têm outra característica inevitável: são obrigatoriamente amplos e responsavelmente rasos. 2 km de extensão por  2 cm de profundidade. Neste almanaque não faltarão dicas e referências para todos que quiserem ir além dos 2 centímetros. Os almanaques tradicionais têm periodicidade anual. Este não tem prazo de validade.

    Tudo muito bom, tudo muito bem. Mas, afinal, do que é feito este almanaque? Quais assuntos ele trata? Para quem? Por quê? 

    Quatro Volumes

    O almanaque.digital está organizado em quatro volumes:

    • O TODO: concentra as teorias e ferramentas fundamentais, aplicáveis em todos os demais níveis. É o alicerce ou framework teórico que dá sentido e utilidade para as demais sugestões apresentadas.
    • A ORGANIZAÇÃO: qualquer organização, seja ela pública ou privada, minúscula ou imensa. Neste volume tratamos da empresa e sua co-evolução com o ambiente que a cerca. 
    • OS TIMES: são as células que dão forma e sentido para uma organização. Há boa ciência por trás dos times de verdade e seus diversos relacionamentos.
    • A GENTE: porque sem a gente nada disso faria sentido.

    A sequência tem uma lógica, é fractal. O modelo que prova a viabilidade de uma organização é o mesmo que atesta a nossa viabilidade e de nossos times. Ele é recursivo. 

    Por isso esse trabalho não será desenvolvido de maneira linear. Os quatro volumes vão evoluir em paralelo. Se for fácil escrever assim, será fácil ler assim. Assim espero. 

    E você, o que pode esperar? Este almanaque te convida para alguns desafios.

    Três Desafios

    Se há alguma chance para nós humanos, ela passa obrigatoriamente pelo bom uso do que nos torna… humanos. O que nos diferencia dos outros seres vivos? 

    Biologicamente, é esse intrincado sistema nervoso central chefiado por uma feia e enrugada massa cinzenta. Esse aparato formado por bilhões de células e capaz de trilhões de relações não tem paralelo conhecido no universo. Ele nos dá três habilidades muito especiais. 

    A primeira é a capacidade de pensar sobre nossos pensamentos, de avaliar nossas ações e rir de nós mesmos. Se somos capazes da autocrítica, humildes e honestos, então estamos liberados para criticar todo o resto. O Pensamento Crítico é nada menos que fundamental em tempos de infobesidade². Sem ele não temos condições de compreender nem de priorizar nada. Sem ele não podemos tirar sarro de ninguém. Este é o primeiro desafio proposto neste almanaque: incentivar o pensamento crítico. 

    Nossa segunda capacidade exclusiva é o ato de sonhar acordado, viajar na maionese e imaginar. Veremos neste almanaque que a imaginação é requisito para a criatividade que é condição para a inovação³. Como colocou Einstein, “criatividade é a inteligência se divertindo”. Pode haver algo mais humano? Segundo desafio: estimular o Pensamento Criativo.

    Não há desperdício maior do que ser capacitado para trilhões de sinapses e se conformar com alguns dogmas ou certezas. Não é possível que todo esse poder computacional que carregamos em nossas cabeças não seja capaz de lidar com a complexidade e perceber o mundo da forma como ele realmente funciona. Terceiro desafio: provar que somos capazes do Pensamento Sistêmico4.

    Três desafios: Crítico, Criativo e Sistêmico. Para quem?

    Dois Leitores

    O primeiro é você, que chegou até aqui. Sinceramente, muito obrigado!

    Porque todas as vezes em que apresentei a ideia deste almanaque ouvi a mesma pergunta: quem é o público alvo? Caraca! Primeiro: detesto esse papo de alvo. Segundo: não sei! Não sei mesmo. Este almanaque não pretende ser um livro de negócios e muito menos um manual de auto-ajuda. É o mau de ser antidisciplinar e indisciplinado: você fica sem rótulo e, consequentemente, sem prateleira nem público-alvo. Isso te incomoda? A mim, não. 

    E eu, como aprendi com William Zinsser5, sou o segundo leitor. Só estou desenvolvendo este trabalho porque não encontrei nada parecido em lugar nenhum. Ou seja, é algo que eu gostaria muito de ler. Isso será suficiente para te satisfazer? Não sei. Mas espero, sinceramente, que você me diga. 

    O que nos traz ao último ponto: por quê? 

    Cinco Porquês

    Por que este almanaque?
    Porque a gente precisa aprender a usar melhor a cabeça.
    Por quê?
    Porque talvez essa seja a única maneira de sobreviver e prosperar.
    Por quê?
    Porque o mundo está ficando a cada dia mais complexo e complicado.
    Por quê?
    Porque a gente não está usando bem a cabeça.
    Por quê?
    Porque o mundo está ficando a cada dia mais complexo e complicado.

    Em Suma

    O almanaque.digital pretende nos ajudar a usar melhor a cabeça.

    Provamos isso quando somos mais críticos, criativos e sistêmicos. Não apenas em nossos negócios, organizações e times, mas em todas as situações do dia a dia.

    Notas

    1. Citado em Systems Thinkers, de Magnus Ramage e Karen Shipp (Springer, 2009).
    2. Infobesidade: Neologismo muito criativo para nomear a sobrecarga de informações que caracteriza esses tempos difíceis.
    3. Porque foi assim que aprendi com um cara fantástico, Sir Ken Robinson, em Libertando o Poder Criativo (HSM, 2011).
    4. Neste almanaque vou tratar como Sistêmico um corpo de conhecimentos que inclui Cibernética, Teoria da Complexidade, Teoria Geral dos Sistemas, Dinâmica de Sistemas, Pensamento Complexo etc. Oportunamente tentarei explicar essa bagunça.
    5. Como Escrever Bem (Três Estrelas, 2017). Se sigo escrevendo mal não é por culpa do Zinsser, ok?
    6. Foto de Gaelle Marcel no Unsplash.
  • Por Querer

    Por Querer

    De propósito; Com intenção; De caso pensado; By design.

    Porque alguém nos vendeu a ideia de que, dada a complexidade galopante, só restaria o improviso just in time. Aquela gambiarra embelezada pelo adjetivo “orgânico”. Quem foi que disse que o que é orgânico não foi pensando nem planejado? Caraca, pra que serve o DNA? 

    O Por Querer aparece na nova assinatura deste finito para não deixar dúvidas: pensar e planejar são verbos que não perderam utilidade no século 21, muito pelo contrário. Estão recuperando seu status. 

    Status que teria sido perdido por causa do Agile. Que bobagem. Nada ali diz: não tenha planos, mapas nem bússolas. Tudo ali ensina: use laços de feedback bem curtos. E seja humilde. Que belo filtro faz essa última frase, não?

    Filtro é tudo o que promete o Lean. Para que a gente possa se concentrar no que é essencial. E só. Como seremos ágeis se não formos enxutos?

    E o que adianta ser enxuto e ágil em um mundo que não existe mais ou que nunca existiu? Ser Sistêmico é ver e entender o mundo da forma como ele realmente funciona. É entender a complexidade e saber usá-la a nosso favor. Até porque não há outra opção: ela é inevitável e invencível. 

    finito: sistêmico, enxuto e ágil. Por querer!

    Porque a gente não vai sair dessa sem querer…

    Nota

    Photo by Tim Graf on Unsplash

  • A Caixa de Ferramentas do PO

    A Caixa de Ferramentas do PO

    Não são poucos nem triviais os trabalhos do PO. Para inspirar e orientar o desenvolvimento de produtos ele precisa de boas ferramentas. Estamos cheios delas. E isso não é necessariamente bom. Sobram sobreposições e redundâncias. Faltam interfaces para que as ferramentas se comuniquem e possibilitem a construção de uma narrativa lógica e coesa. A organização da caixa de ferramentas do PO dá trabalho¹.Uma caixa de ferramentas bagunçada é uma contradição. Ferramentas devem nos tornar mais produtivos – ágeis de fato. O problema é que vivemos numa era de grandes ideias isoladas e quase herméticas. JTBD, OKR, canvases mil, jornadas de clientes e usuários, User Stories, Job Stories, Value Stories e por aí vai. Existem diversos livros, artigos ou cursos sobre cada uma delas. Mas não são comuns os trabalhos que proponham um conjunto ou, melhor dizendo, um sistema.

    Sistema: para entendermos que o TODO deve ser maior que a soma das partes; Para fazer com que as ferramentas conversem entre si. Como o JTBD troca ideias com um OKR? De que forma eles se relacionam com épicos e histórias? Como eles apoiam a organização e priorização do backlog? Precisamos de um mapa.

    Mapa Rico

    São duas as principais inspirações para a sugestão que segue. A primeira é o Pensamento Sistêmico. Mais especificamente, a Rich Picture proposta por Peter Checkland somada ao DSRP. A segunda fonte de inspiração é o livro User Story Mapping de Jeff Patton (O’Reilly, 2014). Vejamos.O diagrama é formado por três camadas: Bússola, Mapa e Roteiro.

    Bússola: seja dia ou noite, faça chuva ou faça sol, ela sempre nos dá o norte. Em nosso caso, ela sempre lembra as motivações do produto. Motivações, no plural, porque buscamos criar valor para o cliente (expresso no JTBD) e para o negócio (VS – Value Stories). Um GPS sempre ajuda. Aqui ele atende pela sigla OKR (Objectives and Key-Results). Você informa para onde quer ir (JTBD + VS) e ele te guia, mostrando a sua distância em relação aos Resultados-Chave. O ‘O’ de objetivo é o elo entre as três ferramentas.  

    Mapa: se estamos falando de um produto ou serviço que será comercializado, faz sentido que o mapa capture toda a jornada do cliente. Por isso temos um cabeçalho identificando o que ocorre Antes, no Início, Durante e Depois da compra ou contratação. A inspiração aqui é o Service Blueprint. Na primeira linha desenhamos as ações do cliente na forma de um fluxograma. Na linha inferior colocamos o trabalho interno – tudo o que precisa ser feito para que o cliente tenha aquela experiência. Se você registrou Atividades-Chave em um Business Model Canvas, por exemplo, é nessas duas linhas que elas serão desenhadas. Se você identificou Recursos-Chave no Canvas, faz sentido explicar quando e onde eles serão necessários. Daí a terceira linha do mapa. Jeff Patton é econômico nesta camada, mas não desmerece o seu valor. Tanto que a trata como o Backbone (espinha dorsal).

    Roteiro: ou, para ser menos direto, Roadmap + Product Backlog. Porque um backlog orientado pelo negócio, pela experiência do cliente, faz muito mais sentido do que uma fila indiana. Quando alguém vê um item², entende não apenas o que ele é e deve fazer mas também o seu propósito. O contexto está dado: onde e quando aquela função ou atributo é necessário. A posição vertical dos itens indica prioridades. Quanto mais alto, maior a contribuição do épico/história para a realização dos resultados descritos no OKR. Mas não ficamos só nisso. Em cada item devemos registrar o seu valor³. E, oportunamente, também o seu custo. As linhas divisórias do roteiro são traçadas em outro momento, quando já temos razoável noção do que precisa ser feito. Podemos dizer que a primeira linha representa o MVP/MVS (Minimum Viable Product / Solution). O importante é que cada linha (cada versão do produto) se comprometa com resultados. Daí o lembrete ou detalhamento de OKRs no canto direito do diagrama.

    O mapa é uma ferramenta que pode acomodar, como no exemplo acima, outras ferramentas. Não é uma colcha de retalhos. É um sistema. Ou, caso queira, é uma história que deve ser contada de forma colaborativa. E iterativa. O mapa evolui na medida em que navegamos entre os trabalhos de descoberta, exploração, desenvolvimento e entrega.No exemplo acima tivemos que colocar o roteiro no lado direito. A bússola (post-its no topo e anotações no canto) foi junto.

    As informações (quem, o que, quanto, onde, quando) descobertas, o conhecimento (como) desenvolvido e a compreensão (por que) alcançada com o apoio das ferramentas citadas são essenciais para o desenvolvimento de um produto. O Mapa Rico pode ser a principal ferramenta de um PO. Mas, claro, não pode ser a única.

    Notas

    1. E isso justifica, em partes, o intervalo de dois meses desde o último artigo. As sugestões aqui apresentadas foram testadas em uma turma da oficina FDP e com três times do Ateliê de Software, uma empresa que é 100% Ágil há dez anos. Agradeço ao pessoal do Ateliê pela oportunidade e acolhida. E ao Will pela foto.
    2. O diagrama indica quatro formatos possíveis para itens: Épicos, US – User Stories, JS – Job Stories e UC – Use Cases. Poderia ter citado protótipos também. Não são variações do mesmo tema. Cada formato captura informações e perspectivas diferentes. Vale sempre lembrar: só a variedade absorve variedade. E existe coisa mais variada do que desejos, necessidades, restrições e caprichos de clientes e usuários?
    3. Se você pretende utilizar um conjunto da sequência de Fibonacci ou escalas mais simples não importa. Importante é que isso seja pensado e negociado. E que a régua definida para o Valor seja a mesma utilizada na aferição dos custos. 
    4. Rectilinear, de Stuart Caie, ilustra este artigo.
  • Se Apaixone pelo Problema

    Se Apaixone pelo Problema

    Nos dois artigos anteriores (1 | 2) tentei mostrar a necessidade de uma maior preocupação com o Domínio do Problema. Eles se concentraram no porquê. O texto de hoje ilustra como podemos nos apaixonar por problemas. A correta definição de um problema é parte do problema¹. Não é uma definição simples. Porque as diversas partes interessadas não enxergam o mesmo problema. Ou não o veem da mesma maneira. Talvez algumas nem reconheçam o problema. Isso pode ser consequência de uma organização meio biruta – sem noção do que quer. Porque o ambiente é cada vez mais incerto e dinâmico. O mais provável é que seja uma mistura disso tudo.

    É certo que o jeito Ágil de pensar – com iterações curtas e feedback rápido – nos ajuda a compreender e delimitar melhor o problema enquanto desenvolvemos e entregamos a solução. Mas qual é o marco zero? Qual deve ser o nosso ponto de partida? Se a gente soubesse o quanto esse primeiro passo influencia o desenho da solução seríamos um tanto mais cuidadosos.

    Qual é o problema? Por que é um problema? Quem é afetado por ele? O que está envolvido? O que pode acontecer se a gente não resolver o problema?

    Desenvolver o sistema X ou o app Y; Aumentar o market share; Reduzir os custos do processo Z; Melhorar a nossa imagem; Aumentar o faturamento em tantos milhões. Nada disso é problema.

    Todas as frases acima sinalizam possíveis soluções. Mas dizem muito pouco ou nada sobre o problema. Foi por isso que o pessoal da Toyota inventou o 5 Porquês. Porque geralmente precisamos de cinco enxadadas para alcançar a raiz do problema.

    Tratar a ferramenta 5 Porquês como guia para uma entrevista 1:1 é um desperdício e tanto. Porque ela só prova todo o seu potencial quando é combinada com outras ferramentas em uma Investigação Sistêmica². Este processo de descoberta deve envolver o maior número possível de interessados, interesseiros e encrenqueiros. Todos juntos no mesmo lugar. As respostas para cada porquê se desdobram em potenciais componentes do verdadeiro problema.

    É um engano relativamente comum entender o Pensamento Sistêmico como uma forma de “ver o todo”. Ver o todo é só uma PARTE desse jeito de pensar. Se vemos só essa parte, perdemos o TODO do Pensamento Sistêmico.
    (A recursividade é intencional. Na dúvida, releia o parágrafo).

    Uma Rica Fotografia

    Orientados pela ferramenta 5 Porquês podemos desenvolver uma Rica Fotografia (Rich Picture, no original em inglês). Esse modelo vem de uma das diversas propostas do Pensamento Sistêmico, a Soft Systems Methodology (SSM), de Peter Checkland. A fotografia é rica porque apresenta o contexto em toda a sua riqueza de diversidade, estrutura, relacionamentos e pontos de vista. DSRP: Distinções | Sistemas | Relacionamentos | Perspectivas. São as quatro regras que, em conjunto, nos ajudam a enxergar e compreender o mundo como ele realmente funciona. Ou seja, nos ajudam a pensar sistemicamente.

    Devemos evitar a definição prévia do tipo de fotografia que queremos. Processos ou cadeias de valor não são indicados porque restringem, logo de partida, a forma como vemos o problema. Além disso, passa da hora da gente entender que esse jeito linear de criação de valor não é onipresente, muito pelo contrário. Enfim, a Fotografia Rica deve nascer sem moldura, grades ou guias. As fronteiras e a lógica do modelo devem emergir. Partimos do problema como apresentado na primeira vez – mesmo que seja um simples “precisamos de um app” – e perguntamos: Por que precisamos de um app?

    As discussões em torno das respostas nos permitem identificar as partes envolvidas e as relações entre elas. A classificação dos relacionamentos – forte, fraco, direto, indireto, entrada, saída, colaborativo, conflituoso, rápido, devagar etc – enriquece a fotografia. Parte da fotografia pode ser capturada na forma de um Mapa Causal (CLD – Causal Loop Diagram). Assim o modelo fica com um jeito de filme – ganha dinâmica.

    Como essa fotografia é produto de um processo colaborativo, é de se esperar que ela capture diversos pontos de vista. Condenamos o processo e o ambiente se alguma perspectiva for favorecida ou ignorada. Se uma pessoa chave não puder participar, adie o encontro. Aliás, a falta de agenda pode ser um sinal de que o problema não é assim tão relevante. Pelo menos, não para aquela pessoa.

    Um subproduto desejável da elaboração da Rica Fotografia é uma igualmente rica análise dos stakeholders (ou partes interessadas). Em uma única reunião somos apresentados não apenas às pessoas envolvidas (holders) mas também ao seu grau de envolvimento, aos seus pontos de vista e interesses (stakes). Isso é de suma importância em qualquer iniciativa porque, como ensinou Gerald Weinberg em The Secrets of Consulting (McGraw-Hill, 1985), “a despeito do que o cliente possa lhe dizer, sempre existe um problema. Não importa o que pareça a princípio, o problema é sempre com as pessoas”.

    A bola chega redonda para DeMarco e Lister, que em Peopleware (Makron Books, 1990) emendam: “os principais problemas de nosso trabalho não são de natureza tecnológica mas sim sociológica”.

    Conclusão

    Vale a pena repetir sempre: não é o modelo; não se trata do entregável (sic). É o processo de elaboração que nos interessa. São as conversas que importam. É a criação de uma visão compartilhada do problema o que buscamos. Isso, por si só, fará você se apaixonar pelo problema? Talvez não. A sugestão aqui apresentada deve te deixar mais íntimo do problema. E problemas, assim como as pessoas, podem nos decepcionar quando desnudados. O que fazer com essa desilusão é outra conversa.

    Que não será a próxima. Se hoje apresentei uma sugestão para tratar de um problema interno e específico, no próximo artigo eu pretendo falar sobre problemas externos e gerais – problemas que nos motivam a criar produtos ou serviços. Desconfio que eles sejam um tanto mais atraentes. Veremos.

    Notas

    1. Gerald Weinberg? Russell Ackoff? Tantos já falaram sobre isso que fica difícil decidir a quem creditar aquela frase.
    2. Como eu queria que a gente tivesse adotado em português um termo bastante comum entre os pensadores sistêmicos: Inquiry – investigação, pesquisa. É bem melhor que análise, descoberta e exploração. Porque explica melhor o trabalho que realizamos.
    3. Heart-it foi compartilhada por The ReflexMan no flickr.
  • Dentro do Buraco

    Dentro do Buraco

    “Não morda o meu dedo, olhe para onde estou apontando.“
    – Warren McCulloch

    “Para o observador casual, definições do problema podem parecer desperdício. É tempo gasto longe do teclado e a educação ocidental nos ensina que estamos enrolando ou sendo improdutivos quando estamos ‘só conversando’. Mas o Lean é cheio de paradoxos como esse.”

    “Muito do Lean é baseado no Pensamento Sistêmico e uma definição de problema bem colocada pode levar o time para além de suas preocupações com a solução – para uma compreensão mais ampla do contexto.”

    “O Lean nos pede para reduzir tensões e inconsistências no sistema. A definição do problema articula um objetivo consistente. São comuns os projetos que sofrem porque seus participantes não estão resolvendo o mesmo problema. Uma definição de problema bem escrita oferece uma visão consistente de direção. Como tal, ela pode ser uma poderosa ferramenta para o time e para a gestão.”

    “Uma boa definição do problema pode funcionar como um catalisador para a auto-organização.”

    “Em uma verdadeira organização Ágil aqueles que são responsáveis pela solução do problema participam da definição do problema. Essa definição deve ajudar a canalizar a energia da organização na direção correta.”

    Lean Architecture | James Coplien e Gertrud Bjørnvig
    Wiley, 2010 – Págs. 68~74

    Eu sabia que não estava sendo original quando escrevi que Histórias – de Valor ou de Usuários – são catalisadoras. Só não lembrava a origem.“Antes de iniciar um sprint de criação-de-valor-para-o-cliente precisamos de um backlog inicial do produto. E para gerar esse backlog nós precisamos da visão do produto. Muitas organizações também acham útil a criação de um roadmap preliminar, definindo uma série de releases incrementais. Chamo as atividades que criam esses artefatos de envisioning ou product-level planning.”

    “O envisioning não deve ser confundido com um pesado e cerimonioso processo de planejamento. No Scrum, nós não acreditamos que podemos (ou devemos) conhecer todos os detalhes de um produto antes de começarmos. Entretanto, nós entendemos que o financiamento de um produto não pode começar sem uma visão; sem um entendimento adequado acerca dos clientes, das features e da solução em alto nível; nem sem uma ideia de quanto o produto vai custar.”

    “Não gastamos muito tempo ou esforço no envisioning porque queremos rapidamente passar do estágio do achismo – quando a gente pensa que conhece as necessidades dos clientes – para as etapas de feedback rápido – para os sprints de criação de valor.”

    Essential Scrum | Kenneth Rubin
    Addison-Wesley, 2013 – Pág. 287

    “O primeiro passo no Scrum é a elaboração da Visão do Produto pelo Product Owner.”

    Scaling Lean & Agile Development | Craig Larman e Bas Vodde
    Cap. 12 – Scrum Primer, por Pete Deemer & Gabrielle Benefield
    Addison-Wesley, 2009 – Pág. 311

    1. Uma VISÃO projeta um futuro onde determinado problema deixa de existir. Uma VISÃO assume o entendimento prévio desse problema.
    2. Ignorar a definição do problema e tratar o envisioning como o “estágio do achismo” (guessing, no original) é frágil e perigoso.
    3. Entender que a elaboração da VISÃO é responsabilidade exclusiva de um PO é detonar, logo de cara, uma boa oportunidade de formar um time de verdade.

    “A diretriz fundamental de qualquer sistema verdadeiramente enxuto consiste em estabelecer e entregar valor definido pelo cliente”.

    “ não devemos gastar esforços ou recursos antes de termos um profundo entendimento do valor definido pelo cliente.”

    Sistema Toyota de Desenvolvimento de Produto | James Morgan e Jeffrey Liker
    Bookman, 2008 – Págs. 45~46

    “A característica organizacional definidora do modelo do Spotify é o conceito de squads com ‘baixo acoplamento e alto alinhamento’. A tese central aqui é que ‘alinhamento permite autonomia – e quanto maior o alinhamento, mais autonomia é possível dar’. É por isso que a empresa passa tanto tempo alinhando todos com objetivos e metas antes de iniciar um trabalho.”

    Tempo Talento Energia | Michael Mankins e Eric Garton
    figurati, 2017 – Pág. 163

    1. A distância que separa a Toyota do Spotify é a mesma que separa o Japão da Suécia. Mas uma coisa elas parecem ter em comum: tempo pra pensar.
    2. Não é curioso que esse tempo para pensar não seja considerado trabalho? Repare na frase destacada no último parágrafo acima. Coplien e Bjørnvig, citados lá no início, já haviam alertado para essa característica bem ocidental de não relacionar esse tipo de conversa com trabalho.

    “Quando você dispara qualquer coisa nova, há forças te puxando para todas as direções. Há coisas que você pode fazer, coisas que você gostaria de fazer e coisas que você precisa fazer. Comece pelo que precisa ser feito. Comece pelo epicentro.”

    Rework | Jason Fried & David Hansson
    Crown Business, 2010 – Pág. 72

    “Tome uma grande decisão sobre sua Visão de forma antecipada e todas as futuras pequenas decisões se tornarão bem mais fáceis.”

    Getting Real | 37signals
    37signals, 2006 – Pág. 43

    “Todo o trabalho com requisitos é precedido por algum tipo de processo de iniciação: alguém tem uma ideia de que algo deve ser desenhado e construído.”

    “Se não formos cuidadosos, a ideia inicial vai colocar todo o processo em um caminho improdutivo do qual nunca vamos nos recuperar. Se os participantes não começarem pensando em conjunto, vamos perdê-los antes de ganhá-los.”

    “Como podemos sintetizar a grande variedade de pontos de partida potenciais em uma plataforma única e sólida para a exploração de requisitos? Uma solução possível é entender cada projeto como uma tentativa de resolver algum problema e então reduzir cada ponto inicial a uma forma comum de descrição do problema.

    “Um problema pode ser definido como: A diferença entre as coisas conforme são percebidas e as coisas conforme são desejadas.”

    Exploring Requirements: Quality Before Design | Donald Gause e Gerald Weinberg
    Dorset House, 1989 – Pág. 49

    “A palavra problema sempre significa algo ruim, como em ‘Houston, temos um problema’ Mas as inovações bem sucedidas sempre envolvem mais atenção ao problema do que às soluções. Einstein um dia disse, “Se eu tiver 20 dias para resolver um problema, gastarei 19 para defini-lo”.

    The Myths of Innovation | Scott Berkun
    O’Reilly, 2007 – Pág. 127

     

    “O problema não é o problema. O problema é a sua atitude em relação ao problema.”

    – Capitão Jack Sparrow

    1. Pois é, terceirizei a argumentação. Parti dos originais e a tradução é livre, provavelmente enviesada e eventualmente desastrada. Por  favor, não morda o meu dedo.
    2. Se você não entendeu minha motivação, por favor, veja o artigo anterior.
    3. Se tem o que acrescentar, por favor, comente!
    4. Aquela foto bem sacada de dentro do buraco é da Alexandra Brovco.
  • 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.
  • Checkup Ágil – Parte II

    Checkup Ágil – Parte II

    Como nós criamos e entregamos valor? Na primeira parte deste checkup nós conversamos sobre eficácia. Agora o tema é eficiência: criar e entregar valor do jeito certo. Como trabalhamos? Nosso método realmente ajuda? Calma, não é mais uma comparação entre Scrum e Kanban. Até porque ambos tropeçam no mesmo lugar.A essência de nossos trabalhos é criar valor eliminando problemas. Nossos projetos, produtos e serviços são desenvolvidos para isso. A visão curta – imediatista, mecanicista e reducionista – nos leva a resolver problemas. Quase sempre isso redunda em paliativos e efeitos não previstos nem desejados. Ou seja, em mais problemas. Isso pode até ser um meio de vida: receitas recorrentes, como não? Pode ser um sonho para quem vende horas. E um caro e merecido pesadelo para quem as compra. Mas isso não pode ser a intenção de quem se propõe verdadeiramente Ágil.

    Entre todos os grandes pensadores sistêmicos, Ackoff foi o mais incisivo¹: devemos dissolver problemas. Devemos redesenhar o sistema de forma a evitar reincidências e efeitos negativos. O Pensamento Sistêmico nos dá essa visão privilegiada: de longo alcance, inclusiva e obrigatoriamente atenta à dinâmica das relações entre todos e tudo o que está envolvido em dada situação.

    O mundo Ágil, através de livros e propostas, gosta de apontar o Pensamento Sistêmico como uma de suas bases. É uma pena que, quase sempre, tal referência se limite a um capítulo ou nem isso². Pior ainda é quando o Pensamento Sistêmico é interpretado através de uma visão curta. Vira mera etiqueta que tenta dar ares de coesão e coerência para ideias frouxas. Nesses casos é sempre bom relembrar a Lei de Durden.

    Retomando: como criamos e entregamos valor? Como trabalhamos? Estamos de fato dissolvendo problemas? Ou simplesmente criando outros?

    Método

    O Design Thinking, também derivado do Pensamento Sistêmico, foi feliz ao escolher um losango como representação de um jeito de pensar e eliminar problemas. E muito desastrado quando resolveu trocá-lo por um squiggle. Sigamos com o losango. Na primeira metade temos a compreensão. Na outra, criação. Na primeira metade criamos opções. Na outra, tomamos decisões. Convenhamos, isso é tão antigo quanto andar para a frente. O que o mundo do design nos deu foi uma imagem e termos sofisticados: movimento divergente, movimento convergente. No fundo isso é, sempre foi e sempre será uma sequência de ANÁLISE e SÍNTESE. Necessariamente nessa ordem³.O losango perde sua utilidade quando nos deparamos com dois problemas. Primeiro: esse pensamento é linear. Os problemas que justificam os nossos salários e lucros não são eliminados assim. Eles pedem por iterações porque, como humanos, a chance de acertarmos na primeira tentativa é quase nula. Uma imagem bem melhor é a do semi círculo ornamentado por uma seta que aponta para o início e diz: vamos experimentar, aprender e tentar de novo. E de novo…

    O segundo problema é a necessidade de uma segunda dimensão. Um eixo que nos permita separar o que é CONCRETO do que é ABSTRATO. Dados, fatos, pessoas e soluções são coisas concretas. Ideias, hipóteses, opções, oportunidades e experimentos são abstrações. Acabamos de ganhar mais uma matriz 2×2.Quase todos os frameworks e métodos propostos nas últimas décadas apresentam, em seus próprios termos, a visão acima. O que não se encaixa ali é o jeitão antigo – linear, mecanicista e reducionista – de fazer as coisas. Até o ciclo PDCA (Plan-Do-Check-Act), por exemplo, não combina. Apesar de suas origens sistêmicas e, como tal, ser iterativo. OODA (Observe-Orient-Decide-Act), por sua vez, se encaixa perfeitamente. Se uso outros nomes é para aproximar o modelo de nosso contexto. OODA foi sugerido por um piloto de caças.

    Talvez alguém queira apontar a coincidência dos quadrantes acima com aqueles do Cynefin: Descoberta é Caótica, Exploração é Complexa, Desenvolvimento é Complicado e a Entrega é Simples. A coincidência é feliz. Aliás, esse caminho seria feliz… se não fosse equivocado. Se o problema que pretendemos resolver é complexo, ele não deixa de sê-lo só porque se encontra em outro momento (quadrante) daquele ciclo.

    No próximo artigo nós vamos esticar esse papo. E ver como Scrum, Kanban e derivados compartilham problemas semelhantes. Agora é hora de uma segunda rodada de nosso autoexame.

    Autoexame

    Como a sua organização CRIA e ENTREGA valor?

    • O trabalho executado no lado esquerdo do diagrama acima obedece ao mesmo ritmo e às mesmas restrições daquele que é executado no lado direito? As Sprints têm a mesma duração nesses dois hemisférios?
      Obs.: aos adeptos do Kanban deixo minha desconfiança de que o que chamo de lados esquerdo e direito são, respectivamente, o que vocês tratam como upstream e downstream Kanban. Mas vem coisa nova por aí, um tal Discovery Kanban. O nome não é mera coincidência. A necessidade, tardia, parece óbvia.
    • Você usa sprints 0, -1 e afins para tentar entender o problema?
    • Como são iniciados os seus projetos? Com Histórias de Usuários? Com hipóteses? Com planos?
    • Todas as hipóteses se tornam experimentos?

    Qualquer SIM não é bom sinal.

    Notas

    1. Dois trabalhos sintetizam bem as propostas de Russell Ackoff: Ackoff’s Best (Wiley, 1999) e, para os apressados, Differences that Make a Difference (Triarchy Press, 2010).
    2. Craig Larman e Bas Vodde vão um pouco além de um capítulo em Scaling Lean & Agile Development (Addison-Wesley, 2009) e Large-Scale Scrum – More with LeSS (Addison-Wesley, 2017). O mesmo pode ser dito sobre Managing the Design Factory (Free Press, 1997) e The Principles of Product Development Flow (Celeritas, 2009) ambos de Donald Reinertsen. No entanto, para perceber a aplicação do Pensamento Sistêmico como um todo e no todo (e como é estranho escrever isso) vale a pena ler The Journey to Enterprise Agility: Systems Thinking and Organizational Legacy (Springer, 2017) de Daryl Kulak e Hong Li.
    3. Aquela frase não seria necessária caso eu não tivesse me deparado com Essential Upstream Kanban, de Patrick Steyart. O cara tá falando que a síntese antecede a análise?!?
    4. 4 Windows, compartilhada por gmahender no flickr, ilustra este artigo.