O que é Reserva Técnica?

Já citei várias vezes o conceito de reserva técnica em equipes SCRUM, a utilizo sob esta designação desde 2011, mas apesar de sua importância e efetividade para o sucesso de uma sprint, nunca tinha dedicado um post para explicar com detalhes. Isso acontece as vezes, algumas coisas parecem óbvias de tanto que falo no dia-a-dia e por isso acabo esquecendo de compartilhar.

Nos treinamentos sempre dedico um slot para seu entendimento na teoria e na prática, utilizo em todos os projetos com diferentes percentuais e insumos, mas refletindo sobre um bom post no LinkedIn do amigo José Alberto Esteves do Nascimento, CEO da Dura-Lex Sistemas, aqui vai um post mais detalhado sobre o uso da Reserva Técnica em equipes SCRUM.

O começo de tudo

Release Plan é o marco que divide o pré-game do game, quando finalmente botamos a mão na massa e geramos código de qualidade e valor em ciclos iterativo-incrementais-articulados. A técnica pode ser Inception, Direto ao Ponto ou outra, conforme crenças e conveniência.

Antes do início de um Release Plan, é preciso estabelecer os critérios e parâmetros que estão postos ou precisam estar postos para balizar um bom planejamento. Para isto eu venho utilizando o Project Model Canvas do Prof Finocchio e o meu SCRUM Setup Canvas para mapear o que um time SCRUM precisa saber.

Durante um Release Plan, utilizaremos direta ou indiretamente as informações destes dois Canvas para bem conduzir e planejar nosso projeto, levando em consideração expectativas, premissas, restrições e riscos, bem como os parâmetros de setup que balizam um projeto SCRUM, explicitamente debatidas na construção de um SCRUM SetUp Canvas.

No final de um Release Plan queremos que seja possível termos um bom planejamento de Sprints e Releases, nem otimista e nem pessimista, mas um planejamento realista, baseado nas melhores informações e projeções que o capital intelectual de todos os presentes puderam compôr a partir dos insumos necessários e que vinham sendo coletados, trabalhados e refinados a algum tempo.

Tenho muitos posts sobre quase tudo, mas estava devendo um bom post sobre Reserva Técnica, premissa para um bom planejamento, pois sem levá-la em consideração correremos o risco de passados apenas um ou dois sprints vermos todo nosso planejamento ir para o ralo por fatos e situações que são de nosso conhecimento, mas que por desinformação, preguiça ou insegurança não usamos.

Reserva técnica

Auto-conhecimento é valor, como levantar uma média histórica ou fazer uma projeção de cenários que levam em consideração o tempo ou percentual que NÃO teremos de disponibilidade do time para o projeto que iremos planejar. Levamos em consideração dedicação a outros afazeres, como sustentação, atendimento, sazonalidade, alocações previsíveis e relevantes para os próximos meses. Alguns são duradouros, outros esporádicos, como prever um pico no sprint seguinte a uma entrega em produção, atendimentos, manutenção a treinamentos.

Creio que mais de 80% das equipes com quem trabalho se utilizam de reserva técnica, pois dão sustentação a solução que hora estão aprimorando ou evoluindo ou o fazem para outras soluções em produção, até mesmo legados. O índice varia muito, usualmente fica em torno de 25%, mas tenho variações de 10% a 50% … e funciona muito bem, inclusive planos de ação para entendê-la e reduzi-la sempre tem bom feedback em nossas sprints review.

O primeiro passo em uma iteração é o Sprint Planning, dinâmica destinada a entender melhor, validar a estimativa e expectativa inicial, a partir agora de uma especificação (DoR) mais clara. Projeções de presenças e ausências, confirmação da Reserva Técnica, inicio do uso técnicas que inicialmente impactem em produtividade, etc. Ao final saímos com um quadro Kanban montado com tarefas para construção do Sprint Backlog e eventuais tarefas técnicas.

Usualmente em quadros Kanban físicos eu crio raias para as histórias terem suas tarefas evoluindo de forma visualmente explícita, facilitando a leitura do Kanban, mas a imagem abaixo mostra um esquema sem ter as raias de histórias, somente a de Reserva Técnica, que no exemplo está com 25%, apenas para ilustrar:

A cada reunião Diária, as quatro frases quanto ao que fez e vai fazer para o sucesso da sprint desde a última e até a próxima daily, se vê riscos ou se vê oportunidades para o sucesso do sprint. Avaliando a evolução da sprint, tendência e equilíbrio entre projeto e reserva técnica, de forma a tomar decisões de acionamento, planos de ação, comunicação e o que mais for necessário para garantir o máximo de valor possível a cada sprint.

Eu tenho uma frase que costumo usar em treinamentos e já compartilhei em posts sobre a reunião diária: Se passarem algumas diárias e tudo estiver perfeito, é porque um ou todos estão mentindo ou foram excessivamente pessimistas nas estimativas. Só dá tudo absolutamente certo se colocamos um enorme CC no planejamento, porque quem tenta acertar acaba errando para cima e para baixo, acertamos na média e não na tampa … disso eu não tenho dúvida!

O maior “segredo” de um time ágil é o senso de pertença na auto-organização, logo, é da alçada do time avaliar cada dia trabalhado e buscar o seu equilíbrio de forma pró-ativa e efetiva, gerando valor, evitando desperdício, buscando ajuda, blindando, antecipando, etc. Tudo isso de forma 100% transparente, contando com o PO e SM, indiretamente dos stakeholders quando preciso, sempre com o intuito de atingir o melhor resultado a cada iteração.

Ao final de cada sprint, em cada sprint review e em cada retrô, o prazer de participar de algo em que todos juntos temos orgulho de ter feito o nosso melhor, aprendido e buscar a cada passo melhorar ainda mais. A reserva técnica é um insumo do processo de auto-organização e kaizen que exige auto-conhecimento e comprometimento, porque há ocorrências inevitáveis, mas há muito de divida técnica, de treinamento, de falta de qualidade, falta de automação de testes, …

Em equipes SCRUM de projeto, quer seja por algo novo, pacote de evolutivas ou corretivas, é um privilégio equipes dedicadas exclusivamente a um projeto, mas mesmos estas a partir da primeira entrega já entram em ritmo de sustentação, um ritmo mitigado quanto maior a qualidade e excelência, desde o planejamento, DoR, DoD, engenharia de software e interação, mas nada disso funciona a contento sem muita auto-organização e senso de pertença … lembre disso!

A tempo, tenho muitos cases e exemplos práticos e este post é uma introdução ao tema, logo, como sempre, fico a disposição por aqui ou pelas redes … agradeço a parceria e até a próxima!