Scrum e a Estratégia
Normalmente, quando uma pessoa é questionada sobre a diferença entre o workflow Scrum e o "Processo Tradicional" conduzindo a execução de projetos, a resposta mais simples é a de que: planeja-se ao extremo na antiga abordagem antes de iniciar a execução, enquanto no modelo mais novo, planeja-se apenas o suficiente para iniciar a execução e vai-se refinando o plano à medida que o projeto segue. Uma resposta um pouco mais elaborada que vem à mente é - em Scrum, a profundidade do planejamento é menos granular à medida que se distancia no tempo. Em outras palavras, o sprint atual é planejado em extremos detalhes, enquanto você possui uma ideia do que alcançar nos próximos 3 sprints e muito além disso é apenas uma linha do tempo esparsa. Ótimo - isto faz muito sentido, não é? Mas olhando além da engenharia, é possível identificar que existem inúmeros outros fatores para executar um negócio - previsões, estratégia de produto, execução da estratégia definida - além de estabelecer uma linha do tempo de como os resultados se alinhariam e adicioná-los nos alvos de lucro. Se Scrum é sobre curto prazo, como então os caras da estratégia trabalham neste ecossistema? Mais importante, como isto ajudaria os líderes a fazerem e conviverem com compromissos acordados?
Perguntas interessantes, mas não existem respostas fáceis o suficiente. Entretanto, sem sombra de dúvida, estratégia é tão importante quanto a execução pois é a luz condutora que lidera o caminho para que seu negócio navegue em um túnel escuro. Nunca foi tão importante possuir uma boa estratégia quanto as condições atuais de mercado necessitam que seja. Tudo isto não faz Estratégia e Scrum parecerem dois pólos de um ímã, ou ainda mais - os dois extremos de um planeta?
Desmistificando Planejamento em Scrum
Uma das idéias mal interpretadas do Scrum é que você não possui a menor idéia de quando o ciclo de release estará completo e quando o produto final (alinhado a todas as funcionalidades acordadas) está pronto para ser lançado. Este é o principal argumento que os proponentes mais ardentes de um processo não-Ágil tem a dizer sobre Scrum. Na realidade, isto não poderia ser mais distante da verdade. Tendo Scrum a qualidade definitiva de possuir uma natureza não prescritiva, acaba-se com este argumento justamente com tal característica de não ser prescritivo. Nem ao menos de forma remota Scrum sugere que se páre de realizar planejamentos de longo prazo. De fato, o planejamento de longo prazo é essencial para fornecer aos stakeholders uma idéia sobre as possibilidades do projeto, se ele é realizável ou não. As ferramentas tradicionais de negócio como análise de investimento de capital, análise break-even, etc. se tornam ainda mais relevantes em Scrum pois ajudam a determinar o valor não apenas do produto como um todo, mas também a soma de suas partes - a funcionalidade específica que fantasia o projeto. Isto auxilia product owners também a encontrar, e conseguir, o valor máximo de um investimento no projeto. Em suma, tudo o que a abordagem Scrum sugere é que se tenha um objetivo de alto nível em mente e que se vá refinando o planejamento para o nível de granularidade necessária para o curto prazo. De tal forma que, se houver necessidade de mudança na direção ou correção de curso do projeto, não apenas será menos doloroso mas dará ao negócio melhor controle sobre a reação da mudança.
Holístico, ainda que Logico
Scrum, usando o jargão de negócio, é sobre execução "orientada a valor". Comparando dois cursos diferentes de ação: se uma ação espera fornecer um valor maior, ou ROI, em comparação a outra ação, Scrum será todo para o primeiro caso, e entregando-a alinha-se com os objetivos de longo prazo e une-se com as necessidades dos stakeholders. Todas essas ideias podem ser explicadas melhor através um desenho pictoresco ao qual fui exposto durante a certificação CSM: 
Apesar de autoexplicativo o diagrama acima, segue um sumário verbal dos pontos chave:
- Toda a premissa dos processos tradicionais, seja Waterfall ou qualquer variante, é entregar valor sólido e significativo após um período de tempo. O eixo Y no diagrama acima apresenta o valor em $; o eixo X, o tempo. Uma rápida olhada no gráfico mostra que processos Ágeis atuam entregando pouquíssimo valor a todo instante de tempo, fazendo um pouco de tudo (a chave) desde o princípio e apresentando um progresso mensurável aos stakeholders. De outro modo, o processo tradicional entrega um grande valor *depois* de algum período de tempo. O processo Ágil é sobre progresso pequeno e incremental através do mesmo intervalo de tempo. Essencialmente, o foco deste gráfico é apresentar como os aspectos de negócio de um projeto estão fortemente ligados ao workflow Scrum de execução de estórias priorizadas.
Assim, o foco está em como o Scrum coloca o negócio em estado de controle. As funcionalidades de maior valor são desenvolvidas primeiro, provendo ao negócio as oportunidades de:
- Modificar a data de entrega (adiantar) baseado em valor suficientemente agregado ou acordos oportunistas.
- Tradeoffs entre menos funcionalidades vs. atraso no plano de release que permite que datas sejam alcançadas com pouco ou nenhum impacto no lucro projetado.
- Tradeoffs entre menos funcionalidades vs. estórias emergentes com maior prioridade que podem prover oportunidades de venda mais cedo.
Adotando a abordagem Scrum cercam-se os problemas que são tipicamente comuns ao planejamentos altamente granulares e de longo prazo:
- Precisão falsa nas estimativas
- Mudanças nas condições de negócio necessitam que planos detalhados e designs sejam repriorizados
- Incertezas são normalmente ignoradas e não visíveis até tarde no projeto.
Problemas com planejamento/estratégia tradicionais:
- Foco nas tarefas (documentos de requisitos, documentos de design, plano de teste) ao invés de valor de negócio
- Atividades não são independentes e rastreabilidade de dependências é bastante complexo
- Atrasos são passados adiante no cronograma
Unindo os pontos
Para um leitor casual, pode parecer estranho como a primeira e a segunda parte da sessão acima se relacionam. Este é o ponto em que observar a estratégia num sentido holístico nos ajuda a unir os pontos - Estratégia, colocando em termos simples, é sobre olhar para o futuro em sentido teórico. De certa forma Scrum e Agile, em sua premissa são contrários a se olhar muito à frente. O senso de construir uma estratégia não como um conceito teórico, mas em fundações sólidas erguidas sobre os benefícios de negócio que apresenta o framework Scrum está na raiz desta filosofia. Em outras palavras, a arquitetura de um monumento apoia-se tanto na força de suas fundações, quanto na habilidade de visualmente agradar através de sua fachada exterior. Da mesma forma, os valores do Scrum são a fundação para uma estratégia sólida.
Iniciamos este artigo com algumas noções comumente percebidas do Scrum e descrevemos como Scrum apresenta-se congruente quando se fala em estratégia, seguindo logicamente deste ponto tentamos conectar todas as peças do quebra-cabeças. Em resumo, espero que este artigo ajude a endereçar o menos familiar e menos falado sobre a natureza do Scrum. Mais importante, execução e estratégia são como dois olhos - Scrum ocupa-se das especificidades da execução, enquanto a estratégia em um ambiente Ágil é menos cuidada, apesar de não menos importante. À medida que nós, como praticantes de Scrum, estamos cientes dos meandros intrinsecos do papel da estratégia no framework Scrum, estaremos fazendo justiça a nós mesmos. Como nota final, lembremos que desenvolvimento Ágil é não prescritivo e dadas as rédeas da liberdade, a flexibilidade para melhorar o processo está em nossas mãos!