Lean, Ágil ou Design Thinking?

Este artigo foi baseado na palestra Lean vs Agile vs Design Thinking de Jeff Gothelf.

Na conferência Agile AUS 2018, Jeff Gothelf mostrou por que simplesmente treinar equipes de tecnologia com Ágil, de produtos com o Lean e de design com o Design Thinking não trará apenas soluções para o negócio. Na apresentação Lean, Ágil ou Design Thinking?, Gothelf fala sobre o desafio de criar uma integração onde as equipes compartilham o mesmo vocabulário, alinham os objetivos e mantém a cadência reconciliando as diferenças percebidas entre Lean Startup, Ágil e Design Thinking. Gothelf ainda fala sobre como as equipes devem se concentrar nos valores oferecidos e não nos rituais ou práticas vindas de diferentes mindsets.

Sobre Lean, Ágil e Design Thinking

A ideia de treinar a equipe de produtos com Lean, de tecnologia com Ágil e a de design com Design Thinking é criar produtos melhores e deixar os clientes satisfeitos, mas isso parece não funcionar se faltar comunicação, senso compartilhado dos objetivos ou visão do produto. Quando adotamos uma abordagem para resolver uma situação peculiar tudo que temos é um processo para um problema específico.

Um ponto interessante é que o tamanho da empresa irá determinar como isso funciona. Observando o problema sob a perspectiva de uma startup, por exemplo, as consequências sobre cada decisão são imediatas. Não importa se houverem 5, 10 ou 15 pessoas, em uma startup as consequências são mais evidentes, portanto, sabe-se que ao se tomar muitas decisões erradas ela vai quebrar, independente da abordagem que foi utilizada.

Quando a empresa cresce, é comum as pessoas assumirem o domínio sobre o processo escolhido, assim pressupõem que basta escalar a abordagem escolhida anteriormente para toda a empresa. Contudo, à medida que a empresa cresce fica mais difícil decidir pois há mais dinheiro, tempo, pessoas, especialistas e decisões envolvidas.

Dessa forma é comum grandes empresas desejarem se tornar uma startup novamente utilizando Lean e Ágil; entretanto, não existe receita ou atalho para fazer essa transformação. Quanto maior a empresa, maiores são as possibilidades de escolha. Um gerente que deseja criar uma equipe ágil ou implantar a agilidade na empresa, por exemplo, não deve se assustar pela quantidade de opções disponíveis.

O Ágil

Segundo Gothelf, a abordagem Ágil refere-se à agilidade e não a um processo ou rituais específicos. Sendo assim, a agilidade é responder à mudança mais do que seguir a um plano. Contudo, o que o palestrante presenciou especificamente em grandes empresas, foi que o Ágil foi implementado para melhorar o ritmo no qual o software é entregue.

A falha acontece quando deixam a tomada de decisões para o Ágil. A forma como o framework está sendo implementado não supre as habilidades para tomada de decisões, sobre o quê construir e está realmente pronto.

Tomadas pelo mindset de fábrica de software, algumas empresas contratam engenheiros para escrever o código e para se certificar que nada desastroso aconteça, solicitando que os códigos sejam "persistidos" tão logo estejam prontos, assim poderão medir a velocidade da equipe. Não podemos continuar operando como uma fábrica de software porque mais código não é igual a mais valor ao cliente, afirma Gothelf.

Precisamos começar a pensar como a nossa medida de sucesso deve mudar, como podemos aplicar Lean, Ágil e Design Thinking de maneiras que mudem a medida do sucesso. Afinal, só porque pode fazer não significa que deva fazê-lo.

O Lean

A abordagem Lean vem com uma proposta de que há muitas maneiras de colocar um cérebro no processo ágil de tomada de decisão. O Lean nasceu a partir de uma necessidade na década de 1950, quando a Toyota tentava competir com os fabricantes de carros americanos em um cenário pós-guerra.

Embora essa abordagem tenha muita coisa para ser explorada, Gothelf conduziu a apresentação focando na definição Lean de que estamos sempre nos movendo de uma posição de dúvida para uma posição de certeza. Não se pode prever o futuro, então para reduzir o risco de ir longe demais no erro, conduzimos e trabalhamos em pequenos lotes. Iterações e sprints possibilitam o entendimento de como trabalhar dessa maneira, assim o Lean começa a colocar cérebro no processo Ágil.

A abordagem Lean Startup dá um passo além e sugere experimentar, escrever, testar hipóteses, pensar sobre o que será feito e como reduzir o risco a partir da construção do menor incremento possível, verificando como isso afeta o comportamento do cliente para determinar se isso é algo que se deseja trabalhar.

O desafio, particularmente em médias e grandes empresas, é que ninguém quer comprar experimentos, as pessoas querem comprar aplicativos, sistemas, soluções. Como podemos conciliar isso? Vejamos algumas ideias do Design Thinking.

O Design Thinking

O Design Thinking simplesmente diz que designers tem um jeito de trabalhar e pensar; por que não pegar essas ferramentas e aplicar aos negócios da mesma maneira que os designers resolvem seus problemas?

• Um ótimo exemplo de Design Thinking foi o da montadora de automóveis Volkswagen, com foco na mudança de hábito das pessoas na população de Odenplan, Estocolmo. O objetivo era fazer com que as pessoas optassem pelas escadas físicas tradicionais ao invés das rolantes e para isso eles criaram uma forma criativa e mais divertida. A equipe personalizou toda a escada de forma que cada degrau parecesse com uma tecla de piano, além disso sensores sonoros foram adaptados aos degraus. O resultado dessa intervenção chamada de Teoria da Diversão foi o aumento de 66% das pessoas que utilizam as escadas tradicional. Veja como foi essa experiência no YouTube.

Design thinking é uma abordagem centrada no ser humano para a inovação, que se baseia no kit de ferramentas do designer para integrar as necessidades das pessoas, as possibilidades da tecnologia e os requisitos para o sucesso do negócio

Tim Brown, CEO da IDEO

Um método bastante comum utilizado na prática do Design Thinking é o Duplo Diamante criado pelo Conselho Britânico de Design. Neste processo criativo as ideias tendem a surgir quando divergimos e convergimos as ideias em cada uma das quatro etapas.

Na fase descoberta o designer tende a coletar o máximo de ideias possíveis sem julgamentos, aqui o segredo é quanto mais ideias melhor. Em seguida temos o processo de definição, alguns filtros como viabilidade, relevância e priorização são considerados. O terceiro estágio chamado de desenvolvimento é onde os conceitos são consolidados, às hipóteses são criadas e protótipos são testados. Por fim temos a fase da entrega onde os resultados são entregues ao usuário final.

Juntando os mindsets

O primeiro exemplo enfatiza, define, idealiza, prototipa e testa as ideias conversando e aprendendo com clientes. O mais interessante é que se encaixa muito bem no loop construir, medir e aprender do Lean Startup e com o processo Ágil.

Na maioria das situações, ao misturar esses três processos gera-se algum tipo de criação monstruosa impossível de se manter. Para isso, Gothelf propõe a integração dos princípios ao invés de simplesmente juntar os processos. Alguns princípios específicos realmente funcionam e Gothelf compartilhou dez que certamente irão agregar maior valor ao produto e deixar o cliente satisfeito.

Princípio #1 - Valor para o cliente e para o negócio são a mesma coisa

Se fizer seu cliente um sucesso, se respeitar seu tempo, criar produtos que realmente gostam e que resolvam problemas reais de forma significativa, sua empresa será recompensada, pois o cliente irá adquirir mais serviços e até indicá-lo para colegas. Caso ignore isso, o cliente também irá ignorá-lo.

Na apresentação, é citado o exemplo da Gibson. Em sua estratégia, a Gibson optou pela inovação a todo custo ignorando o cliente e o sucesso de pessoas comuns, celebrando em seu website os deuses da guitarra e ignorando o mercado e o cliente atual.

Enquanto isso, a Fender procurou entender o que acontece no mercado e em como a demografia dos guitarristas está mudando - metade são mulheres e novos guitarristas querendo aprender a tocar. Com a perspectiva centrada no usuário (como faremos nossos clientes serem um sucesso), vemos em parte do website uma seção dedicada a ensinar como tocar guitarra. Aprendizagem como medida do comportamento do consumidor.

A ideia é criar valor a partir do que entregamos ao cliente e não ao terminar o software.

Princípio #2 - Trabalhar em ciclos curtos

Tentamos trabalhar com muitos detalhes e depois corremos contra o tempo para terminar as coisas. Isso acontece porque tentamos fazer um planejamento de longo prazo, o que gera risco e incerteza. Particularmente em software, quando desenvolvemos produtos de longo prazo, o planejamento inevitavelmente falha. Tentamos tomar decisões deliberadas sobre o futuro e esperamos que as coisas surjam a partir de um único processo.

Ao gerenciar através dos resultados, começamos a tomar decisões baseadas em evidências. Se tentar algo que não funciona, testamos algo novo, sempre em ciclos curtos pois nos ajuda a aprender e a refletir.

A melhor coisa sobre decisões baseadas em fatos é que elas sobrepõem a hierarquia.

- Jeff Bezos, CEO da Amazon.com

Coletamos evidências sobre o que realmente está mudando no comportamento do cliente. Então podemos ajustar nosso planejamento em ciclos mais curtos em vez de esperar longos períodos. É incrível como quanto mais aprendemos, mais justificável será o nível de investimento e esforço empreendido.

Dessa forma, os investimentos iniciais podem ser menores e mais focados no entendendimento sobre a posição do produto no mercado. Eventualmente, começamos a dimensionar as coisas e entender se devemos empreender mais tempo, contratar mais pessoas e investir neste nível particular de trabalho.

Essas evidências nos ajudam a construir produtos a longo prazo e então começamos a responder diferentes perguntas. A primeira delas é se devemos construir o produto (princípio do Lean startup) e automaticamente se podemos desenvolver o negócio e escalá-lo em torno do produto.

Pensando em cada um dos pontos de decisão, ao final de cada ciclo curto de trabalho responderemos a duas questões:

• Qual é a próxima coisa mais importante que precisamos aprender?

Note que não falamos de qual a próxima coisa mais importante que precisamos para entregar. E uma vez respondida essa pergunta, então:

• Qual a quantidade mínima de esforço que precisamos para aprender isso?

Iniciando um novo ciclo de aprendizagem, durante este curto ciclo será possível coletar evidências e isso ajudará no gerenciamento dos projetos.

Princípio #3 - Manter retrospectivas regulares

As retrospectivas são extremamente poderosas, com ela podemos olhar para trás e entender o que funcionou e o que não, e então fazer as coisas melhores.

Ao manter retrospectivas regulares e consistentes, podemos melhorar o produto. Podemos entender o que não funcionou, o que deveria ser feito e o que deveria ser depreciado. Além disso, essas cerimônias também ajudam a melhorar o processo. A retrospectiva é um princípio ágil que nos ajuda a construir maneiras melhores de trabalhar.

Princípio #4 - Sair e observar

Observar como as coisas estão funcionando para o time, especialmente se estiver em uma posição de gestão. Se disser às equipes que está tentando implementar um processo, a equipe utilizará apenas o processo que funciona melhor para ela.

Verifique se o processo está funcionando para essa equipe, amplifique essa abordagem, não importa se é uma abordagem Lean, Ágil, Design Thinking ou qualquer variação do modelo Cascata (Waterfall), tanto faz. Se está funcionando para uma equipe e é algo que outros times podem aprender, como um líder, é sua responsabilidade observar o que as equipes estão fazendo e em seguida elevar essas boas práticas para que os outros em toda a organização possam aprender com isso.

Princípio #5 - Testar hipóteses de alto risco

Ao gerenciar resultados, não sabemos o que realmente vamos fazer e a maneira de aprendermos sobre é através da experimentação. Expressamos o que estamos tentando aprender como uma afirmação testável, conhecida como uma declaração de hipóteses. Abaixo, temos um exemplo de como escrevê-las; não importa como são escritas mas é melhor iniciar de forma simples.

Acreditamos que podemos alcançar um resultado ou mudança no comportamento do cliente se o usuário, subconjunto específico do nosso público-alvo, puder conseguir algum tipo de benefício, algo que realmente se preocupam como uma solução ou um recurso.

O que estamos fazendo com isso é justificar qualquer trabalho daquela funcionalidade, em outras palavras, só haverá permissão para trabalhar na próxima funcionalidade se as primeiras três variáveis desta declaração forem preenchidas. Devemos ser capazes de dizer que estamos trabalhando nesta funcionalidade para este cliente porque isso é importante para ele, assim saberemos se foi uma boa ideia.

O problema é que podemos escrever muitas declarações de hipóteses mas não há como testar todas. Em algum momento será preciso entregar o produto, logo não podemos simplesmente trabalhar apenas em atividades de aprendizagem. Sendo assim, é importante pensar sobre as hipóteses que deseja testar e caso a hipótese seja algo de alto valor percebido e baixo risco apenas faça.

As hipóteses posicionadas no topo e direita desta matriz são realmente utilizadas como experiências e conhecimento sobre o que acreditamos ter alto valor para o cliente. Neste ponto as coisas podem ser tecnicamente arriscadas, talvez haja riscos no design do projeto ou riscos de mercado. Contudo, certifique-se de que as hipóteses que caem nesta posição são as que realmente devem ser testadas.

Se a hipótese cair no canto inferior esquerdo, baixo risco e pouco valor agregado, geralmente descartamos e caso a hipótese caia no canto inferior direito, risco alto e baixo valor percebido, definitivamente descartamos.

Princípio #6 - Faça menos com mais frequência

Um princípio aplicável a praticamente tudo, ciclos mais curtos, menos trabalho e revisão. Para ver como isso funciona, especificamente nas atividades de aprendizagem, porque uma das coisas que acontecem muito, particularmente em equipes multifuncionais, é que se faz muita pesquisa ou desenhos iniciais e então após entregá-los esperamos que funcionem sem nos preocuparmos com o que aprendemos naquela pesquisa.

Gothelf explica que trabalho tradicional de pesquisa pode ser um desperdício e que para evitar o desperdício é preciso se questionar:

- Qual o caminho mais rápido para aprender a coisa mais importante?

- Qual é a menor quantidade de trabalho que podemos fazer para aprender isso?

- Como podemos reduzir os elementos de pesquisa do nosso trabalho?

Assim como escrever código ou criar o design, a pesquisa faz parte do desenvolvimento de software, e Gothelf cita exemplos de descoberta de produtos que funcionaram:

• No desenvolvimento do Amazon Echo, em algum momento uma das coisas mais importantes que precisavam aprender era o que as pessoas iriam perguntar e o que seria uma boa resposta.

Este time colocou um usuário na frente de um cilindro vazio e um engenheiro em outra sala na frente de um computador. O usuário perguntava algo ao cilindro, enquanto na outra sala o engenheiro fazia a consulta no Google e respondia de volta para o usuário.

Isso foi a coisa mais importante que precisavam para aprender, o que seria mais perguntado pelas pessoas e quais seriam boas respostas. Essa foi a quantidade mínima de trabalho que precisaram fazer para aprender, uma simulação.

• Outro ótimo exemplo citado vem da fábrica de carros Ford. Construindo carros há mais de 100 anos, agora precisavam aprender a construir carros sem motorista. Entretanto, em vez de construir um carro sem motorista para entender certas coisas, optaram por disfarçar um homem como o banco do próprio veículo.

Artigo original em Inglês: Ford disfarça homem como banco de automóvel para investigar a autonomia

Tudo isso porque precisavam aprender algo rapidamente e, neste ciclo de aprendizagem, os engenheiros puderam criar todas as iterações, independente do tempo gasto. Essa foi a forma que encontraram para entender mais rápido como as pessoas iriam reagir a carros sem motorista.

Não é necessário construir o carro inteiro, podemos simular um, ou seja, devemos começar a pensar em fazer menos com mais frequência.

Princípio #7 - Trabalhar como um time equilibrado

Gothelf explica que para trabalhar como uma equipe equilibrada precisamos abandonar tarefas que possivelmente não adicionem valor, colocando o time em projetos que realmente agregam algo. Além disso, é interessante manter times pequenos. Esses times devem se dedicar ao projeto em que estão trabalhando (em vez de cobrir duas ou três iniciativas diferentes), estando em sincronia (mesmo que o fuso-horário seja diferente) e sendo multifuncional com Designers, Engenheiros, Testadores (QA) ou especialistas da área. O time deve ser autônomo, capaz de trabalhar por conta própria e o mais importante, deve ser empoderado.

Trabalhando em ciclos curtos e aprendendo em cada um deles, o período mais longo que temos para tomar decisões talvez seja de uma ou duas semanas. É preciso deixar os times tomarem as decisões corretas, pois caso as decisões estejam equivocadas, poderão corrigi-las em duas semanas.

Uma vantagem nos times multifuncionais é que trabalhar nos mesmos projetos, incentivar discussões e socializar fomenta a criatividade e provoca inspirações. Algo impossível com pessoas trabalhando em silos ou literalmente separadas.

Princípio #8 - Transparência radical

Colocar as informações disponíveis nas paredes e nos canais de informação, compartilhe o que aprendeu, o que funcionou e o mais importante, compartilhe o que não está funcionando. Uma tática que funciona muito bem para compartilhar informações vêm do mundo ágil, são as chamadas stand-up meetings, reuniões rápidas e geralmente feitas de pé.

Gothelf faz uma analogia com o filme Karatê Kid, onde Daniel vai até o sr. Miyagi para aprender karatê.

Sr. Miyagi diz: - Pinte a cerca.

Daniel responde: - Quero aprender karatê.

Sr. Miyagi diz: - Encere o meu carro.

Daniel responde: - Mas quero aprender karatê.

Daniel não sabe mas está realizando os movimentos para aprender karatê. Temos a mesma proposta ao praticar stand-ups meetings - os participantes podem não saber mas estão aprendendo por meio de rituais ágeis a dar transparência aos trabalhos.

Scrum de scrums, demonstrações diárias, canais de informação, acesso aos clientes, e relatórios de progresso são coisas que conduzem à transparência. Entender como os clientes estão reagindo às coisas e por que estamos tomando decisões nos ajuda a determinar se um produto é minimamente viável.

Quando os clientes trabalham com nosso produto, isso nos dá uma noção de quão bem o produto está funcionando, nos certificando que sabemos o que estamos construindo e de que não acabaremos construindo produtos como este:

• Este é o Juicero. Uma empresa captou 120 milhões de dólares de financiamento e falharam porque construíram uma máquina excêntrica para fazer sucos e disseram que essa era única maneira de extrair o suco de seus pacotes sofisticados. Entretanto, é possível apertá-lo com as próprias mãos para extrair o suco.

Mais uma tática para manter a transparência é prover acesso aos dados, se certificar de que as pessoas da equipe podem medir as análises do produto. Entender o que está acontecendo com o produto é crítico, não devemos criar uma lista de critérios apenas para fazê-lo passar.

Princípio #9 - Rever o gerenciamento de performance e incentivos

Trabalhamos com muitas empresas realizando transformações ágeis, construindo equipes, criando vocabulários, mas não mudamos a forma como incentivamos e medimos o desempenho das pessoas. A forma como medimos está ultrapassada segundo Gothelf.

Considere a demanda de trabalho que é solicitada versus o incentivo recebido pela equipe. Se houver discrepância entre este dois fatores, significa que não funciona.

Princípio #10 - A aprendizagem como um item de primeira classe no backlog

A aprendizagem deve se tornar um item primordial no backlog principal, nunca em local diferente. De acordo com Gothelf, escrevemos histórias sobre o aprendizado que queremos adquirir da mesma forma que escrevemos histórias sobre as coisas que estamos construindo, e então atribuímos às pessoas.

Após a atribuição, estimamos e adicionamos ao backlog, o mesmo backlog onde as histórias estão localizadas, e as priorizamos em relação a todos os outros trabalhos que a equipe multifuncional e colaborativa tem para fazer.

Assume-se explicitamente que qualquer coisa após a atividade de aprendizagem é potencialmente um risco a subir ou descer na escala da priorização (e inclusive ser reescrito, se for o caso).

Conclusão

Gothelf sugere que devemos utilizar os princípios Lean, Ágil e Design Thinking que fazem sentido para o projeto em que estiver trabalhando. Em seguida, junte os processos e amplifique aqueles que realmente funcionam para você e sua equipe.

Sobre o palestrante

Jeff Gothelf é autor, palestrante, coach executivo e cofundador da Neo Innovation em Nova York, empresa que ajudou a transformar em uma das marcas mais conhecidas sobre estratégia, desenvolvimento e design de produtos modernos. Também é co-autor dos livros Sense and Respond, Lean UX and Lean vs Agile vs Design Thinking e recentemente fundou a Sense / Respond Press, uma editora de livros de negócios modernos.

Sobre o autor

Edeilson Silva é analista de projetos e está engajado com o mindset ágil; sua missão é ajudar desenvolvedores junior a resolver problemas com agilidade para se tornarem sênior mais rápido e entregar produtos com maior valor. Acredita que não deve haver barreiras para a aprendizagem e por isso ajuda a comunidade traduzindo e escrevendo artigos para o InfoQ Brasil.