9 vantagens de usar Scrum em seus projetos

Desde 13 de novembro de 2001 pra cá, quando o Manifesto Ágil foi assinado por 17 das mentes mais brilhantes da indústria de software à época, que o hype em torno de métodos ágeis só cresce. Em parte pelo demérito dos métodos tradicionais de desenvolvimento que priorizam muitas vezes a burocracia em detrimento do resultado, mas gosto de pensar que a principal razão é porque Scrum e cia realmente funcionam.

No entanto, para quem é novo nesse mundo ágil e apenas ouviu falar em buzzwords (e bizarrices) como planejamento com Poker, reuniões em pé e equipes sem chefe, fica difícil entender porque alguém adotaria tais excentricidades no seu ambiente de trabalho.

Por que eu realmente devo utilizar métodos ágeis em meu ambiente de trabalho?

Por que usar Scrum?

Quais as vantagens?

No post de hoje falarei de 9 vantagens inerentes à aplicação de Scrum no seu time, embora os métodos ágeis compartilhem de praticamente as mesmas premissas.

E se você nunca trabalhou com Scrum antes, recomendo assistir ao vídeo abaixo onde resumo ele em apenas 10 minutos.

#1 – Adaptabilidade

O controle de processos empíricos e a entrega iterativa fazem com que os projetos sejam adaptáveis e abertos à incorporação de mudanças.

Enquanto os métodos tradicionais de desenvolvimento, em especial o cascata, valorizam análise extensa e definições rígidas de requisitos, visando “segurança” (ou a falsa sensação dela), o Scrum abraça a imprevisibilidade que um projeto longo possui ao inserir mais resiliência em projetos.

Isso não é apenas algo etéreo, está lá, documentado no Scrum Guide como o terceiro pilar do framework!

Como diria Bruce Lee, abrace a mudança, a imprevisibilidade, seja como a água, meu amigo! Não apenas o chinês está muito certo como outro dito oriental, desde vez japonês, do Karatê Goju-ryu, fala sobre resiliência quando cita que os pinheiros que duram mais tempo são aqueles que “aprendem” a se vergar nas tempestades. De nada adianta uma árvore imponente se ela for rígida e “imóvel”, sempre haverá uma tempestade forte o bastante para quebrá-la, e o mesmo acontece com projetos.

Como diria a equipe dev do Spotify, construa princípios sólidos e metas claras, mas adapte a execução conforme a necessidade. Isso é ser ágil.

#2 – Transparência

Todos as fontes de informações, tais como, o quadro de tarefas (Kanban) e o gráfico Burndown, são compartilhadas gerando um ambiente de trabalho aberto.

Na administração tradicional a Gestão à Vista não é algo novo e comprovadamente vantajoso para as organizações. Isso porque permite que todos vejam o que está acontecendo e consigam tomar atitudes em relação à isso.

Scrum fala de adaptação, mas não há como se adaptar ao que não se consegue ver, e por isso que o primeiro pilar da metodologia é a transparência. Tudo começa com ela.

Sem transparência não há:

inspeção adequada
adaptação
engajamento
confiança
evolução do time
sucesso no projeto

Gerentes temem expor informações que possam gerar medos e conflitos no time. Ao fazerem isso, impedem que o time amadureça e realmente “abrace a causa”. John Maxwell diz que não tem como o time saber se está ganhando se ele não pode ver o placar!

Tem um ditado que diz também o seguinte (adoro eles!): se você não sabe para onde está indo, qualquer lugar serve. Um projeto não fracassa se não havia um objetivo para o mesmo, certo?!

#3 – Feedback Contínuo

O feedback contínuo é fornecido através de processos denominados como a Reunião Diária e a Sprint Review.

O Scrum fornece diversos mecanismos de feedback, o que garante o segundo pilar do framework: inspeção.

Feedback contínuo não é dar tapinhas nas costas na reunião de final de ano da empresa. Feedback contínuo tem a ver com transparência, pois o time precisa saber se suas ações estão gerando resultado. Você precisa saber se está no caminho certo. O seu colega precisa saber como pode lhe ajudar e você precisa saber se ele precisa de ajuda também.

Inspeção leva à adaptação, em um ciclo virtuoso que gera a melhoria contínua.

4# – Melhoria Contínua

As entregas melhoram progressivamente, Sprint por Sprint, através do processo de refinamento do Backlog do Produto e do processo em si.

Na metodologia de inovação em startups denominada Lean Startup, existe um ciclo chamado construir-medir-aprender (build-measure-learn no original) que trabalha da seguinte maneira:

Você constrói um incremento de produto
Você mede o desempenho dele
Você aprende com os erros e refina-o
Volte ao passo 1

E assim o é também no Scrum.

O framework é enxuto, apenas 19 páginas. Talvez não cubra nem sequer 10% da “ciência” da gestão de projetos. Mas os seus princípios fundamentais te ajudam a pensar de uma maneira diferente, com o mindset correto. Ele próprio te ensina que a inspeção vai te levar inerentemente ao aprendizado (adaptação) e com isso à melhoria contínua dos processos e produtos.

Esqueça aquela ideia que alguns métodos pregam que você deve apenas confiar cegamente em um livro e seus problemas estarão resolvidos!

#5 – Entrega Contínua de Valor

Os processos iterativos permitem a entrega contínua de valor tão frequente quanto exigido pelo cliente.

Tenha em mente que ninguém compra software. Ninguém.

“Como assim?” você deve estar se perguntando agora… Sim, as empresas que usam softwares nunca quiseram ter aqueles programas instalados em seus servidores ou nas máquinas dos funcionários. Eles sempre quiseram soluções para seus problemas, sempre quiseram ser mais produtivas, mais assertivas, mais competitivas, etc.

Só quem gosta de software é programador. Cliente gosta de solução que entrega valor. Se o seu time não entrega valor, ele não vai ir muito longe. E se ele demora demais para entregar valor, também não.

A chave aqui é entregar valor continuamente, em pequenas porções mas frequentes, deixando sempre o cliente satisfeito e com um “gostinho de quero mais”. A cada iteração do Scrum (sprint), um incremento de produto é entregue ao cliente, um que gera valor ao mesmo. É assim que tem que ser em todos os projetos.

Você nunca terá como entregar tudo o que o cliente quer, no prazo que ele quer e dentro do orçamento dele. Isso não existe!

Mas o processo de criar e priorizar um Backlog de Produto garante que as exigências de maior valor ao cliente sejam atendidas primeiramente e que o valor que ele tanto busca (não confunda valor com custo) seja entregue em partes, à cada iteração.

Uma abordagem colaborativa com stakeholders (como a do Scrum) e a ênfase no valor de negócio, garantem uma estrutura orientada para o cliente. E não orientada ao software.

Lembre-se: seus clientes não querem seus softwares. Eles querem o valor gerado pelos mesmos. Eles querem ser “melhores” do que eram antes de comprar seu software.

#6 – Eficiência

O Time-boxing e a minimização de trabalho não-essencial conduzem a níveis mais altos de eficiência.

Eu sou obcecado por eficiência. Admito.

Já escrevi aqui no blog sobre como conduzir reuniões mais eficientes, sobre como ser uma pessoa mais eficiente e muitas outras dicas nesse mesmo sentido. E o Scrum, o meu framework ágil favorito prioriza a eficiência, por isso que o amo. S2

As coisas mais excêntricas existentes no Scrum são em prol da eficiência. E por isso que seguir o Scrum à risca é tão importante, principalmente em equipes imaturas do ponto de vista de agilidade.

Pense nas time-boxes: restrições pétreas quanto à duração de eventos no ciclo de desenvolvimento. Sprints de x semanas. Reuniões de x horas. E por aí vai. Isso não é algo negociável. Esse tipo de restrição estimula os desenvolvedores do time a pensar no que é mais importante ser desenvolvido HOJE rumo ao objetivo de AMANHÃ. Não há tempo a perder com coisas que não gerem valor à meta da sprint. Estimula o Product Owner a manter o backlog priorizado com o que realmente deve entrar no produto na próxima sprint, deixando para um futuro incerto o que não é essencial à aplicação.

Todos sabemos (ou deveríamos saber) que a falácia da próxima feature e a over-engineering são alguns dos piores maus que podem arruinar um projeto de software e até mesmo uma empresa. As restrições de tempo do Scrum (e as demais também) te ajudam a não cair nessas tentações, como essa outra, de reescrever todo o código da sua aplicação para que fique “melhor”, por exemplo.

#7 – Motivação

Os processos de conduzir a Reunião Diária e de Retrospectiva da Sprint conduzem a níveis mais altos de motivação entre os colaboradores.

Uma das chaves para a motivação é o que Simon Sinek chama de Golden Circle, neste brilhante vídeo. Conforme evidenciado não apenas nesse trabalho (do vídeo) mas em muitos outros, é necessário um ambiente de alta confiança para que o time se sinta motivado a seguir em frente em prol dos objetivos gerais da sprint.

Processos do Scrum (sim, ele ajuda nisso também) como a Reunião Diária e a Retrospectiva da Sprint promovem a transparência (pilar 1, lembra?) e a colaboração, resultando em um ambiente de trabalho de alta confiança, e garantindo baixo atrito entre os colaboradores, além de uma alta motivação, uma vez que o time tem o suporte e aval necessários para que consiga avançar sem impedimentos (né, sr. Scrum Master?!).

Quando os times confiam sem si mesmos e seus líderes confiam no time, a motivação se torna algo inabalável, gerando a responsabilidade coletiva e o comprometimento, que é o que todo gerente quer da sua equipe e toda empresa quer ver nos seus funcionários.

O processo de aprovar, estimar e comprometer-se às tarefas (ou histórias de usuário, casos de uso, etc) permite que os membros do time se sintam responsáveis pelo projeto e por seu trabalho, resultando em uma qualidade muito maior. Não importa se você vai usar planning poker ou não, mas se não houver confiança no time para tomar essas decisões, não haverá motivação para executar as tarefas.

Tudo começa na confiança!

#8 – Alta Velocidade

Uma estrutura de colaboração permite que os times multifuncionais atinjam o seu pleno potencial e alta velocidade.

Se o seu time vem vencendo nos demais quesitos como motivação, entrega contínua de valor, transparência, adaptação, etc você terá o que todo gerente de software almeja: alta velocidade!

Pausa para aquele momento em que uma música de cornetas toca e as nuvens se abrem para os céus porque você atingiu a iluminação.

Não, agilidade não é entregar software, pura e simplesmente, mais rápido. É sobre entregar valor mais cedo. Mas quando você entrega valor mais cedo, a percepção que TODOS tem (interna e externamente) é que o time está avançando mais rápido.

Pense comigo: o que vale mais, eu (um professor sedentário) correndo em linha reta por 100m ou o Usain Bolt correndo em zigue-zague para chegar no mesmo destino que está 100m à frente? É o mesmo para software!

Se você não está trabalhando com um backlog priorizado, não está entregando software com foco no cliente (ou seja, entregando valor pra ele), você está “andando em zigue-zague” rumo ao mesmo objetivo que poderia estar perseguindo em linha reta!

A alta velocidade obtida com o Scrum não está na quantidade de linhas de código que seu time vai escrever por sprint. Mas sim nas linhas certas que serão escolhidas para serem escritas. Aquelas que trarão os maiores resultados para o cliente em menos tempo.

Ponto.

Isso é velocidade, de maneira inteligente!

#9 – Ambiente Inovador

Os processos de Retrospectiva da Sprint e de Review da Sprint criam um ambiente de introspecção, aprendizagem e adaptabilidade, que levam a um ambiente de trabalho inovador e criativo.

Não custa repetir: transparência, inspeção e adaptação. Os três pilares do Scrum.

Esse ciclo virtuoso é a chave para a inovação. A inspeção e adaptação frequentes do Scrum levam o seu produto sempre aonde ele deve estar, agora, neste momento. E não conforme foi planejado um ano atrás com a diretoria em um lindo restaurante estrangeiro com todo mundo em seus belos ternos sob medida.

Ninguém sabe o amanhã, e embora seja extremamente válido (e aconselhável) definir as estratégias e médio e longo prazo, é a execução em curto prazo (aliado aos pilares do Scrum) que vão garantir a existência do projeto para TALVEZ chegar no destino desejado. Se ele ainda fizer sentido um ano depois de traçado.

A chance de revisitar o processo e ajustá-lo a cada sprint é única e dá ua vantagem muito grande ao time frente às metodologias tradicionais: a vantagem de poder errar. Mas errar rápido e aprendendo com esse erro, acertar.

Ninguém tem as respostas sobre como os softwares tem de ser desenvolvidos em todos os casos. Nem o Scrum. Mas se ele tem algo de valioso e memorável são que a inspeção e adaptação às mudanças devem ser o cerne dos projetos.

Be water, my friend!

Quer conhecer algumas práticas ágeis aplicáveis a qualquer time e empresa? Leia este artigo e assista ao vídeo abaixo.