Design thinking vs lean vs agile vs design sprint: qual e quando

Escolha design thinking quando você ainda não entende o problema. Escolha lean startup quando tem uma ideia e precisa descobrir, com pouco gasto, se ela funciona. Escolha agile quando sabe o que construir e precisa entregar em partes que funcionam. Escolha um design sprint quando um problema claro e importante precisa de uma resposta testada em uma semana. Eles não são rivais: cada um responde a uma pergunta diferente, e a maioria dos projetos reais usa mais de um, em sequência.

A confusão vem do fato de os quatro falarem de usuários, iteração e aprendizado. A diferença está no que cada um supõe que você já sabe quando começa. Para a pergunta mais ampla de qual ferramenta isolada usar, veja qual ferramenta de inovação usar?.

De onde vem cada um

Um pouco de história ajuda, porque cada abordagem ainda carrega o problema para o qual foi criada.

• Design thinking nasceu da prática do design e foi popularizado como abordagem geral de resolução de problemas pela empresa de design IDEO e pela d.school de Stanford (o Hasso Plattner Institute of Design, fundado em 2005). O Double Diamond do Design Council do Reino Unido, criado em 2003, descreve um formato parecido. Foi criado para problemas em que a própria necessidade não está clara.
• Lean startup foi apresentado por Eric Ries em seu livro de 2011, A Startup Enxuta (The Lean Startup), com base no customer development de Steve Blank e na manufatura enxuta. Foi criado para fundadores que correm o risco de passar anos construindo algo que ninguém quer.
• Agile remonta ao Manifesto para Desenvolvimento Ágil de Software, escrito por 17 profissionais de software em Snowbird, Utah, em fevereiro de 2001. O Scrum, criado por Ken Schwaber e Jeff Sutherland, é o seu framework mais conhecido. Foi criado para projetos de software que fracassavam sob planos longos e fixos.
• O design sprint foi desenvolvido por Jake Knapp no Google e no Google Ventures e descrito no livro Sprint, de 2016, de Knapp, John Zeratsky e Braden Kowitz. Foi criado para levar uma equipe de uma pergunta difícil a um protótipo testado em cinco dias.

Lado a lado

Quando cada um se encaixa

Use design thinking quando o problema não está claro

Você ouve várias descrições diferentes do problema, de pessoas diferentes. Existem reclamações, mas ninguém sabe dizer o que as causa. É preciso um serviço novo para um grupo que vocês nunca estudaram. Nesses casos, começar por ideias ou pela entrega pula o trabalho mais valioso. Comece com entrevistas com stakeholders e feche o enquadramento com uma declaração de ponto de vista e perguntas Como poderíamos. O processo completo está em design thinking, passo a passo.

Não use quando o problema já é bem entendido e a organização precisa de entrega. Fazer uma fase de descoberta sobre um problema que todos já entendem testa a paciência, não as ideias.

Use lean startup quando você tem uma ideia e o risco é ninguém querer

Você tem um conceito, um patrocinador e algum entusiasmo, mas nenhuma evidência de que as pessoas vão usar, pagar ou mudar de comportamento por causa dele. O pensamento lean pede que você identifique a premissa mais arriscada com um mapa de premissas, escreva um teste de hipótese e faça o menor experimento capaz de provar que você está errado, como um teste concierge. Mais em como testar uma ideia antes de construí-la.

Ele é mais fraco quando o próprio problema não está claro (você vai testar respostas para a pergunta errada) e em serviços em que não é possível, ética ou legalmente, fazer experimentos com o público sem cuidado. No governo, muitos experimentos exigem uma conversa sobre consentimento e risco diferente da de uma startup.

Use agile quando você sabe o que construir

O conceito está validado e o trabalho é sobretudo de entrega: construir o sistema, o processo, o serviço. O agile quebra o trabalho em pequenos incrementos, escritos como histórias de usuário, entrega partes funcionais em ciclos curtos e se ajusta por meio de retrospectivas regulares.

O agile não diz o que construir. Equipes que o usam para descoberta muitas vezes acabam entregando rapidamente funcionalidades de que ninguém precisava. Ele também se encaixa mal onde contratos, compras ou regulação fixam o escopo de antemão, a menos que esses estejam montados para permitir mudanças.

Use um design sprint quando uma pergunta importante precisa de resposta nesta semana

Um design sprint se encaixa quando o desafio está definido, o que está em jogo justifica cinco dias do tempo de quem decide e a equipe está travada entre opções. O formato clássico: segunda-feira, mapear o problema e escolher um alvo; terça, esboçar soluções individualmente; quarta, decidir e montar o storyboard; quinta, construir um protótipo realista; sexta, testá-lo com cinco usuários.

Ele se encaixa mal quando ninguém pesquisou os usuários (o sprint vai se apoiar em suposições), quando quem decide não pode participar ou quando o problema é grande demais para ser prototipado em um dia.

Combinando: a sequência habitual

As abordagens funcionam melhor numa ordem que acompanha a incerteza.

1. Design thinking para entender e enquadrar. Pesquisa e uma declaração do problema aprovada.
2. Um design sprint para convergir. Use a pesquisa para deixar a segunda-feira do sprint mais rápida e mais bem fundamentada, e saia com um conceito testado.
3. Experimentos lean para reduzir o risco. Teste as premissas que o sprint não resolveu, como se as pessoas vão continuar usando o serviço depois da primeira semana.
4. Agile para entregar. Construa e lance em incrementos, e continue testando com usuários ao longo do caminho.

Nem todo projeto precisa dos quatro. Uma pequena correção de processo interno pode precisar de uma semana de descoberta e depois da entrega. Um novo produto digital pode pular direto para um sprint se a pesquisa já existir. A regra prática: identifique sua maior incógnita e use a abordagem criada para ela.

Um exemplo prático

Ilustrativo. Uma operadora postal nacional de um país europeu de porte médio quer oferecer um serviço para pequenos vendedores online.

Design thinking (seis semanas). A equipe entrevista vinte vendedores e observa vários deles embalando pedidos. O problema esperado era o custo da postagem. O real: os vendedores perdem horas por semana lidando com devoluções, porque os compradores imprimem as etiquetas errado e os pacotes voltam sem identificação. A declaração do problema é aprovada: "Como poderíamos tornar as devoluções fáceis para vendedores com menos de cinquenta pedidos por semana?"

Design sprint (cinco dias). Com o chefe de encomendas na sala na segunda e na quarta, a equipe esboça, escolhe e prototipa um código de devolução que o comprador mostra no balcão, sem imprimir nada. Cinco vendedores testam na sexta. Quatro querem o serviço, e os cinco perguntam se ele funciona com o marketplace que usam.

Experimento lean (quatro semanas). A premissa mais arriscada que resta é que os atendentes conseguem processar os códigos sem atrasar a fila. A equipe roda uma versão concierge em três agências, com os atendentes tratando os códigos manualmente a partir de uma lista impressa. O tempo de fila se mantém estável.

Entrega agile (contínua). Uma equipe de entrega constrói o sistema real em sprints de duas semanas, começando por uma integração com um marketplace e pela etapa de leitura no balcão, e testando cada versão com os vendedores.

Cada abordagem fez o trabalho para o qual foi criada. Começar pelo agile teria produzido rapidamente uma ferramenta de desconto na postagem. Começar por um sprint teria deixado o problema das devoluções totalmente de fora.

O que fazer e o que evitar

Faça

• Dê nome à sua maior incógnita primeiro e depois escolha a abordagem criada para ela.
• Alimente os design sprints com pesquisa. Um sprint apoiado em insights reais de usuários é muito mais forte que um construído sobre palpites.
• Continue testando com usuários depois que a entrega agile começar.
• Combine de antemão quem é dono da passagem entre as etapas, sobretudo do sprint para a entrega.

Evite

• Não trate os quatro como marcas concorrentes nem pergunte qual é "o melhor". É como perguntar se um mapa é melhor que um martelo.
• Não use agile para descoberta. Ciclos curtos de entrega não substituem entender o problema.
• Não faça um design sprint sem quem decide. Você terá um bom protótipo e nenhuma decisão.
• Não chame todo workshop de design sprint. Cinco dias com a estrutura definida são uma coisa; uma sessão de ideação de duas horas é outra.
• Não deixe cada abordagem viver num departamento diferente, com vocabulário próprio. É nas passagens que o aprendizado se perde.

Perguntas frequentes

Design sprint é a mesma coisa que design thinking? Não. Um design sprint é um processo fixo de cinco dias que usa várias ferramentas de design thinking para responder a uma pergunta definida. Design thinking é a abordagem mais ampla, e o trabalho de descoberta dele normalmente vem antes de um sprint.

Design thinking e agile podem funcionar juntos? Sim, e deveriam. O design thinking descobre o que construir e para quem; o agile constrói em incrementos. O padrão comum é um período de descoberta e depois uma entrega agile que mantém um ritmo regular de testes com usuários.

Qual é melhor para projetos de governo? Depende da incógnita. Design thinking serve para serviços em que as necessidades dos cidadãos não estão claras; agile serve para a entrega digital quando as necessidades já estão claras; experimentos lean exigem cuidado extra com consentimento e risco quando o público está envolvido. Muitos padrões de serviços digitais de governo combinam descoberta com entrega agile.

Para onde ir agora

Para a descoberta, comece com entrevistas com stakeholders. Para reduzir o risco de uma ideia, use o mapa de premissas. Para o dia do protótipo no sprint, veja protótipo em papel e, para a entrega, histórias de usuário. Todos os guias de método estão no índice de guias.