Processo Foco & Fôlego para desenvolvimento de produto

Ciclo de 6 semanas de Foco e Ciclo de 2 semanas de Fôlego

v0.1.49— Última modificação: 03/07/2020 às 16h20.

Nova versão

05/03/2021: Uma nova versão alterada e simplificada do processo utilizando padrões de linguagem foi publicada no link abaixo:

Processo Foco & Fôlego atualizado e simplificado

Este texto abaixo descreve um processo inspirado e derivado do Shape Up da Basecamp (recomendo a leitura) , empresa remota com mais de 15 anos de mercado, e também de ideias do Triple Track Agile para tentar minimizar alguns dos desafios que percebo nos processos de desenvolvimento de produto que impactam nos resultados, foco e engajamento das pessoas.

A intenção do texto NÃO é descrever algo que sirva pra qualquer situação — one-size-fits-all — e nem fazer alguém acreditar que esse processo resolva todos os problemas ou é melhor do que qualquer outro processo e metodologia por si mesmo.

Tudo depende do contexto.

O que vai ajudar você a justificar o experimento com esse processo é saber como — e se — esse processo pode te ajudar nos desafios atuais.

Não copie e cole sem entender como as coisas funcionam atualmente em sua empresa e sem adaptar pro seu contexto.

Processo é uma ferramenta, e como tal devemos aplicar o processo certo ao problema certo.

Desafios atuais

Esses são alguns dos desafios que percebo atualmente ao apoiar organizações:

• A discussão para saber qual o próximo OKR demanda um bom investimento de tempo e negociação, sem garantia de ter um alinhamento e desenvolvimento efetivo. Por vezes, se torna mais crítico: a discussão é feita num prazo curto de tempo e há uma dificuldade para conseguir alinhar todos os objetivos entre os times com os OKRs globais.
• As empresas aprenderam a copiar o nome “squads” mas no sabem como se organizar.
• Times em Delivery desenvolvem histórias pequenas e nem sempre conseguem entregar valor que gerem resultado em 2 semanas de sprint — tempo comum em times que usam Scrum;
• Planejamentos de entrega de produto para algumas semanas acabam se tornando projetos de meses sem fim.
• A formatação de iniciativas de produto e validação por vezes é pulada ou feita às pressas para permitir que o time tenha qualquer coisa em Delivery. O investimento de tempo e atenção acontecem na maior parte do tempo em Delivery;
• As Product Managers e Product Designers investem muito tempo em Delivery e pouco tempo em Discovery ou em formatação de iniciativas formatadas com riscos mitigados;
• Times se sentem numa correria constante;
• Pessoas em Delivery são surpreendidas com riscos críticos não previstos e mitigados, perguntas importantes não respondidas e falta de informações que comprometem a entrega delas dentro do período, forçando-as resolver sozinhos e tomando boa parte de seu tempo, ou tendo que manter uma discussão sem fim com PMs e PDs, ou fazendo histórias voltarem para o backlog;
• Times em Delivery nem sempre têm uma visão do todo: fazem pequenas histórias ou tarefas mas não sabe como isso se encaixa no final ou o que resolverão no final.

Benefícios em potencial do processo:

• Tempo para definir o problema/oportunidade a resolver no próximo ciclo, aprofundar no Problem Space e fazer Discovery de próximas iniciativas;
• Iniciativas formatadas permitindo que o Delivery sofra menos com imprevistos que impossibilitem as entregas;
• Iniciativas com apetite previsto de quanto tempo investirá para implementá-la completamente. Sem mais iniciativas que duram meses e nunca terminam. Os Ciclos para Foco são para entregas completas;
• Maior tempo para foco, sem grandes interrupções e com menos reuniões;
• Trabalho mais assíncrono para permitir trabalho distribuído com menos microgerenciamento e mais tempo para trabalho aprofundado;
• Tempo para fôlego, onde acontecem reuniões, práticas, aprendizados, manutenção de sistemas e projetos paralelos;
• Cada papel existente no time de produto sabe qual é o seu escopo de atuação;

Tópicos

• Processo Foco e Fôlego
• Ciclo de Foco: 6 semanas
• …Potenciais benefícios do Ciclo de Foco
• …Trilhas de Problem Space e Discovery
• …Trilha de Delivery
• Ciclo de Fôlego: 2 semanas
• …Primeira semana do Ciclo de Fôlego
• …Segunda semana do Ciclo de Fôlego
• Rituais para experimentar ao longo de todos os Ciclos
• Apêndice
• …Quais empresas utilizam esse tipo de ciclos?
• …Como iniciar o experimento com esse processo?
• …Como iniciar o processo com um produto novo que ainda não foi lançado?
• …Como usar o processo em um lançamento de produto?
• ...O que fazer quando ainda não tenho iniciativas para Delivery
• …Iniciativas de melhorias ou suporte
• …Variações dos times que participam nas trilhas
• …Curiosidade: Modelo Spotify e Shape Up
• …Comparação com a estrutura de times da Basecamp
• …Pesquisa de engajamento
• Observações sobre linguagem e termos utilizados no texto
• Outras referências

Processo Foco & Fôlego

O processo Foco & Fôlego é constituído de:

• Ciclo de 6 semanas para Foco
• Ciclo de 2 semanas para Fôlego

Estratégia (🏗️ em construção):

• Efetividade e resiliência em vez de produtividade máxima constante.
• Período de tempo fixo acima de escopo fixo.
• Apostas sob demanda acima de planos futuros.
• Auto-organização, alinhamento, autonomia e transparência acima de controle e gerenciamento externo.
• Propósito e estratégia acima de metas.

O que esse processo intencionalmente não utiliza:

• 🚫 OKRs. Os times — e a organização — serão alinhados por propósito e estratégia. A cada ciclo de foco haverá iniciativas completas entregues, continuamente. Métricas ainda serão úteis para acompanhamento do escopo de cada produto. Nada impede de você adaptar com OKRs.

Será que sua empresa realmente precisa de metas? E se você descobrir que não?

• 🚫 Backlog e Roadmap: dada a situação dinâmica e complexidade do mundo, somadas à impossibilidade de fazer previsões de médio-longo prazo que realmente funcionem na realidade, esse processo prevê como alternativa um período de descobertas e de apostas de iniciativas para ciclos seguintes. É possível utilizar um roadmap de temas com três blocos em vez de datas para separá-los: agora, depois e algum dia.

Ciclo de Foco: 6 semanas

Vivemos num tempo em que os locais de trabalho têm se tornado cada vez mais um local de distrações e improdutividade, seja no escritório físico quanto em ferramentas digitais. Com o trabalho remoto, muitas empresas replicaram esse cenário ou até pioraram.

As pessoas têm dificuldade em ter tempo sem interrupção para um trabalho aprofundado e concentrado. Há muitas reuniões, conversas e projetos paralelos. Se o assunto te interessa, veja o vídeo “Porque não se trabalha no trabalho” do CEO da Basecamp, Jason Fried.

Paul Graham — escritor, desenvolvedor e investidor, distingue as reuniões das pessoas que gerenciam e das que fazem o trabalho em seu texto Maker’s Schedule, Manager’s Schedule. Para quem gerencia, a reunião parece fazer parte do trabalho: é só ter um pequeno espaço na agenda que ela atua no que precisa.

Já para quem de fato faz o trabalho, o bloco de tempo em geral precisa ser ao menos uma metade de um dia para conseguir se concentrar e realizar o que precisa. Horas quebradas não permitem nem começar o trabalho.

Quando você está operando conforme o cronograma de quem faz o trabalho, as reuniões são um desastre.

— Paul Graham

Apesar de muitas startups estarem utilizando Scrum com sprints de 2 semanas — podendo variar o período — muitas reuniões síncronas extras acontecem no meio do caminho, as especialidades dos times acabam tendo que participar de projetos paralelos aos seus times de produto e o tempo dedicado para foco e entrega passam longe. Além disso, as reuniões de refinamento, planejamento e outras em períodos curtos de tempo também podem tornar o tempo escasso.

Considerando esse contexto a intenção desse Ciclo é criar um período maior para Foco.

Aqui teremos três trilhas em paralelo:

1. Aprofundamento de Problem Space
2. Formatação + Discovery (um ciclo à frente)
3. Delivery

Potenciais benefícios do Ciclo de Foco

Menos mudança de contexto e menos tempo perdido (1, 2)

• mesmo breves bloqueios mentais criados pela troca de tarefas podem custar até 40% do tempo produtivo de alguém, de acordo com Meyer e outros pesquisadores.
• após uma interrupção, demora em média 25 minutos para retornar à tarefa original, de acordo com Gloria Mark.

No texto Multitasking: Switching costs é dito que “a realização de mais de uma tarefa por vez, especialmente mais de uma tarefa complexa, afeta a produtividade. Embora isso não deva surpreender quem fala ao telefone enquanto verifica e-mail ou fala ao celular enquanto dirige, a extensão do problema pode ser um choque. Psicólogos que estudam o que acontece com a cognição (processos mentais) quando as pessoas tentam realizar mais de uma tarefa por vez descobriram que a mente e o cérebro não foram projetados para multitarefas de tarefas pesadas. Os psicólogos tendem a comparar o trabalho à coreografia ou ao controle do tráfego aéreo, observando que nessas operações, como em outras, a sobrecarga mental pode resultar em catástrofe”.

Menos sobrecarga cognitiva

No texto “That Stress You Feel? It’s A ‘Mental Load’ Of Invisible Work That Needs Talking About”, a autora diz que “a carga mental é a soma total de responsabilidades que você assume para gerenciar ‘a lembrança das coisas’”.

Estar ativo em mais de um projeto por vez que demanda constante atenção, não favorece o nosso foco e aumenta nossa carga mental, podendo prejudicar nosso desempenho.

Mais concentração e prazo determinado

A visão em túnel, muitas vezes lembrada de forma prejudicial por ser um hábito ou tendência de apenas vermos ou focarmos em uma única prioridade, enquanto negligenciamos ou ignoramos outras prioridades importantes, pode ser utilizada a nosso favor para um foco estreito ou exclusivo em uma única iniciativa.

No livro UpStream o autor Dan Heath fala sobre isso:

A primeira coisa a perceber é que “criar urgência” consiste basicamente em cooptar o poder do tunelamento para o bem. Em vez de tentar escapar do túnel — como ocorre com a discussão sobre folga, podemos tentar usar o foco extremo que ele fornece em nossa vantagem. Quem não foi mais produtivo — e mais motivado — ao declarar uma data limite (deadline)? Um prazo fornece urgência artificial a uma tarefa. […] À medida que o prazo se aproxima, você acaba descartando todo o resto e fazendo o que é preciso ser feito (get it done).

Em vez de ser um período aberto sem expectativa de alguma entrega, aqui as expectativas são alinhadas e há o comprometimento com a entrega da iniciativa.

O período definido de 6 semanas beneficia para criar uma urgência saudável que favoreça tomada decisões e adaptação do escopo.

Qual o motivo para a escolha de 6 semanas?

Ryan Singer, estrategista de Produto da Basecamp e autor do livro ShapeUp, diz que “seis semanas são longas o suficiente para criar algo significativo do início ao fim e curto o suficiente para que todos possam sentir o prazo se aproximando desde o início, para que usem o tempo com sabedoria”.

Apesar de não acreditar que esse número tenha algo de especial, o período de 6 semanas parece razoável em sua proposta. Nada impede de você experimentar com outro período.

Trilhas de Problem Space e Discovery

A trilha de Problem Space é uma fonte de conhecimento mais estável e pode ser mantida por Product Managers (PM), Product Designers (PD) e/ou Researchers.

Já a trilha de Discovery, pode ser mantida pela Product Manager (PM), Product Designer (PD) e Tech Lead (TL).

Inicialmente a PM propõe quais Problemas deseja resolver ou Oportunidades deseja atender no próximo Ciclo de Foco.

Para chegar nessa proposta, ela terá algumas responsabilidades:

• Garantir alinhamento com o propósito e estratégia do time e empresa;
• Consulta ao conhecimento já registrado do Problem Space;
• Análise de oportunidades de negócio;
• Análise de insights qualitativos e quantitativos com a solução atual;
• Análise de demanda de arquitetura de sistemas (design ou código).

Garantir alinhamento com propósito e estratégia

A autonomia e agilidade do time se dará através do alinhamento com o propósito e estratégia do time e empresa. As decisões de produto serão feitas dentro desses limites.

Estudo do Problem Space

Além de consultar o material disponível sobre o Problem Space, se a PM percebe que há perguntas em aberto que desejaria explorar ou ela tem algumas hipóteses em mente, esse é um momento de aprofundar no Problem Space e convidar a PD para rodar essa trilha com ela, fazendo entrevistas e pesquisas.

A ideia é tentar enxergar quais necessidades são importantes para o público-alvo, indepentente da solução atual, e que ainda exige muito esforço pra se resolver com todas soluções atuais que as pessoas precisam juntar pra realizar um Job. Aqui podem aparecer oportunidades interessantes.

Análise de oportunidades de negócio

Além de todo conhecimento que já exista sobre o Problem Space, é possível que existam também oportunidades de negócios não previstas lá, como por exemplo uma expansão para outras regiões e países.

É importante estar bem alinhada com a área de negócios, operações e marketing para ter noção das oportunidades.

Análise de insights qualitativos e quantitativos

Nessa parte a ideia é vasculhar insights que possam ter sido colhidos ao longo da existência do produto. Onde há mais fricção e dificuldade no uso da solução?

Análise de demanda de arquitetura de sistemas (design, dados ou código)

A consulta a líderes de áreas ou especialistas é importante para saber que tipo de demanda crítica há sobre a arquitetura dos sistemas. Há algo que precisa se tornar uma iniciativa? É algo que poderá ser feito apenas por um time ou precisará de esforço conjunto?

Definição do Problema

Agora sim, já há insumo o suficiente para realizar uma proposta de quais os Problemas deseja resolver no próximo Ciclo e confirmá-los consultando líderes e stakeholders, e contando com o apoio de PD e TL.

Após confirmação da proposta, o trio — PM, PD e TL — entra em fase de ideação. Stakeholders podem ser envolvidas nessa ideação.

Em seguida elas começam a formatação de iniciativas.

Formatação de iniciativas

Dentre várias coisas, a formatação de uma iniciativa descreve:

• o problema;
• nível de confiança de resolução do problema;
• o apetite — veja mais abaixo;
• nível de confiança de implementação no apetite;
• a solução bruta em nível macro e como tudo se conecta — não quebrará e descreverá tarefas detalhadas para Delivery, pois isso será feito ao iniciar a trilha de Delivery;
• decisões sobre riscos previstos;
• fronteiras: o que está e o que não está no escopo da iniciativa (quais casos irá cobrir ou não).

Você pode consultar o guia rápido para formatação de iniciativas para ver mais detalhes.

É necessário garantir que qualquer pergunta em aberto, que possa impactar no desenvolvimento, tenha sido respondida e que qualquer interdependência também tenha sido resolvida antes de um comprometimento para o próximo Ciclo de Foco que acontecerá o Delivery. Por isso a fase de formatação de iniciativas é extremamente importante.

As iniciativas não conterão detalhes de implementação pois esse tipo de decisão está na responsabilidade e autonomia das pessoas que focarão em Delivery.

Veja alguns exemplos de como a Basecamp descreve suas iniciativas:

• The next cycle: Blackburn (Sep 19 — Oct 28)
• Pitch: Making a move a move

Exemplo extraído do Twitter do Ryan: https://twitter.com/rjs/status/1120765677680386050/photo/1

Definição do apetite

Sabendo qual o problema deseja resolver, vocês informam o quanto de tempo estão dispostas a arriscar para implementar uma iniciativa. Chamamos isso de apetite.

Isso incentivará tomada de decisões críticas e flexibilização do escopo para uma solução que caiba dentro desse apetite.

Para facilitar, restrinja o apetite em duas opções: 2 semanas para pequenas iniciativas onde coisas pontuais podem ser agregadas para serem realizadas como uma iniciativa nesse período ou 6 semanas para iniciativas completas e maiores.

Se uma iniciativa (ou um conjunto de coisas) ganha um apetite de apenas 2 semanas, então ela é somada com outras iniciativas de 2 semanas até que totalize 6 semanas para participar do Ciclo de Foco completo com outros times da empresa.

Níveis de confiança

Determine os níveis de confiança da iniciativa resolver o problema e dela conseguir ser implementada dentro de um apetite. Você pode utilizar um intervalo de confiança de 0 a 100% com intervalos de 10 (0, 10, 20, 30, etc), por exemplo.

Ao medir nível de confiança, você demonstra que não é mais questão de estar certa ou errada, mas de quanto de informações há para dar precisão às apostas.

Te apoiará na decisão de quantas pesquisas e validações considera necessárias e ajuda saber qual adaptação será necessária no escopo.

Pesquisas e validações

Após reflexão sobre níveis de confiança, é tomada a decisão sobre realizar validações das iniciativas nos riscos que elas levantam.

As validações podem gerar insights e novas perguntas a serem respondidas, tanto com novas validações, aprofundamento do Problem Space ou lançamento para usuários beta.

Apesar de ser tentador validar tudo que for possível, tenha cuidado assim como o cuidado de implementar tudo sem validação.

Validações custam tempo e dinheiro, e nem sempre garantem qual será a resposta do mercado ao utilizar o produto em um contexto real.

Além disso há iniciativas que serão realizadas com conhecimento prévio do assunto (negócios, tech e design) e com riscos baixíssimos.

Tudo será uma aposta. Avalie caso a caso.

Telas / UI

Se o trio já validou algumas possíveis soluções, possivelmente já terá parte das UIs prontas.

Vocês podem decidir por avançar para completar todas UIs necessárias ainda em Discovery.

Porém, pode acontecer de não terem tempo suficiente e por isso podem decidir utilizar parte do próximo Ciclo de Foco no qual acontecerá o Delivery das iniciativas para finalizar as UIs. Tratarei sobre isso ao falar de Delivery mais abaixo.

Atualização dos níveis de confiança

Após pesquisas e validações realizadas, é momento do trio atualizar os níveis de confiança de (1) resolução de problema e de (2) implementação dentro do apetite para facilitar a aposta.

O que esperar no fim do Ciclo de Foco nessa trilha?

• Proposta de Problemas a resolver + Iniciativas formatadas e validadas;
• Desenvolvedoras cientes das iniciativas propostas;
• POTENCIALMENTE: UI com principais partes prontas para desenvolvedoras utilizarem.

Adaptações

Acompanhamento da trilha de Discovery pelo time inteiro (assincronamente)

• Compartilhamento assíncrono em uma ferramenta digital sobre novas descobertas de pesquisas e validações.
• Todas iniciativas se mantêm disponíveis em uma ferramenta digital que permita e favoreça o acesso do time inteiro — isso inclui também as pessoas que estão focadas no Delivery. A ideia é permitir que qualquer pessoa possa consultar e discutir as iniciativas e os critérios a qualquer momento, assincronamente.

Desenvolvedora em Discovery

De forma rotativa a cada Ciclo de Foco, convide uma — ou mais — desenvolvedora para representar as demais desenvolvedoras e apoiar nas trilhas de Problem Space e Discovery. Ela também pode apoiar as desenvolvedoras em Delivery quando não tiver algo pra realizar em Discovery.

Trilha de Delivery

Nessa trilha, as desenvolvedoras realizarão o desenvolvimento e entrega das iniciativas selecionadas para o atual Ciclo de Foco.

Em vez de todas desenvolvedoras dividirem histórias e tarefas pequenas entre si ou todas atuarem na mesma iniciativa, a proposta é dividir as desenvolvedoras em sub-times de 2 a 3 pessoas.

Cada sub-time ficará responsável por uma iniciativa completa dentro das 6 semanas. Com isso as desenvolvedoras conseguem ter a visão do todo e tomar decisões necessárias para a entrega.

Elas terão tempo contínuo sem grandes interrupções para se coordenarem e decidirem juntas como realizarem as iniciativas.

Ao ter mais de uma pessoa por iniciativa, é importante definir qual desenvolvedora será a líder da iniciativa em Delivery.

A PD ainda estará envolvida e dando suporte aos sub-times de desenvolvedoras em Delivery:

• caso a UI já esteja definida, a PD estará disponível para tirar dúvidas, adaptar para casos não previstos ou adaptar por questões tecnológicas.
• caso a UI não foi definida a tempo no Ciclo de Foco anterior, a PD estará envolvida para criação da UI das iniciativas nesse início.
• ou, a PD pode trabalhar em Delivery durante todo o ciclo. Para essa alternativa, leia também o tópico [Product Designer trabalhando junto com desenvolvedoras em Delivery] no Apêndice do texto.

A ideia é que nos primeiros dias do Ciclo, as pessoas em Delivery:

• Comecem por algo central e importante. Primeiro, descubra o que é central e importante da solução. Segundo, deve ser algo pequeno. Terceiro, deve ser algo novo que nunca fizeram antes.
• Mapeiem os escopos. Divida a iniciativa em escopos. De acordo com Ryan Singer, “os escopos refletem as partes significativas do problema que podem ser concluídas de forma independente e em um curto período de tempo — alguns dias ou menos. Eles são maiores que tarefas, mas muito menores que o projeto geral”.

Recomendo a leitura sobre o assunto no capítulo Map the Scopes do livro Shape Up com informações mais aprofundadas.

Imagem do livro ShapeUp representando o mapeamento de escopos de um projeto

Kickoff

Os sub-times de cada iniciativa fazem seus próprios encontros iniciais para alinharem entendimento e tirarem dúvidas (1h-2h). Posteriormente, se necessário, as pessoas podem abrir uma discussão assíncrona na plataforma digital mencionando e envolvendo PM, PD ou TL.

É responsabilidade da PM, PD e TL estarem acompanhando as discussões pós-kickoff para apoiarem os sub-times.

É importante que o escopo da iniciativa possa ser adaptado, conforme questões e necessidades do sub-time, para que as pessoas consigam se comprometer com a entrega.

É importante um alinhamento com a PM, PD e TL sobre as adaptações necessárias.

Não é necessário reunião para fazer estimativa ou criar tarefas

As tarefas são criadas de forma assíncrona nos primeiros dias de trabalho do Ciclo, descobrindo os escopos e quebrando em novas tarefas, conforme vão realizando outras.

O trabalho a ser feito é descoberto conforme se coloca a mão na massa e ganha maior noção dos desafios. Você não sabe dos detalhes até começar a implementar algo.

Conforme a iniciativa anda, mais tarefas e trabalho vão aparecendo, especialmente no início do Ciclo.

Uma outra curiosidade interessante para lembrar é que esse trabalho não é linear. Se você tem 5 de 10 tarefas feitas, não significa que tem 50% do trabalho feito. Pode ser que 90% do trabalho esteja nas próximas 5 tarefas. E que mais 2 tarefas apareçam no final.

Veja alguns trechos do que o Ryan Singer diz a esse respeito no ShapeUp:

Quando os membros do time assumem o projeto, eles começam a descobrir tarefas. As tarefas são um ponto de partida natural, porque são concretas e granulares. É muito cedo para organizá-los em categorias de nível superior. Seria artificial tentar agrupá-los arbitrariamente. É suficiente no início apenas para capturar uma variedade de coisas que precisam acontecer.

Mas não queremos ficar com essa foto por muito tempo. É de nível muito baixo. Não há nada visível de grandes altitudes.

À medida que o time começa a trabalhar de verdade no projeto, eles aprendem como as tarefas estão relacionadas e como é realmente a estrutura do projeto. Então eles se tornam capazes de fatorar o projeto em escopos. É como dividir o mapa do projeto em territórios separados. […] É por isso que, no início de um projeto, não esperamos ver escopos precisos. É mais provável que os vejamos no final da primeira semana ou no início da segunda, depois que o time tiver tido a chance de fazer algum trabalho real e encontrar as linhas divisórias naturais na anatomia do problema.” […]

“A maneira de realmente descobrir o que precisa ser feito é começar a fazer um trabalho real. Isso não significa que os times começam a construir qualquer coisa. Elas precisam escolher algo significativo para construir primeiro. Algo que é central no projeto enquanto ainda pequeno o suficiente para ser finalizado — com interface do usuário e código funcionais — em alguns dias”. — Livro Shape Up (Basecamp)

Por isso, nos primeiros dias de trabalho não terá algo realmente sendo implementado. Não espere algum progresso de implementação nesses primeiros dias.

As pessoas podem estar descobrindo quais são os sistemas que precisarão mexer, como dividir os escopos, quais são as dependências entre os sistemas, quais são as APIs, etc. Reconheça essa fase.

Integração o quanto antes e continuamente

Não espere integrar design, frontend, backend e sistemas por último ou em grandes intervalos. Pelo contrário.

Integre desde os primeiros dias e frequentemente. A ideia é continuamente minimizar os riscos.

Leia mais sobre isso no livro ShapeUp.

Entregue o quanto antes

Se no ciclo de 6 semanas há 3 iniciativas com apetite de 2 semanas, não esperem para finalizar as 3 iniciativas no fim do ciclo de 6 semanas.

Dê preferência para entregar uma iniciativa antes da outra o quanto antes e evitar acumular o desenvolvimento das três em paralelo. Assim você pode ter um impulso de energia por finalizar algo e estar renovada para outra iniciativa.

Evite débitos técnicos

Se você produz algo que não é a versão final ou é uma versão má feita, você espera ter uma segunda chance para resolver melhor futuramente.

E isso acaba acumulando e atrapalhando oportunidades de novas iniciativas.

Evite essa pendência. Trabalhe como se você não tivesse uma segunda chance de retomar esse projeto.

Apresentação entre a quarta e quinta semana do que foi implementado até o momento

Para mitigar ainda mais riscos, incentive os sub-times compartilharem, em um local onde PM, PD e TL também tenham acesso, o que foi implementado entre a quarta e quinta semana do ciclo, onde a maior e mais crítica parte já deveria ter sido desenvolvida e integrada no produto, podendo dar uma noção do andamento e dando tempo para que juntos adaptem o escopo para conseguirem terminar no prazo do Ciclo.

Essa demonstração pode ser feita assincronamente na plataforma digital enviando um vídeo ou imagem com comentários e link para à iniciativa rodando em homologação, por exemplo.

Apresentação no fim do ciclo da iniciativa implementada

No fim do ciclo, as líderes das iniciativas compartilham assincronamente sobre a iniciativa entregue num canal específico da empresa.

A ideia é que todas pessoas da empresa possam saber o resultado do Ciclo de Foco permitindo se coordenarem e interagirem.

O que esperar no fim do Ciclo de Foco nessa trilha?

• Iniciativas implementadas e entregues.
• Apresentação assíncrona das iniciativas para toda a empresa.

Rituais para Ciclo de Foco

Checkin síncrono semanal do time

Caso o time esteja livre de outras reuniões, como imaginado nesse processo, é possível experimentar um checkin síncrono semanal com o time inteiro por 45 min (defina o tempo que julgarem melhor).

Exemplo de tópicos:

• Checkin: como tem sido os dias para você?
• Atualizações de Problem Space, Discovery e Delivery (caso seja um Ciclo de Foco)
• Quais são suas maiores preocupações com as atividades atuais? (caso seja um Ciclo de Foco)
• Checkout: como você está saindo da reunião?

Dicas:

• Torne os tópicos da reunião visível na agenda de todas pessoas e durante a reunião.
• Convide alguma pessoa para ser guardiã do tempo e garantir que avancem os tópicos dentro do tempo acordado de reunião.
• Qualquer discussão que começar a se aprofundar e tomar o tempo de outros tópicos, indique para: (a) duas pessoas discutirem após essa reunião e chegarem a uma proposta pra dividir com o time posteriormente ou (b) criarem um tópico e discutirem assincronamente em uma ferramenta digital. A escolha da opção dependerá da urgência e complexidade.

Ciclo de Fôlego: 2 semanas

Organizações são sistemas complexos e para se manter capaz de se adaptar e persistir em um ambiente variável é necessário resiliência, além de outos elementos.

Resiliência pode ter inúmeras definições, mas de forma geral, resiliência é a capacidade de voltar à forma depois de ter sido esticado ou pressionado.

De acordo com a autora Donella H. Meadows, em seu livro “Thinking in Systems - A Primer”, a resiliência é algo que pode ser muito difícil de ver, a menos que você exceda seus limites, sobrecarregue e danifique os loops de equilíbrio e a estrutura do sistema se quebre. E, como pode não ser óbvia sem uma visão geral do sistema, as pessoas costumam sacrificar a resiliência pela estabilidade, produtividade ou alguma outra propriedade do sistema mais imediatamente reconhecível.

Manter o sistema funcionando na sua maior capacidade para extrair o máximo possível, pode ser um perigo. Você não observará isso a curto prazo e nem de forma reducionista, porém ao observar por um período de tempo de forma mais sistêmica poderá perceber os efeitos gerados na resiliência do sistema.

Na pesquisa In Praise of Slack: Time Is of the Essence é dito que “a folga organizacional, em termos de tempo e [recursos humanos] que não estão constantemente sujeitos a medidas de eficiência a curto prazo, é importante para as organizações que lidam com os desafios do século XXI […] As demandas futuras por flexibilidade estratégica e por integrar aprendizado e conhecimento em todas as organizações destacam a necessidade de reexaminar a importância do tempo no trabalho organizacional — e reconhecer que todos os recursos organizacionais não podem ser comprometidos com os esforços imediatos de produção, se quisermos ter tempo para prestar atenção, pense e se beneficie do conhecimento adquirido”.

Abaixo exploro ideias do que se fazer no Ciclo de Fôlego.

A inovação é maior que um produto ou uma plataforma tecnológica. E, na verdade, são as inovações para organizações e gerenciamento que precedem a inovação de produtos ou tecnologia de qualquer maneira. Grandes líderes não inovam o produto; eles inovam na organização. — David Burkus

Primeira semana do Ciclo de Fôlego

Abaixo há uma proposta de atividades possíveis de utilizar na semana de Fôlego.

Conclusão das pendências do último Ciclo de Foco

É possível que alguns detalhes de entrega em produção tenham ficado pendentes, e é possível finalizar isso no início desse Ciclo.

Se as pendências forem maior do que algo pra ser finalizado em um ou dois dias, a iniciativa é discutida e uma decisão é tomada:

• a iniciativa inacabada é descartada por padrão: a iniciativa foi maior do que você tinha para apetite e você arquiva a iniciativa. Se você quebrar esse critério seguidamente, o apetite perde o crédito e o impacto nas decisões.
• em raros casos a iniciativa será priorizada para outro ciclo: é possível dar um apetite de 2 semanas para o próximo Ciclo, permitindo que outras iniciativas menores sejam somadas para totalizar 6 semanas.

Aposta de iniciativas para Delivery no próximo Ciclo de Foco

Com as iniciativas discutidas e validadas, o time apostará em quais iniciativas entrarão na trilha de Delivery no próximo Ciclo de Foco afim de resolver os Problemas definidos.

Por qual motivo chamar de aposta? Pois sabemos que não é possível prever com exatidão se uma iniciativa cabe dentro do apetite de tempo. Decisões complexas envolvem certa aposta.

Parte da aposta vem com informações que levantamos na formatação de iniciativas e na mitigação de riscos. Parte vem com a “sorte”: variáveis, interações e efeitos que não conseguimos prever.

Também não conseguimos prever com exatidão se a iniciativa resolverá as necessidades das pessoas e se o produto ou funcionalidade serão utilizados.

O Discovery ajudará, mas não garantirá.

Precisamos reconhecer que nunca teremos todas as informações. Só com o produto de fato no mercado é possível ter a resposta se algo reagirá de maneira que atende necessidades das pessoas e ao mesmo tempo se permitirá seu negócio se manter.

Experiência e conhecimento sobre o público somados a um bom processo de Discovery podem fazer você ter melhores apostas pro apetite de Delivery e para a satisfação do mercado mas não garantem melhores resultados.

Basta ver empresas de sucesso com especialistas em seus times ainda assim lançando produtos que falham no mercado.

Ao mesmo tempo, sem uma boa formatação de iniciativas e Discovery, você poderá estar colocando toda sua aposta na mão do acaso.

A aposta nas iniciativas para o próximo Ciclo pode ser feita de algumas formas:

• pontuação do time inteiro sobre as iniciativas, baseada em alguns critérios — exemplo: nível de confiança sobre o impacto da iniciativa na resolução do problema escolhido e nível de confiança que têm sobre a implementação dentro do apetite. Um papel do time pode ter um peso maior sobre a pontuação de uma iniciativa, caso seja previamente acordado entre todas pessoas do time.
• consulta: as pessoas em Delivery são consultadas para compartilharem informações e preocupações porém a decisão se mantém com um papel específico ou com o trio PM+PD+TL.
• consentimento: a parte do time em Delivery consente ou não com as iniciativas propostas por PM+PD+TL. A proposta não é usar: gosto ou não gosto, e sim consentimento: há algum risco que evita que consigamos atingir o objetivo da iniciativa e do nosso time como um todo com essas iniciativas propostas?

É importante ter um acordo prévio com o time inteiro de como será a forma de tomar decisão. Cada forma apresentada acima tem seus prós e contras.

Formação de sub-times para as próximas iniciativas

Para cada iniciativa para Delivery do próximo Ciclo de Foco atribua de 2 a 3 pessoas para a formação de um sub-time.

A TL do time propõe quais desenvolvedoras trabalharão nas iniciativas, tendo o objetivo e responsabilidade de combinar competência necessária para iniciativa e nível de interesse das pessoas com o tipo de desafio.

A ideia aqui é focar nas forças de cada pessoa. Uma força é uma atividade que fortalece a pessoa. Algo que ela está ansiosa para fazer. É uma atividade que deixa ela se sentindo energizada, em vez de esgotada.

Em seguida, a líder consulta e refina sua proposta com essas pessoas.

Assim que os sub-times se formarem para as iniciativas, um novo projeto é criado para cada iniciativa em uma ferramenta digital e o sub-time pode discutir e tirar dúvidas entre si e também com PM, PD e TL.

É possível automatizar essa parte para que um sistema digital faça a primeira proposta da melhor combinação de pessoas e iniciativas.

Retrospectiva (~2h — 4h)

As pessoas podem realizar retrospectiva geral entre todas pessoas que participaram do Ciclo de Foco levantando tensões sobre assuntos como:

• processo;
• papéis;
• produto;
• relações.

É possível experimentar ter uma ferramenta digital no estilo fórum para adicionar tópicos para discussão durante o Ciclo de Foco, permitindo discussão assíncrona. Assim, o tempo da retrospectiva síncrona pode ser utilizado para compartihar decisões tomadas em decisões assíncronas, discutir assuntos ainda pendentes, tratar assuntos emergentes, etc.

Para cada tensão levantada, tente:

• descobrir se algum papel é responsável e tem autonomia sobre o escopo da tensão. Se sim, a tensão pode ser automaticamente delegada para que a pessoa com esse papel possa tratá-la;
• senão, gerar auto-reflexão e estimular quem trouxe a tensão: do que você precisa para resolver isso? qual o primeiro passo que poderia dar em direção à resolução?
• ou, caso a pessoa não consiga pensar em algo e é algo que o time também enxerga como uma dor, convide duas ou três pessoas para co-criarem uma proposta e apresentarem ao time.

Retrospectiva geral da empresa para tratamento de tensões (~2–4h)

Utilizando Open-Space Technology, cada pessoa que tiver uma tensão organizacional que deseje discutir e possivelmente um plano de ação, coloca o tema num mural eletrônico. Depois, salas virtuais são abertas para cada tema e as autoras desses temas se tornam as anfitriãs das salas.

As pessoas que desejam discutir determinado tema entram na sala correspondente.

Ao fim, a ideia é que tenham temas e propostas de resoluções discutidas e compartilhados com as pessoas com que possuem o papel e responsabilidade nesse escopo do tema. Ou, como opção, essas pessoas mesmo podem formar um grupo para atuar no tema.

Estratégia e arquitetura dos sistemas

• Discutem pontos sobre as arquiteturas dos sistemas das especialidades (dados, tech, design, etc): riscos, mudanças e possibilidades;
• Refatoração de sistemas;
• Refinamento de Design System;
• Correção de bugs;
• Hackaton;

Pesquisa de engajamento

Aproveite para realizar pesquisa de engajamento periodicamente. Ao mesmo tempo não torne isso algo super complexo ou invente perguntas que não tenham correlação com o que é esperado.

Para inspiração dê uma olhada nas perguntas que o Marcus Buckingham* indica fazer baseado em evidências de experimentos no assunto. Veja uma versão em português e mais detalhes no apêndice desse artigo.

Aprendizado prático

Aproveite o tempo para aprenderem juntas na prática sobre:

• Algo de alguma especialidade;
• Auto-gestão;
• Gestão de conflitos;
• Organização do ambiente de trabalho pessoal;
• Trabalho remoto;
• Novas tecnologias e ferramentas;
• Etc.

Outras atividades com o restante do tempo

Dê liberdade para que as pessoas usem esse tempo com qualquer novo projeto que desejarem.

Um critério que vocês podem experimentar é garantir o alinhamento do projeto com a missão da empresa.

Segunda semana do Ciclo de Fôlego

• As pessoas podem continuar atuando nas atividades da primeira semana do Ciclo de Fôlego;
• As pessoas podem utilizar para estudar e se atualizarem;
• A organização pode determinar que é um período sabático: as pessoas podem tirar folga do seu trabalho. Veja o exemplo da BLANC MEDIA que experimentou com uma semana sabática:

BLANC MEDIA demonstrando seu ciclo de foco de 6 semanas, seguido de uma semana de buffer e uma semana de sabático.

Rituais para experimentar ao longo de todos os Ciclos

Checkin assíncrono de progresso diário

Diariamente as pessoas respondem assincronamente em uma ferramenta digital que faz checkin automático:

1. No que você tem trabalhado?
2. O que aparenta ser um impedimento ou risco? E qual estratégia está adotando para remover o impedimento ou mitigar o risco?

A primeira pergunta pode fornecer respostas tanto de atividades de uma iniciativa que esteja no Ciclo de Foco ou atividades quaisquers que as pessoas estão envolvidas em Ciclo de Foco ou para Fôlego.

É uma forma da pessoa poder se expressar, dar visibilidade de suas atividades e ao mesmo tempo colher reações ou suporte de outras pessoas sobre essas questões.

Aqui é possível deixar a forma de resposta livre: texto, bullet points, imagens, etc. Dependendo da pessoa e do contexto, uma forma ou outra pode favorecer o registro para ela.

Checkin assíncrono de progresso semanal: o que trabalhará nessa semana

No início de cada semana o time responde assincronamente no que trabalhará na semana que se inicia. Essa pergunta pode estimular a priorização e organização das atividades, além de coordenação entre as pessoas.

Checkin assíncrono quinzenal sobre aprendizado

Semanalmente as pessoas são convidadas a responder assincronamente em uma ferramenta digital:

1. O que aprendeu nos últimos dias?
2. O que está sendo difícil, frustrante ou consumido muito tempo no seu trabalho e como você tem lidado e tentado resolver?

Manutenção das relações

Se o trabalho for distribuído e remoto, a sugestão é que as pessoas do time se reúnam quinzenalmente por 45 min para conversarem sobre qualquer assunto, evitando assunto de trabalho.

Tente dividir em grupos de 3 a 8 pessoas para o papo.

Aceitar o convite é opcional, mas é fortemente incentivado para aprofundar e manter relações.

Para quebrar o gelo e iniciar um papo, experimente algumas dessas ferramentas:

• 120+ TEAM BUILDING ICEBREAKER QUESTIONS FOR WORK
• Icebraker.range.co — Start your meetings and gatherings with over 300 questions designed to build trust, connectedness, and psychological safety.
• Get your shot of inspiration for your check-in question
• Have fun, build trust, boost teamwork

Checkin assíncrono semanal para integração e suporte

Como complemento ao item acima sugiro um checkin automático assíncrono em uma ferramenta com perguntas não relacionadas a trabalho:

• O que você fez nesse fim de semana? (pergunta para uma segunda-feira)
• O que você leu, assistiu ou ouviu na última semana e quais foram os pontos que mais te inspiraram?
• O que você tem feito para cuidar da sua saúde mental e física?
• Como tem sido os últimos dias para você?

Tente variar essas perguntas ao longo dos dias e semanas.

Reconhecimento

A todo momento incentive Kudos (reconhecimentos) entre as pessoas dentro de uma plataforma digital.

Design e Code review

Para dar oportunidade dos princípios de design e código serem aplicados na prática, aprendidos pelos times e ao mesmo tempo garantir a evolução de uma estrutura sustentável, experimentem:

• reviews assíncronos de design ou código em um canal apropriado da especialidade.
• reviews síncronos de design ou código combinado entre pares. O fato de restringir essa possibilidade apenas entre duas pessoas aumenta o foco e evita usar horas de mais pessoas. A mentoria — tópico abaixo — pode ser utilizada para isso.

Mentoria de especialidade

Todas colaboradoras podem ser incentivadas a terem uma mentora da sua especialidade. Essa relação de mentoras e mentoradas pode se estabelecer por um período pré-determinado, exemplo: durante 2 Ciclos de Foco.

As alternativas são:

• cada pessoa pode escolher sua própria mentora dentre as disponíveis.
• ter uma proposta de mentora para cada pessoa.

Para uma pessoa se candidatar como mentora, pode ser necessário passar por alguns critérios. Exemplo: tempo de experiência em determinada especialidade, competências, confirmação pelos líderes ou por pessoas sêniores.

Assim, é possível diminuir a necessidade de one-on-one com “chefe”, que nem sempre possui tempo e conhecimento prático necessário, e acaba concentrando um poder que desfavorece a equivalência. Além disso é uma ótima forma de permitir pessoas se desenvolverem como mentoras.

O encontro com as mentoras pode ser sob demanda, quando a mentorada desejar e ao mesmo pode ser programado por período, como semanalmente.

Isso pode ajudar a pessoa sair do isolamento e bloqueios criativos em sua especialidade, favorecer aprendizado e aprofundar relação e confiança.

Apoio na caminhada

Além da mentoria, experimente incentivar que cada pessoa tenha algúem para apoiá-la durante um período determinado. Após o período, trocam os pares ou renovam o vínculo.

Estimule para que elas se ajudem em qualquer assunto para o seu bem-estar no trabalho.

_________Apêndice_________

Quais empresas utilizam esse tipo de ciclos?

Dê uma olhada aqui. Se sua empresa estiver experimentando ou utilizando, me notifique para incluir aqui.

Como iniciar o experimento com esse processo?

Procure conversar com os times de produto que estão mais sofrendo com o processo atual, apresente esse texto a eles e veja como o processo (ou alguns elementos) poderiam ajudar. Discutam.

Após isso, faça o convite: quais desses times estão dispostos a experimentar?

Pense no Discovery também do próprio processo: o que é possível validar para mitigar riscos?

Exemplos:

• Experimentar ciclo de 6 semanas e 2 semanas de fôlego mesmo dentro do processo atual.
• Conversar com o time e saber quais são as críticas e benefícios que enxergam nesse processo descrito. Como poderiam experimentar?
• Tentar formatar iniciativas com apetite de 6 semanas ou formatar algumas iniciativas de 2 semanas para agrupar antes de implementar o processo para saber quais dificuldades aparecem.
• Minimizar reuniões em grupo durante um ciclo e favorecer comunicação assíncrona.

Como iniciar o processo com um produto novo que ainda não foi lançado?

Nesse estágio uma alternativa é manter PM, PD e TL responsáveis por irem fazendo descobertas contínuas dentro do Ciclo de 6 semanas até terem uma estrutura sólida do que será a base do produto e suas funcionalidades críticas principais.

É possível que a formatação de iniciativas seja muito mais enxuta nessa fase para avanço rápido da descoberta da base do novo produto.

Não tente prever o produto e todas suas funcionalidades de antemão com milestones definidos. Comece pelo principal.

E as desenvolvedoras? Talvez seu time precise de poucas, se alguma, desenvolvedoras atuando nesse estágio, além da TL.

Por isso, as desenvolvedoras podem estar atuando em outros times e produtos.

Após finalizada a fase de estruturação da base do produto, convide todas desenvolvedoras para seguir o processo normal descrito nesse texto.

Como usar o processo em um lançamento de produto?

Sabemos que ao lançar um produto temos que estar aptos a responder a possíveis adaptações necessárias no produto e em nossos serviços. Por isso, uma alternativa ao abrir uma versão beta para o público ou lançar a v1 do seu produto é pausar Discovery e Delivery habituais do Ciclo de Foco e usar o ciclo para manter o time vigilante e respondendo conforme necessidade: adaptações no produto e nos processos, suporte, acompanhamento de erros, acompanhamento das reações dos usuários, etc.

O que fazer quando ainda não tenho iniciativas para Delivery?

No início desse processo é possível que você ainda não tenha grandes apostas para 6 semanas (nem um conjunto de iniciativas de 2 semanas que somem 6 semanas) em Delivery ou que ainda tenha muito para validar em Discovery.

Uma alternativa é manter o ciclo de 6 semanas porém fazer Formatação e Discovery e Delivery no mesmo Ciclo com todo o time integrado, trabalhando colaborativamente nas trilhas.

Logo que tiver alguma iniciativa formatada, validada, e que apostem que um sub-time conseguirá entregar no tempo restante do ciclo atual, entregue a iniciativa para umsub-time desenvolver. Façam isso até que todas as desenvolvedoras tenham iniciativas para atuar em Delivery do ciclo atual com o tempo restante ou ao menos tenham iniciativas formatadas e validadas para apostarem para o próximo Ciclo de Foco.

Assim, no próximo Ciclo de Foco, o trio atua em Discovery e as desenvolvedoras atuam nas iniciativas que ajudaram a formatar e validar no ciclo atual.

Iniciativas de melhorias ou suporte

É possível que algumas atividades no Ciclo de Fôlego tomem uma grande proporção e precisem ser uma iniciativa por si só. Exemplos: refatoração de algo no software ou design system, bugs, manutenção de um sistema complexo, etc.

Nesse caso uma iniciativa poderia ser uma soma de itens para se realizar e resolver.

Por isso, pode ser necessário criar uma iniciativa para o Ciclo de Foco, tendo como responsável para a formatação da iniciativa a líder mais próxima do problema técnico e com competências nessa área.

Será importante negociar a disponibilidade das pessoas necessárias com mais de um time de produto para formar um time específico para a iniciativa. Exemplo: 2 PDs para refatorar ou ajustar o Design System; 2 Devs sêniores para refatorar um sistema complexo.

Variações dos times que participam nas trilhas

Times dinâmicos: uma PM com PDs e TLs variadas em Discovery

Se sua organização não possui times de produto permanentes ou não deseja ter, você pode optar por ter times totalmente dinâmicos, com número reduzido de PMs — talvez tendo apenas uma — que formatará novas iniciativas consultando PDs e TLs, e criando a cada Ciclo times de PDs + TLs para Discovery e times de desenvolvedoras para Delivery.

Uma PM e times dinâmicos com especialidades necessárias para fazer Discovery ou Delivery

Você pode compartilhar todas iniciativas disponíveis numa plataforma digital, informando o que é da trilha de Discovery e o que é da trilha de Delivery, e as pessoas podem se atribuir às iniciativas que precisam de suas competências e naquelas que mais desejam atuar.

Assim a organização pode se beneficiar de ter as pessoas necessárias em cada iniciativa, sem depender de ter especialidades fixas em cada time.

Discovery inicial feito por todo time, incluindo desenvolvedoras

Pessoas da trilha de Delivery participam de um Discovery Sprint com todo time no início do Ciclo de Foco — uma semana ou menos — e logo voltam pra Delivery. PM, PD e TL continuam fazendo ideação e Discovery de outras iniciativas.

Product Designer trabalhando junto com desenvolvedoras em Delivery

Nesse processo eu mantive PD mais focada em Discovery, apesar de saber que ela precisará trabalhar a UI das iniciativas. Fiz isso pois em geral PDs fazem a parte de UI em ferramentas que não geram código completo para reaproveitamento no desenvolvimento e acabam tendo que realizar a maior parte do seu trabalho antes da implementação pelas desenvolvedoras.

Porém se o time tiver PDs que saibam desenvolver HTML+CSS ou usam uma ferramenta como Bootstrap Studio (que exporta o código), é possível que seu time possa ter uma PD atribuída a um sub-time responsável por uma iniciativa em Delivery, construindo a parte de UI em paralelo ao trabalho das desenvolvedoras.

Para isso é indicado que a PD inicie seu trabalho pelos affordances — quaisquer elementos que permitam interação e relação com o usuário, em vez de iniciar por fontes, cores, espaçamentos e detalhes de layout. Assim permite que as desenvolvedoras já possam ir fazendo as ligações necessárias e fundamentais com o código.

Recomendo a leitura do tópico “Affordances before pixel-perfect screens” do livro Shape Up para maior aprofundamento.

Caso você vá nessa linha, pode ser importante garantir uma outra PD para estar na trilha de Discovery com PM e TL.

E com uma PD em Delivery, você terá mais uma alternativa de alguém para ser líder de iniciativa em Delivery.

Curiosidade: Modelo Spotify e Shape Up

No texto em inglês, “O modelo de #SquadGoals do Spotify falhou”, o autor Jeremiah Lee recomenda Scaled Agile Framework ou Shape Up como alternativa a modelos atuais, dependendo do tamanho da empresa.

Acredito que é possível adaptar o processo para escalar em diferentes tamanhos de empresas.

[Saiba mais sobre os princípios e práticas da Spotify]

Comparação com a estrutura de times da Basecamp

A Basecamp possui entre 50 e 60 pessoas. Dentre elas há ~8 devs (2 android, 2 iOS) e ~8 designers. Além disso há o Ryan Singer (Product Strategist), Jason Fried (CEO) e o David Heinemeier Hansson (CTO) envolvidos diretamente no produto.

Até onde entendo, eles 3 em geral são os envolvidos na formatação de iniciativas (Shaping) e ficam mais na trilha de Discovery.

Já as outras pessoas de desenvolvimento e design ficam mais na trilha de Delivery, formando subtimes de 2 a 3 pessoas por cada iniciativa.

No processo Foco & Fôlego algo similar acontece em um time de produto: enquanto desenvolvedoras (e talvez product designer) estão em Delivery em subtimes de 1–3 pessoas, a PM, PD e TL estão em Discovery.

A diferença maior é que designers na Basecamp possuem conhecimento de HTML+CSS e dependendo do nível de senioridade também entendem de programação como Ruby on Rails. Por isso, designer trabalha em Delivery juntamente com as desenvolvedoras. Veja o tópico “Product Designer trabalhando junto com desenvolvedoras em Delivery” mais acima.

Pesquisa de engajamento

*Marcus Buckingham é consultor, palestrante e autor de diversos livros. Durante os 19 anos que trabalhou na Gallup como pesquisador e vice-presidente, ele tornou-se membro de uma equipe que trabalhou em uma pesquisa que media uma ampla gama de fatores que contribuíam para o engajamento das pessoas nas empresas. Atualmente ele faz parte da ADP Research Institute e continua realizar descobertas baseadas em dados e experimentos sobre engajamento e performance.

Essa é a lista de perguntas em português:

1. (Propósito) Estou realmente entusiasmado com a missão da minha empresa.
2. (Excelência) Na minha equipe, estou cercado por pessoas que compartilham meus valores.
3. (Suporte) Minhas colegas de equipe me defendem.
4. (Futuro) Tenho muita confiança no futuro da minha empresa.
5. (Propósito) No trabalho, eu entendo claramente o que é esperado de mim.
6. (Excelência) Tenho a chance de usar minhas forças todos os dias no trabalho.
7. (Suporte) Eu sei que serei reconhecida por um excelente trabalho.
8. (Futuro) No meu trabalho, sempre sou desafiada a crescer.

As colaboradoras que respondem positivamente a essas oito perguntas acima são mais frequentemente vistas como altamente produtivas e com menor probabilidade de sair.

Observações sobre linguagem e termos utilizados no texto

• Linguagem no feminino: utilizei a linguagem no feminino como uma agente socializante de gênero, no intuito de evitar que usando no masculino houvesse uma interpretação de discriminação fundamentada no sexo.
• Termos em inglês: apesar de considerar que em geral termos em inglês são menos inclusivos, acredito que muitos dos termos são comuns em startups de tecnologia — possivelmente o maior público desse texto — e mais entendidos do que os próprios termos em português. Aceito sugestões.

Outras referências

• Referências sobre ciclo de 6 semanas para desenvolvimento de produto
• Triple Track Agile: uma combinação de Problem Space com Solution Space
• Shape Up: Stop Running in Circles and Ship Work that Matters
• This Is How We Manage Projects on a Fully Remote Team
• What Agile Development Looks Like on a Remote Team
• O modelo de #SquadGoals do Spotify falhou