Relatório de atualização: Testando a metodologia 'Shape Up' do Basecamp

No ano passado, tentei mudar minha equipe de produto da abordagem clássica SCRUM para a metodologia Shape Up do Basecamp. Foi uma experiência incrível; Aprendi muito com isso e pensei em compartilhar algumas de minhas descobertas com você.

Se você já experimentou, adoraria saber como foi. Se ainda não o fez, adoraria saber por que você ficou longe.

Parte 1: Por que moldar?

Minha equipe usa SCRUM desde sempre. Durante nossos dias de startup, vivíamos os ciclos tecnológicos clássicos: trabalhar rápido, entregar e não pensar muito nos processos. Então, fomos adquiridos.

Assim que tive um pouco mais de tempo para considerar nossas opções de metodologia de produto, decidi experimentar o Shape Up. Houve alguns motivos:

1. Até então, estávamos tentando sprints de 2 semanas e falhando consistentemente em terminá-los. Cada semana parecia uma esteira rolante de ingressos que nunca conseguiríamos terminar.

   
   

2. A equipe parecia macacos de código. Escolha o ingresso. Bilhete de trabalho. Entregar ingresso.

   
   

3. Como nunca terminamos o sprint, as tarefas sempre passavam para o próximo. Eventualmente, a barragem rompe.

   
   

4. Todos nós faltou foco. Cada sprint foi uma seleção e combinação de coisas para trabalhar em toda a base de código.

   
   

5. Muito pouco trabalho em equipe. Cada desenvolvedor trabalharia em seu pequeno pedaço do bolo, deixando pouco espaço para aprender uns com os outros e, francamente, um senso de comunidade.

   
   

6. Quase nenhuma compreensão do cliente. Os desenvolvedores pegariam os tickets atribuídos, os realizariam e não teriam ideia de por que/quem/o quê.

Depois de reler A evolução do Basecamp , pensei em tentar, pois afirmava resolver a maioria desses problemas.

Parte 2: lançando internamente

Uma das partes mais difíceis de mudar para o Shape Up foi apresentar a ideia internamente.

Passei um tempo extra internalizando a maioria dos conceitos do Shape Up para garantir que estava pronto para qualquer dúvida. Não é novidade que os desenvolvedores adoraram a ideia dessa nova abordagem (mais tempo, mais foco, mais colaboração; por que não adorariam!).

Também sem surpresa, a hierarquia foi mais reticente. No final das contas, consegui convencê-los:

1. Garantindo que fosse apenas um teste. Se as coisas não dessem certo, voltaríamos ao 'normal'.

   
   

2. Garantindo que eu permaneceria tão disponível como sempre para ajudá-los. Os desenvolvedores seriam focados e ininterruptos, mas eu não.

   
   

3. Destacar o Shape Up permite-nos resolver problemas maiores, o que significa oportunidades maiores.

   
   

4. Insistir na dor que o produto está vivenciando atualmente e como isso afeta cada equipe.

Preparei uma apresentação de slides muito clara e analisei cada chefe de departamento (atendimento ao cliente, vendas e diretoria).

Parte 3: Medos e Preocupações

Minha experiência como fundador, profissional de marketing e gerente de produto me ensinou que sempre vale a pena anotar as preocupações antes de iniciar um experimento. Eu tive alguns com Shape Up:

• Como lidamos com as distrações? Eu sei que devo 'dizer não'. 'Estamos ocupados.' 'No próximo ciclo, podemos investigar isso.' Essa é a teoria, e funciona se toda a empresa aderir a essa metodologia. Durante meu primeiro ciclo de teste, fiquei preocupado que uma emergência surgisse.

• Atrasos? O Shape Up recomenda não haver pendências (capítulo 7). Como estávamos apenas testando isso, obviamente não fui cmd+a+delete nosso backlog, mas ainda assim. Se adotássemos essa metodologia, eu me sentiria um tanto perdido sem atrasos.

• 'Quase terminado.' Este realmente me assustou. O que acontece se chegarmos ao final do ciclo de 6 semanas e estivermos lá, mas ainda não? Basecamp diz 'começar de novo' (a menos que você esteja muito perto). Eu estava preocupado que erraríamos o alvo na irritante faixa de 20-30%.

Em última análise, nenhum destes medos/preocupações poderia impedir-me de prosseguir com o julgamento. Valeu a pena mantê-los em mente, no entanto.

Parte 4: O Ciclo

E partimos!

Comecei o primeiro ciclo numa segunda-feira de manhã, com seis semanas de intenso foco e trabalho em equipe. Aqui está um resumo do que aconteceu a cada semana:

• Semana 1 : Início e... silêncio. Deixar a equipe em paz, deixá-los pesquisar e mergulhar no código em seu próprio tempo são uma parte importante desta metodologia. Foi incrivelmente difícil para mim desistir durante a primeira semana e não pedir atualizações. Eu me segurei forte!

• Semana 2 : A equipe finalmente saiu da concha. A comunicação foi captada. O design do trabalho começou a aparecer, pude dar feedback e trabalhar em conjunto.

• Semana 3 : Em teoria, a semana 3 deveria ser o topo da curva do ciclo. No final, a equipe deverá ter uma boa ideia de como construirá o que precisa ser construído. Criamos um canal Slack específico para o ciclo à medida que a comunicação começou a aumentar adequadamente. No final daquela semana, vimos protótipos, designs, trechos de código e muito mais. Estávamos no caminho certo!

• Semana 4 : Silêncio novamente. Todas as idas e vindas da semana 3 produziram uma semana 4 focada, à medida que todos implementavam seu trabalho. Demos início a um 'mostre e conte' na sexta-feira.

• Semana 5 : Semana da bola curva. Um dos escopos começou a gerar bastante conversa. Rapidamente ficou claro que o escopo não era suficientemente claro. Eu não fui suficientemente preciso em minhas exigências, e o que inicialmente parecia agradável e simples acabou se tornando complexo. Tive que tomar a difícil decisão de cortar esse escopo.

• Semana 6 : Os escopos restantes estavam funcionando bem. A intensidade aumentou drasticamente na semana 6, enquanto eu fazia o controle de qualidade em todos os lugares, e os desenvolvedores repetiam meu feedback com uma rapidez incrível; estávamos todos nos unindo para alcançar a meta.

  
  

No final, atingimos o alvo. Conseguimos! Foi super intenso e fiquei arrasado por termos que cortar uma das miras, mas conseguimos.

Na segunda-feira seguinte, às 10h, entramos em produção.

Parte 5: Algumas Lições

Sem nenhuma ordem específica, aqui estão algumas lições e recomendações:

1. Moldar é difícil . Achei que tinha feito um trabalho decente moldando a maioria das partes assustadoras do ciclo. Acontece que perdi algo flagrantemente óbvio que quase atrapalhou todo o ciclo.

   
   

2. Inclua sua equipe durante a modelagem . Eu o moldei principalmente sozinho e, às vezes, com o líder da minha equipe de desenvolvimento. Teria sido valioso para mim incluir outros desenvolvedores.

   
   

3. Se você estiver discutindo ou moldando o meio do ciclo, algo deu errado . Pare tudo. Sua prioridade é descobrir isso antes que atrapalhe completamente todo o resto.

   
   

4. A intensidade não é distribuída uniformemente . Seja entre os membros da equipe ou ao longo do ciclo, a intensidade do trabalho vai variar muito. Como PM, é sua função identificar esses focos de intensidade e prestar atenção especial aos indivíduos que passam por eles.

   
   

5. Crie um canal separado do Slack . Tornou a comunicação muito mais fácil, mas também muito mais divertida. A equipe do ciclo desenvolveu rapidamente uma linguagem compartilhada, memes relacionados ao trabalho em que estávamos trabalhando e assim por diante. Basicamente parecia ser uma startup dentro da equipe.

   
   

6. Implemente reuniões de mostrar e contar a partir da semana 1 . Esperamos muito para fazer isso. Deve haver o suficiente para mostrar ou discutir a partir do final da semana 1. É também uma oportunidade para encontrar, discutir, aprender, etc.

   
   

7. O período de espera acabou sendo muito mais difícil que o próprio ciclo . Todos os “outros trabalhos” acumularam-se durante 6 semanas; foi como voltar ao SCRUM. Isso é algo que ainda estou trabalhando para melhorar.

Como você provavelmente pode perceber, fui vendido por este teste.

Implementar o Shape Up e adotar suas peculiaridades certamente não acontece da noite para o dia. Suspeito que será um longo processo de aprendizagem. Apreciei particularmente a mudança de mentalidade que este ensaio nos permitiu. Nós (e as outras equipes, espero) aprendemos a ver o trabalho como ele é: um desafio emocionante que superaremos juntos.

Se você já testou isso (ou não), adoraria ler algumas histórias ou comentários!

Se você gostou deste post, você pode gostar do meu boletim informativo . Escrevo sobre gerenciamento de produtos, compartilho insights práticos e enfrento desafios de produtos da vida real para me divertir (eu sei, certo?).