Um case aplicado de estratégia “Even Over”
O cenário era um time, recém formado, criando uma aplicação para substituir uma solução em produção. Durante o desenvolvimento, que era greenfield para um “novo produto” já se acumulava uma dívida técnica considerável. Em paralelo, haviam múltiplos projetos sendo desenvolvidos e assim que entrou em produção recebeu muitos elogios dos usuários por proporcionar uma experiência muito superior ao seu antecessor mas ainda trazendo problemas funcionais e de usabilidade.
O problema é que entre múltiplos projetos, incidentes e problemas, não se existia uma definição clara sobre o que era mais importante. Não existia uma clareza sobre o Roadmap do produto com relação aos projetos em andamentos e próximos a serem priorizados pelas diferentes áreas de negócio.
O Product Owner era diretamente influenciado por uma estrutura multi-nível de gestão, pensem em um cachorro com dois donos (Difusão de Responsabilidades). O time era composto por uma mistura de desenvolvedores internos e desenvolvedores terceiros (de mais de um cnpj), ou seja, faziam parte da sua própria estrutura de gestão. Qualidade era responsabilidade de uma terceira área.. Infraestrutura uma outra área.. Suporte e Atendimento uma outra área.. outros silos coadjuvantes também estavam presentes.
Um ambiente que representa a antítese do DevOps.
Neste contexto, um dos desafios era que o time deveria desempenhar diferentes atividades e era cobrado por diferentes entregas pelas suas respectivas linhas de gestão e pelas diversas áreas de negócio da organização.
Mudamos o mindset de desenvolvimento projetizado (paramos de montar time e desmontar após o final do projeto) e passamos a trabalhar com times estáveis (chamamos de “Times Perenes”). Para resolver dúvidas de priorização, críamos uma visão a nível operacional do time sobre a distribuição da sua capacidade de desenvolvimento.
A distribuição inicial da capacidade produtiva do time era algo como:
- 30% Incidentes e Problemas
- 70% Novas Funcionalidades
- 0% Dívida Técnica, melhorias, pocs (provas de conceito), spikes e quaisquer outras coisas que não estivessem em escopo dos Projetos ou não fosse um incidente/problema em produção.
Na prática, tínhamos 2 desenvolvedores atendendo a Incidentes e Problemas e os demais (~5) trabalhando em 2 ou 3 projetos em paralelo. Existia uma frequência para rotacionar estas responsabilidades, para que todos membros do time fossem capaz de resolver qualquer problema ou serem capazes de desenvolver novas funcionalidades. [7 devs + 1 PO + 1 SM + 2-3 QAs + …]
A aplicação do “Even Over” na estratégia é que apesar de termos uma capacidade pré-definida para determinadas atividades (30% Incidentes e Problemas e 70% Novas Funcionalidades) nós tínhamos clareza que se houvéssemos de tomar uma decisão entre um problema em produção ou um incidente ou entregar uma funcionalidade previamente acordada, havia um consenso organizacional de que problemas e incidentes são mais importantes.
Passou a existir um alinhamento organizacional de que era aceitável replanejar a entrega de uma funcionalidade caso houvesse um problema em produção para ser resolvido.
É como no manifesto Ágil..
Quando houver dúvida entre os princípios da esquerda e da direita, devemos priorizar os da esquerda.
ATÉ MESMO SOBRE (Even Over..)
Processos e ferramentas (que são importantes!) os indivíduos e interações são mais importantes ainda.
Se houver uma decisão que impacte negativamente os indivíduos e suas interações em prol de processos e ferramentas, se a empresa acredita em Agilidade e está buscando este caminho, a escolha deveria tender a ser tomada a favor dos indivíduos e de suas interações.
Origem desse post
Algumas semanas atrás, eu assisti o video do pessoal da TargetTeal (https://targetteal.com/en/) “OKR : modinha ou ferramenta útil? Fim da Firma – Ep. 1” (você pode assistir aqui).
Depois da conversa que tivemos no Slack da Agilidade eles citaram “Even Over” como uma forma mais efetiva de deixar claro para os colaboradores qual é a Estratégia da empresa e como os profissionais devem agir.
Fui ler sobre o assunto (aqui) e então descobri que mesmo sem conhecer a prática já havia aplicado a mesma abordagem algumas vezes.
Agile Coach .Ninja 