Conceitos básicos do Shape Up

Recentemente participei de uma Officeless Class sobre Shape Up. Foi uma live de 1h40 sobre os principais conceitos e premissas e tirando dúvidas sobre o framework.

O Shape Up, pra quem não conhece, é o framework de gestão de produto da 37signals. É assim que produtos como Basecamp, HEY e Ruby on Rails foram e são construídos há mais de 20 anos. E como quase tudo por aqui, possui um olhar fora do convencional para problemas recorrentes. Gosto de pensar na metodologia como uma alternativa ágil ao Scrum, que de vez em quando parece não funcionar.

O legal de fazer essa live foi rever os conceitos básicos, compilar e buscar analogias para explicar as decisões de maneira mais leve em formato de apresentação. Gostei tanto do exercício que resolvi trazer pra cá por escrito.

Premissas

O Shape Up funciona em três momentos: Shaping, Betting e Building.

Além disso, existem algumas premissas básicas do Shape Up que mais os diferencia de outros frameworks ágeis que valem a pena serem destacadas:

→ Ciclos de 6 semanas

Trabalha-se em ciclos de desenvolvimento de 6 semanas. Por que? Por que meses são períodos longos demais para que se possa iterar um projeto e 2 semanas é curto demais para construir qualquer coisa significativa.

Seis semanas é o número mágico nesse caso. É “curto o suficiente” para que se possa iterar e também é “longo o suficiente” para que o time possa construir algo relevante.

→ Cooldown de 2 semanas

Entre os ciclos de desenvolvimento, existe um período de “cooldown” de 2 semanas. Esse período é importante para que o time de desenvolvimento tenha tempo para respirar entre projetos e iniciativas. Nesse momento resolvem-se débitos técnicos, refactors no código, resolução de bugs e projetos paralelos de melhorias no produto.

→ Pessoas certas para fazer o Shaping

Uma outra premissa importante é que se tenham pessoas no time dispostas a participar do processo de Shaping (mais detalhes logo mais). A questão é que o grupo que faz o Shaping precisa ser composto por pessoas com conhecimento técnico, criatividade, visão de produto ou da estratégia e “engenhenhosidade” de design para esboçar soluções. Dificilmente todas essas características vão estar presentes em uma mesma pessoa, por isso recomenda-se um pequeno grupo.

O trabalho de Shaping é bem diferente do trabalho de Building. E para isso, é importante ter as pessoas certas para o trabalho. Como veremos ao longo do texto, Building se assemelha muito ao track de delivery no famoso ”dual track” de Marty Cagan.

→ Betting Tables

As Betting Tables são cerimônias que acontecem em paralelo ao período de Cooldown para que seja decidido o que será construído pelos times no próximo ciclo de 6 semanas.

→ Times pequenos e com autonomia (~3 pessoas)

Os times que trabalham os ciclos são muito pequenos. Preferimos times pequenos por diversos motivos e buscamos trabalhar com times de 2 a 3 pessoas. Esses times são compostos exclusivamente pelas pessoas responsáveis por construir o produto. No nosso caso, designers e desenvolvedores. Buscamos dar o máximo de autonomia para que essas pessoas possam ditar os rumos de desenvolvimento das soluções.

Disclaimer: Aqui na 37signals designers também desenvolvem front-end.

Shaping

Shaping é o ato de “modelar” um pedaço de trabalho (melhor tradução que consegui). Esse nome é dado por que começamos com uma demanda, sugestão ou ideia e o que buscamos aqui é “modelar” esse trabalho para transformá-lo em algo que pode ser passado para um time trabalhar em cima.

Shaping é sobre atingir o nível de abstração correto. Na maioria das vezes Product Managers erram o nível de abstração de seus escopos e passam para os times de desenvolvimento algo muito concreto ou muito abstrato.

Trabalho muito abstrato, como um documento somente com palavras e requisitos imaginados, pode levar o time a caminhos tortuosos, imprevistos e rabbit holes desnecessários. Além de correr o risco de não refletirem o que de fato se espera que seja construído.

Em contraponto, trabalho muito concreto, como um wireframe, dá muito pouca margem para adaptação e mudança de escopo, deixando o time refém de uma solução fechada para o problema inicial. Isso é ruim por que o time não consegue mudar de curso durante o desenvolvimento para se ater ao prazo inicial.

O trabalho de Shaping consiste em transformar uma ideia ou algo completamente abstrato em um documento que chamamos de Pitch contendo tudo que o time precisará para realizar aquele projeto com sucesso. Um Pitch é passado a um time no início de um ciclo para que possam construir uma solução.

Betting

Betting é o processo de decisão do que será trabalhado nos ciclos. Como dito anteriormente, acontece enquanto os times estão em cooldown. Durante uma Betting Table, todos os Pitches elaborados nas 6 semanas anteriores são avaliados e discutidos pelos stakeholders para que se decida o que será passado para o time.

Chamamos essas decisões de Bets — ou apostas em Português — para sermos lembrados de que o trabalho tem ganhos esperados, exige comprometimento prévio e pode incorrer em prejuízos. Essas são caracteristicas de apostas na vida real.

Quem participa das Betting Tables geralmente são os principais stakeholders e lideranças da companhia. Aqui na 37signals esse comitê é formado pelo CEO, CTO, Head de Estratégia de Produto e mais um programador sênior.

As principais perguntas feitas durante esse processo são:

• Esse problema é importante?

• Nosso apetite está certo?

• A solução é atraente?

• Esse é o melhor momento?

• O time certo está disponível?

Building

A etapa de Building talvez seja a que precise de menos explicações. É onde os times que estão trabalhando nos ciclos vão passar 6 semanas construindo o produto. Ainda assim, existem algumas formas interessantes como encaramos a melhor forma de lidar com a construção de produtos.

O primeiro ponto é que como você deve ter notado, o que é passado para os times são Pitches, ou seja, projetos inteiros e não tarefas. Não existe uma figura intermediando o entendimento do projeto e da solução e as tarefas que serão realizadas para construir o software em questão. Os próprios times são estimulados a ganharem entendimento sobre o problema e a solução a ponto de pensarem qual é a melhor forma de dar vida a elas.

Acreditamos que o deseconhecido tem um papel muito grande no desenvolvimento de software. Nesse caso, a melhor forma de descobrir o trabalho que deve ser feito é trabalhando. Na teoria é perfeitamente plausível listar todas as tarefas que precisam ser feitas na construção de uma feature. Na prática, acabamos descobrindo grande parte delas enquanto estamos no processo de construção.

Outra crença importante é de que a melhor forma de se obter progresso dentro do escopo de um projeto é construindo “pedaços” dele que funcionem.

Podemos pensar nos projetos em duas camadas: front-end e back-end ou design e código. O que queremos é escolher um pedaço do projeto para integrar de uma vez. Com isso, o time vai ter algo tangível para provar que funciona (ou não e reconsiderar). Qualquer pessoa vai poder clicar em algo real e testar seu comportamento.

Acabou que esse texto ficou um pouco maior do que eu imaginava. No futuro pretendo escrever sobre as analogias e explorar mais a fundo alguns dos princípios fundamentais do Shape Up como Estimativas vs Apetite, ou ferramentas como Hill Charts e Fat Marker Sketches.

Espero que tenha ajudado a entender um pouco do funcionamento básico do framework ou pelo menos aguçado a curiosidade. Para saber mais, recomendo a leitura do livro original (em breve em Português).

Se quiser trocar ideias sobre Shape Up ou está buscando implementá-lo no seu time, me manda uma mensagem que vou adorar conversar.

Happy Shaping!