“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.

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.

Se pretendemos estudar, criar e impulsionar negócios, precisamos de vários modelos. Não de um amontoado de diagramas, jogos e canvases, mas de ferramentas que, em conjunto, nos ajudem a contar histórias.

Este é o objetivo desta videoaula: apresentar uma caixa de ferramentas fundamentais para o desenho de negócios – peças para boas histórias.[videoembed url=”https://youtu.be/M05FktlYJVE”]

Observações

• A aula foi transmitida ao vivo, via Youtube, no dia 19/9/2017.
• Existem pequenas falhas no vídeo. Peço desculpas por isso.

A sua organização é viável? Como ela estará quando a crise passar? O que lhe diz isso? A contabilidade? Um canvas? Sério?

Este vídeo mostra um jeito diferente de olhar, desenhar e diagnosticar negócios. Veja como um modelo bem pensado pode trazer novas questões, perspectivas e possibilidades.[videoembed url=”https://youtu.be/Bz3dwRu9Kyk”]

Observações

• A aula foi transmitida ao vivo no dia 26/7/2017.
• Existem algumas pequenas falhas no vídeo. Peço desculpas por isso.

O desenvolvimento de produtos e serviços, em sua forma tradicional, parte de atributos dos clientes ou das soluções. Tendências, concorrentes, desejos e necessidades entregam os requisitos e parâmetros comuns. A teoria JTBD propõe outro caminho através de uma simples questão: qual trabalho o cliente precisa executar?

Um trabalho pode ser algo simples como “lavar roupas em casa” ou “tornar mais agradável a espera pelo avião”. Também pode ser complexo como “encontrar uma carreira mais promissora”. Um trabalho pode ser parte de um projeto: “desenvolver requisitos”³. Ou a razão de um projeto: “aprender a tocar violão para animar as festinhas das família” (opa! qual é o verdadeiro trabalho aqui?).

Dos exemplos acima derivamos duas características fundamentais:

• Um JTBD sempre expressa o que precisa ser feito, nunca o como; e
• Um JTBD pode ser apresentado assim: verbo + substantivo .

Trabalho (O Quê) x Solução (Como)

Um trabalho não pode ser inventado – ele é descoberto. E é perene e recorrente. O que muda, cada vez mais, são as alternativas para executá-lo – as soluções. Pense, por exemplo, em seu trabalho de “ir ao cinema”. Caminhando, no transporte público, de táxi, bicicleta ou carro próprio são opções. Uber e equivalentes são novos “comos”.

Repare o jogo de soma zero: no instante em que um produto ou serviço é contratado para executar um trabalho, outro é demitido.

A correta definição do que precisa ser feito é briga antiga. E cria confusões mil, até onde menos se espera. Gente de marketing (e de análise de negócios) vive replicando um dito um tanto bugado: “clientes não querem brocas de ¼ de polegada, querem furos com ¼ de polegada”. Oras, quem deseja um furo pelo furo? O verdadeiro trabalho (JTBD) talvez seja “colocar um quadro na parede”. Ou, indo mais fundo, “deixar a sala de visitas mais bonita”. O tal furo, em linguagem jornalística, é uma bela barrigada. No desenho de soluções, uma perigosa miopia. Que pode ser curada através de outra ferramenta, a 5 Porquês (5 Whys).

Há Controvérsias

Apesar da relativa simplicidade da teoria e ferramenta JTBD, existem interpretações conflitantes. Christensen e Ulwick concordam que, além da parte funcional, um trabalho pode envolver os lados:

• Emocional: como o cliente/usuário quer se sentir;
• Social: como o cliente/usuário espera aparecer perante sua patota.

Quem contrata um iPhone, por exemplo, talvez dê mais valor aos trabalhos emocionais e sociais do que aos funcionais.

Alan Klement, autor de When Coffee and Kale Compete (PDF gratuito aqui), acha isso tudo uma baboseira. Para ele o trabalho é um só e deve ser definido assim. Klement detona o trabalho de Christensen, citando um caso de fracasso. Neste artigo, muito bom, ele mostra como escrever Job Stories. Este outro, igualmente bom, de Fabrício Teixeira, traça um comparativo entre Job Stories e User Stories.

Apesar de certo cinismo e dos golpes abaixo da linha da cintura, o debate é bom porque enriquece a ferramenta.

Ferramenta Multiuso

JTBD, em sua intenção original, nos ajuda a iniciar o processo de desenho de produtos e serviços. Clayton Christensen, em Muito Além da Sorte (Competing Against Luck), reposiciona a proposta: organizações podem ser desenhadas a partir dos Trabalhos a Executar. Seria uma maneira de derrubar silos e entregar valor de forma mais eficaz e eficiente.

Scott Anthony, em Dual Transformation, coloca o JTBD como peça chave dos processos de transformação de uma empresa. E mostra modelo e casos de enfrentamento bem sucedido do que Christensen chamou de O Dilema da Inovação.
(Mais sobre isso no próximo artigo)No FAN eu mostro como a ferramenta JTBD ajuda analistas de negócios em dois momentos: iniciando projetos e desenvolvendo requisitos.

Na OPA! a JTBD é o ponto de partida para o desenvolvimento de projetos de aprendizagem. “Tocar violão”, “Fazer pão de queijo”, “Administrar Riscos” e “Promover Comunicação Não Violenta” são alguns exemplos.

Na oficina/lab Design de Negócios Viáveis, JTBD é a segunda ferramenta utilizada. Ela nos ajuda a desenhar um negócio e sua proposta de valor. A partir dela desenvolvemos: Mapa de Expectativas, Mapa de Alternativas, Mapa de Transformações, Matriz Benefício/Custo, Pitch etc.
(Clique aqui ou na imagem ao lado para baixar modelo em PDF)

JTBD é uma ferramenta versátil, simples e poderosa. Daquelas que merecem posição privilegiada no cinto de utilidades, sempre ao alcance das mãos.

Notas

1. Na edição original de 2003, pela HBR Press. Neste livro Christensen atribui o termo original a Richard Pedi, então CEO da Gage Foods. E reconhece as contribuições de Tony Ulwick, que então chamava a ideia de “outcomes that customers are seeking” (resultados esperados pelos clientes). Ulwick se apresenta como o pai da ferramenta em Jobs to be Done: Theory to Practice (Idea Bite Press, 2016).
2. Dentre eles:
   • The Innovator’s Toolkit – David Silverstein et al. (Wiley, 2009).
   • Value Proposition Design – Alex Osterwalder et al. (HSM, 2014).
   • Dual Transformation – Scott D. Anthony et al. (HBR, 2017).
3. Puristas e puritanos deram pulos neste momento. “Um JTBD não pode ser uma tarefa ou atividade”, eles dirão. Meus caros, se a ferramenta funciona nesses contextos, por que não utilizá-la? Vale apenas o alerta: em seu propósito original e quando bem utilizada a ferramenta tem mais valor,  menos concorrentes e poucos cupins, por enquanto.
4. Beautiful Tools, de THOR, foi surrupiada no flickr para ilustrar este artigo.

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.