Resenhas - Scrum

Samy 26/05/2019

Um pouco de Scrum
Em uma leitura fluida é possível aprender sobre as principais atividades, papéis, conhecer a origem e desenvolvimento do Scrum.

O livro é bom e consegue transmitir bastante o que é o Scrum, achei um pouco exagerada a idealização apresentada no livro, trabalho com Scrum e acho ótimo, no time ainda temos muito a nos desenvolver, porém o livro faz parecer muito fácil e mágico e a realidade é consideravelmente mais difícil.

De forma geral gostei do livro e recomendo principalmente para quem deseja conhecer um pouco sobre a metodologia.

Dorgi.Barros 19/04/2019

Importante pra quem quer ter um gostinho do que está por vir em matéria de modelos de trabalho e essencial para quem deseja atuar em áreas de tecnologia e afins.
Apesar do título sugerir alguma espécie de método milagroso pra alcançar resultados, o livro se baseia em experiências reais e ensina aprofundadamente como a metodologia ágil SCRUM pode contribuir para o avanço rápido em empresas. Esse é basicamente o método usado por todas as grandes empresas de tecnologia de hoje em dia e pode ser aplicado em praticamente qualquer área de atuação, melhorando não só a eficiência, mas a autonomia e a satisfação das equipes que aplicam as técnicas ensinadas. Importante pra quem quer ter um gostinho do que está por vir em matéria de modelos de trabalho e essencial para quem deseja atuar em áreas de tecnologia e afins.

@moisesffelipe 31/03/2019

Uma nova forma de se organizar equipes.
Esse livro traz vários exemplos de como o scrum pode revolucionar a organização de qualquer tipo de trabalho em equipe. Foi interessante ler que essa metodologia de trabalho pode ser aplicada inclusive em um canteiro de obras.

Jeromix 06/02/2019

Não cumpre o que promete, mas é uma boa leitura
Livro bem escrito (e traduzido), de leitura fluida e leve. Mas ele não cumpre o que promete, não passando de um livro de autopromoção do autor. O livro “Sprint” é bem mais didático e realmente cumpre sua premissa.

Elaborada para o ambiente empresarial/corporativo, especialmente nos setores de P&D mas também válido para startups, a importância do livro se encontra em apresentar um olhar crítico perante metodologias produtivas tradicionais – tidas como “o modo correto de fazer”– e apresentar um outro olhar mais atualizado à época que estamos, propiciando um método mais ágil e com maior precisão na busca por resultados.

Não é um livro prático, ou um guia de como fazer – neste caso, o “Sprint” é muito melhor. Mas as histórias contadas são muito boas, sendo apresentadas nos mais variados e inusitados exemplos. Ainda assim, o livro soa muito mais como autopromoção do autor do que qualquer outra coisa.

É preciso deixar claro que o “Scrum” seria uma parte intermediária de uma metodologia projetual muito maior e mais demorada. Assim, tem-se que o "Sprint" faz parte do "Scrum", e este faz parte de uma metodologia projetual maior e variada, como o "Design Thinking". Em resumo: Sprint < Scrum < Design Thinking.

nataliardasilva 21/01/2019

Nota 3
Achei interessante o conceito do Scrum e sua finalidade, entender as facilidades que tal método traz para aplicação na rotina seja do trabalho ou pessoal.
No entanto, o autor enrola muito nesse livro, são muitas páginas que acaba por se tornar entendiante e a leitura se arrasta.
Indico a leitura e conhecimento do método ágil do Scrum, mas não através desse livro e sim de outro que seja mais objetivo.

Paulo @paulocorrea.br 17/01/2019

Scrum
Recomendo a leitura. É um livro com apresentação inicial das práticas e aborda também suas origens de produtividade ágil. Fácil de ler com escrita fluída e de apresentação lógica e própria para quem deseja espelhar-se nas melhores práticas de produtividade e sentir-se encorajado na busca de resultados superiores.

Hilde 13/01/2019

Um guia simples
O livro basicamente traz os principios do scrum de forma simples e clara, podendo ser aplicado a qualquer coisa na vida de tarefas simples a mais compexa. Leitura obrigatória para quem deseja uma certificação.

Bruno.Felipe 28/12/2018

Um ótimo livro
Neste livro, Jeff Sutherland nos guia pela história e conceitos do scrum com linguagem relativamente simples e, ainda assim, bem detalhada.

Laio 09/12/2018

Leitura um pouco cansativa!
O livro detalha todos os pontos importantes do SCRUM, com exemplos do começo ao fim! O ponto ruim é que as vezes parece que tem exemplos demais e a leitura fica um pouco cansativa!

Moitta 05/11/2018

Scrum
um sistema em cascata – , era completamente falho. Em vez dele, as melhores empresas usavam um processo de desenvolvimento em sobreposição que era mais rápido e mais flexível. As equipes eram multifuncionais. Tinham autonomia. Recebiam a autoridade para tomar as próprias decisões. E tinham um objetivo transcendente. Estavam em busca de algo maior do que elas mesmas. A gerência não impunha ordens. Em vez disso, os executivos eram líderes que prestavam serviços aos funcionários e eram facilitadores focados em retirar os obstáculos do caminho das equipes, em vez de determinar o que tinham de fazer e como deveriam desenvolver o produto. Os professores japoneses comparavam o trabalho de equipe a um time de rúgbi, e diziam que as melhores equipes agiam como se estivessem em um scrum: “A bola é passada pelo time conforme ele avança, em unidade, pelo campo.”


A abordagem de MacArthur para reconstruir a economia foi demitir a maioria dos altos gerentes nas empresas japonesas, promover os gerentes de produção e importar especialistas em operações de negócios, como Deming, dos Estados Unidos. A influência de Deming na indústria japonesa foi impactante. Ele treinou centenas de engenheiros no que chamamos “controle estatístico de processo”. A ideia básica é medir exatamente o que está sendo feito, assim como a qualidade do que é executado, e lutar por um “aprimoramento contínuo”. Não melhorar apenas uma vez; melhorar constantemente. Sempre procurar algo que possa ser aprimorado. Nunca, jamais, se acomodar. Para chegar lá, é preciso criar o tempo inteiro testes para verificar se é possível alcançar resultados melhores. Será melhor se eu tentar esse método? E quanto a esse outro? E se eu mudar esse pequeno detalhe?


[...] não importa que seus técnicos sejam excelentes, vocês, líderes, devem buscar sempre o aprimoramento da qualidade e a uniformidade do produto para que seus técnicos consigam fazer melhorias. Portanto, o primeiro passo pertence à gerência. Em primeiro lugar, os técnicos da sua empresa e suas fábricas precisam saber que vocês se dedicam fervorosamente ao avanço da uniformidade e da qualidade dos produtos e a um senso de responsabilidade em relação à qualidade do produto. Nada acontecerá se vocês apenas falarem sobre o assunto. As ações são importantes.


E o método para agir, que talvez seja a razão para Deming ter se tornado tão famoso, é o ciclo PDCA


Quando treino profissionais para usar o Scrum, é este o exemplo que uso: aviões de papel. Divido as pessoas em equipes e digo a elas que o objetivo é produzir o maior número possível de aviões de papel capazes de voar até o outro lado da sala. Há três funções a serem desempenhadas em cada equipe. Alguém verifica quantos aviões conseguem de fato voar. Outro indivíduo trabalha na produção, mas também presta atenção ao processo em si e busca maneiras de fazer com que a equipe construa aviões melhores e acelere a montagem. Os demais participantes devem se concentrar em fazer a maior quantidade possível de aviões capazes de atravessar a sala no tempo estipulado. Em seguida, digo que vamos fazer três ciclos de seis minutos para a fabricação dos aviões. As equipes têm um minuto de cada ciclo para planejar (P) como farão a montagem, três minutos para fazer (D) – construir e testar o maior número possível de aviões que realmente voem – e, por fim, dois minutos para verificar (C). Nessa fase, a equipe procura formas de melhorar o processo. O que deu certo? O que deu errado? O design deve ser alterado? Como a construção pode ser melhorada? Então, vem o momento da ação (A). Para Deming, “agir” significa mudar o modo de trabalho com base em resultados reais e informações reais extraídas do ambiente em questão. É a mesma estratégia usada pelo robô de Brooks.


Shu Ha Ri, que estabelece diferentes níveis de domínio. No estado Shu, você conhece todas as regras e formas e as repete, como se fossem os passos de uma coreografia, para que o seu corpo as assimile. Você não desvia. No estado Ha, uma vez que já domina as formas, você pode inovar, acrescentar um novo passo à coreografia. No estado Ri, você é capaz de deixar as formas de lado. Você realmente domina a prática e é capaz de ser criativo de uma forma desimpedida, porque o conhecimento do que o aikido – ou o tango – significa está tão profundamente entranhado em seu ser que todos os seus passos manifestam a essência dessa arte.


Hesitação significa morte. Observar, Orientar, Decidir, Agir. Saiba onde você está, avalie suas alternativas, tome uma decisão e aja! Olhe para fora para obter respostas. Sistemas adaptativos complexos seguem algumas regras simples, que são captadas do ambiente. Equipes excelentes são. Elas são multifuncionais, autônomas e capacitadas, com um propósito transcendente. Não adivinhe. Planeje, faça, verifique, aja. Planeje o que você vai fazer. Faça. Verifique se o produto alcançou o resultado desejado. Aja em relação a isso e mude a forma como está fazendo as coisas. Repita o processo em ciclos regulares e, dessa forma, alcance um aperfeiçoamento contínuo. Shu Ha Ri. Primeiro, aprenda as regras e as formas. Quando tiver domínio delas, inove. Por fim, em um estado elevado de mestria, descarte as formas e apenas seja – com todo o conhecimento internalizado e as decisões tomadas quase inconscientemente.


No artigo “The New New Product Development Game”, que descrevia o que mais tarde se tornou o Scrum, os professores Takeuchi e Nonaka listaram as características das equipes que encontraram nas melhores empresas do mundo:
1. Transcendentes: Elas têm uma noção de propósito que vai além do comum. Esse objetivo autoconcebido lhes permite ultrapassar o trivial e alcançar o extraordinário. A decisão de não se contentar com a média, mas de ser grande, muda por si só a forma como a equipe se vê e o que é capaz de realizar.
2. Autônomas: As equipes são auto-organizadas e se autogerenciam. Podem decidir como executar o trabalho e têm o poder de fazer com que suas decisões sejam cumpridas.
3. Multifuncionais: As equipes têm todas as habilidades necessárias para completar o projeto. Planejamento, design, produção, vendas, distribuição. E essas habilidades alimentam e reforçam umas às outras. Um integrante de certa equipe projetou uma nova câmera revolucionária para a Canon e declarou: “Quando todos os membros da equipe trabalham em uma mesma sala, a informação de alguém se torna sua, e não é preciso fazer esforço algum para isso. Assim, você começa a pensar no que é a melhor opção, ou a segunda melhor, para o grupo como um todo, e não apenas do seu ponto de vista.”


Ele era o produtor que estava no comando no local, mas, assim como um oficial de treinamento em West Point, um produtor da NPR é um facilitador e organizador – um ajudante ou um apoio, e não um típico gerente ou líder. O trabalho de J.J. era ajudar a equipe a fazer o melhor trabalho possível. Não era mandar, e sim lhes proporcionar o que fosse necessário.

A cada um desses ciclos, J.J. falava com os repórteres e fazia três perguntas muito simples: o que você fez desde a última vez que nos falamos? O que você vai fazer antes de nossa próxima reunião? E quais são as dificuldades que você está enfrentando? Essas perguntas – que constituem um dos rituais do Scrum – faziam com que os correspondentes falassem e compartilhassem suas experiências uns com os outros. E a principal tarefa de J.J., que na prática atuava como o Scrum Master, era se assegurar de que as dificuldades que a equipe enfrentava em uma reunião fossem eliminadas antes da seguinte.


A terceira perna do tripé das grandes equipes é que elas tenham todas as habilidades necessárias para realizar as tarefas.


“Você faz parte de qual equipe?” Se ele ou ela responder mencionando o produto em que está trabalhando (por exemplo, automação ou integração), em vez da sua especialidade (engenharia de redes), ela assente em aprovação. Quando um especialista se identifica com sua especialidade mais do que com o produto que está desenvolvendo, Dourambeis sabe que ainda tem trabalho pela frente.


O que eles fizeram foi criar uma equipe multifuncional que tinha todas as habilidades necessárias para executar o trabalho. Em vez de manter esses especialistas em grupos separados e que raramente trocam informações,

Trata-se de uma das principais razões pelas quais o Scrum foi desenvolvido: toda vez que há uma passagem de bastão, existe a possibilidade de que um desastre aconteça.


As equipes com integrantes de diversas agências tornam possível a eliminação das fissuras entre os diferentes atores da coalizão no Iraque, mantendo alvos de alto valor sob a mira de um “olho que nunca pisca”. [...] A passagem de incumbências entre unidades e organizações representava um “piscar de olhos organizacional”, durante o qual o ímpeto diminuía e o alvo podia escapar.


Não é só porque a multifuncionalidade pode gerar ótimos resultados que você deve bancar o Noé e pegar dois indivíduos de cada área para a sua equipe. Essa dinâmica só funciona bem em grupos pequenos. A configuração clássica é de sete pessoas, podendo-se acrescentar ou eliminar duas delas, embora eu já tenha visto grupos que funcionavam muito bem com apenas três integrantes. O mais fascinante é que os dados mostram que, se mais de nove pessoas são incluídas em uma equipe, a velocidade diminui.


O que nos leva de volta a Brooks. Quando tentou desvendar por que acrescentar mais pessoas fazia com que um projeto demorasse mais, ele descobriu dois motivos. O primeiro é o tempo que os indivíduos levam para entrar no ritmo. Como é de esperar, fazer com que um novo integrante entre no ritmo acaba desacelerando todos os outros membros da equipe. O segundo motivo tem a ver não apenas com a forma como pensamos, mas também, quase literalmente, com o que nossos cérebros são capazes de pensar. O número de canais de comunicação aumenta de maneira radical de acordo com a quantidade de pessoas, e nosso cérebro não consegue lidar com isso.

Se quiser calcular o impacto do tamanho de um grupo, pegue o número de integrantes de uma equipe, multiplique-o por esse mesmo número menos um, e divida o resultado por dois. Canais de comunicação = n (n – 1)/2. Por exemplo, se houver cinco indivíduos, haverá dez canais. Seis indivíduos, quinze canais. Sete, 21. Oito, 28. Nove, 36. Dez, 45. Nosso cérebro não é capaz de lidar com tantas pessoas ao mesmo tempo. Não sabemos o que todo mundo está fazendo. E diminuímos o ritmo enquanto tentamos descobrir.


Assim como em uma equipe das Forças Especiais, todos os integrantes de uma equipe do Scrum precisam saber o que todos os outros estão fazendo. O trabalho que está sendo realizado, os desafios que estão sendo enfrentados e o progresso que é feito precisam ficar claros para todo mundo.


“Scrum Master”. Ele ou ela conduziria todas as reuniões, se certificaria de que houvesse transparência e, o mais importante, ajudaria a equipe a descobrir o que estava atrapalhando o andamento do projeto.


quando põe a culpa em outra pessoa, você encontra falhas pessoais nela, enquanto se você for apontado como culpado, torna-se muito mais consciente dos fatores situacionais que levaram ao problema e do motivo pelo qual você agiu de determinada forma. Sabe por quê? Quando fala sobre si próprio, você está completamente certo. No entanto, quando fala sobre os outros, comete um dos erros humanos mais comuns – e destrutivos – no julgamento das ações de terceiros. Tem até um nome: “Erro fundamental de atribuição”.
Todo mundo faz isso. Temos a impressão de que reagimos às situações, mas achamos que os outros são motivados por sua personalidade.


Os autores de Induction traçam um paralelo interessante entre o modo como pensamos erroneamente sobre motivações sociais e como indivíduos que não são cientistas ou que têm apenas um entendimento intuitivo da física enxergam o planeta. Um físico intuitivo talvez explique por que uma pedra cai dizendo que a pedra tem a característica intrínseca da gravidade, em vez de afirmar que a gravidade é parte de um sistema de forças que age sobre a pedra. Da mesma forma, quando falamos sobre os outros, mencionamos suas propriedades inerentes, e não enxergamos a relação dessas propriedades com o ambiente externo. Na verdade, são as interações com o ambiente que guiam nosso comportamento. É o sistema à nossa volta, e não uma qualidade intrínseca, o responsável por grande parte de nossa conduta. O Scrum é projetado para modificar esse sistema. Em vez de procurar culpa e falha, ele recompensa comportamentos positivos ao fazer com que as pessoas se concentrem em trabalhar em conjunto e completar as tarefas.


Pessoas comuns, simplesmente fazendo seu trabalho, e sem qualquer hostilidade pessoal específica, podem se tornar agentes de um terrível processo destrutivo. Além disso, mesmo quando os efeitos destrutivos de seu trabalho se tornam evidentes e pedem que elas executem ações incompatíveis com padrões morais fundamentais, relativamente poucas pessoas têm os recursos necessários para resistir à autoridade.

Quando esse experimento é debatido em sala de aula, em geral destaca-se para os alunos que o culpado é o sistema dentro do qual as pessoas comuns agiram, e não os próprios indivíduos. Mas internalizar essa lição é uma tarefa difícil, porque, se aceitarmos que é verdadeira, o que ela diz sobre você? O que ela afirma é que somos todos criaturas do sistema do qual fazemos parte. O Scrum aceita essa realidade e, em vez de procurar alguém para culpar, tenta examinar o sistema que produziu o fracasso e consertá-lo.

Quantos daqueles que foram informados de que precisavam ir rápido pararam para ajudar? Dez por cento. Dos seminaristas. Ainda assim as pessoas querem culpar os indivíduos, e não os sistemas. A sensação é melhor. O erro fundamental de atribuição atrai nosso senso de justiça. Se pudermos culpar alguém, nos isolamos da possibilidade de que faríamos o mesmo – de que temos tanta probabilidade de apertar o botão quanto qualquer um, se nos encontrarmos nas circunstâncias adequadas.


A chave é estabelecer a estrutura correta, com os incentivos certos, e dar aos indivíduos a liberdade, o respeito e a autoridade de fazer coisas por conta própria. A grandeza não pode ser imposta; ela precisa vir de dentro. Mas ela existe dentro de cada um de nós.


RESUMO
Puxe a alavanca certa. Mude o desempenho da equipe. Isso tem muito mais impacto – muito mais mesmo – do que o desempenho individual. Transcendência. Equipes excelentes têm um propósito maior do que o individual. Por exemplo, enterrar o general MacArthur ou ganhar o campeonato da NBA. Autonomia. Dê às equipes liberdade para tomar decisões sobre como agir – para que sejam respeitadas como referência em suas respectivas áreas. A capacidade de improvisar fará toda a diferença, não importa se o grupo está cobrindo uma revolução no Oriente Médio ou vendendo algo. Multifuncional. A equipe precisa ter todas as habilidades necessárias para completar um projeto, não importa se a missão é produzir software para a Salesforce.com ou capturar terroristas no Iraque. Menor é melhor. Equipes pequenas trabalham mais rápido do que as grandes. A regra básica é que o ideal são sete integrantes – mais ou menos dois. Eu diria que menos. A culpa é idiota. Não procure as pessoas ruins, procure os sistemas ruins – aqueles que incentivam comportamentos errados e recompensam desempenhos fracos.



A velocidade com que trabalhavam se devia a uma política que o Laboratório de Mídia estabelecera para todos os projetos. A cada três semanas, as equipes precisavam mostrar para os colegas o que estavam fazendo. Era uma demonstração aberta; qualquer um podia aparecer. E, se o produto demonstrado não funcionasse ou não fosse legal, os diretores do laboratório cancelavam o projeto. Isso obrigava os estudantes a desenvolver coisas legais com rapidez. E, além disso, o que era ainda mais importante, fazia com que tivessem feedback imediato.


No entanto, um elemento crucial de um sprint é que, assim que a equipe se compromete com aquilo que realizará, as tarefas sejam fixas. Nada mais pode ser acrescentado por alguém de fora da equipe.


Ele então mapeou todos os fluxos de comunicação entre a equipe – quem falava com quem, quando a informação fluía e quando ela emperrava. Esse tipo de mapeamento é uma ferramenta que pode ser usada para identificar gargalos ou indivíduos que prendem informações. Quanto maior a saturação de comunicação – quando todo mundo fica sabendo de tudo –, mais rápida é a equipe. Basicamente, esse tipo de análise mede quanto cada um sabe sobre o que precisa para realizar seu trabalho. A Borland tinha o maior percentual já encontrado: 90%. A maioria das empresas tem cerca de 20%.


Como poderíamos atingir o mesmo nível de saturação em nossa equipe? O fator que atrapalha esse fluxo é a especialização – a quantidade de papéis e títulos em um grupo. Quando recebem um título especial, as pessoas tendem a fazer somente o que parece corresponder a ele. E, para proteger seu cargo, em geral tentam reter conhecimentos específicos.


O outro “ingrediente secreto” da Borland era que eles faziam reuniões diárias com todos os integrantes do grupo para discutir como ia o trabalho


A segunda regra era que a reunião não poderia durar mais do que quinze minutos. Queríamos que ela fosse ágil, direta, sem divagações. Se qualquer ponto demandava mais discussões, anotávamos a questão e nos reuníamos de novo mais tarde. A ideia era obter a maior quantidade possível de informações valiosas e úteis no menor intervalo de tempo possível. A terceira regra era que todos tinham de participar ativamente. Para ajudar nisso, pedi que todo mundo ficasse de pé.


O problema que surge com frequência é que as pessoas têm a tendência de tratar a reunião diária como um simples relatório individual. “Fiz isso”, “Vou fazer aquilo”, e passa para o próximo. A melhor abordagem se parece com as ocasiões em que os atletas se reúnem entre uma jogada e outra no futebol americano. Um deles pode dizer: “Estou tendo dificuldades com aquele defensor.” Outro responderá: “Deixa que eu cuido disso, vou abrir espaço para você.” Ou o quarterback poderá dizer: “Nosso ataque não está conseguindo passar pela defesa, vamos surpreendê-los com um passe pela esquerda.” A ideia é que a equipe debata rapidamente como prosseguir em direção à vitória, isto é, ao sucesso do sprint. A passividade não é apenas um comportamento preguiçoso, ela atrapalha o desempenho do resto do grupo. Quando identificada, precisa ser eliminada na mesma hora.


“Vocês querem mesmo ser péssimos para sempre? É esse o propósito que vocês têm para suas vidas? Porque se trata de uma escolha

Uma equipe precisa exigir excelência para si própria.


RESUMO
O tempo é finito. Trate-o como tal. Divida seu trabalho em partes que possam ser realizadas em um intervalo de tempo curto, regular e definido – de preferência entre uma e quatro semanas. Se você tiver sido contaminado pelo Scrum, chame esses períodos de sprints. É demonstrar ou falhar. Ao fim de cada sprint, tenha algo pronto –algo que possa ser usado (que alguém possa pilotar, dirigir, o que for). Jogue fora seus cartões de visita. Títulos são marcadores especializados de status. Seja conhecido pelo que faz, não pelo seu cargo. Todo mundo sabe de tudo. A saturação da comunicação acelera o trabalho. Uma reunião por dia. Quando se trata de reuniões para verificar como vai o trabalho, uma vez por dia é o suficiente. Junte sua equipe durante quinze minutos na reunião diária, analise o que pode ser feito para aumentar a velocidade e coloque em prática.


A essência do Scrum é o ritmo. O compasso é algo essencial para os seres humanos. A pulsação está presente em nosso fluxo sanguíneo e embrenhada em alguns dos recônditos mais profundos de nosso cérebro. Buscamos padrões, somos feitos para encontrar o ritmo em todos os aspectos da vida.


Ohno definiu três tipos de desperdício. Ele usou as seguintes palavras em japonês: Muri, o desperdício causado pela irracionalidade; Mura, o desperdício causado pela inconsistência; e Muda, o desperdício causado pelos resultados. Essas ideias se alinham com o ciclo PDCA de Deming, já mencionado: Plan, Do, Check, Act.
Planejar significa evitar o Muri (o desperdício causado pela irracionalidade). Fazer significa evitar o Mura (o desperdício causado pela inconsistência). Verificar significa evitar o Muda (o desperdício causado pelos resultados). E Agir se refere ao ímpeto, à motivação e à determinação de fazer tudo isso. Vou abordar esses passos, um de cada vez, e destacar o que evitar – o desperdício no estoque, o desperdício resultante de não fazermos tudo direito de primeira, o desperdício de trabalhar demais, o desperdício emocional causado por expectativas irracionais.


“As pessoas não realizam multitarefas porque são boas nisso. Elas o fazem porque são mais distraídas. Têm dificuldade para inibir o impulso de se dedicar a outra atividade.” Em outras palavras, quem costuma realizar várias tarefas simultâneas simplesmente não é capaz de se concentrar. Esses indivíduos não conseguem se impedir de pular de uma atividade para outra.


Tarefas incompletas e produtos que não estão sendo usados são dois aspectos da mesma coisa: esforço investido sem resultado positivo. Não faça isso.


Como mencionado antes, na Toyota, qualquer funcionário da fábrica pode parar a esteira. A ideia é que o processo seja melhorado continuamente e que o momento certo para corrigir um problema é quando ele é detectado, não depois de já ter se concretizado.

A mente humana é restrita. Conseguimos nos lembrar de um número limitado de coisas; só conseguimos concentrar nossa atenção em um elemento por vez. Esta tendência – de o processo para consertar algo ficar mais difícil à medida que o tempo passa – representa uma limitação parecida. Enquanto trabalha em um projeto, você cria um espaço em seu cérebro em torno dele. Sabe todos os diferentes motivos para algo ser feito. Sustenta uma arquitetura complicada em sua mente. Recriar essa arquitetura uma semana depois é difícil.


E, por fim, aconteceu algo que é um dos grandes benefícios desse método: a OpenView descobriu como as pessoas trabalham de fato, em vez de como dizem trabalhar.


Por que você produzirá mais se trabalhar menos horas? Isso não parece fazer nenhum sentido. Scott diz que quem trabalha horas demais começa a cometer erros, os quais, como vimos, demandam mais esforço para serem corrigidos do que criar algo novo. Funcionários que trabalham demais se tornam mais distraídos e começam a distrair os colegas. Em pouco tempo, todo mundo toma decisões ruins.

Basicamente, logo após uma pausa, os juízes tinham uma postura mais positiva e tomavam decisões mais tolerantes. Demonstravam mais imaginação e capacidade de enxergar que o mundo e as pessoas podem mudar. Entretanto, conforme queimavam suas reservas de energia, começavam a tomar cada vez mais decisões que mantinham o status quo. Se você perguntasse a esses juízes se eles tinham certeza de que estavam tomando decisões igualmente boas todas as vezes, estou certo de que eles se sentiriam ofendidos. Mas os números, assim como os sanduíches, não mentem. Quando não temos mais nenhuma reserva de energia, ficamos propensos a fazer resoluções inadequadas.

Esse fenômeno tem sido rotulado de “esgotamento do ego”. A ideia é que fazer qualquer escolha envolve um custo de energia. É um tipo estranho de exaustão: você não se sente fisicamente cansado, mas sua competência em tomar decisões diminui. Na verdade, o que muda é seu autocontrole – sua capacidade de ser disciplinado, cuidadoso e prudente.

Portanto, o número de decisões sensatas que você pode tomar ao longo de um dia é limitado. À medida que faz mais e mais escolhas, você corrói a capacidade de regular seu próprio comportamento. Começa a cometer erros, e pode acabar cometendo erros graves. Como mostra a Curva de Maxwell, decisões ruins prejudicam a produtividade.


Uma equipe que depende de ações heroicas para cumprir seus prazos não está trabalhando da maneira correta. Pular constantemente de uma crise para outra causa esgotamento, e não permite uma melhoria contínua e racional. Essa é a diferença entre um caubói que invade o recinto e salva a mocinha dos bandidos e um pelotão disciplinado de fuzileiros navais que libera uma zona de conflito.


Porém, como o mestre de kung fu, o monge, o dançarino ou a estrela da ópera poderão lhe contar, a disciplina é a raiz do fluxo. Não pode haver nenhum movimento desperdiçado, nenhum elemento estranho, somente a aplicação absolutamente focada de uma habilidade humana. Desperdício é qualquer coisa que distraia você disso. Se começar a pensar sobre o trabalho em termos de disciplina e de fluxo, é possível que você concretize algo incrível.


RESUMO
Realizar muita coisa ao mesmo tempo emburrece. Dedicar-se a mais de uma atividade simultaneamente faz com que você fique mais lento e tenha um desempenho pior nas tarefas. Não faça isso. Se estiver pensando que isso não se aplica a você, está errado. Isso serve para todo mundo. Fazer pela metade é igual a não fazer nada. Um carro fabricado pela metade engessa recursos que poderiam ser usados para gerar valor ou economizar dinheiro. Qualquer coisa “em andamento” custa dinheiro e energia, mas não dá nenhum retorno. Faça direito de primeira. Quando cometer um erro, corrija-o na mesma hora. Pare tudo o que está fazendo e se dedique a isso. Consertar o problema mais tarde pode demorar mais de vinte vezes o tempo que levaria para corrigi-lo no momento em que ele surgiu. Trabalhar demais dá mais trabalho. Ficar mais tempo no trabalho não faz com que você produza mais. Na verdade, faz com que produza menos. Trabalhar demais leva à fadiga e resulta em erros, o que faz com que você tenha que consertar aquilo que acabou de terminar. Em vez de trabalhar até tarde ou nos fins de semana, trabalhe em um ritmo sustentável apenas nos dias de semana. E tire férias. Não seja irracional. Objetivos desafiadores são motivantes; metas impossíveis são apenas deprimentes. Nada de heroísmo. Se precisa de um herói para concluir o trabalho, você tem um problema. Esforços heroicos devem ser vistos como uma falha de planejamento. Chega de políticas corporativas idiotas. Qualquer política que pareça ridícula provavelmente é ridícula. Formulários idiotas, reuniões idiotas, aprovações idiotas, padrões idiotas são isto mesmo: idiotas. Se seu escritório se parece com um cartum do Dilbert, mude isso. Nada de imbecis. Não seja um imbecil e não permita que esse comportamento ocorra. Qualquer um que crie caos emocional, inspire medo ou receio, humilhe ou diminua os outros precisa ser impedido de fazer isso. Busque o fluxo. Escolha a maneira mais suave e tranquila de fazer as coisas. O Scrum possibilita o máximo de fluxo possível.


O motivo é que a Medco cometeu um erro muito básico. O pessoal de lá pensou que poderia planejar tudo com antecedência.


Como já disse antes, o próprio ato de planejar é tão sedutor, tão atraente, que o planejamento em si se torna mais importante do que o plano. E o plano se torna mais importante do que a realidade. Nunca se esqueça disto: o mapa não é o terreno.


Infelizmente, essa fase de cálculo pode ser um processo do tipo “garbage-in, garbage-out”.* Os indivíduos envolvidos podem ser muito inteligentes, mas, ainda assim, não vão perceber que o que estão incluindo em seus gráficos de planejamento não passa de pensamento positivo.


E todo mundo concorda em seguir um caminho que aparenta ser ótimo naquele momento, mas acaba se mostrando um desastre completo. Quando questiona os indivíduos sobre a decisão tomada, você quase sempre descobre que eles tinham algumas ressalvas, mas não as expressaram porque achavam que o resto da equipe estava animado. As pessoas presumem que, se todo mundo concorda com algo, suas próprias ressalvas são bobas ou estão erradas, e ninguém quer parecer burro perante o grupo. Lembre-se de que esse tipo de decisão grupal não é uma falha individual, é uma falha humana.


Na literatura científica, esse efeito é explicado como uma “cascata informacional”. Sushil Bikhchandani, David Hirshleifer e Ivo Welch, autores do artigo “A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades”, descrevem o processo: “Uma cascata informacional ocorre quando o ideal para um indivíduo, tendo observado as ações daqueles à sua frente, é seguir o comportamento de quem o precedeu sem levar em conta sua própria informação.”


As pessoas presumem que as outras tomam boas decisões, mesmo que essas opiniões contradigam as suas próprias. Isso é ruim.


Quando está estipulando um prazo de entrega para um projeto multibilionário, ou tentando prever se vai conseguir aprontar tudo a tempo para o seu casamento, é fundamental que você tome suas próprias decisões. Use outras estimativas apenas para melhorar a sua, não para substituí-la. Outro problema bem conhecido é o que chamamos de “efeito halo”. Ele ocorre quando uma característica de algo influencia o modo como as pessoas percebem outras características da mesma coisa, não relacionadas à primeira.


Essa pesquisa foi corroborada por outros estudos ao longo dos anos, confirmando que, por exemplo, se alguém é bonito, todo mundo presume que também é inteligente e confiável.3 Mas o efeito halo vai muito além da mera beleza física; ele pode surgir em qualquer situação. Pesquisadores apontam, por exemplo, que as ONGs são frequentemente tratadas como grupos que praticam o bem, mesmo que não o pratiquem; que as montadoras de automóveis criam um carro “halo” para passar uma boa impressão para a linha inteira; e que o iPod deu um verniz cool a todos os produtos da Apple.


Tal como acontece com o efeito de contágio, as pessoas que se concentram no “halo” não analisam os dados reais. Em vez disso, elas são atraídas para algo que tem uma aparência positiva. De novo, essa falha não é proposital; trata-se da natureza humana. Combatê-la é bobagem, é como tentar lutar contra a força da gravidade. Mas você pode lidar com ela de forma inteligente.


A vantagem do método Delphi é que ele recolhe uma grande variedade de pontos de vista, tenta remover a maior quantidade possível de ideias preconcebidas e, com informações úteis porém anônimas, restringe as opiniões a uma estimativa geralmente aceitável. A parte ruim, para nossos propósitos, é que isso leva muito tempo.


Então é a vez da cozinha, e há um 3, um 8, um 13 e um 5 sobre a mesa. A pessoa do 3 diz que o cômodo é muito pequeno, portanto há menos área de parede para pintar do que nos quartos. O indivíduo que escolheu o 13 argumenta que levará muito tempo para instalar a proteção contra tinta nos armários e nas bancadas, e que todas as áreas pequenas precisarão ser pintadas com pincel, e não com rolo. A equipe seleciona rapidamente novas cartas. Agora o 3 se tornou um 8, e todo o resto permaneceu igual. Tudo próximo o suficiente, então o grupo soma os números, tira a média e passa para a próxima tarefa. Esse método incrivelmente simples evita qualquer tipo de comportamento de ancoragem, como o efeito de contágio ou o efeito halo, e permite que toda a equipe compartilhe seus conhecimentos a respeito de determinada tarefa. No entanto, é fundamental que as previsões sejam feitas pelo grupo que executará o trabalho, e não por quaisquer avaliadores “ideais”.


Essas histórias têm o tamanho adequado para que uma equipe as execute. É possível debater sobre como implementá-las. Elas são específicas o suficiente para serem postas em prática, mas não prescrevem como serão feitas. Lembre-se: a equipe decide como o trabalho será realizado, mas o que será feito é definido pelo valor do negócio. O conjunto de histórias que, unidas, podem se tornar a ideia de uma livraria on-line é muitas vezes chamado de um “Épico”. Ele é grande demais para ser executado por inteiro, mas inclui uma série de histórias menores que, somadas, formam uma única ideia.


Quando for escrever histórias ou elaborar uma lista de tarefas, é importante fazer duas perguntas: A história está pronta? E como você vai saber quando ela estiver concluída?


Bill diz que, para que uma história esteja pronta, ela precisa atender aos critérios invest: Independente. A história precisa ser acionável e “completável” por conta própria. Ela não deve ser intrinsecamente dependente de outra história. Negociável. Até que seja de fato executada, é preciso que a história possa ser reescrita. Dar margem para mudanças deve ser uma de suas características. Valiosa. Ela realmente entregará valor a um cliente, um usuário ou um stakeholder. Estimável. Você tem que ser capaz de dimensioná-la. Sucinta. A história precisa ser pequena o suficiente para que seja possível estimá-la e planejá-la com facilidade. Se for grande demais, você deve reescrevê-la ou dividi-la em histórias menores. Testável. A história precisa possuir um teste pelo qual ela deve passar a fim de ser declarada como concluída. Elabore o teste antes de executar a história.


Para cada história, deve haver tanto uma “definição de pronta” (como, por exemplo, “Será que ela satisfaz a todos os critérios invest?”) quanto, por fim, uma “definição de concluída” (como “Que condições precisam ser atendidas, em quais testes a história precisa passar, para que a gente encerre os trabalhos?”). Na prática, descobrimos que, se as histórias estiverem realmente prontas, a equipe duplicará a velocidade de implementação. E, se as histórias forem de fato concluídas até o fim de um sprint, as equipes podem dobrar a velocidade novamente. Esse é um dos truques necessários para fazer o dobro do trabalho na metade do tempo.


No Scrum, esse tipo de planejamento acontece a cada sprint numa reunião que é chamada de “planejamento do sprint”. Todo mundo se reúne, analisa a lista de histórias que precisam ser concluídas e diz: “O que podemos fazer neste sprint? Essas histórias estão prontas? Elas podem ser concluídas até o fim deste ciclo? Podemos, então, demonstrá-las para o cliente e apresentar valor real?” O segredo para responder a essas perguntas se encontra na velocidade com que a equipe está trabalhando.


RESUMO
O mapa não é o terreno. Não se apaixone pelo seu plano. É quase certo que ele esteja errado. Planeje apenas o necessário. Não tente projetar tudo com anos de antecedência. Planeje apenas o suficiente para manter suas equipes ocupadas. Que raça de cachorro é esta tarefa? Não estime em termos absolutos, como horas. Foi provado que os seres humanos são péssimos nisso. Calcule o tamanho das coisas de modo relativo – por exemplo, esse problema corresponde a que raça de cachorro, ou a qual tamanho de blusa (P, M, G, GG, GGG)? Ou, mais comumente, use a sequência de Fibonacci. Pergunte ao oráculo. Use uma técnica de cegamento, como o método Delphi, para evitar vieses, como o efeito halo, o efeito de contágio ou um simples raciocínio ruim de grupo. Planeje com o pôquer. Use o pôquer do planejamento para estimar rapidamente alguma atividade que precisa ser realizada. O trabalho é uma história. Pense primeiro em quem receberá o valor de algo, em seguida pense sobre o que esse algo é, depois por que essa pessoa precisa disso. Os seres humanos pensam por meio de narrativas, então dê uma narrativa a eles. Como X, eu quero Y, para que Z. Saiba sua velocidade. Toda equipe deve saber quanto trabalho consegue realizar em cada sprint. E também deve saber quanto pode aumentar essa velocidade ao trabalhar de modo mais inteligente e ao remover barreiras que diminuem seu ritmo. Velocidade × Tempo = Entrega. Uma vez que souber a sua velocidade, saberá em quanto tempo chegará ao destino. Defina metas audaciosas. Com o Scrum, não é tão difícil dobrar a produção ou cortar pela metade o tempo de entrega. Se você aplicá-lo da maneira certa, sua receita e o valor de sua empresa devem dobrar também.


Era racional e científico, então levei algum tempo para descobrir que, para empoderar as pessoas, para mudar a vida delas para melhor, eu também precisava mudar. Ao longo dessa primeira tentativa do Scrum, percebi que a verdadeira grandeza está profundamente enraizada na alegria. E que ser feliz é dar o primeiro passo em direção ao sucesso.


Até mesmo um pouco de felicidade leva a resultados muito melhores. As pessoas não precisam estar felizes de um jeito delirante, como se estivessem sempre no dia do casamento. Precisam estar somente um pouco mais felizes do que antes. Claro, torná-las ainda mais felizes tem um efeito ainda maior. Mas a mensagem que quero passar é simples: mesmo pequenos gestos podem ter um grande impacto. O Scrum se concentra em pegar esses pequenos detalhes e uni-los sistematicamente, construindo um andaime para o sucesso. Com apenas uma coisa de cada vez, você pode mudar o mundo de verdade.


Chegar a certo nível de produtividade e permanecer nele não é o suficiente; a ideia é examinar de forma constante os seus processos, de forma a melhorá-los o tempo todo e para sempre. Claro que é impossível atingir a perfeição, mas cada incremento em direção a ela é relevante.



Para ser eficaz, essa reunião requer certo nível de maturidade emocional e um ambiente de confiança. É essencial que todos se lembrem de que não estão procurando um culpado, mas sim examinando o processo. Por que isso aconteceu dessa forma? Por que não percebemos aquilo? O que faria com que trabalhássemos mais rápido? É crucial que as pessoas assumam a responsabilidade pelo processo e pelos resultados em equipe e busquem soluções em equipe. Ao mesmo tempo, os indivíduos precisam ter estrutura emocional para mencionar as questões que os incomodam de modo a buscar uma solução, e não de uma forma que pareça acusatória. E o resto do grupo tem que ter maturidade suficiente para ouvir o feedback, levá-lo em consideração e procurar uma solução, em vez de ficar na defensiva. A reunião de retrospectiva é a parte “Verificar” do ciclo Planejar-Fazer-Verificar-Agir (PDCA), de Deming. O segredo é alcançar o passo “Agir”, o kaizen, que é o que de fato mudará o processo e o tornará melhor da próxima vez. Compartilhar seus sentimentos não é o bastante; você precisa ser capaz de agir.


Ao fim de um sprint, cada integrante da equipe responde a algumas perguntas: 1. Em uma escala de 1 a 5, como se sente em relação ao seu papel na empresa? 2. Nessa mesma escala, como se sente em relação à empresa como um todo? 3. Por que se sente assim? 4. O que faria com que ficasse mais feliz no próximo sprint?


Dentro de algumas semanas, nossa velocidade aumentou de 40 para 120 pontos por sprint. Triplicamos a produtividade só de perguntar o que tornaria as pessoas mais felizes. Como resultado, nossos clientes ficaram mais felizes e nossa receita disparou de maneira drástica. Tudo o que precisei fazer foi começar a perguntar para a equipe “O que faria com que você ficasse mais feliz?” e, em seguida, tentar concretizar isso.


Quais são os elementos que realmente fazem as pessoas felizes? São os mesmos que produzem grandes equipes: autonomia, domínio e propósito.


Um elemento do Scrum que muitas vezes é um prelúdio para o alcance da autonomia, do domínio e do propósito é a transparência.


Quero que todos os funcionários da empresa se unam em torno de um único propósito. Pulverizar as pessoas em feudos informacionais só diminui a velocidade de todo mundo. Além disso, esse tipo de cultura gera suspeita e desconfiança. Divide uma empresa entre os grandes, que sabem de tudo, e os peões, que se limitam a executar pequenas tarefas para algum propósito misterioso que são incapazes de compreender. Besteira. Se não pode confiar nas pessoas que trabalham com você, isso significa que contratou os indivíduos errados e criou um sistema que carrega o fracasso em sua estrutura.


O Scrum fornece um alicerce para que isso seja feito. Ele oferece uma estrutura para a organização inteira caminhar em direção a um objetivo comum. Seus pilares são a transparência, o trabalho em equipe e a colaboração.


Você se lembra do erro fundamental de atribuição? Quando estiver cercado por idiotas, não busque as pessoas ruins; procure os sistemas ruins que as recompensam por agir dessa maneira. Em seguida, use a métrica da felicidade para consertar a situação.


todos conhecemos essa pirâmide de maneira intuitiva, mesmo que nunca a tenhamos visto. O truque é tentar escalar até as camadas mais altas e, em seguida, ter uma maneira de medir com precisão o impacto que você produz.


RESUMO
O que importa é a viagem, não o destino. A verdadeira felicidade é encontrada no processo, não no resultado. Muitas vezes só premiamos os resultados, mas devemos de fato recompensar as pessoas que se esforçam para obter excelência. A felicidade é a nova moda. A felicidade ajuda a tomar decisões mais inteligentes. Além disso, quando se está feliz, a pessoa é mais criativa, não quer largar o emprego e é mais propensa a realizar muito mais do que podia imaginar. Quantifique a felicidade. Sentir-se bem não é o suficiente; você precisa medir esse sentimento e compará-lo com o desempenho. Outras métricas se concentram no que já aconteceu. A felicidade é uma métrica que mira no futuro. Melhore a cada dia – e meça isso. Ao fim de cada sprint, a equipe deve escolher um pequeno aprimoramento, ou kaizen, que a tornará mais feliz. Esse elemento deve se tornar o objetivo mais importante do sprint seguinte. O sigilo é venenoso. Nada deve ser secreto. Todo mundo deve saber de tudo, e isso inclui os salários e as finanças. O obscurantismo só serve àqueles que servem a si próprios. Torne o trabalho visível. Providencie um quadro que mostre todo o trabalho que precisa ser feito, o que está sendo feito e o que já foi realizado. Todo mundo deve vê-lo e atualizá-lo todo dia. Felicidade é autonomia, domínio e propósito. Todo mundo quer controlar seu próprio destino, melhorar naquilo que faz e servir a um propósito maior. Estoure a bolha da felicidade. Não fique feliz a ponto de acreditar em suas próprias mentiras. Certifique-se de que a felicidade seja medida em relação ao desempenho. Se houver uma desconexão, prepare-se para agir. A complacência é inimiga do sucesso.


Scott Maxwell diz que o verdadeiro poder do Scrum está na lista de coisas a fazer definida, priorizada e estimada de acordo com o escopo das tarefas.


O primeiro passo quando se está implementando o Scrum é criar uma lista de tarefas, que também podemos chamar de backlog.


No fim das contas, a lista tinha centenas de itens. Trata-se de um sistema grande e complicado. A ideia do backlog é conter tudo o que pode ser incluído no produto. Na realidade, você não vai desenvolver tudo, mas é bom ter uma lista de tudo o que poderia haver nessa visão de produto.


Porém, é crucial o que você decide realizar primeiro. Esta é a pergunta que deve ser feita: quais são os itens que têm o maior impacto sobre o negócio, que são mais importantes para o cliente, que podem gerar mais dinheiro e que são mais fáceis de concretizar?


O engenheiro-chefe não pode simplesmente dizer que algo precisa ser feito de determinada maneira. Ele precisa convencer, persuadir e demonstrar que o seu caminho é o correto, o melhor.


Eu queria isso no Scrum, mas também tenho consciência de que pouquíssimas pessoas têm esse nível de habilidade e experiência. Então, dividi a função em duas, dando o como ao Scrum Master e o quê ao Product Owner.


Ele conhecia aquilo que estávamos produzindo não de um ponto de vista técnico – embora entendesse disso o suficiente para se comunicar com os desenvolvedores –, mas, sim de um ponto de vista do cliente. Do que precisavam as pessoas que estavam de fato usando o produto? Quando for escolher um Product Owner, contrate alguém que consiga se pôr no lugar de quem receberá o valor do que está produzindo.


O Product Owner não precisa apenas de uma gama de habilidades mais ampla do que o Scrum Master. Essas habilidades também precisam ser postas em prática de acordo com um conjunto de padrões diferentes. O Scrum Master e a equipe são responsáveis pela velocidade do trabalho e pelo quanto podem aumentá-la. O Product Owner é responsável por traduzir a produtividade da equipe em valor.


“Quem consegue lidar com a taxa de mudanças mais rápida sobrevive.”


OODA. É a sigla para Observar, Orientar, Decidir e Agir.


Se tiver algumas centenas de itens, esse processo de ordenamento pode se tornar bem complexo em pouco tempo. O essencial é descobrir como entregar o máximo de valor o mais rápido possível. Pode haver milhões de maneiras de organizar o backlog, mas a ideal é a entrega no período mais curto possível daqueles 20% de funcionalidades que concentram 80% do valor. É quase certo que sua primeira tentativa de fazer isso no primeiro sprint não seja o caminho certo – mas ela será sua melhor escolha naquele momento. Mas isso é apenas a primeira tentativa. Após o primeiro sprint, depois de ter concluído o ciclo OODA e entregado algum produto aos clientes, você vai mudar a ordem da lista, percebendo que, na verdade, outra organização é melhor. Então você continua fazendo isso, atualizando e revisando as prioridades do backlog a cada sprint, tentando chegar à ordem que entrega valor mais rápido. É provável que a ordem perfeita nunca seja alcançada, mas você deve caminhar em direção a ela passo a passo, a cada sprint. O mais importante é se lembrar de que a ordem está sempre em fluxo. A ordem certa para uma semana não será a mesma na semana seguinte. Seu ambiente terá mudado. Você terá aprendido coisas novas. Terá descoberto que alguns itens são mais fáceis e outros, mais difíceis. Essa mudança constante do ordenamento do backlog acontece em cada sprint. O essencial é reconhecer a incerteza, aceitar que suas concepções atuais de ordem e valor só são relevantes naquele momento específico. Elas mudarão de novo. E de novo.


melhor desse processo é que ele é cíclico: simplesmente repita. Quando receberem o seu produto, o seu serviço ou uma mudança em suas vidas, as pessoas vão informar quais são os próximos itens mais valiosos. Em seguida, desenvolva 20% deles e entregue de novo. E de novo.


Um dos maiores motivos do excesso de custos nesse projeto – e em praticamente qualquer contrato, seja para desenvolver software, fabricar aviões ou construir edifícios – eram as taxas de alteração. Acumular taxas de alteração é, na verdade, o modelo de negócio de um monte de fornecedores do governo. Eles orçam um projeto por baixo, sabendo que vão lucrar por causa de pedidos de alteração.


O que eles não percebem é que estão criando um sistema que nega às pessoas o que elas realmente querem. Ao tentar limitar os custos, eles limitam a aprendizagem, a inovação e a criatividade. Se você começar um projeto e perceber em pouco tempo que o valor real, aqueles 20%, não reside nas funcionalidades que foram estabelecidas, mas sim em um conjunto diferente de elementos que você descobriu durante o trabalho, o gerenciamento de projetos tradicional é configurado para detê-lo. É configurado para deter a entrega de valor mais rápida.


Foi por isso que pensei na ideia de “alterações gratuitas”. Em um contrato de preço fixo padrão, diga que as alterações são de graça. Liste todas as funcionalidades que espera. Por exemplo, se estiver fabricando um tanque, quer que ele alcance uma velocidade de 110 km/h e dispare dez séries de tiros por minuto, tenha capacidade para quatro pessoas, ar-condicionado etc. – tudo aquilo que acha necessário em um tanque. O construtor olha para essa descrição e diz: “Hmm, construir esse motor, acho que isso equivale a cem pontos; o mecanismo de carregamento, digamos que são cinquenta pontos; o assento, cinco pontos.” E por aí vai, até o fim da lista. Por fim, há determinado número de pontos para cada recurso. Então, a cada sprint, o cliente, que nesse cenário é obrigado por contrato a trabalhar em estreita colaboração com o Product Owner, pode mudar as prioridades. Todos os itens do backlog podem ser reordenados. E novos recursos? Sem problema: basta abdicar de outras funcionalidades com o mesmo tamanho. Ah, você quer um sistema guiado a laser agora? Bem, isso equivale a cinquenta pontos de trabalho – para compensar esse acréscimo, vamos deixar de lado cinquenta pontos de funcionalidades de baixa prioridade, que estão nas últimas posições do backlog.


Dessa forma, o Scrum atende aos interesses de todos: da equipe, do Scrum Master, do Product Owner, do cliente e da empresa. Todos trabalham para o mesmo objetivo e com a mesma visão: oferecer valor real o mais rápido possível.


O gerenciamento de risco está no cerne de qualquer empreendimento de sucesso. O Scrum permite que você reduza os riscos de fracasso. Os três tipos mais comuns são o risco de mercado, o risco técnico e o risco financeiro. Ou, para dizer o mesmo de outra forma: As pessoas querem o que estamos produzindo? Podemos de fato produzi-lo? Vamos conseguir vender o que produzimos?


Certo, o que você pode fazer amanhã para implementar o Scrum no seu trabalho? O primeiro passo é montar um backlog e uma equipe. Pense na visão que tem para o seu produto, o seu serviço, o que for, e comece a delimitar as tarefas que precisa executar para concretizar essa visão. Você não precisa de muito, basta um backlog equivalente a uma semana de trabalho. Enquanto os integrantes da equipe estiverem realizando as reuniões diárias e executando o primeiro sprint, você conseguirá elaborar um backlog suficiente para manter a equipe ocupada durante os dois sprints seguintes. Contudo, fique atento ao backlog, porque, conforme sua equipe for acelerando, ela começará a executar mais trabalho do que você pensava que fosse possível.


RESUMO
Faça uma lista. Verifique duas vezes. Crie uma lista de tudo o que poderia ser feito em um projeto. Em seguida, ordene os itens de acordo com as prioridades. Coloque os itens com maior valor e menor risco no começo do backlog, e assim por diante. O Product Owner. Transforma a visão em um backlog. Precisa compreender o negócio, o mercado e o cliente. Tem conhecimento do setor e poder de tomar decisões definitivas. Está disponível para responder a perguntas e é responsável pela entrega de valor. Um líder não é um chefe. Um Product Owner define o que precisa ser feito e por quê. Cabe à própria equipe decidir como a equipe realiza o trabalho e quem faz o quê. Observar, Orientar, Decidir, Agir (OODA). Observe todo o quadro estratégico, mas aja de forma rápida e tática. Medo, incerteza e dúvida. É melhor dar do que receber. Invada o ciclo OODA de seus concorrentes e faça com que eles fiquem confusos em seu próprio processo decisório. Dinheiro e alterações grátis. Crie funcionalidades novas apenas quando elas acrescentarem valor ao produto. Esteja disposto a trocá-las por coisas que exigem a mesma quantidade de esforço. O que pensou que precisava no início nunca é de fato necessário.


Na parte inferior das colunas há quatro títulos adicionais: “D.O.D.”, sigla para “Definition of Done” [definição de feito]; “Grafiek”, que indica o gráfico de burndown do grupo, mostrando o progresso em direção à meta; e, por fim, retrospectiva e velocidade, onde os estudantes medem quantos “pontos” realizam durante cada lição. Os sprints geralmente duram de quatro a cinco semanas e terminam com um teste.


Os alunos têm uma parte exclusiva do quadro Scrum: uma “definição de diversão”. O trabalho não é só realizar todas as tarefas, eles também precisam se divertir no processo. Os três testes são confiança, humor e uma palavra holandesa quase intraduzível: Gezelligheld. É um conceito que pode ser descrito como “aconchego”, “companheirismo”, “divertido” ou “agradável”,


O Scrum, ou o eduScrum, como Wijnands chama sua abordagem, é apresentado aos estudantes no primeiro dia de aula. A primeira tarefa deles é escolher as equipes, que precisam ser multifuncionais. Os alunos se avaliam em várias categorias, como bravura, gosto pela matemática, preocupação com os sentimentos dos outros e “foco nos objetivos”. Em seguida, são orientados a formar grupos multifuncionais, que tenham todas as habilidades necessárias para aprender a matéria. Wijnands afirma que isso ensina algo tão importante quanto a química: a trabalhar com pessoas com talentos diferentes dos seus e a valorizá-las.

Wijnands afirma que esse tipo de aprendizado é parte do seu objetivo – fazer com que habilidades inconscientes se tornem conscientes. Habilidades que podem ser testadas em uma prova estão longe de ser as únicas que importam. Ajudar os alunos a identificar e valorizar pontos fortes diferentes em si mesmos e nos outros é uma habilidade do século XXI. É algo que todo mundo precisa aprender.


Ao fim de cada conjunto de lições, as equipes fazem uma retrospectiva, na qual se perguntam “O que deu certo?”, “O que poderia ter ido melhor?” e “Como a equipe pode melhorar?”.


era isto que estava procurando: uma abordagem que ensina os alunos a ser autodidatas e a valorizar suas próprias habilidades e as dos outros. E, além disso, que permita que eles se divirtam no processo.



Ele diz que cada vez que alguém pede um conjunto de funcionalidades, sua equipe classifica o pedido em uma escala de 1 a 7 em três questões: 1. Qual é a importância desse trabalho para a missão de ajudar os pobres? 2. Como essa funcionalidade contribuirá para o trabalho dos CKWs? 3. Há o apoio de algum parceiro para a funcionalidade? (A fundação prefere trabalhar com parceiros, como a Fundação Gates, em vez de realizar os projetos sozinha.) Isso permite que Kamara priorize o trabalho usando critérios objetivos. Ele conta que, antes do Scrum, as pessoas pediam tudo ao mesmo tempo. Com os recursos limitados de uma organização sem fins lucrativos, era impossível fazer tudo. O resultado era que a equipe acabava não fazendo nada. Agora, em cada sprint, os diferentes grupos que querem funcionalidades fazem seus pedidos e podem ver de forma transparente como o que pedem se compara a outras requisições. Isso ajuda um grupo com pouco poder de barganha a determinar o que terá o maior impacto.


Quando converso com as pessoas no universo das ONGs, uma queixa recorrente é que suas organizações estão cheias de pessoas que têm propósitos e compromissos em comum, mas que não têm disciplina. O Scrum é capaz de pegar a paixão das pessoas e aproveitá-la, deixando claro o que devem priorizar.

A corrupção é resultado da falta de transparência e da centralização do poder nas mãos de poucos.

Contudo, como enfatizei no Capítulo 3, é inútil tentar apontar as pessoas ruins; em vez disso, devemos procurar os sistemas ruins. Façamos uma pergunta que tem uma chance real de mudar as coisas: “Quais são os incentivos que impulsionam as atitudes ruins?”

O próprio fato de que soam como um clichê é um indicador de sua importância. Afinal de contas, um clichê é apenas uma verdade repetida tantas vezes que se torna banal.


Já falei neste livro sobre o conceito Shu Ha Ri, que vem das artes marciais. Os indivíduos no estado Shu seguem as regras de maneira estrita, para que aprendam as ideias por trás delas. As pessoas no estado Ha começam a criar seu próprio estilo dentro das regras, adaptando-as a suas necessidades. Os indivíduos no estado Ri têm uma existência que transcende as regras; eles incorporam os ideais.
A Valve não é avessa a toda estrutura organizacional – ela acaba brotando em muitas formas o tempo todo, temporariamente. Mas surgem problemas quando a hierarquia ou as divisões codificadas de trabalho não são criadas pelos integrantes do grupo ou quando tais estruturas persistem por longos períodos. Acreditamos que, de maneira inevitável, essas estruturas começam a servir a suas próprias necessidades e não às necessidades dos clientes da Valve. A hierarquia começará a reforçar sua própria estrutura por meio da contratação de pessoas que se encaixem em seu formato e pela adição de indivíduos para preencher funções subordinadas de apoio. Seus membros também são incentivados a desenvolver comportamentos de busca de ganhos pessoais que se aproveitam da estrutura de poder, em vez de se concentrar em simplesmente entregar valor aos clientes.

Pablito 03/11/2018

Passos simples para a produtividade
Uma abordagem focada mais nos casos de sucesso para mostrar o poder do SCRUM, apresentando uma introdução superficial do mesmo. Apresenta bem as causa do muitos negócios não terem sucesso, mesmo quando era "óbvio" que deveriam ter um crescimento digno de nota.

Como o livro usa seu tempo para mostrar o SCRUM na prática (ou as consequências de sua ausência), fica mais fácil visualizar o método e o resumo no final do livro se torna um guia prático. Em alguns momentos é uma leitura "monótona", parecendo que está levando tempo demais pra se chegar num ponto, mas cada passo mostra seu valor quando a tarefa é concluída.

Mario 25/10/2018

Leitura Obrigatória
Leitura básica eobrigatória para qualquer pessoas que queira contribuir e entender o mercado de trabalho. Deveria ser lido no ensino médio!
Ensina organização, ordem.... em meio a desordem inevitável presente tanto na vida quanto no trabalho de todo mundo!

Matheus 27/09/2018

Um ótimo manual para quem quer iniciar no tema!
Jeff Sutherland resumiu anos de experiencia em um livro que traz muita bagagem prática, mas também conceitos teóricos iniciais fundamentais do conceito do Scrum de forma fácil.
O resumo nos finais de cada capitulo para revisão e os títulos para releitura de temas mais importantes facilita muito a vida do leitor que está iniciando no tema.

Bruno 03/09/2018

Leitura introdutória sobre o Scrum
Leitura introdutória e inteligente sobre o Scrum. As bases da metodologia são apresentadas, e é possível identificar exemplos e ganhos na aplicação do método. Vela como leitura inicial!

Heloisa Motoki 19/08/2018

Bons conceitos, mas falta prática
O livro possui bons conceitos mas não possui ferramentas práticas de como aplicar, pode ser complemento de outras leituras, mas sozinho....