PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Scaling Lean & Agile Development

  • 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.
  • ferramentas, FERRAMENTAS

    ferramentas, FERRAMENTAS

    Nossa era da ansiedade é, em grande parte, o resultado de tentarmos fazer o trabalho de hoje com as ferramentas de ontem – com os conceitos de ontem.
    – Marshall McLuhan

    Que tal começar com uma autoanálise? Pense em quantas ferramentas você conheceu nos últimos tempos. Quantas você experimentou? Quais foram incorporadas ao seu dia a dia? Considere tanto aquelas que só demandam papel e caneta quanto os brilhantes apps que inundam seu smartphone. Quais o tornaram um profissional melhor, mais produtivo e eficaz?

    Há muita conversa sobre ferramentas e respectivos guias de seleção e uso, os métodos. Que parte desse papo se concretiza? Quantos trabalhos se tornaram mais eficazes, rápidos e até prazerosos por causa de novas ferramentas? Temo que poucos, muito poucos.

    Participando de reuniões variadas em empresas idem, o que mais vejo é o puro improviso. Não há ordem nem um mínimo sistema dando sentido aos debates. De vez em quando alguém rabisca algumas ideias. Mas a solução do problema em questão, se acontece, é fruto de muito trabalho (e retrabalho) ou do acaso. Quem está ali conhece uma série de ferramentas. Talvez até desconfie que algumas seriam úteis naquele momento. Mas, por algum motivo, abre mão de aplicá-las. Qual motivo? Ou melhor, quais motivos?

    Hábitos, Vícios e Preconceitos

    Velhos hábitos e vícios são duros de matar. Desaprender é mais difícil do que aprender. Se pretendemos aplicar novos conceitos e ferramentas, antes de mais nada, precisamos abrir espaço para eles. Não é algo que ocorre do dia para a noite. Por nítidas que sejam as vantagens de uma nova técnica, o conforto do que é conhecido parece maior. E exerce uma atração irresistível. Na pressa, também comum, optamos pelo caminho que dominamos. Fazendo vista grossa para o fato dele ser o caminho mais longo e, não raro, mais acidentado.

    Outro motivo é confessado em algumas fichas de avaliação de meus treinamentos: “isso não vai funcionar na minha empresa”; “isso não é compatível com a cultura de minha empresa”; “minha empresa não está pronta para isso”; e por aí vai. Não há nem a chance ou curiosidade de experimentar um novo jeito de pensar e trabalhar. Porque regras nunca escritas seriam intransponíveis. Quem, em sã consciência, impediria ganhos de produtividade? Como pode uma ferramenta não testada ser incompatível por natureza? Tente imaginar uma carpintaria incompatível com um martelo, por exemplo. Coisa estranha.

    Assim como são estranhos alguns preconceitos. Adjetivos como “metódico” e “sistemático” são mais frequentes em tom pejorativo. Raramente aparecem como um elogio. O que é metódico e sistemático é invariavelmente chato e indesejado? De onde vem isso? Não é dos dicionários, que relacionam os termos com o perfil de alguém “que procede com método” ou “que segue ou observa um sistema”. Ou seja, são predicados de quem pensa o próprio trabalho. São características necessárias se pretendemos vencer as barreiras colocadas nos dois parágrafos anteriores.

    Voltemos ao McLuhan, citado lá em cima. Até quando insistiremos em ferramentas e conceitos de ontem? O que falta para que você faça um upgrade em seus ativos – no seu cinto de utilidades?

    Transição

    A entrevista de Jeffrey Immelt, presidente do conselho de administração da GE, para a EXAME (edição 1145 de 13/09/17) pode surpreender. A GE de Jack Welch serviu como modelo para muita gente. A cultura de controle e ferramentas como o Seis Sigma já foram coisas invejadas. Aquela GE não existe mais. Nas palavras de Immelt:

    “O Seis Sigma elimina a experimentação. O FastWorks (método ágil e enxuto desenvolvido pela GE) gira em torno da experimentação. O Seis Sigma visa eliminar falhas. No FastWorks, as falhas são endêmicas. Empresas burocráticas perdem rapidez.”

    Immelt não está fazendo nada mais do que seguir um conselho do próprio Jack Welch: “Mude antes de ser obrigado a fazê-lo”. A transição não é pequena. Uma nova cultura está nascendo. E, com ela, novos conjuntos de ferramentas.

    Para Pensar e Agir

    Donald Reinertsen, em Managing the Design Factory (Free Press, 1997), classifica as ferramentas em dois grupos¹:

    • Ferramentas para Pensar: nos ajudam a delimitar, relacionar, estruturar e avaliar determinado problema ou situação. Pensamento Sistêmico, Teoria da Informação, Teoria das Filas, Pensamento Lean e Pensamento Visual são alguns exemplos
    • Ferramentas para Agir: apoiam a execução de determinado trabalho. Diagramas de Efeitos e de Processos, cerimônias, canvases e quadros mil entram nessa categoria. 

    Trabalhos recentes – alguns livros de Design Thinking e o famoso Gamestorming (Alta Books, 2014), por exemplo – desfilam dezenas de ferramentas para agir sem o alicerce de uma teoria unificadora. Isso, por si só, não é um problema. Boas ferramentas provam o seu valor de forma pontual, sem dependências ou requisitos. No entanto, um bom profissional não vive desprovido de métodos e conceitos – sem Ferramentas para Pensar.

    Temos aqui outra tendência difícil de explicar e justificar: o desprezo pelas teorias. Entender o contexto que levou à criação de uma ferramenta – conhecer o seu porquê – é condição para sua aplicação eficaz. Não é por acaso que vemos tantos debates estéreis sobre métodos e ferramentas por aí: falta educação. Para detonar o preconceito (contra teorias e teóricos), Kurt Lewin tem uma boa provocação: “Não há nada mais prático do que uma boa teoria”.

    Assim como não há nada mais eficaz do que boas ferramentas se a nossa intenção é ganhar produtividade. Jurgen Appelo, autor de Management 3.0 (Addison-Wesley, 2011), faz uma aposta ainda maior: boas ferramentas podem nos ajudar a mudar ou implantar culturas. Essa é a proposta de seu novo projeto, Agility Scales².

    Plano de Ação

    Um plano para a reciclagem contínua de seu cinto de utilidades:

    1. Seja teimoso: experimente a ferramenta em três ou mais situações diferentes. Não desanime nem fale mal de uma coisa que você mal conhece. É possível e esperado que sua produtividade caia nas primeiras tentativas. Afinal, você está aprendendo. Lembre-se de como aprendeu a nadar ou andar de bicicleta. Tombos, água e sapos engolidos fazem parte do processo.
    2. Seja desobediente: afinal, a cultura de sua empresa não está escrita em pedra. Teste a ferramenta. Se você for bem sucedido, a empresa ganhou. Mostre os dados, fatos e ganhos. Se ainda assim você for proibido de usar a ferramenta, talvez seja hora de amarrar seu burrinho em outro lugar. Se você for mal sucedido, não desconsidere o que acabou de aprender. Pelo contrário, compartilhe!
    3. Seja aberto: e não perca tempo em debates bobinhos sobre ferramentas e métodos. Lembre-se sempre de que a quantidade de ferramentas dominadas é tão importante quanto a qualidade delas. É lógico que você terá as suas preferências. Por isso mesmo saberá quando um contexto não for favorável a elas. Você não quer queimar o filme de seus xodós, quer?
    4. Seja humilde: e não perca nunca a mentalidade de iniciante e a disposição para aprender. Immelt, na entrevista citada, diz que a resiliência (seu principal aprendizado) só se tornou possível quando ficou mais humilde. 
    5. Invista: As ferramentas formam parte considerável de seus ativos (tema do artigo anterior). Ativo largado é ativo depreciado. Faz quanto tempo que você não aprende e de fato aplica uma ferramenta nova? Se quiser alguma ajuda, consulte minha agenda acima, considere o investimento e volte ao passo #1.

    Notas

    1. Craig Larman e Bas Vodde pegaram carona nessa categorização. E chegaram a estruturar livros assim: Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum e Practices for Scaling Lean & Agile Development (Addison-Wesley, 2009 e 2010, respectivamente).
    2. Cito este projeto com uma ponta de orgulho e outra de inveja. Há semelhanças com o flit, ideia que apresentei há pouco mais de um ano. A grande diferença talvez esteja na minha ênfase nos Trabalhos a Executar (JTBD – Jobs to be Done) e em Ferramentas para Pensar, particularmente no Pensamento Sistêmico. Não tenho dúvidas de que o Agility Scales vingará. Daí a inveja. E gás novo para insistir nesse papo.
    3. Tool board, de Dean Wiles, ilusta este artigo.
  • Scaling Lean & Agile Development

    Scaling Lean & Agile Development

    Craig Larman e Bas Vodde

    A quem pode interessar: Todos que estejam levando métodos ágeis e o pensamento Lean para além de um produto, um projeto ou um time. Deve interessar a todos que já rodaram mais de dois experimentos com métodos ágeis, particularmente com o Scrum.

    Porque ler: Larman tem um histórico de livros que fizeram a cabeça de muita gente, aqui e lá fora. São dele “Utilizando UML e Padrões” (Bookman, 2007) e “Agile & Iterative Development: A Manager’s Guide” (Addison-Wesley, 2004). Seus escritos seguem consistentes e didáticos. Mas agora ele parece um pouco mais divertido e direto. Porque sabe que o sucesso de suas sugestões depende de opiniões claras – de conclusões que podem não agradar todo mundo. Este é um dos poucos títulos (sérios) sobre a utilização do Scrum em projetos de médio e grande portes.

    Estrutura & Conteúdo: O livro tem apenas duas grandes partes, Ferramentas de Pensamento e Ferramentas Organizacionais. Cada uma mereceu cinco capítulos. Os autores começam pegando pesado, citando Woody Allen (!) e falando sobre o Pensamento Sistêmico. Quem sempre se sentiu intimidado ou constrangido pelo “A Quinta Disciplina” de Peter Senge (Best Seller, 2009) sentirá imenso alívio ao ler o primeiro capítulo de “Scaling Lean & Agile Development”. Combinado ao pensamento Lean, o Pensamento Sistêmico é apresentado de forma extremamente prática e didática.

    Também merece destaque o segundo capítulo, sobre o Pensamento Lean. Não se trata de um derivado de outros escritos, mas de um trabalho de pesquisa que envolveu interações diretas dentro da própria Toyota no Japão. Não é por nada não, mas a dupla conseguiu explicar em um capítulo o que muita gente não fez em um livro inteiro! Fechando a primeira parte temos os seguinte capítulos: Teoria das Filas, Falsas Dicotomias e Seja Ágil.

    A segunda parte, sobre Ferramentas Organizacionais, apresenta sugestões um pouco mais controversas. Eu gostei demais de boa parte delas, mas sei que algumas pessoas virarão piruetas ao ler, por exemplo, que “organizações ágeis não precisam de Escritórios de Projetos (PMO’s)” (p. 249). Os autores dizem, no mesmo trecho, que pior que um PMO é a sugestão de um Agile PMO. Claro, não deixam de citar o pai da (indesejada) criança: Jochen Krebs, em “Agile Portfolio Management” (Microsoft Press, 2008). Acho que nem preciso dizer que também gostei muito da alternativa sugerida pela dupla para troca de conhecimentos e experiências: as Comunidades de Prática (p. 252).

    Aliás, o livro todo apresenta dois grandes conjuntos de sugestões (experimentos) etiquetados como “Try…” (Tente) e “Avoid…” (Evite). Uma lista com todas as sugestões aparece logo de cara, na terceira página. Todas são apresentadas e justificadas no decorrer do texto.

    Trechos (livremente traduzidos):

    “Evite… pensar que o gerenciamento de filas, kanban e outras ferramentas são pilares do Lean.”

    “Tente… refletir sobre os dois pilares do Lean: Respeito pelas Pessoas e Melhoria Contínua.”
    (N.T.: Reparou que “eliminar desperdício” também não pintou aqui? Acontece que certos “desperdícios temporários” são necessários. Um buffer com itens do backlog do produto, por exemplo).

    “Uma das mais ignoradas e valiosas sugestões do Scrum diz que algo entre cinco e dez porcento de cada Sprint deve ser dedicado pelo time ao refinamento do backlog do Produto.”

    “O último projeto simples foi feito em 1962. Não acredite que exista algum projeto que não envolva aprendizado ou complexidade ou alguma variabilidade e, consequentemente, não se beneficie do desenvolvimento ágil.”

    “Encoraje os especialistas a ensinar, não a fazer.”

    “Se não há conflito aparente então o time está com problemas.”

    “Evite… ferramentas tradicionais de gerenciamento de requisitos.”

    “Evite… organizações matriciais e escritórios de projetos.”

    “Evite… a IBM.”

    Serviço:

    Scaling Lean & Agile Development
    Craig Larman e Bas Vodde
    Addison-Wesley, 2009
    US$ 39,41 na Amazon (em 24/jan/12)
    US$ 15,92 pela versão eletrônica.

    ?

  • Scrum ‘de Raiz’

    Scrum ‘de Raiz’

    Assim como existem o samba e a música sertaneja ‘de raiz’, também existe um Scrum ‘de raiz’: ideias, princípios e práticas que antecederam e deram forma e jeito ao framework como é conhecido hoje. Ajornada antropológica proposta por este artigo tem como principais objetivos: i) Revisitar os pilares do Scrum; e ii) Descobrir se estamos esquecendo alguma coisa importante em nossos trabalhos com ele. Posso adiantar: estamos!

    ?

    O Scrum foi provocado pelo artigo “The New New Product Development Game” publicado na edição de Jan-Fev/1986 da Harvard Business Review (HBR). Escrito por Hirotaka Takeuchi e Ikujiro Nonaka, o artigo descreve o sucesso de empresas como Fuji-Xerox, Honda e Canon no desenvolvimento de novos produtos. Os autores descobriram que as empresas analisadas compartilhavam seis características fundamentais:

    1. Instabilidade intencional: os times de projetos recebem apenas uma diretriz geral, normalmente uma metáfora indicando o tipo de produto que a organização espera receber. Não existem especificações detalhadas ou plano de projeto. Tensão, pressão, ambiguidade e outros efeitos colaterais da prática são compensadas por tolerância aos erros e pela autonomia concedida ao time.
    2. Times auto-organizados: a autonomia, citada acima, é uma das três condições para a criação de um time auto-organizado. Auto-transcendência (equipe parece buscar algo além de seu limite normal) e fertilização cruzada (time é multifuncional e todos aprendem com todos) são as outras duas.
    3. Fases sobrepostas de desenvolvimento: como em um jogo de rúgbi, onde todos correm juntos e passam a bola lateralmente. A metáfora oposta é a corrida de revezamento (desenvolvimento sequencial ou linear), com um participante aguardando a passagem do bastão por outro.
    4. “Multi-aprendizado”: ocorre o aprendizado multiníveis (indivíduo, time e empresa aprendem) e o aprendizado multifuncional (fruto da fertilização cruzada, citada acima. Um especialista é provocado a aprender coisas de outras áreas).
    5. Controle sutil: a autonomia de um time não significa falta de controle, apenas um tipo diferente de gerenciamento.
    6. Transferência do aprendizado: o item 4 acima trata do aprendizado que ocorre entre as partes interessadas de um projeto específico. Aqui se trata do aprendizado interprojetos e também da transferência da e para a organização.

    A derivação da lista acima que hoje conhecemos como Scrum, criada por Jeff Sutherland e Ken Schwaber, parece dar ênfase aos itens 2~5 em detrimento do primeiro e último tópicos. Jim Highsmith, mesmo sem dar nome ao boi, sugere algumas correções (ou avanços) no já comentado “Agile Project Management“. Craig Larman e Bas Vodde, em “Scaling Lean & Agile Development” (Addison-Wesley, 2009) tentam o mesmo. Apesar de valiosas, essas colaborações não são suficientes.

    Enquanto o Scrum era gestado, Takeuchi e Nonaka prosseguiram com suas pesquisas no campo da Gestão do Conhecimento¹. Do segundo a mesma HBR publicou, na edição Nov-Dez/1991, “The Knowledge-Creating Company“. Em 1995 a dupla voltou com outro artigo seminal, “The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation“. Por mais que a estagnação da economia japonesa – que já dura duas décadas – tente provar o contrário, esses artigos não poderiam ter sido ignorados como aparentemente foram (pelos “criadores” do Scrum e demais envolvidos com métodos ágeis). Porque eles recolocam e evoluem os temas tratados no trabalho original de 1986.

    A crítica sem rodeios nem meias palavras ao jeito ocidental – cartesiano e taylorista – de ver as organizações talvez explique o fato desses artigos terem passado em branco. Mas é exatamente nesta crítica que está seu grande valor. O tal ‘jeito ocidental’ vê as empresas como “mecanismos para processamento de informações”. Nonaka explica:

    “De acordo com essa visão, o único conhecimento verdadeiramente útil é o formal e sistemático – dados difíceis² (leia-se quantificáveis), procedimentos codificados, princípios universais. E as métricas-chave para mensurar o valor do novo conhecimento são similarmente difíceis e quantificáveis – crescente eficiência, custos mais baixos, melhor retorno do investimento (ROI).”

    Por outro lado, no modo oriental (ou japonês):

    1. Há reconhecimento e valorização do conhecimento tático;
    2. A questão não se limita a “gerenciar conhecimentos” mas, principalmente CRIAR conhecimentos;
    3. Entende que todos os colaboradores, e não apenas os gerentes e diretores, são potenciais criadores de novos conhecimentos; e
    4. Recursos e atividades são organizados e desenhados de forma a facilitar a criação e transferência de conhecimentos.

    Voltemos a um ponto chave que deixei um tanto solto acima: a área de especialização de Takeuchi e Nonaka é a Gestão (ou Criação) de Conhecimentos. Eles entendem que cada projeto é uma oportunidade única para criação de conhecimentos (leia-se Inovação). Por isso depositam boa parte de suas sugestões nas trocas e transformações de conhecimentos. O Scrum, até certo ponto, reflete bem a mesma preocupação. Através de suas reuniões diárias, de revisão (de iterações ou sprints) e retrospectivas. Mas ele peca ao desconsiderar ou dar pouca importância ao que existe fora do time de projeto.

    Takeuchi e Nonaka descobriram um tipo de organização que chamaram “hipertexto”. Convivência, confronto e troca entre a estrutura hierárquica (sistemas de negócios) e times de projetos (forças-tarefa) dão forma a uma “hiper-rede”. Uma rede que não se desliga nunca! Por que isso é importante e muito diferente do que vemos no Scrum?

    O Scrum instituiu um e apenas um ponto de contato (ou interface) entre negócio (estrutura hierárquica) e time de projeto: o Dono do Produto. Se por um lado esse “mecanismo” simplificou o processo de comunicação, por outro ele destruiu a permeabilidade e transparência que existem na proposta original da dupla japonesa. Repare no diagrama ao lado. Times de projetos e o negócio se comunicam constantemente. E essa comunicação não se dá através de um “ponto focal”. Acontece que os times são de fato multidisciplinares, compostos por pessoas de todas as áreas de negócio envolvidas. Takeuchi e Nonaka chegam a falar de times com 20~30 pessoas e um “núcleo duro” de 5 integrantes. Essas 15~25 pessoas “extras” são gente do negócio atuando na força tarefa. Gente que “leva e traz”, no bom sentido, o conhecimento necessário.

    Por favor, não estou sugerindo que a figura do Dono do Produto é desnecessária e muito menos que ela seja redondamente equivocada. Mas precisamos aceitar que ela é um “ponto único de falha” nesse sistema chamado Scrum. Suas vantagens (particularmente a esperada agilidade na tomada de decisões) não a livra de um risco potencial: a falta de conhecimento.

    Existem ainda outros dois fatores que diferenciam essa proposta do Scrum. Os times, apesar de levemente acoplados, mantêm comunicação constante. Sei que isso começou a ser tratado quando pipocaram questionamentos sobre a escalabilidade do Scrum. Aquele papo sobre “Scrum de Scrums” e coisa e tal. O fato é que esse patch não seria necessário se o desenho original³ fosse preservado. O segundo fator é a “Base de Conhecimentos”: aqui temos todo o conhecimento explícito acumulado a cada projeto. A ênfase no conhecimento tácito (e na comunicação direta entre times de projetos e o negócio) não significa o desmerecimento de tudo o que pode e deve ser explicitado (e documentado).

    Resumindo, eu vejo dois grandes problemas no Scrum que não existiriam caso seguíssemos acompanhando os trabalhos de Takeuchi e Nonaka:

    1. O “sistema” original é completo. Ele entende que quem cria conhecimentos são os indivíduos mas quem os amplifica é a organização. Times de projetos são sintetizadores desse conhecimento. O Scrum não pode ignorar ou tratar de forma simplista essas trocas;
    2. A ênfase em dados “duros” e conhecimento explícito (e mensurável) é a prorrogação de uma mentalidade herdada do século XX, de Taylor, Ford e afins. Um pensamento que desemboca em um absurdo que vi na forma de um cartaz no último Agile Vale realizado em São José dos Campos: “Se o miojo fosse ágil ficaria pronto em um minuto e meio”. O Scrum, lá na sua raiz, nunca prometeu a agilidade pela agilidade. Nunca foi uma questão de fazer de maneira ultra-rápida o mesmo trabalho. A busca cega por eficiência está nos desviando de forma muito preocupante do que é fundamental: fazer a coisa certa!

    ?

    Observações:

    1. Os dois artigos citados, de 1991 e 95, podem ser encontrados em “Gestão do Conhecimento“, de Hirotaka Takeuchi e Ikujiro Nonaka (Bookman, 2008). Aproveito a deixa para recomendar outro livro, mais completo, que apresenta a versão original (em inglês) do segundo artigo: “Knowledge Management: Classic and Contemporary Works“, editado por Daryl Morey, Mark Maybury e Bhavani Thuraisingham (The MIT Press, 2000).
    2. Ana Thorell, tradutora do primeiro livro acima, optou por “difícil” ao traduzir “hard”. Mantive a tradução original mas, logo abaixo, falei de “dados ‘duros’”. Não sei qual ficou pior.
    3. Assim como não sei se Takeuchi e Nonaka têm noção do belo monstro que ajudaram a criar, o tal de Scrum. É importante lembrar, antes que levem a culpa por alguma coisa, que eles não tinham a intenção de criar um framework para gerenciamento de projetos ágeis. Miravam a lua. É importante que nossos tiros, a partir do momento que são cópias ou derivações, não se contentem em atingir apenas o topo da montanha.
    4. “Tree-in-Pot” é o nome do cartoon de hoje. Pra variar, do HikingArtist.

     

  • Sistema de Blindagem Inteligente, Parte II

    Sistema de Blindagem Inteligente, Parte II

    Caso tenha perdido, aqui está a primeira parte. A encerrei relacionando quatro impedimentos para a adoção do Scrum na empresa YYZ (nome alterado). Importante lembrar: mais que ao Scrum, são impedimentos para a realização de sete objetivos da área de TI daquela empresa. O Scrum é só (!) um possível meio de atendê-los. Dos quatro ‘bloqueios’, um é mais crítico: os times consomem aproximadamente 80% de seu tempo cuidando de problemas do dia a dia. Como proteger os times? Há uma forma de blindagem minimamente inteligente? Abaixo, o desenrolar do enrolado causo.

    ?

    O impedimento crítico foi apresentado para uma equipe de coordenadores – quase todos os responsáveis pelos onze times que formam aquela unidade de TI. Seguiu-se um debate sobre alternativas de solução – opções de blindagem.

    A primeira, aparentemente bastante simpática aos coordenadores, considerava a alocação de poucos membros (20%) de cada vertical para o atendimento das demandas emergentes / urgentes. Além disso, todos os times dedicariam cerca de 20% de seu tempo para essas questões. Era, com certeza, a alternativa que menor impacto causaria na estrutura atual.

    O diagrama¹ acima destaca duas restrições principais para a sugestão. A primeira é “matemática”: mesmo que destacássemos 20% dos membros do time mais 20% do tempo de toda a equipe para cuidar dos requisitos urgentes, não seria possível atender todas as demandas (lembre-se: elas consomem atualmente 80% do tempo útil de todo o time). A consequência natural seria o acúmulo de demandas não atendidas, seguido do aumento da insatisfação dos usuários e assim por diante. Além disso, há o aspecto cultural que não pode ser negligenciado. Ele foi destacado na primeira parte: a empresa YYZ tem uma (honorável) política de portas abertas. Todo mundo pode falar com todo mundo praticamente a qualquer hora do dia (e da noite!). Fazer com que os usuários falassem apenas com determinados membros e/ou em período pré-determinado vai contra uma cultura estabelecida de longa data.

    A mesma questão cultural aparece como impedimento para a alternativa #2. Nela, conforme sugerido pelo responsável pela área de TI, todas as demandas seriam encaminhadas para a área de help desk. Muitos dirão que já deveria ser assim. De certa forma, é. A área de suporte da YYZ recebe uma média de seis mil (6k!) chamados por mês, 1500 deles relacionados ao ERP. E consegue fechar (bem) algo em torno de 85% deles. O resto? Sobra para as verticais de negócios. E junta-se aos requisitos que os usuários preferem apresentar de maneira direta (em uma mistura de demandas ditas “evolutivas” com simples alterações de telas, pequenos bugs etc). Como adiantei, há a questão cultural: os usuários não podem ser impedidos de se relacionar com as verticais que os espelham em TI. Mas há uma segunda e mais grave restrição para a segunda alternativa. Falta gente. Mais: falta gente qualificada. Cheguei a sugerir o deslocamento de analistas de negócios e desenvolvedores para lá. Propus engolindo. E engoli seco. Ninguém aceitaria um movimento que tinha cara e jeito de “rebaixamento”, por nobre que seja o serviço de suporte. O treinamento de novos integrantes foi cogitado. Mas, como o diagrama tenta indicar, é coisa que toma tempo. Muito tempo.

    Sobrou a terceira alternativa. Aquela que, como consultor, defendi. Partindo do princípio de que a blindagem total dos times é impossível, não resta outra opção que não seja a criação de um novo time. Um time que seja desconhecido pelo negócio e respectivos representantes. Ou seja, além de blindado ele também é invisível². Desta forma as verticais de negócios cuidariam exclusivamente do cotidiano – atendimento aos usuários e solução de pequenos problemas. Seriam também a porta de entrada para as chamadas “demandas evolutivas”. Para tanto, seguiriam contando com pessoal capaz de executar atividades de análise de negócios. Talvez um pouco mais que isso. O coordenador de cada área poderia vir a ser um Dono do Produto (Product Owner ou simplesmente PO, como queira). Eu sei, eu não curto muito esse papo de dublê de PO. Mas, neste caso, dado o invejável conhecimento do negócio que cada coordenador apresenta, os riscos inerentes ao desenho eram consideravelmente reduzidos. E haveria outro benefício: o novo time seguiria de fato invisível. Mas, quem integraria o novo time?

    Você se lembra que os coordenadores estavam dispostos a “sacrificar” 20% de seu time para cuidar exclusivamente das demandas não previstas? Bom, se pegarmos 20% de cada uma das sete verticais de negócios (que têm, em média, 8 integrantes) mais o time de controle de qualidade (pelo menos 60% dele – seis profissionais) temos uma nova composição com cerca de 17 pessoas. Praticamente 3,5 times de Scrum (considerando o tamanho ideal sugerido: 5 (+/- 2)). Claro, este time seria multidisciplinar, auto-organizado, dono de seus processos e, o mais importante, orientado por um e apenas um Product Backlog. Quase sem querer (querendo!) já atendemos o objetivo #1 da lista que foi apresentada na primeira parte: “Ter uma fila única de demandas”. Dois coelhos, talvez alguns mais, numa única porretada. Parecia tudo muito bom para ser verdade. Quais restrições para esta alternativa foram apresentadas?

    “Esse time não teria real domínio do negócio”, disseram alguns. Oras, para isso existem os PO’s e seus asseclas (analistas de negócios e afins), certo? Além disso, o novo time é formado por gente que já tem, em média, três anos de casa. E são provenientes de todas as verticais de negócios, o que representa um certo conhecimento e visão do todo. Sinceramente, isso não é restrição que se apresente. Porque ela não para em pé. Então, uma segunda restrição – aparentemente mais forte – foi colocada: “O <nome_do_responsável_por_ti> não quer que demandas evolutivas sejam separadas das corretivas”; “Além disso, o <nome_do_responsável_por_ti> não permite em hipótese nenhuma que duas equipes trabalhem nos mesmos artefatos“. Quantos traumas, quantas noites mal dormidas e quantos sistemas bisonhos de controle de versões são necessários para criar restrições tão… sei lá. Prefiro não adjetivar. Assim como preferi não gastar meu tempo com um estudo antropológico daquelas raízes pré-históricas. Me limitei a lembrar Peter Senge: “Os problemas de hoje vêm das soluções de ontem.”

    Percebi que não se tratava apenas de restrições do <nome_do_responsável_por_ti>. Os próprios coordenadores não gostaram nadinha da ideia de um novo time. Um time que provavelmente viveria sem a figura de um coordenador e que ficaria com o filé, enquanto eles seguiriam com o feijão com arroz do cotidiano. A antipatia deles pela sugestão é perfeitamente compreensível. Mas não é justificável.

    Faltou a eles enxergar um pouquinho além e entender que este desenho, como todos os outros, é temporário. Não entenderam que o novo time seria um “super” prestador de serviços para eles. E faltou acreditar que, com o tempo, o novo time poderia ser gradativamente incorporado às suas unidades. E que isso seria possível tão logo o tempo de resposta fosse reduzido para prazos que excedessem minimamente as expectativas dos usuários; o que os levaria para a fixação de acordos de níveis de serviços (objetivo #4 da lista original). Antes que você me chame de ingênuo e/ou simplório: resumi veredito e consequências.
    {Mas, caso queira explorar um pouco mais esta parte, por favor, comente! Acho que o assunto é bom demais para morrer aqui, só com minhas palavras.}

    Algumas Referências para a Alternativa #3

    Pois é, o artigo está ficando mais longo que o usual. Mas não quero fazê-la(o) esperar por uma terceira parte. Conto com mais um pouco de sua atenção.

    Já tem um bom tempo, creio que quatro ou cinco anos, que li um artigo sobre uma grande mudança que estava acontecendo na Promon. Eles estavam “duplicando” várias gerências. Uma cuidaria do dia a dia. A outra, nova, trabalharia apenas no “amanhã”. Me apaixonei pela ideia mas, infelizmente, não vi mais nada a respeito. Sei lá se foi mantida, muito menos o que conseguiram. Temo que, por considerar apenas os gerentes, a coisa não tenha vingado.

    Mais recentemente começaram a pipocar artigos e teses sobre “organizações ambidestras“. Apesar de algumas interpretações meio tortas e rebuscadas, a proposta central parece ser a mesma: separar o presente do futuro. E fazer com que as organizações trabalhem nas duas frentes com a mesma atenção e dedicação. Não necessariamente com o mesmo volume de recursos. Mas, desejavelmente, com princípios e processos em comum.

    Sinceramente, não vejo alternativa que não passe por uma divisão assim. O problema com esse tipo de mudança é que ela é drástica. O que significa dizer que a resistência a ela será igualmente forte. Pensando Scrum ou, mais precisamente, pensando Lean, não estamos mais falando de Kaizen (melhoria contínua) e sim de Kaikaku (mudança radical). E o que é necessário para a implementação de uma mudança radical? Coragem; sangue frio; apoio dos altos escalões; comprometimento com a solução… A lista é longa e não é estranha para você que conhece mudanças. Por isso vou tocar em um ponto relativamente incomum: quem promove uma mudança radical não alimenta a ilusão de que não haverão “mortos” e feridos. Muitos pularão do barco. E isso não é necessariamente ruim.
    {Está aqui outro ponto que podemos discutir bastante, não?}

    Epílogo

    Se você respeita o jeito Lean de pensar, então sabe que não pode tratar problemas (impedimentos ou bloqueios) com remendos rápidos e muito menos fazer vista grossa para eles. Você deve, literalmente, “parar a linha”, analisar as raízes do problema, encontrar e implantar uma solução para ele. Foi o que aconteceu com este serviço de consultoria. Interrompemos o processo, eu parei meu “relógio”, apresentei e propus discussões sobre os impedimentos. Um mês. Dois meses. Três meses…

    Fiquei sabendo que o <nome_do_responsável_por_ti> foi transferido para outro negócio da YYZ. Não sei dizer se as restrições que ele defendia permaneceram. Creio que não. Mesmo assim, não acredito que minha sugestão tenha uma nova chance. É assim mesmo: quantas vezes já fomos aconselhados a ter uma vida mais saudável, menos sedentária, mais preocupada com o amanhã? E quantas vezes seguimos os conselhos? São poucos os consultores, pais, esposas, médicos e afins que são de fato escutados. Menor ainda é o número dos que recebem prêmios milionários por seu poder de persuasão e objetivos alcançados.

    ?

    Observações:
    1. Não julgue o “diagrama” rabiscado, please! É só um resumo da apresentação das três alternativas e respectivas restrições. E, sim, é um Causal Loop Diagram (Diagrama de Círculos Causais). Caso você não conheça, a “o” (bolinha) ao lado de uma linha significa força (ou feedback) contrário (ou negativo). O “c” significa uma restrição (ou constraint). É uma ferramentinha que, pelo visto, está ganhando novo impulso. Na última segunda vi Jurgen Appelo utilizá-la para mostrar como esse negócio de desenvolver software é “doomed”. Mas pode ser salvo! Craig Larman também usou e abusou dela em seu último livro, “Scaling Lean & Agile Development” (Addison-Wesley, 2009).
    2. O aspecto “invisível” (do novo time) é desejável neste caso específico. Não o indicaria em ambientes que não tenham uma política tão aberta e generosa de “relacionamentos muitos-para-muitos 24×7”. Insisto, na YYZ o time só estaria 100% blindado se fosse “invisível”.
    3. “Trainee hatchings” é o título do cartoon de hoje. Como sempre, foi surrupiado do HikingArtist.
    4. Aquele xampu segue me provocando com o seu “Sistema de Blindagem Inteligente”.