9 vantagens de usar Scrum em seus projetos

700x395xteam.jpg.pagespeed.ic.f9By3MZ2aODesde 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.

#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!

bruce-lee

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!

John-Maxwell-Quotes-3-1024x678

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:

  1. Você constrói um incremento de produto
  2. Você mede o desempenho dele
  3. Você aprende com os erros e refina-o
  4. 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!

Os 6 princípios mais importantes do Scrum

chicken-n-pigTrabalho com métodos ágeis desde 2010. De lá pra cá, nestes 7 anos de estrada, vejo muitas equipes falharem na adoção do framework, seja pela disciplina inerentemente necessária à essa tarefa, seja pela displicência das equipes em realmente “fazer acontecer”.

Sinceramente não acredito que o “Scrum flácido” seja o principal causador dessas falhas, mas sim uma “mentalidade flácida”. Não são raros os times que acham que colocar o Scrum Guide embaixo do braço vai resolver todos os seus problemas de entregas fora do prazo, escopo indefinido, falta de comprometimento e muito mais.

Muito mais do que decorar as regras do Scrum, neste post sugiro que você se foque em entender os 6 princípios mais importantes por trás dessa famosa metodologia. O Scrum não funciona apenas por ter reuniões de 15 minutos em pé todos os dias. Ele funciona por causa dos princípios por trás de cada um dos seus eventos, papéis e, porque não dizer, “excentricidades”.

Resumidamente, os princípios são:

  1. Empirismo
  2. Auto-organização
  3. Colaboração
  4. Priorização baseada em valor
  5. Time-boxing
  6. Iterativo-incremental

Princípio 1: Empirismo

Você sabe o que é algo ‘empírico’?

É algo advindo do conhecimento prático, o oposto de algo que só funciona na teoria, entende?

Scrum é um framework empírico, criado com base em décadas de experiência dos seus fundadores à frente de projetos de software e essa é a filosofia central dele. Não apenas você deve acreditar nos anos de experiência dos srs. Ken Schwaber e Jeff Sutherland como Scrum enfatiza que você aprenda com a sua experiência ao longo das sprints.

Transparência, inspeção e adaptação, os três pilares do Scrum, lembra?.

Após rodar algumas sprints (da maneira correta, fazendo reviews e retrospectivas), você começará a gerar o seu próprio conhecimento empírico, realimentado o framework e aumentado a qualidade dos seus processos.

Princípio 2: Auto-organização

Esse aqui talvez seja o ponto mais falho, uma vez que nem todo mundo tem a disciplina de se auto-organizar. O fato é que as pessoas entregam significativamente um maior valor quando são auto-organizadas e isto resulta em times mais satisfeitos e responsabilidade compartilhada; e em um ambiente inovador e criativo que é mais propício ao crescimento.

Lembra da fábula da “galinha e o porco” (ilustrada no início desse post)? #oldbutgold

A galinha queria abrir um restaurante com o porco, sugerindo o nome “Ovos com Presunto”. No entanto o porco recusou. Isso porque ele estaria comprometido, enquanto a galinha estaria meramente envolvida.

Auto-organização requer um comprometimento altíssimo com os demais membros do time e com a empresa. É um princípio fundamental não apenas para o Scrum, mas para a vida da gente.

Princípio 3: Colaboração

Esse princípio concentra-se nas três dimensões básicas relacionadas com o trabalho colaborativo: consciência, articulação e apropriação. Também defende o gerenciamento de projetos como um processo de criação de valor compartilhado, com times trabalhando e interagindo em conjunto para atingirem melhores resultados.

No livro As 17 incontestáveis leis do trabalho em equipe, de John Maxwell, a primeira lei é a Lei do Monte Everest. Ninguém jamais conseguiu subir o monte Everest sozinho. Sabe por quê? Porque quanto maior o objetivo, maior a necessidade de se trabalhar em equipe, de maneira colaborativa.

Quando o time é competitivo e/ou quando os membros são egoístas, o objetivo do grupo não é alcançado, e muitas vezes os pessoais também não.

Princípio 4: Priorização Baseada em Valor

Esse princípio destaca o foco do Scrum em entregar o máximo de valor de negócio possível, durante todo o projeto.

Quando falamos que Scrum é um framework para desenvolvimento de produtos complexos, que seu cerne é entregar valor de maneira frequente e com qualidade, não estamos falando necessariamente de software. Esse é apenas o uso mais comum do framework.

Entregar valor é atender a demanda do seu mercado. É resolver o problema do seu cliente.

Não tem nada a ver com fazer over-engineering ou escovar bits. Lembra-se do Manifesto Ágil? Software funcionando é mais importante do que documentação abrangente. Eu diria mais, cliente satisfeito é mais importante que usar a linguagem de programação da moda. Que valor é mais importante que tecnologia.

Princípio 5: Time-boxing

O tempo é considerado uma restrição limitada em Scrum, e que ele deve ser usado para ajudar a gerenciar o planejamento e execução do projeto com eficácia. Os elementos Time-boxed em Scrum incluem os Sprints, as Reuniões Diárias, a Reunião de Planejamento da Sprint, e a Reunião de Revisão da Sprint.

Na verdade não só no Scrum, mas o conceito de time-boxing deve ser levado para toda a vida, se você deseja ser mais produtivo.

O princípio de eventos com prazo e duração limitados norteia-nos para que os objetivos sejam atingidos de maneira eficaz e eficiente.

É duro dizer a um colega do time que ele estourou o tempo que tinha para falar na reunião diária. Mas tenha a certeza que da próxima vez ele será mais objetivo, se quiser ser ouvido por completo.

É triste muitas vezes o time falhar na entrega porque faltava “apenas” mais um dia para terminarem as features. Mas tenha a certeza que na próxima sprint eles aprenderão com esse erro e estimarão melhor as tarefas. Ou se descuidarão menos com distrações e imprevistos.

Princípio 6: Iterativo-Incremental

Muita gente confunde iterativo com interativo. E não é um typo, existe um ‘n’ a mais na segunda palavra.

Iteração é uma execução de um laço, uma repetição. Um desenvolvimento iterativo-incremental é aquele cujas etapas se repetem indefinidamente, e a cada iteração, um novo incremento do produto é entregue pronto.

Mesmo que não use Scrum, desenvolver produtos de maneira iterativa-incremental é sempre uma boa ideia. Iterações e colaboração com o cliente garantem uma entrega alinhada com a percepção de valor do cliente, o que por sua vez gera uma maior qualidade no projeto como um todo.

Mesmo que não use Scrum, aplicar estes princípios em seus projetos não faz mal à ninguém, muito pelo contrário, faz muito bem.

Até a próxima!

Utilizando o Scrum em um time que não é de desenvolvimento

scrum4infra

No post de hoje abri espaço para o consultor de TI e gerente de projetos na Umbler, Jonas Salengue, falar da sua experiência implementando Scrum em times que não eram de desenvolvimento. Jonas é um profissional com muitos anos de mercado e já trabalhou em multinacionais, como a HP. Recentemente lançou um livro sobre Scrum para equipes de infraestrutura que está disponível à venda na Amazon.

Olá, sou o Jonas, consultor de TI e analista de infraestrutura. Sou um grande apreciador de desafios e foi dentro de um desafio que tive o contato na prática com o Scrum pela primeira vez. Recebi o pedido de ajuda de um líder de uma equipe de infraestrutura que enfrentava dificuldades para controlar as atividades do dia-a-dia e projetos da sua área, então decidi apostar no Scrum como solução para este problema.

Antes de relatar alguns detalhes desta experiência, gostaria de agradecer ao Luiz (autor do blog) por este espaço. O Luiz é um com certeza uma referência no Scrum com algumas obras excelentes disponíveis na Amazon.

Utilizar o Scrum, independente da característica do time, deve ser um projeto com planejamento e adaptações adequadas. Dificilmente alguém utilizará 100% do que o framework descreve, pois isto acarretaria uma série de complicações, principalmente a resistência e, consequentemente, a desistência das pessoas. Saber como abordar os conceitos do scrum foi fundamental para que o time de infraestrutura “comprasse” a ideia de utilizá-lo. Para tal, utilizei uma dinâmica na qual descrevo em detalhes no livro, porém, resumidamente, trata-se da construção de uma maquete de uma casa utilizando os eventos, papéis e artefatos do framework.

Importante é que para a realização desta dinâmica, não foram utilizados os termos “técnicos” do Scrum, por exemplo, o backlog do produto nós o abordamos como “lista geral”, a sprint como “período de execução” e o backlog da sprint como “lista de execução”. Talvez seja mais interessante no início utilizar palavras e expressões que façam sentido ao pé-da-letra, pois, para esta experiência, fez toda a diferença. O próprio papel do Scrum Master foi apresentado como “facilitador” e na execução da dinâmica o time concluiu o porquê deste nome.

Após este trabalho de construção dos conceitos, garantimos que todos os integrantes do time estavam falando a mesma língua. Dai sim, começou-se o planejamento para adequar o framework à realidade do time de infra que possui características distintas, principalmente devido ao fato de prestarem suporte, ou seja, executarem várias demandas no dia-a-dia que concorrem com a execução das atividades planejadas dos projetos da área.

Basicamente utilizamos os eventos: planejamento da sprint, reuniões diárias, revisão e retrospectiva. Como artefatos definimos o backlog do produto e o backlog da sprint durante o planejamento desta. Inicialmente eu realizei o papel de Scrum Master, participando ativamente durante as 4 primeiras sprints do time. Ah, importante lembrar que desde o início utilizamos métricas através da pontuação das atividades com a técnica de planning poker. Essa técnica foi utilizada inclusive na dinâmica da casa para que o time já se tivesse contato e fosse desenvolvendo seu poder de estimar e controlar o progresso.

O resultado final desta adaptação do scrum para um time de infraestrutura foi um sucesso. Apesar de ter sido uma consultoria, algo temporário, mantenho contato com o time até hoje e continuam utilizando o framework. Eles mantém o controle do progresso dos projetos e demandas utilizando as métricas da pontuação das tarefas, construindo o gráfico burndown para representar as entregas planejadas versus o burnup que representa as demandas que surgem e devem ser atendidas durante as sprints.

Bem, resumidamente o livro aborda as questões que comentei acima, porém é claro, com muito mais detalhes e uma narrativa na qual procurei tornar interessante.

Confiram a obra em www.scrum4infra.com

Abraços e até!

Jonas

Deixem seus comentários para o Jonas no espaço abaixo, que eu aviso ele para ler!