Scrum é de longe o framework ágil mais popular na atualidade 😁, e já existe há quase 30 anos. Sua aparente simplicidade pode enganar: Na sua essência trata de um time autônomo que trabalha de forma auto-organizada com um único objetivo: entregar uma nova versão do produto "pronto" a cada cíclo.

Os membros do time planejam juntos o que vão entrega durante um período fixo (como por exemplo duas semanas). Depois das duas semanas, o resultado é mostrado aos clientes. Com o feedback, ajusta-se o plano, e o próximo cíclo começa...

Na teoria é fácil, mas infelizmente, a prática é mais complicada...

Perguntinha rápida: o profissional de UX (design de interação, design visual, estratégia de conteúdo, marketing, etc.) faz parte deste time ou não?

Muitos vão responder: Claro que não! Como é possível planejar toda a parte visual, a interação com o usuário, as telas, a navegação, a arquitetura de informação, o look-and-feel e depois programar e testar tudo isso em tão pouco tempo? Melhor fazer isso antes, e passar para o time para executar, não é mesmo? Se você pensou assim, sinto lhe informar, mas você não pensou em um time multi-funcional.

O Que Podemos Aprender Como Dilema dos Testadores

Essa aparente contradição me lembra o dilema que times ágeis enfrentavam quando precisavam aprender a codar e testar dentro do mesmo cíclo de trabalho (que chamamos tecnicamente de uma Sprint). Na época os testadores dentro do time não tinham nada a testar durante a primeira semana, enquanto os programadores estavam super ocupados programando as novas funcionalidades. No final da Sprint, os testadores estavam super-estressados e os programadores ficavam a toa, e geralmente não sobrava tempo suficiente para deixar tudo pronto. O resultado: vamos testar na próxima Sprint, enquanto os desenvolvedores trabalham nas novas funcionalidades.

Assim nasceu o famoso anti-padrão de Dual-Track: Sprint 1: programar, Sprint 2: testar o trabalho da Sprint 1, e programar as coisas do sprint 2, etc.

Isso era ruim, porque quando um testador acha um erro em uma funcionalidade o programador já avançou e está trabalhando em outro assunto...

Como podemos testar algo que ainda não foi desenvolvido? Que louco!! Este desafio foi só possível de se resolver com uma radical mudança de perspectiva.

Shift-left: "testar" vem antes ou ao mesmo tempo do desenvolvimento com práticas como TDD e BDD

O conceito de um "teste" evoluiu para "especificações com exemplos", tanto a nível técnico (o que eu espero do meu componente? como isso deveria se comportar em uma certa situação? pode concretizar isto com um exemplo?) como a nível funcional (quais são exemplos concretos de uma funcionalidade que podemos usar como testes automatizados? "Me da um exemplo concreto de como funciona este desconto?")

Claro que isso significava que testar começou a ser uma atividade compartilhada pelo time inteiro, e "qualidade" começou a ser uma responsabilidade de todo mundo. Testadores começaram a aumentar os seus horizontes, e aprenderam a programar (pelo menos um pouco), e o mesmo aconteceu com os programadores. Raramente você vai achar programadores que não testam também o seu trabalho. Práticas como testes unitários fazem parte das habilidades básicas de qualquer programador hoje em dia.

Nos nossos times, quando planejamos a Sprint, grande parte do tempo gastamos em discutir e especificar cenários de testes e criar um plano de teste e todo o time participa.

Vamos voltar ao assunto de UX...

Eu confesso que tive as minhas dúvidas a respeito de UX e design gráfico. Será que o time também pode assumir como um todo essas habilidades? O que me inspirou a aplicar isso foi o livro de Jeff Gothelf e Josh Seiden "Lean UX".

O livro se baseia em 3 pontos fundamentais:

1. Design Thinking: a filosofia de inspirar inovação pela observação direta das pessoas para entender as suas necessidades e desejos na seu dia-a-dia. Observar empiricamente do que gostam, e não gostam de como produtos são feitos, entregues, vendidos, seu marketing e o seu suporte.

2. Casamento com os princípios do Manifesto Ágil para desenvolvimento de software.

3. Saber quanto trabalho cabe no ciclo de trabalho (Sprint)

Gostei do livro porque é muito prático. Os autores apresentam uma séria de princípios e mostram como eles aplicaram eles no seu trabalho.

Design Colaborativo

Adotamos o design da Experiência de Usuário como um processo colaborativo. Lean UX define o que é Experiência de Usuário como:

A soma de todas as interações de um usuário com o seu produto ou serviço:

1. a sua precificação

2. a sua apresentação

3. o seu marketing

4. como é vendido

5. como o onboarding funciona

6. o suporte

7. a manutenção etc.

Ou seja, o produto é criado por um time e não um designer de UX. Por isso, o design da experiência do Usuário também deveria ser um processo colaborativo.

Design Studio

Começamos com o método de Design Studio. O processo é descrito no livro de Lean UX, mas para aprofundar recomendo o livro "The Design Studio method" de Brian Sullivan. É uma abordagem de co-criação que junta designer com não-designer.

O processo se baseia na idéia que um grupo tem coletivamente mais e melhores idéias do que qualquer rock-star designer. Para chegar nesta inteligência coletiva, é necessário um processo de facilitação (que o designer ou o Scrum Master pode liderar). O método de baseia nos seguintes passos:

Todo começa com um desafio para o qual se busca uma solução. Para dar um exemplo simples: quando desenvolvemos uma App para uma empresa nos deparamos com a dúvida: "Qual a melhor maneira de enviar uma mensagem para um grupo de clientes? Primeiro selecionar a mensagem, depois os clientes, ou vice-versa? como ? O que seria mais intuitivo e menos confuso?". Tem várias formas de abordar o problema, e decidimos perguntar ao nosso "cérebro coletivo", o time.

1. Todo mundo do grupo desenha ideias para uma possível solução

Sim, todo mundo rabisca juntos, todo o time, desenvolvedores, testadores, incluindo os clientes da empresa para qual desenvolvemos o App. Claro, precisa ensinar as técnicas mais básicas de rabiscar wireframes (na prática, não precisa mais de 5 min para isso). Vocês vão descobrir que todo mundo adora rabiscar!

2. Trabalho coletivo começa com trabalho individual

Soa contraditório, mas para ser bom de forma coletiva, precisa começar de forma individual. Cada participante cria primeiro suas próprias ideias, e o foco neste momento é mais quantidade do que qualidade. O desafio era de criar individualmente 4 ideias diferentes!

3. Os resultados individuais são apresentados

Os resultados individuais são primeiro analisados com curiosidade e sem julgamento para depois serem coletivamente criticados através de um sistema de votação com pontos. Importante é separar o pensamento criativo e o pensamento crítico.

4. Afunilar de forma iterativa

O processo é iterativo, dependendo do tamanho do problema, entre 2 e 3 iterações. Cada participante - depois de ouvir o feedback do grupo inteiro e entender todas as ideias dos outros - recomeça o trabalho e tem a liberdade de recriar, refinar ou criar soluções totalmente novas. Importante aqui é que o número de soluções tem que diminuir agora. Na primeira iteração pedem-se por exemplo 4 ideias individuais, na segunda iteração é necessário reduzir para 2 ideias, e assim sucessivamente.

5. Mashup final

No final deste método todo mundo tem um entendimento profundo do problema e das ideias coletivas e com as soluções finais, o grupo cria um mashup que representa a solução final do grupo.

Conclusão

Um workshop deste tipo pode ser bem rápido (menos de uma hora) para problemas menores e menos participantes, ou até 3-4 horas para desafios mais complexos.

Porque nos fazemos assim?

Primeiramente, as soluções coletivas são melhores. É profundamente interessante, pois a versão final é diferente de todas as ideias iniciais, não tem um dono, é verdadeiramente uma solução coletiva. Como tem um dedo de todo mundo, o time fica mais comprometido. Alem do mais, todo o conhecimento é compartilhado pelo time.

Fica ainda a grande pergunta: como organizar o trabalho de design UX dentro do time Scrum? E como fica o trabalho de descoberta, como Pesquisa de usuário?

Vamos falar primeiro do Dual Track.

Dual-Track Agile como Anit-pattern

Autores como Desiree Sy, Lynn Miller, Marty Cagan, e Jeff Patton pregam um processos que basicamente separa o trabalho em 2 backlogs: um discovery backlog e um delivery backlog. Na prática o que geralmente se ve é que o time se separa em 2 times onde o Product Owner (ou Product manager) e o UX designer fazem a maior parte do trabalho de discovery e os desenvolvedores focam no trabalho de entrega. Como resultado, temos de novo um mini-waterfall, o entendimento compartilhado piora, a velocidade da tomada de decisão é reduzida, assim como a coesão, produtividade e o aprendizado.

Soluções para Manter um Único Ciclo

Para manter as vantagens da agilidade, adaptamos táticas sugeridas pelo Lean UX, que permitiam manter um único ciclo e assim um rítmo compartilhado pelo time inteiro. Todas as atividades acontecem dentro de sprints:

1. Usar Workshops de Design Studio (3-4h) junto com o cliente para refinar features maiores

2. Refinamento de features menores com workshops de Design Studio mais curtos (1-2h). As vezes dentro durante a Sprint ou durante a própria Sprint Planning

3. Os resultados dos Design Studios, os wireframes são insumos para as reuniões de Sprint Planning

4. Fatiamento rigoroso dos wireframes para caber dentro da Sprint

5. Spikes Técnicos: pesquisa de cunho técnico, como descobrir como uma nova tecnologia funciona.

6. Spikes de Discovery: trabalho de discovery é gerenciado junto com o Product Backlog. Exemplos são testes com usuários, entrevistas, etc. Durante a Sprint Planning o time decide quem for liderar esta atividade e os resultados são compartilhados com o time inteiro.

7. Pesquisa de Usuário (user research) é feito de forma contínua. Tentamos marcar um fluxo contínuo de entrevistas com clientes, onde mostramos tanto a versão atual do produto como o feature em andamento.

Discovery Contínuo

Para quem quiser aprender mais a respeito de técnicas de Discovery contínua, recomendo o livro da Teresa Torres, Continuous Discovery Habits, onde ela explica como ela faz a gestão de hipóteses numa estrutura de árvore, a Opportunity Solution Tree, e esta árvore é alimentada com um fluxo constante de entrevistas com usuários do produto.