Os 6 melhores livros para estudar metodologias ágeis

Vez ou outra eu recomendo livros que já li aqui no blog, geralmente relacionados à empreendedorismo, que é o que mais tenho lido nos últimos anos. Hoje resolvi falar de livros sobre uma outra paixão minha: gerenciamento ágil de projetos. Desde 2010, quando conheci e me especializei no uso de Scrum e outras metodologias ágeis que não parei mais de estudar e ensinar o assunto para outras pessoas.

Após algum treinamento ou palestra, sempre vem aquela pergunta: que livros você recomenda? Pois bem, aqui vão eles!

Os livros que eu recomendo são:

Clique nas capas para mais detalhes e para adquirir os livros. Não, eu não faço pirataria e não vou colocar (nem permitir nos comentários) livros para download que não sejam realmente gratuitos.

Boa(s) leitura(s)!

Guia do Scrum
Guia do Scrum

O Guia do Scrum

Download gratuito

Existe uma frase popular que diz: “O Scrum é um framework simples de entender, mas difícil de dominar”. Por que isso?

Estamos falando de um framework ágil, e não de uma metodologia de desenvolvimento de software como RUP, ou seja, não há uma receita pronta aqui, mas sim uma estrutura mínima a ser seguida em um eterno fluxo de construir-medir-aprender assim como o do Lean Startup. Há apenas esse livro gratuito, de 19 páginas, para ser estudado e praticado ad infinitum.

Este guia é a base para entender o básico do Scrum e deve ser usado, na minha opinião, como ponto de partida de qualquer equipe que queira se tornar ágil. No entanto, conforme a equipe avança e percebe a necessidade de mais ferramental e informações, entram os demais livros abaixo listados.

Aqui no blog tem um bom resumo dele, caso queira saber mais, neste post.

Scrum: A arte de fazer o dobro do trabalho
Scrum: A arte de fazer o dobro do trabalho

Scrum: A arte de fazer o dobro de trabalho na metade do tempo

Comprar na Amazon

O Scrum foi co-criado por Ken Schwaber e Jeff Sutherland. Esse sr. Jeff serviu como militar e mais tarde, durante vários anos, atuou como gerente de projetos em grandes empresas públicas e privadas incluindo o FBI, sendo que essas experiências foram adicionadas ao que mais tarde ele e sr. Ken chamariam de Scrum.

É um excelente livro que conta as aventuras de Jeff Sutherland na aeronática americana em meio à guerra do Vietnã e como isso influenciou seu modo de gerenciar projetos. Também conta como aprendeu os princípios do Lean, das artes marciais japonesas e como isso tudo influenciou seu modo de pensar e acabou originando o Scrum. Em meio às histórias das origens do Scrum, ele fala muito sobre princípios e conta cases de aplicações bem sucedidas, de software à jornalismo.

Sinceramente? É uma leitura prazerosa e rica, mas não ensina Scrum para ninguém, gosto de indicar pois ajuda a entender os princípios, o mindset que originou o Scrum.

Implementando o desenvolvimento Lean
Implementando o desenvolvimento Lean

Implementando o desenvolvimento Lean de software: Do Conceito ao Dinheiro

Comprar na Amazon

Outro excelente livro que li já tem vários anos, desta vez de Mary e Tom Poppendieck. A Mary é uma engenheira com algumas décadas de desenvolvimento nas costas, que fala muito bem sobre Lean Software Development, outra técnica adaptada da indústria japonesa Toyota para o mercado de software, assim como o Kanban e até mesmo o Scrum (em partes).

Assim como o livro “Scrum: a arte de fazer o dobro de trabalho na metade do tempo”, que citei logo acima, a autora se prende demais em contar cases de sucesso e acaba demorando para entrar no Lean em si. No entanto, é muito enriquecedor do ponto de vista de princípios.

Programação Extrema
Programação Extrema

Programação Extrema Explicada: Acolha as mudanças

Comprar na Amazon

De todos os livros que vou indicar aqui, este é o único que nunca li. No entanto, conheço a trajetória de seu autor principal, que hoje trabalha no Facebook como mentor dos desenvolvedores mais jovens, Kent Beck.

Este livro é indicado pois é a obra-prima de Kent Beck (com a ajuda de Cynthia Andres), um dos signatários originais do manifesto ágil, movimento que difundiu as metodologias ágeis pelo mundo, e criador também das metodologias TDD (Test Driven Development) e XP (Extreme Programming).

Apesar do XP ser uma metodologia “concorrente” ao Scrum (que é a minha favorita), há conceitos muito valiosos no XP que cobrem “furos” do Scrum, como Pair Programming, só para citar um exemplo. Vale a indicação.

SBOK
SBOK

Guia SBOK: Um guia para o conhecimento em Scrum

Download gratuito

A Scrum Study é uma empresa que dá cursos e aplica provas de certificação em Scrum (embora eu sugira fazer direto com a Scrum.org) e, o SBOK (Scrum Body of Knowledge), é o guia que eles criaram (em analogia ao PMBOK) para ajudar que profissionais consigam tangibilizar melhor a adoção do Scrum em seus projetos, uma vez que o Guia do Scrum original não ajuda muito neste ponto.

O Guia SBOK tem vários pontos positivos e negativos: ele é muito útil ao discutir mais à fundo alguns conceitos pouco explorados no Guia do Scrum, levantar questões importantes e ensinar algumas novas técnicas de aplicação. Por outro lado, cria termos novos que não necessariamente (na minha opinião) enriquecem o Scrum, apenas complicam-o.

Enfim, é uma leitura muito boa que as vezes eu revisito para lembrar de algumas coisas.

Scrum e Métodos Ágeis
Scrum e Métodos Ágeis

Scrum e Métodos Ágeis: Um Guia Prático

Comprar na Amazon

E por último, mas não menos importante, o livro que eu escrevi sobre Scrum e Métodos Ágeis em 2016. Trabalho com Scrum desde 2010, principalmente como Scrum Master, o responsável por garantir e aperfeiçoar os processos dentro do time. Depois de tantos anos, Sprints e times diferentes, resolvi exteriorizar o que eu considero que funcionou nos times que eu trabalhei para complementar o Guia do Scrum, ou seja, não é um substituto ao Guia do Scrum, mas um adendo ao mesmo.

O Scrum fala por exemplo sobre fazer a Sprint Planning, mas não te diz como estimar as tarefas. Ele fala a Definição de Pronto, mas não te diz como criá-la. Fala sobre transparência no projeto, mas não te dá dicas de como alcançá-la. O meu livro procura preencher estas lacunas e só coloquei ele aqui por último na lista para não soar favoritismo. Mas eu realmente acho que ele é um bom livro. 🙂

5 técnicas para minimizar riscos de projetos oriundas do Scrum

Enquanto na função de gerente de alguns projetos, uma de minhas missões é minimizar ao máximo os riscos de cada um dos projetos. São vários os tipos de riscos inerentes a projetos de software, tais como:

  • risco de estourar o prazo;
  • risco de estourar o orçamento;
  • risco de não obter o retorno do investimento (ROI);
  • riscos tecnológicos;
  • riscos de pessoal;
  • etc

Obviamente não existe uma maneira de gerenciar um projeto 100% à prova de riscos e por isso me empenho o máximo que posso ao mesmo tempo que me preparo para imprevistos. As metodologias ágeis, e especialmente o Scrum (assunto principal do meu livro), foram criados exatamente para lidar com as incertezas dos projetos, ao contrário de metodologias mais tradicionais que tentam planejar tudo, em todos os detalhes, antecipadamente ao início do desenvolvimento.

Muitos gerentes mais tradicionais enxergam métodos ágeis como um risco a ser evitado, entendem que é mais seguro continuar do jeito tradicional de gerenciar projetos. No entanto, é exatamente o contrário. Sendo um processo iterativo e ágil, o framework Scrum inerentemente minimiza o risco ao abraçar as incertezas e inclui-las na pauta dos projetos. No artigo de hoje vou listar as práticas do Scrum que facilitam o gerenciamento eficaz de risco:

  1. Flexibilidade de escopo
  2. Feedback regular
  3. Empoderamento do time
  4. Transparência
  5. Entrega iterativa

Vamos lá!

Flexibilidade de escopo

Você sabia que os pinheiros mais antigos não são os mais fortes? São os mais flexíveis. Quando acontecem as tempestades, os primeiros pinheiros que quebram são aqueles que não se torcem ao vento, que não se adaptam, que tentam se manter rígidos e impassíveis em qualquer situação.

Da mesma forma, a flexibilidade de escopo  reduz o risco do projeto em relação ao ambiente externo. Tendências aparecem. Clientes desaparecem. Crises acontecem. O mercado muda. Você tem de ser o mais resiliente possível se quiser se manter no “jogo”.

O risco é, em grande parte minimizado em Scrum, devido à flexibilidade de adicionar ou modificar requisitos em cada iteração durante o ciclo de vida do projeto. Isso permite que a organização possa responder às ameaças ou oportunidades do ambiente de negócios e as necessidades imprevistas, sempre que surgirem, geralmente com custo baixo de gerenciamento.

Feedback regular

Você sabe o que significa a palavra feedback? Retroalimentação. Ou seja, “alimentar de volta”. Do ponto de vista de gerência de projetos, você inicia o projeto “alimentando” (feeding) seu time com informações sobre o projeto e espera que, regularmente, você seja “retroalimentado” (feedbacked) sobre como anda o mesmo.

Ciclo de Feedback
Ciclo de Feedback

O feedback regular é útil para diversas situações e estados do projeto, como ajudar a manter o foco no objetivo final, corrigir deficiências nos processos e especialmente no caso de gerenciamento de riscos, ele reduz as expectativas relacionadas com o risco. Isso é útil tanto nos casos em que o projeto está indo bem, quanto no caso contrário, afinal, é melhor saber que há algo de errado o mais cedo possível, e não no dia anterior à entrega, certo?

Sendo iterativo, o framework Scrum dá ampla oportunidade para a obtenção de feedback e definição de expectativas ao longo do ciclo de vida do projeto. Isso garante que os stakeholders do projeto, bem como o time, não sejam pegos de surpresa por má comunicação relacionada aos requisitos, por exemplo.

Empoderamento do time

Existe um vídeo muito famoso na Internet em que um gerente de projeto do Spotify apresenta a cultura de engenharia deles, que é uma evolução do Scrum em conjunto de uma série de técnicas ágeis. Em dado momento no vídeo, ele cita um gráfico de “alinhamento x autonomia” e como isso afeta os resultados obtidos enquanto um time.

alinhamento-x-autonomia
alinhamento-x-autonomia

Dê pouco alinhamento e pouca autonomia e você será aquele “gerentão” 1.0 que manda e a equipe tem de obedecer (isso ainda funciona no século XXI?), mesmo sem saber porque está trabalhando no projeto. Dê pouco alinhamento e muita autonomia e sua equipe desperdiçará tempo e dinheiro da empresa pois não trabalhará em um objetivo comum. Dê muito alinhamento e pouca autonomia e sua equipe ficará frustrada, pois apesar de saber o objetivo, você ainda quer mandar no dia-a-dia deles e, bem, pessoas inteligentes não gostam disso.

Então o que sobra?

Muito alinhamento, para que todos saibam qual é o objetivo, o que deve ser feito. Mas o “como deve ser feito”, deixe para o time decidir (alta autonomia). Entre tantas responsabilidades que dar poder ao time tira dos ombros do gerente está o das estimativas de software. Deixar para o time estimar o tempo de desenvolvimento cria estimativas mais precisas, aumenta o engajamento e reduz os riscos, permitindo uma entrega oportuna de incrementos do produto.

Transparência

Lembra do que falei sobre a importância do alinhamento no tópico anterior? Para garantir que o time esteja sempre alinhado, e não apenas na reunião de planejamento do projeto, é vital que exista transparência no projeto. Nas decisões, nas métricas, nos objetivos, no andamento, etc. Dentre muitos benefícios de uma gestão transparente do projeto está a redução dos riscos não detectados inicialmente e a resolução proativa de muitos problemas.

O princípio de transparência do Scrum, em torno do qual o framework Scrum é construído, garante que os riscos sejam detectados e comunicados no início, levando a um melhor tratamento e mitigação de riscos. Além disso, quando as Reuniões Diárias do Scrum são realizadas, os impedimentos que um time está enfrentando atualmente, podem ser considerados um risco para outros projetos e times no futuro, e eles devem ser tratados e registrados de forma que não se repitam.

Entrega iterativa

O método de desenvolvimento de software mais tradicional de todos é o Cascata (Waterfall). Ele possui esse nome pois é um método composto por fases bem definidas, onde cada uma acontece de uma vez, em ordem linear, do início ao fim do projeto, ou seja, do levantamento de requisitos até à implantação no cliente. Como você deve saber, existem projetos de software que duram anos e empregam dezenas ou até centenas de desenvolvedores. Qual a chance de uma especificação de software feita há anos atrás ainda representar a realidade do cliente hoje? Ou a realidade do mercado?

O que acontece na prática é que não temos como prever o futuro diante das incertezas da construção de software moderno, principalmente web e mobile. Se começarmos a definir “no detalhe” como o software será daqui há alguns anos, estaremos apenas chutando, na melhor das hipóteses.

Entregar o projeto iterativamente, em ciclos curtos de algumas semanas, gera valor e valida o andamento do projeto com o cliente a cada iteração, reduzindo significativamente os riscos do mesmo, tanto para você, quanto para seu cliente.

Afinal, gerenciar riscos de projetos não é exatamente isso, que todos se saiam bem sucedidos ao final do mesmo? Ou você ainda tem aquele mindset que o Manifesto Ágil condena de ficar se defendendo atrás de um contrato?

Deixe nos comentários a sua opinião!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis clicando no banner abaixo pra aprender muito mais!

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!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis clicando no banner abaixo pra aprender muito mais!