Parei de usar Scrum. Você Já ouviu falar em Shape Up?

Compartilhando minhas experiências aplicando o Shape Up, metodologia usada no basecamp.com.

Este artigo não é sobre os motivos que me fizeram procurar outras formas de gerenciar nosso time de desenvolvimento, falei um pouco sobre isso em outro papo: Lidere como gostaria de ser liderado.

O objetivo aqui é compartilhar um pouco sobre como o Shape Up funciona, as minhas experiências aplicando-o e como tem melhorado nosso dia a dia. Não acredito que qualquer metologia seja a solução para 100% dos casos, entenda o seu cenário, faça os ajustes necessários e aplique.

No meio do ano de 2022 conheci o Shape UP através de um parceiro de desenvolvimento, muito provavelmente já descontente com o modelo atual aplicado, que até então era o Scrum, em janeiro de 2023, iniciamos a implementação dessa metodologia para gerenciar as atividades de desenvolvimento de produto.

Durante esse período, notei melhoras significativas em vários pontos:

1. Aumento de produtividade
2. Redução significativa de erros pós-deploy
3. Maior autonomia para os times de desenvolvimento
4. Aumento na previsibilidade de entregas

Mas sobre tudo, os aspectos mais importantes foram:

1. Aumento do estímulo à criatividade
2. Equipe de desenvolvimento com maior compreensão sobre a essência do nosso produto e dos nossos clientes
3. Qualidade de vida dos desenvolvedores
4. Redução drástica nos processos burocráticos

Mas o que é ShapeUp? e como funciona?

O ShapeUP é uma estrutura de gestão de projeto desenvolvida pelo Ryan Singer na plataforma basecamp.com, sido divulgada oficialmente em 2019 no livro Shape Up — Stop Running in Circles and Ship Work that Matters.

Se você quer ganhar um pouco mais de tempo resumirei para você, mas recomendo que leia na íntegra, valerá a pena.

No Shape Up há basicamente 4 etapas importantes que se interligam: qualquer membro da organização poderá criar Pitches descrevendo os problemas ou ideias (que surgiram nas últimas 6 semanas) durante a fase de Shape, esses pitches serão utilizando em um segundo momento durante a Betting Table onde a diretoria define quais pitches serão escolhidos e desenvolvidos no próximo ciclo de 6 semanas pelo time de programadores e designers. Após as 6 semanas de desenvolvimento o time de construção entra em uma fase de Cooldown, na qual programadores e designers decidem o que querem fazer, normalmente investem para estudos ou testar soluções que serão aplicadas no futuro.

1. Shape: etapa onde qualquer membro da empresa poderá se dedicar a estudar e descrever os problemas e soluções de uma ideia, com uma atenção máxima ao nível certo de abstração que as descrições devem ter.
2. Pitch: documento que detalha os problemas e soluções dos estudos realizados na etapa de Shaping. Este documento será usado tanto na fase de Betting como também será entregue aos desenvolvedores e designers na fase de construção.
3. Betting Table: momento em que a diretoria analisará os Pitchs apresentados e escolherá quais serão definidos no próximo ciclo de construção. Não há acúmulos de pitchs nesse momento, apenas os escritos nas últimas 6 semanas podem ser apresentados.
4. Build: durante um período de 6 semanas programadores e designers trabalharão (focados) para resolver os problemas descritos no pitch escolhido, eles criarão a solução de fato durante essa fase: interface, frontend, backend e outras demandas técnicas se necessárias.
5. Cooldown: fase com 2 semanas de duração na qual o time de desenvolvedores e designers param para respirar e trabalhar no que desejam, normalmente para resolver alguns bugs ou estudar alguma nova tecnologia aplicável ao projeto no futuro.

Continua sem interesse de ler na íntegra o restante desse artigo? Então dá uma olhada no livro e beba direto na fonte: Shape Up — Stop Running in Circles and Ship Work that Matters.

Entenda um pouco mais…

Ciclos de 6 semanas (Build)

No Shape Up a construção da solução propriamente dita (não estou falando apenas de código, este é uma parte da solução) fica a cargo da equipe de desenvolvedores e designers quase que exclusivamente (normalmente 1 designer e 2 programadores e 1 QA), em uma janela de tempo de 6 semanas, tempo suficiente para construir algo significativo e não tão longo para sentir o prazo se aproximando desde o início da construção.

Nesta fase, os membros da equipe assumem total responsabilidade por suas tarefas individuais, realizam ajustes necessários no escopo do projeto e distribuem as atividades entre si de maneira colaborativa, visando construir conjuntamente fatias verticais do produto.

Não contabilizamos horas nem questionamos como são gastos os dias individualmente. Não realizamos reuniões diárias. Não reconsideramos nossa rota a cada duas semanas. Nosso foco está em um nível mais elevado.

A integração entre designer e programadores, durante essa fase de descoberta e construção da solução é muito importante, ao invés de construir várias partes desconectadas, esperando a integração apenas no final, o time constrói uma peça significativa do trabalho de ponta a ponta desde o início, realizando a integração o mais cedo possível.

Para dar início aos trabalhos, a equipe de desenvolvimento recebe um projeto apresentado a eles por meio de um Pitch que é elaborado durante uma fase de modelagem denominada Shaping.

Pitch e Modelagem (Shape)

Esta é, sem dúvida, a etapa mais importante do Shape Up, ela é quem define o formato e conteúdo das informações que chegarão para o time de programadores e designers. O maior desafio é garantir que essas informações não sejam vagas demais nem muito concretas.

É importante saber o nível de detalhamento e abstração ideal a ser passada para o seu time de desenvolvimento, par garantir que seu time poderá ser criativo e autônomo.

1. Wireframes são concretos demais: isso não deixa espaço para criatividade dos designers e não garante a viabilidade técnica de desenvolvimento. E por mais contraintuitivo que seja, quanto mais específico, mais difícil de estimar, quando o escopo não é variável, a equipe não pode reconsiderar uma decisão de projeto que está custando mais do que vale.
2. Poucas palavras são abstratas demais: por outro lado, descrições curtas e sem detalhes podem também não funcionar. Não há informações suficientes para deixar o time livre para construir a solução sem ultrapassar os limites.

Em seu livro o Ryan usa um bom exemplo utilizando um conceito da engenharia elétrica para nos ajudar a entender o nível certo de abstração: um protoboad é um protótipo de engenharia elétrica que possui todos os componentes e fiação de um dispositivo real, mas nenhum projeto industrial.

Decidir incluir uma luz indicadora e um botão giratório é muito diferente de debater o material do chassi, se o botão deve ficar à esquerda ou à direita da luz, quão afiados devem ser os cantos e assim por diante.

Fat-marker vs Wireframe

Algo recomendado é o uso de Fat-markers para desenhar as possíveis soluções, isso permite uma maior flexibilidade e autonomia à equipe de designers sem influenciá-los nas decisões técnicas por trás de cada componente de layout, além de garantir maior celeridade no processo de modelagem do projeto.

Trabalhar no “nível de abstração” certo não apenas garante que avançamos na velocidade certa, mas também deixa esse importante espaço para a criatividade nos estágios posteriores.

Afinal, de forma prática, como modelar?

O livro aborda 4 tópicos importantes que devem ser considerados na hora de modelar o projeto:

1. Defina o problema e os limites: primeiro descobrimos quanto tempo vale a ideia bruta e descrever o problema. Isso nos dá os limites básicos do projeto.
2. Encontre a solução: depois vem o trabalho criativo de esboçar uma solução. Fazemos isso em um nível de abstração mais alto do que os wireframes, visando avançar rapidamente e explorar uma gama maior de possibilidades. O resultado desta etapa é uma ideia que resolve o problema, mas sem todos os detalhes resolvidos.
3. Aborde riscos e surpresas desagradáveis: quando achar que tem uma solução, chegou a hora de analisá-la com atenção para encontrar lacunas ou perguntas sem resposta que atrapalhem a equipe no futuro. Alteramos a solução, cortamos coisas ou especificamos detalhes em determinados pontos complicados para evitar que a equipe fique presa ou perca tempo.
4. Defina o que não quer fazer: finalmente se há algo que possa ser mal-entendido ou recursos que não devem fazer parte desse projeto é recomendado detalhar para evitar que os desenvolvedores percam tempo em recursos que não são realmente necessários.

Betting Table

Os famosos e gigantescos backlogs nos fazem perder tempo constantemente revisando, preparando e organizando ideias antigas, nos impedindo de avançar nos projetos oportunos que realmente importam no momento.

Backlogs intermináveis, nunca mais! basecamp.com/shapeup

É por isso que na Betting Table a diretoria define quais os projetos que serão desenvolvidos no próximo ciclo, mas com uma diferença que muda tudo: na “mesa” há apenas os pitchs escritos nas últimas 6 semanas, ou outros que foram reescritos intencionalmente, isso mesmo, não há acúmulos de tarefas que todos sabemos que nunca irão acabar, o famoso backlog.

E se algum pitch não for escolhido? Está tudo bem! Boas ideias sempre voltam, se em 6 semanas seu pitch continua sendo uma boa ideia, você poderá reescrevê-lo ou simplesmente defendê-lo novamente na próxima betting table.

Dessa forma a conversa é sempre fresca. Qualquer coisa trazida de volta é trazida de volta com um contexto, por uma pessoa, com um propósito. Tudo é relevante, oportuno e do momento.

Cooldown

Se realizássemos ciclos um após o outro, não teríamos tempo de respirar e pensar no que vem a seguir. Sendo assim, a cada 6 semanas existe um período de 2 semanas de “resfriamento”: período sem um trabalho programado.

Isso não significa que os programadores e designers ficarão inativos nessa fase. Após seis semanas de trabalho e a entrega do projeto, os desenvolvedores apreciam ter algum tempo sob seu controle. Durante essa etapa, eles têm a liberdade de se dedicar ao que desejarem, geralmente utilizando esse período para corrigir bugs, explorar novas ideias ou experimentar novas possibilidades técnicas.

Como estamos aplicando por aqui?

Como falei no início desse papo: “Não acredito que qualquer metologia seja a solução para 100% dos casos, entenda o seu cenário, faça os ajustes necessários e aplique”.

Nosso objetivo é alcançar o máximo que o Shape Up se propõe a ser em 2 anos, mas com a consciência que as adaptações do processo sempre irão existir, e tudo bem. Até lá temos um caminho de mudanças e aprendizados que sem dúvida alguma por si só já tem agregado bastante experiência à nossa equipe.

Adaptação do fluxo

A principal adaptação que fizemos por aqui até então foi encurtar o Ciclo de 6 semanas para 4 semanas, mantendo o período de Bet em 2 semanas mas o Cooldown em 1 semana. Acredito que essa é uma mudança temporária, tem sido um desafio e tanto convencer outros gestores acostumados com sprints de 2 semanas a termos um tempo de entrega um pouco mais longo, mas estou conseguindo, graças às mudanças positivas (algumas das quais já citei anteriormente), que tem ficado cada vez mais evidentes com o tempo.

Outro desafio importante é garantir que os programadores estejam focados e não sejam interrompidos durante a fase de construção da solução. Isso acontece principalmente devido a bugs que eventualmente aparecem (estamos aprendendo a lidar com eles), esse tem sido um papel meu particularmente: investigar ao máximo o problema até ter certeza de que ele realmente precisa ser resolvido com urgência e não pode esperar até o próximo ciclo.

Interrupções para implementar funcionalidades que não estavam previstas no ciclo aconteceram com certa frequencia nos 2 ou 3 primeiros meses mas isso foi mais fácil de resolver, depois de algumas conversas com outros membros do nosso time e a participação ativa dos programadores em nos mandar feedback sobre a situação facilitou o alinhamento entre todos.

Sobre o Shaping, como falei antes é umgrande desafio manter o nível de abstração ideal: as vezes vai descritivo demais (diminuindo o processo criativo dos desenvolvedores) e as vezes de menos (travando o desenvolvimento por falta de informação), estamos aprendendo e avançando.

O que eu não posso esquecer é o que me motivou a procurar outra forma de gerenciar meu time (falei um pouco sobre isso nesse outro artigo Equilíbrio desafiador entre a satisfação do cliente e o bem-estar do programador). E quem melhor para falar sobre o dia a dia dos nossos programadores se não eles mesmos? Rodar uma pesquisa a cada final de ciclo perguntando a opnião dos programadores não só sobre a experiência geral durante o ciclo mas especificamente sobre a qualidade dos pitches, o quão criativos eles precisaram ser e quão desafiador ele considerou o ciclo, tem nos ajudado a moldar cada vez melhor e no nível certo.

Espero que de alguma forma esse conteúdo possa te fornecer insights que melhorem o seu dia a dia e do seu time de tecnologia.

Vamos bater um papo a mais sobre isso? Me chama no linkedin.