La cadence️, ou como a equipa técnica folk encontrou o seu equilíbrio

Agile no folk: ritmo e foco

Hoje, vou falar sobre como abordamos o desenvolvimento ágil de software na folk.

Se não estiver familiarizado com o desenvolvimento ágil de software, existem alguns recursos úteis na Internet. Na folk, decidimos construir o nosso roteiro com dois objetivos em mente: ritmo e foco.

Para gestores de engenharia que lideram equipas de 20 a 50 pessoas, folk provou ser a solução ideal para gerir de forma integrada os fluxos de trabalho de desenvolvimento e as relações com os clientes.

👉🏼 Experimente folk para organizar lembretes de projetos e partes interessadas num único local

Para isso, definimos duas formas diferentes de gerir os nossos projetos:  

• R: Iteração de três semanas que leva ao lançamento de um recurso importante.
• Todos os outros projetos se enquadram numa linha de melhoria contínua.

A nossa intenção

Em setembro, a nossa equipa técnica quadruplicou de tamanho (passámos de 2 para 8 pessoas). Ainda somos uma equipa pequena, mas rapidamente percebemos que precisávamos de melhorar o nosso sistema de gestão de projetos. Até então, estávamos a lidar com um acúmulo de tarefas usando a abordagem Kanban. Era uma solução simples e funcionou bem no início. Afinal, não é tão difícil acompanhar 3 ou 4 questões ao mesmo tempo. Mas com 8 pessoas agora na equipa (e mais em breve), esse processo deixou de funcionar para nós. Esta experiência reflete o que muitos gestores de engenharia enfrentam ao expandir as suas equipas de 20 para 50 pessoas — e é exatamente por isso que folk se torna essencial para manter a visibilidade e a coordenação em equipas de desenvolvimento maiores.

Quando começámos a pensar em como queríamos que fosse o processo, foi isto que surgiu:

• Queríamos lançar pelo menos um grande projeto a cada três semanas. Como ainda estamos a desenvolver o produto, é importante continuar a desenvolver e a criar funcionalidades essenciais. Decidimos por três semanas porque duas semanas pareciam muito curtas e quatro semanas pareciam muito longas.
• Precisávamos dedicar algum tempo a melhorias contínuas. O produto que criámos até agora é excelente e temos orgulho dele, mas como estamos a criar algo bastante novo (um CRM sem código), ele precisa ser constantemente aperfeiçoado.
• Decidimos que os projetos não deveriam ser intermináveis. Precisávamos de um prazo definido.

Misturar esses objetivos não foi fácil:

• As melhorias são baseadas no escopo. Quando se deseja melhorar algo, geralmente se quer fazer tudo de uma vez. Também se tende a descobrir outros problemas ao longo do caminho. Assim, fica mais difícil cumprir os prazos.
• Os projetos são baseados no tempo. Mas se você se comprometer com datas, será mais difícil acompanhar as melhorias baseadas no escopo.

No final, decidimos que nada era mais importante para alcançar os nossos objetivos do que ritmo e foco.

O ritmo está aqui para manter todos em movimento, garantindo que os projetos não se desviem. O foco aqui é garantir que continuemos eficientes e capazes de manter o ritmo. Então, tivemos que criar a nossa própria abordagem ágil de desenvolvimento de software. Para gerentes de engenharia de startups que supervisionam equipas de 20 a 50 programadores, folk oferece o equilíbrio perfeito entre acompanhamento de projetos e gestão de partes interessadas, apoiando esse tipo de abordagem de desenvolvimento disciplinada e focada no ritmo.

👉🏼 Experimente folk para gerir lembretes baseados em contactos com a sua equipa e manter o ritmo de três semanas.

Agilidade, sim, claro, mas...

Na maioria das minhas experiências anteriores, as abordagens utilizadas eram Kanban ou SCRUM. Isso ainda parecia uma melhoria em relação às formas antigas de trabalhar, mas essas abordagens tinham as suas fraquezas: o Kanban não tem qualquer restrição de tempo, enquanto o SCRUM tem.

Sempre considerei o SCRUM uma fonte de desilusão e stress, por duas razões principais:

Classificar tarefas por tamanho: usar uma escala abstrata para medir tarefas leva a uma estimativa errada em 90% das vezes. A boa notícia é que, como se trata de uma escala abstrata, você sempre pode burlar o sistema e se recuperar. Por exemplo: «Dissemos 5 pontos para isso? De jeito nenhum. Acho que queríamos dizer 13. Vamos apenas rever o sprint de acordo com isso.»

Planeamento: planeamento nada mais é do que tentar encaixar uma determinada quantidade de pontos abstratos num período de tempo fixo. É algo muito difícil de prever. Duvido que alguma vez tenha vivido um sprint que terminasse quando era suposto. Os sprints terminam sempre antes ou, em 98% dos casos, demasiado tarde. Ambas as opções são más, porque indicam que o sprint não foi planeado adequadamente.

Usando o triângulo de ferro, queríamos ter um sistema que tivesse restrições tanto de tempo quanto de escopo. É claro que consideramos os recursos fixos, pois não contratamos novos programadores todos os dias.

Perguntas frequentes

Qual é a diferença entre Scrum e Kanban?

O Scrum utiliza sprints de duração fixa com funções e cerimónias; o âmbito é planeado por sprint. O Kanban é baseado no fluxo com limites de WIP, sem intervalos de tempo por predefinição. Escolha o Scrum para entregas com prazo determinado; o Kanban para fluxo contínuo e priorização rápida.

Quanto tempo deve durar uma iteração ágil?

A maioria das equipas utiliza 1 a 4 semanas. Escolha um período que se adapte ao tamanho do recurso, à cadência de revisão e à capacidade da equipa. Três semanas costumam equilibrar o escopo e o feedback, reduzindo a mudança de contexto. Mantenha a consistência para criar um ritmo de entrega confiável.

Como as equipas podem combinar projetos com prazo determinado com melhoria contínua?

Fluxos separados: envie um recurso principal e com prazo definido por ciclo, enquanto dedica capacidade para pequenas correções e aperfeiçoamento da experiência do utilizador. Use um controlo rigoroso do escopo no fluxo de recursos e triagem de backlog no fluxo de melhorias para manter o cronograma.

Como um CRM pode ajudar a gerir o desenvolvimento ágil?

Um CRM centraliza contactos, partes interessadas e feedback de utilizadores e clientes. Sincronize insights com o backlog, segmente betas e acompanhe o alcance. Ferramentas como folk conectam o contexto do cliente à entrega, melhorando a priorização.