Scrum Executivo – Pt. 2

Algumas dores do mundo executivo

Em projetos de software temos o costume de ouvir queixas quanto a mudança de requisitos. É frustrante para times de projetos de software enxergar uma grande quantidade de requisitos ser alterada quando mal o projeto foi iniciado. No entanto esta não é uma dor apenas dos times desta área, a realidade do mercado requer frequentemente uma mudança no plano estratégico da empresa logo após a sua escrita, e ver a dor que um executivo sente com isso é bem similar à cena que vemos no mundo de software.
Os problemas com silos em projetos de software nos levou a refletir sobre a utilização de times multi-disciplinares, e o mesmo vem acontecendo no mundo corporativo. Como fazer para que um gerente de recursos humanos esteja focado não apenas na sua meta local, mas sim em como aquele time, composto por executivos de diversas áreas, pode colaborar com a meta da empresa. Enquanto em software nos perguntamos em como fazer para um arquiteto, por exemplo, estar preocupado com a meta do time e não com “minha parte está pronta!”, no mundo executivo há a necessidade de fazer com que o gerente de vendas não esteja preocupado unicamente com “as vendas estão boas!”. As soluções não entregam tudo que podem, em sua maioria pela distância que há entre quem planeja o plano estratégico e quem o executa.

Experimentando o Scrum Executivo

Após as experiências isoladas que citei anteriormente, eu resolvi sentar e pensar em como realmente aplicar algo bem próximo do Scrum proposto por Ken Schwaber e Jeff Sutherland em um time executivo.
O planejamento estratégico da empresa, somado às informações que foram adquiridas através de um Business Plan e outros, serviram de referência para a criação da visão do produto. Esta Executive Product Vision foi o que guiou o Executive Team dentro deste grande programa por estar completamente alinhado às metas anuais da empresa.
Tendo a visão correta para guiar nosso time executivo, partimos então para a criação de um Executive Backlog. Este artefato, assim como um Product Backlog do Scrum, possuía itens priorizados de acordo com o valor para o negócio. Estes itens do Backlog são apontados pelo Executive Product (ou Program) Owner, papel ocupado pelo Diretor Executivo da unidade. Nosso Executive Backlog foi composto por:

Executive Stories: normalmente resultavam em ações executivas
Executive Themes: normalmente resultavam em projetos, portifólios ou programas
Executive Candidates: candidatos a ações, projetos, portifólios ou programas

Nossas Sprints, que tinham o tamanho de 30 dias, eram iniciadas com uma Sprint Planning Meeting. O Executive Team, que era formado por gerentes e diretores da unidade (Sales, Production line, Finance, Support, R&D and Quality) se reunia para planejar o que ia ser trabalhado durante a próxima Sprint. O Executive Product Owner apresentava a meta e explanava sobre os itens mais prioritários, o time tirava as dúvidas e discutia quais dos papéis deviam ser envolvidos em cada um dos itens, em uma atividade chamada Who would help?. A necessidade de haver um facilitador para este trabalho se tornou latente logo nas primeiras reuniões, e com este propósito o time passou a ter um Executive ScrumMaster, executivo da empresa com conhecimento no processo e em técnicas de facilitação e liderança, que além desta atribuição era ainda o responsável pela remoção dos impedimentos do time. Durante a Sprint Planning Meeting o time já procurava identificar quais as tarefas que seriam necessárias para a execução de cada um dos itens, antecipando assim possíveis problemas. Então, por exemplo, de um item chamado “Restruturação de Plano de Cargos e Salários” seriam geradas tarefas como “Identificar premissas para o projeto”, “Levantar histórico dos planos utilizados até hoje”, “Identificar budget do projeto”, “Identificar time para este projeto”, “Colher dados financeiros do plano atual”, etc.
Dentro de uma Sprint o time realizava as atividades necessárias para que o conceito de pronto de cada um dos itens executivos fosse atingido, o que incluía – mas não se limitava a – levar para dentro dos departamentos da empresa a execução, acompanhamento, redirecionamento ou finalização dos projetos. Esses projetos eram rodados dentro dos departamentos utilizando Scrum e, em grande parte deles, tinha o executivo membro do time do Scrum Executive como (Chief) Product Owner ou Program Owner.
Diariamente o time realizava uma Daily Meeting para fornecer visibilidade das suas ações aos outros membros do time. Devido a dificuldade de se realizar estas reuniões de forma presencial todos os dias, era bastante comum a participação de alguns membros do time através de celular, Skype e outros.
Ao fim de uma Sprint os executivos se reuniam para apresentar os resultados ao Executive Product Owner no formato de um Sprint Review comum. Através dos resultados apresentados nesta reunião avaliávamos se a Sprint Executive Goal havia sido atingida ou não. Por fim, o time participava de uma Retrospective que era facilitada pelo Executive ScrumMaster para avaliar os pontos positivos e negativos daquela Sprint, bem como para discutir como melhorar na próxima reunião.

Conclusão

Apesar de ser apenas um primeiro passo na busca de técnicas mais adequadas para os projetos e programas executivos, a utilização de Scrum neste cenário se mostrou bastante eficiente. Como resultado a empresa enxergou claramente um novo comportamento dos seus executivos – agora envolvidos em um real trabalho de time, uma aproximação entre estratégia e execução e uma maior visibilidade do quão as ações executivas estavam alinhadas aos objetivos de negócio da empresa. Scrum se mostra então como uma boa alternativa não apenas para projetos de software, mas sim para projetos em qualquer ambiente onde se necessite elevação do sentimento de urgência, criação de um espírito de time, alinhamento de expectativas e preparo para as mudanças, e no mundo de hoje eu vejo pouquíssimos ambientes em que estas necessidades não sejam latentes.