Bate papo sobre o livro "A Scrum Book: The Spirit of the Game"

No livro A Scrum Book: The Spirit of the Game, Jeff Sutherland e James Coplien exploram maneiras de executar melhor o Scrum usando os mais de noventa padrões que fornecem informações sobre os elementos construtivos do Scrum, como funcionam e como as equipes altamente eficazes podem utilizá-los.

Os leitores do InfoQ podem baixar uma amostra do livro A Scrum Book: The Spirit of the Game.

O InfoQ entrevistou Sutherland e Coplien sobre o propósito atendido pelos padrões Scrum e como podemos aplicá-los na criação de equipes eficazes, e também foi pedido que descrevessem alguns dos padrões Scrum citados no livro.

InfoQ: Por que escreveram o livro?

Jeff Sutherland: Dois dos líderes do movimento original queriam se concentrar nos padrões Scrum (Cope e Neil Harrison). Ken Schwaber e eu, estávamos discutindo há algum tempo sobre como aplicar melhor o Scrum, sem ser autoritário. The Scrum Guide se concentra no que é o Scrum, mas a verdadeira mágica vem da maneira como implementamos. O conceito fundamental de Alexander de gerar integridade a partir de padrões, parece correto e profundo. Queríamos ajudar a descrever como criar ótimas equipes Scrum que são tanto superprodutivas quanto transformadoras para os participantes. Trabalhei particularmente em padrões críticos para uma boa implementação do Scrum, e junto a Neil Harrison publicamos um artigo sobre "Teams That Finish Early Accelerate Faster". Hoje utilizo padrões como uma maneira de ensinar o Scrum.

James Coplien: Tive duas motivações. Apesar de ter trabalhado com muitas equipes Scrum, ainda me impressiona como tantas pessoas podem ter uma visão errada dele, mesmo depois de serem treinadas e terem acesso ao Guia do Scrum. A grande maioria das pessoas não conseguiu responder adequadamente às perguntas mais simples como: "Por que realizamos o Scrum diariamente?". Pensei que seria bom criar um padrão que explicasse as razões por trás das atividades realizadas no Scrum. Segundo, fiquei triste, pois a comunidade dos padrões se perdeu no que tange às noções de Alexander de totalidade e beleza. Todo o objetivo da generalização indireta e, grande parte do plano de conforto humano de Alexander havia sido perdida. Os padrões de Scrum ofereceram uma oportunidade para um novo começo, juntamente com os esforços dos padrões existentes, e para atrair alguns líderes da comunidade de padrões, na tentativa de ajudar a comunidade a encontrar novamente a direção.

InfoQ: Para quem o livro é dedicado?

Coplien: Há conteúdo para todos aqueles que produzem. O mercado é composto, em sua maioria, por Scrum Masters, profissionais de Scrum, as pessoas dentro das empresas, os coaches, os treinadores e os consultores que os atendem. Os gerentes podem usar o livro para entender que não devem se intrometer na produção, ao mesmo tempo em que devem assumir a responsabilidade de dar suporte aos envolvidos no desenvolvimento, colher os benefícios e gerenciar o risco dos tipos de mudanças radicais que podem levar empresas para um período de pouca, ou nenhuma mudança. O livro é para qualquer um que constrói produtos complexos de qualquer tipo.

Sutherland: Qualquer pessoa que esteja implementando o Scrum e tenha um problema, provavelmente poderá encontrar uma solução nos padrões Scrum apresentados neste livro. Os padrões passaram por um rigoroso processo de workshop, e somente após provarem funcionar correta e repetidamente em várias empresas, serem consistentes com todo o corpo dos padrões do Scrum e facilmente compreendidos e implementados pelas pessoas, é que são aprovados por um corpo internacional de especialistas do Scrum. Alguns dos padrões mais importantes de desempenho demonstraram funcionar todas as vezes, em dezenas de empresas ao redor do mundo. Não há outro livro como esse, e não executaríamos o Scrum sem ele.

InfoQ: Qual é o propósito dos padrões Scrum?

Sutherland: Quando criei o Scrum, me concentrei em documentar o que funcionava em equipes de alto desempenho. Particularmente nas equipes do Bell Labs, que fizeram coisas que são contra-intuitivas. Quem diria que uma equipe não deve ter mais que 4 ou 5 pessoas? Somente as pessoas que inventaram a linguagem C e o Unix. Quem se livraria de todos os cargos porque atrasam as coisas? Mais tarde, a pesquisa da Cope no Projeto Pasteur e uma grande quantidade de pesquisa em outros lugares, provaram que todos esses conceitos fundamentais estão corretos, mas ainda há equipes grandes e com muitos especialistas com vários cargos, fazendo o "Scrum". O básico não é óbvio para o grupo padrão de TI e imaginei que levaria mais de uma vida para a maioria das empresas descobrir o básico. O Guia Scrum é muito curto para demonstrar os estilos vencedoras de agir. Muitas das equipes desestruturadas continuarão sugando tempo e dinheiro para sempre se não implementarem esses padrões.

Coplien: Todos nascemos com senso comum e por meio das nossas experiências ao longo da vida desenvolvemos um profundo senso do que funciona e do que não funciona. As equipes poderiam aproveitar essa profunda percepção coletiva para juntos, criarem coisas grandes. Os formalismos de gestão, normas culturais ultrapassadas, o desejo de exercer poder, a cultura e, a história corporativa, muitas vezes frustram as tendências que levam a esses caminhos intuitivos. Os padrões Scrum nos ajudam a lembrar o que sabíamos, talvez apenas de maneira implícita, sobre como organizar o trabalho e, como tal, se opõem a muito do que a academia e as práticas de desenvolvimento profissional nos ensinaram. Não somos obrigados a segui-los literalmente, mas dicas que podem despertar grandeza dentro de cada grupo para criar equipes e produtos excelentes.

InfoQ: No primeiro livro sobre os padrões, The Spirit of the Game, foi mencionado que "o Scrum requer um espírito de interação entre as pessoas, que é difícil de definir". Por que o Scrum exige isto e como podemos verificar se esse espírito realmente está presente numa equipe e na empresa?

Coplien: Nos inspiramos no Espírito do Cricket, de Rob Smyth, no qual é relatado como os árbitros de críquete forçaram um jogador a remover um fone de ouvido pelo qual estava recebendo instruções do treinador durante o jogo. Não existe uma regra explícita que impeça a comunicação eletrônica no críquete, mas existe uma regra que afirma que qualquer coisa que viole "o espírito do jogo" é o mesmo que violar qualquer regra escrita. O mesmo se aplica ao Scrum. O Guia do Scrum é o livro de regras que define o Scrum de maneira canônica. Mas o Scrum está apenas engatinhando, com o entendimento de que as equipes cometerão erros e não seguirão a risca o Guia do Scrum enquanto estão aprendendo, assim como uma criança que cai e se machuca enquanto aprende a andar de bicicleta. É assim que uma equipe aprende a seguir uma cláusula específica do livro ou, ocasionalmente, aprende que a improvisação pode ser a melhor alternativa. Não recebemos um prêmio por seguir as regras a risca, o foco está nos resultados. Uma visão que vá além do Scrum e alcance as noções mais profundas de resultados, valor, paixão e realização deve ser o que impulsiona as decisões de uma equipe de Scrum. Como mensurar? Veja como a equipe está envolvida no trabalho, ou veja seus resultados.

Sutherland: O espírito do Scrum é eliminar impedimentos que bloqueiam a produtividade ou a capacidade da equipe de executar, incluindo tudo o que afeta negativamente a felicidade da equipe. O espírito do Scrum é colocar o cliente em primeiro lugar, encantá-lo, entregar produtos incríveis que mudam suas vidas a um custo baixo o suficiente para que qualquer pessoa possa tê-lo. O espírito do Scrum é melhorar o desempenho organizacional para que empregos sejam criados, uma liderança seja desenvolvida e investidores sejam recompensados. Qualquer coisa que não esteja neste espírito, não é o "Scrum". É apenas uma farsa.

InfoQ: Como o Scrum enxerga o papel da gerência? Como podemos envolver os gerentes na execução do Scrum?

Coplien: Grande parte do Scrum é sobre o desenvolvimento de produtos. No Scrum os gerentes não devem interferir nas decisões diárias de desenvolvimento e não devem ter controle sobre as decisões de conteúdo do produto. Nesse sentido, a equipe Scrum se gerencia. A equipe melhora de maneira incremental por meio do Kaizen: Melhoria Contínua. No entanto, existem oportunidades de melhoria fora do escopo do desenvolvimento ou no lançamento de um novo produto, alocação de recursos para melhoria ou busca por economia de escala e escopo. Um gerente pode melhorar o valor geral que uma empresa fornece aos clientes (e melhorar a rentabilidade correspondente) extinguindo um produto com desempenho inferior e redirecionando os esforços para um produto mais rentável. O Google, por exemplo, matou dezenas de produtos na última década. Essas são mudanças de descontinuação ou o que os japoneses chamam de kaikaku. Estes são os trabalhos da gerência.

Sutherland: Acompanhamos o trabalho do professor Kotter por décadas e, em um de seus livros recentes, XLR8, Kotter diz que nunca viu uma transformação ágil bem-sucedida sem que um sistema operacional separado tenha sido criado rodando sob princípios ágeis e gerenciado por líderes ágeis. Nas últimas conferências, perguntei a milhares de pessoas quantas delas tinham gerenciamento em cascata para a prática ágil. Mais de 90% afirmam que esse é um grande problema na empresa. Portanto, documentei no Scrum@Scale como criar um ecossistema ágil liderado por uma Equipe de Ação Executiva (EAT) que protege a bolha ágil de qualquer burocracia em cascata que comprometa o desempenho das equipes ágeis. Isso inclui alterar, ou eliminar, todas as regras, princípios, procedimentos e políticas que impedem a maximização da agilidade dos negócios. Esse é o papel dos gerentes no Scrum, precisam se tornar líderes ágeis, coaches de coaches, ouvir as equipes e esmagar qualquer coisa que atrapalhem as equipes. E os líderes de empresas no Vale do Silício dizem que fazer isso é um trabalho de tempo integral. Não apenas isso, mas algumas equipes de gerenciamento que trabalham comigo, cancelaram todas as reuniões e todos os relatórios que não são do Scrum, pois o gerenciamento tradicional em cascata não agrega valor e é contraproducente.

InfoQ: Vamos explorar alguns dos padrões que estão no livro, começando com o Scrum Master Anônimo. Com o que este padrão se parece e quais benefícios pode trazer?

Coplien: A reunião diária do Scrum pode parecer com isso:

O padrão avisa aos Scrum Masters que os desenvolvedores frequentemente os tratarão como velhos gerentes, reportando status e esperando saber o que fazer em seguida. O Scrum Master deve se portar de maneira clara e anônima quando sentir isso. Isso envia a mensagem de que a equipe tem as próprias decisões e que devem gerenciar a si mesmos e organizar o próprio trabalho.

Sutherland: Esse padrão é implementado por alguns dos melhores coaches ágeis quando assumem uma função de Scrum Master. Se lermos o artigo que escrevi com o Scott Downey (J. Sutherland, S. Downey e B. Granvik, "Shock Therapy: A Bootstrap for a Hyper-Productive Scrum" no Agile 2009, Chicago, 2009), verá que uma das principais estratégias usadas para criar equipes superprodutivas é ter um Scrum Master que não é o centro da atenção na reunião diária do Scrum. Isso ocorre apenas depois que a equipe é inicializada e tem conhecimento suficiente para começar a se auto-organizar para atingir a meta do sprint.

Coplien: A frase "somente após a equipe ser inicializada" é o que, na linguagem dos padrões, chamamos de contexto. Alguns padrões exigem que outros estejam em vigor antes de se tornarem acionáveis. O livro ajuda os leitores a entender qual contexto deve existir para que cada padrão faça sentido. Também informa os contextos de cada padrão e sua resultante, unindo a rede para que a equipe possa definir um plano ordenado do Kaizen.

InfoQ: O que é o Ritmo do Sprint Organizacional e como as organizações podem aplicar este padrão?

Sutherland: Em 2006, comecei a trabalhar com o OpenView Venture Partners, e o fundador e sócio, Scott Maxwell, desenvolveu um programa de treinamento em gerenciamento para as empresas do portfólio. Maxwell disse que todo o trabalho resulta da entrega de incrementos ao final de cada sprint e as entregas devem ser integradas se houver várias equipes no final do sprint. Portanto, a empresa precisa ter dados financeiros e o método Scrum integrados semanal, mensal, trimestral e anualmente. Todas as partes da empresa terão um desempenho melhor com esse simples ritmo organizacional. Temos quase um bilhão de dólares investidos em dezenas de empresas e essa abordagem foi o primeiro programa de treinamento completamente documentado que chamamos de Scrum@Scale. Nosso mais recente fundo para cerca de uma dúzia de empresas que usam essa abordagem aumentou a avaliação de menos de 200 milhões para quase 500 milhões de dólares em 2018. O Sprint Pulse realmente funciona!

Coplien: O Scrum, e a vida humana em geral, tem muito a ver com ritmos. A ideia básica aqui é que as equipes trabalhem em ciclos com uma cadência regular. Além disso, as equipes de Scrum que cooperam devem sincronizar-se entre si e com a cadência da empresa ao seu redor. Se várias equipes que cooperam no mesmo processo, perdem a sincronia, a entrega de uma equipe poderá ficar em standby até que possa ser combinada com a entrega de outra para então criar os resultados. Os japoneses diriam que devemos reduzir a inconsistência (mura) para evitar esses desvios de alinhamento. Os ritmos sincronizados também criam um contexto consistente entre as equipes, suavizando o fluxo e reduzindo o estresse nas atividades de desenvolvimento local (reduzindo o muri).

InfoQ: Como o padrão de Alto Valor Em Primeiro Lugar ajuda a entregar os itens mais essenciais da lista de funcionalidades do produto?

Sutherland: Constatamos repetidamente que é essencial priorizar todas as iniciativas de uma empresa baseadas no valor para perceber que 30% dos projetos, entregas ou iniciativas não têm valor e devem ser encerradas. Por exemplo, uma empresa de serviços de TI que após descobrir que 30% dos funcionários estavam oferecendo suporte ao Windows 7 quando a maioria dos usuários já havia migrado para o Windows 10, em uma única tarde, liberou centenas de funcionários para realizarem outras funções. Depois, analisando as demais funções ou recursos, temos dados extensos em software e estamos vendo o mesmo no hardware que dois terços desses recursos nunca, ou raramente, são usados ​​pelo cliente, mesmo quando diz que precisa deles no momento das especificações do projeto. Um grande desafio para o proprietário de um produto é concentrar todos os esforços nos recursos que o cliente realmente usará e não perder tempo com funcionalidades que não serão efetivas. Isto permitirá que todos os projetos sejam concluídos mais cedo e é a base para novas estratégias de projeto baseadas na Mudança de Graça e Dinheiro Por Nada. Consulte "Update 2018: Agile 2008 - Money for Nothing and Your Change for Free" em scruminc.com. O Scrum@Scale permite o Alto Valor Em Primeiro Lugar especificando um Metascrum empresarial, que é uma reunião regular de uma equipe de proprietários de produtos com os stakeholders para obter um alinhamento das prioridades. O Metascrum e a equipe proprietária do produto são dois dos padrões do próximo livro.

Coplien: Embora esse padrão seja na verdade otimizado para o caso especial de desenvolvimento de produto de custo e escopo fixos, frequentemente as equipes fazem entregas com base naquilo que o vendedor diz ser a "prioridade". A maioria das equipes deseja entregar cada vez mais, em vez de entregar as coisas certas na ordem correta. No entanto, Taichi Ōno observa que a superprodução é a principal causa de desperdício (se o leitor não acredita nisso, basta analisar o código para descobrir quanto dele nunca ou raramente é executado). No Scrum, organizamos a lista de funcionalidades ordenando a entrega com base no que tem maior prioridade, baseando cada item em uma classificação independente de importância e, em seguida, começamos com os itens mais atraentes ou aqueles que serão direcionados ao cliente mais importante. Ao construir uma casa, a base de concreto deve ser colocada antes daquela adorável cozinha que desejamos.

InfoQ: O que é uma Especificação de Apoio e como ajudam a equipe de desenvolvimento a permanecer no fluxo?

Sutherland: Gerenciei o primeiro projeto Scrum compatível com a FDA em 1997. Ken Schwaber era o Scrum Master. Eliminamos 95% do custo do compliance com a FDA, para fazer isso, foi preciso rastrear tudo de volta para o design para obter a aprovação. Então, queria uma "Especificação Ágil" que fosse curta, clara e rapidamente executável. Um dos nossos colegas e o Signatário do Manifesto Ágil, Alistair Cockburn, fez uma objeção vigorosa e disse que não havia uma "Especificação Ágil". Como estava envolvido em muitos pedidos de patentes, sabia que tinham em média cerca de seis páginas e eram específicos o suficiente para serem implementados por terceiros sem necessitar entrar em contato com o inventor. A lei de patentes dos EUA os define como "Especificação de Apoio". Então, disse que sabemos o que são e que podem ser julgados em um tribunal. É disso que precisamos para os documentos de design. Há algum tempo, trabalhava com o chefe da Samsung TV no Vale do Silício e ele disse: "Odeio nossas especificações de 300 páginas. São difíceis de ler, de entender e de atualizar. Gerenciei a Apple TV por 10 anos, e tinha apenas quatro especificações com seis páginas cada uma!". Portanto, um produto importante deve ter apenas algumas especificações e uma média de seis páginas.

InfoQ: Como o Padrão das Melhorias Mensuráveis coopera na avaliação das melhorias nas equipes?

Coplien: A melhoria contínua é um foco central do Scrum, assim como as decisões empiricamente informadas. E o Scrum reconhece que os sistemas complexos têm desempenho variável ao longo do tempo. Portanto, mesmo sem fazer nada, ou fazendo algo arbitrário, o desempenho pode ocasionalmente aumentar. Então, primeiro, avaliamos se o desempenho melhora em alguma dimensão, o que implica que o resultado deve ser mensurável. Segundo, medimos se a equipe de fato executou a atividade que afirmaram ter melhorado o desempenho. Por fim, analisamos se é duradoura. Essa última avaliação aparece em outros padrões, como o de velocidade da atualização, enquanto esse padrão se concentra mais em saber se a equipe de fato disse o que fez e fez o que disse. Encontramos algo semelhante na noção japonesa de kamashibai, que é conformidade com o padrão de trabalho.

Sutherland: Hoje, treino novos Scrum Masters no Toyota Kata, com a metodologia Kaizen. Todo impedimento é uma oportunidade de melhoria esperando para ser executada. Em cada sprint, a equipe precisa priorizar a melhoria que trará o maior benefício pelo menor custo. A melhoria deve ser pequena o suficiente para medir o efeito no próximo sprint. Isso é fundamental para o método Lean, e o Scrum deriva do artigo do Lean, de Takeuchi e Nonaka, que cunhou o termo "Scrum". O Padrão das Melhorias Mensuráveis mostra a uma equipe como isso pode ser implementado.

InfoQ: Como podemos aplicar os padrões na implantação do Scrum para criação de equipes efetivas?

Coplien: Apenas mergulhe nos padrões, deixe-os falar com o seu eu mais profundo e com a sensação de entusiasmo da equipe sobre o que pode ser melhorado e tente aplicar um padrão por vez enquanto mede os resultados. Podemos começar procurando os padrões que atacam as fraquezas mais graves, ou os que atraem a paixão da equipe, ou podemos simplesmente aplicar um por um. Deixemos que cada padrão nos guie e nos inspire, ao invés de restringir a intuição sobre como implantaremos a solução.

Sutherland: O Scrum é um conjunto de padrões. Não é uma metodologia. É uma estrutura para implementar padrões que grandes equipes usaram repetidamente em todo o mundo nos esportes, nas indústrias, nos governos e até nas universidades. O Scrum Patterns Group fez um trabalho incrível, mantendo-se focado por 9 anos para fornecer os padrões mais importantes escritos de maneira que qualquer equipe possa escolhê-los e executá-los. Portanto, se tivermos um problema, podemos consultar o livro Scrum Patterns. A solução pode ser um padrão esperando por nós!

Sobre os autores

James "Cope" Coplien (como realizar uma melhoria mensurável) é colaborador e PO do livro "A Scrum Book". Como consultor, coach e educador, atende empresas nas jornadas Lean e ágeis em todos os níveis, da sala de reuniões à mesa de programação. Também trabalha com arquitetura de software e é co-criador do paradigma de software Data-Context-Interaction. Quando crescer, quer se tornar antropólogo.
 

Jeff Sutherland é um ex-piloto de caça e professor de radiologia. Usando o design operacional do treinamento de pilotos e a pesquisa de supercomputação em medicina, se tornou co-criador do Scrum e criador do Scrum@Scale. É mais feliz no Tesla P100D quando pressiona o acelerador que atinge 0-60 em 2,4 segundos.