Houve um Scrum *?

* Scrum (substantivo) é uma estrutura que ajuda a resolver tarefas que mudam durante o processo de trabalho, a fim de entregar produtos de forma produtiva e criativa aos clientes com o maior valor possível.

Por que eu decidi escrever este artigo

Muitas vezes, em um ambiente de trabalho, na Internet e em entrevistas, você pode ouvir, por exemplo, o seguinte:

“Existem tantas reuniões com este Scrum! Quando trabalhar, então?! ”;
“Bem, que seja pelo menos Scrum, pelo menos Vergonha, apenas desenrole e deixe-me escrever o código!”;
“Também impusemos esse Scrum, em geral não está claro o porquê”;
“Todos os dias, stand-ups por cerca de quarenta minutos, para que eu tenho que comparecer? Quer saber o que eu fiz e no que estou trabalhando agora - veja Jira, Confluence, Git etc. "
“O mestre do Scrum geralmente é um bobo da corte, ele teria que dançar em vez de gerenciar o projeto!”;
"Sim, usamos Scrum: o principal é que realizamos retrospectivas".

O objetivo deste artigo é mostrar que a negatividade, que ainda está fluindo em um grande fluxo para o Scrum, na verdade não se aplica a ele, e o problema precisa ser procurado em outro lugar.

Em seguida, gostaria de falar sobre casos típicos de onde esses problemas se originam.

Eu próprio sou um funcionário Scrum certificado (scrum.org) de uma grande organização do setor financeiro (não "verde" se isso). No momento, não temos o Scrum, mas estamos caminhando nessa direção, e pessoalmente tenho uma visão do porquê e como continuaremos fazendo isso.

De fato, o fascínio por metodologias flexíveis e pelo Scrum em particular me ocorreu há não muito tempo, mas, na minha opinião, é importante não "há quanto tempo", mas "como qualitativa e conscientemente".

E quanto mais você mergulha neste tópico, mais percebe que essa estrutura é uma “ferramenta” poderosa, e mais triste cada vez que você encontra frases e críticas no início do artigo, as quais, em regra, são evidências de tentativas desajeitadas de mudar para o Scrum.

Por que tentativas, e até desajeitadas: porque elas não perceberam por que todo esse Scrum e Agile, em princípio, pararam um pouco antes do que no início da transição.

Empresas que entendem por que o Scrum é necessário e como usá-lo, na minha opinião, não é uma ocorrência tão frequente em nosso país.

O poder do Scrum, invisível para muitos, pode ser comparado em certa medida com o poder do Excel: tudo parece bem simples, mas se você procurar ...

No entanto, não considero o Scrum uma bala de prata, assim como seus criadores (não fornecerei um link para um artigo publicado recentemente em uma publicação oficial), e isso já é um tópico para um artigo separado.

1. "Imposto"

Na minha opinião, uma das principais razões pelas quais Scrum provoca tanta aversão é quando ele foi simplesmente "rebaixado de cima" durante a transformação da organização. E o problema aqui é exatamente como foi a transformação:

• A gerência percebeu por que iria adotar metodologias flexíveis e o Scrum em particular?
• Como eles informaram os funcionários sobre a necessidade de transformação e por que metodologias flexíveis e o Scrum em particular ajudarão nisso?
• Como você apoiou os funcionários nas condições de transformação, ofereceu treinamento, certificação e assistência de qualidade no lançamento de equipes?

Uma história muito comum é quando as empresas se transformam, simplesmente porque estão "na moda".
No final, é improvável que algo bom aconteça, e o murmúrio resultante, subseqüentemente flui para uma onda de negatividade.

A esse respeito, gostei de uma frase no tópico: "Nas empresas tradicionais, os gerentes tradicionais organizam transformações tradicionais".

No entanto, vou ser sincero com você: quando fomos levados para o Agile / Scrum / Kanban, era sobre o Scrum que eu pensava inicialmente como algum tipo de lixo com reuniões intermináveis. Mudanças na minha atitude em relação a ele ocorreram depois que eu me fiz a pergunta: "E se ...?" Para mim mesmo em um projeto muito legal.

2. Cartomancia por Scrum

Outro motivo para a indignação e até alguma amargura no Scrum é sua interpretação incorreta, associada principalmente a onde obtemos conhecimento disso. Como resultado, por exemplo, temos "cerimônias de chá" ou "rituais de sacrifício" em vez de "eventos".

Não excluo a presença de cismáticos que discutem sobre estar no Daily Scrum com um círculo, quadrado ou alguma outra figura. Se for redondo, passe a palavra no sentido horário, contra ou de outra forma.

Ao mesmo tempo, existe uma completa falta de entendimento sobre por que essas notórias reuniões obrigatórias (eventos) existem no Scrum, que, a propósito, podem ser contadas nos dedos de uma mão.

Observando o enorme fluxo de informações na rede, parece que muitos simplesmente não sabem qual é a fonte principal e onde obter o conhecimento básico da estrutura.

Portanto, o principal documento do Scrum é o The Scrum Guide, co-escrito por Ken Schwaber e Jeff Sutherland, disponível em vários idiomas, incluindo o russo.
Na minha opinião, para obter conhecimento básico do Scrum e, posteriormente, não entupir sua mente com todos os tipos de adições incompreendidas ao Scrum, você precisa de apenas dois componentes principais: desejo e leitura cuidadosa do The Scrum Guide, e mais de uma vez. Este documento é bastante compacto - menos de vinte páginas, você pode dominar.

Quanto aos treinamentos, direi brevemente: tenha cuidado! Não anunciarei ninguém no âmbito deste artigo, mas acredito que em nosso país apenas uma ou duas empresas possam confiar nos "treinamentos certos" sobre este tópico.

3. "Interpretação" de algumas seções do Guia Scrum e não apenas

No contexto de quantas discussões semelhantes na rede ocorrem em torno do Scrum, tentarei chamar a atenção para elas e declarar meu entendimento de acordo com o guia e a experiência do Scrum.

Scrum é ...

Vou destacar duas das três características: simples para entender e difícil para um domínio perfeito .

Algumas pessoas pensam que há uma contradição.

Sprint

Nesta subseção, levantarei deliberadamente algumas perguntas que podem fazer você pensar e repensar sua abordagem à estrutura.

1. O que você acha que faz sentido chamar os Sprints fixos em intervalos de tempo? Por exemplo, pode ser mais fácil enviar um relatório de progresso a cada duas semanas?
2. Se você está mudando para o Scrum, há quanto tempo você escolhe a Sprint? Quando fiz essa pergunta, na maioria das vezes encontrei um olhar atônito e a resposta: "Padrão - 2 semanas".
3. Por que você escolheu uma corrida tão longa?
4. Por que não é recomendado definir a duração do sprint por mais de um mês?

Alguns podem não acreditar, mas as respostas para essas perguntas estão no Guia Scrum.

4. Scrum Diário

Um dos tópicos mais controversos é o Daily Scrum, também conhecido como Daily Standup Meeting, também conhecido como Daily Scrum, ou simplesmente "Stand-up".

Você pode não acreditar em mim, mas esse evento tem um tempo fixo (caixa de tempo) - não mais que 15 minutos, independentemente da duração do Sprint.

A própria equipe determina o formato da reunião. E o mais importante nesse período de quinze minutos é entender o status do progresso em direção ao Objetivo da Sprint.

Agora, perguntas para preenchimento: quantos de vocês sabem qual é o objetivo da Sprint? Quantos de vocês sabem como formulá-lo? E quem as formula?

Na grande maioria dos casos, Scrum fica indignado justamente por causa de sua ignorância e mal-entendidos, pois esse evento chamado Daily Scrum é necessário.

Esta não é uma reunião de relatórios! Nas reuniões que assisto com frequência, não há informações suficientes, exceto sobre quantas vezes uma pessoa bebeu café, chá, água e também foi ao banheiro. E "não mais que 15 minutos" pode durar uma hora e meia.

Mais uma vez: Daily Scrum é sobre avançar para os Objetivos da Sprint!

Percebendo apenas essa parte do Scrum, você, na minha opinião, será capaz de fazer um avanço significativo.
E outra observação, que para muitos se torna uma revelação, o Daily Scrum é um evento no qual pode participar (observe: "participe" e "aguarde, ouça" são duas coisas diferentes) apenas a Equipe de Desenvolvimento! Mesmo o Scrum Master (Scrum master) e o Product Owner (Product Owner), se não forem membros em tempo parcial da equipe de desenvolvimento, não estarão diretamente envolvidos nesta reunião!

5. Scrum master não é um gerente de projetos e não um servidor

Outro tópico muito comum: Scrum Master (SM) = Gerente de Projeto (PM).

Você pode encontrar vários artigos sobre SM vs. PM.

Vou destacar o principal:

• O Scrum Master é responsável por promover e apoiar o Scrum de acordo com o Guia Scrum.
• Os principais equívocos sobre o Scrum-master:
• O Scrum Master NÃO gerencia o projeto;
• O Scrum Master NÃO gerencia a equipe (a quem levar, a quem remover);
• Os mestres de scrum não são selecionados com base no funcionário mais experiente ou de longo prazo da empresa;
• O Scrum-master NÃO é um secretário da equipe, "entupindo os que se aproximam".
• Os deveres do Scrum Master NÃO incluem entrega de pizza às sextas-feiras (um tópico favorito nos treinamentos), lavar meias e passar os cadarços do Dono do Produto ou membros da Equipe de Desenvolvimento.

As áreas de responsabilidade do Scrum Master também são descritas no Guia Scrum.
No final desta seção, posso discutir mais alguns tópicos, para estudo independente, se alguém estiver interessado:

• Scrum como um culto à carga vs. Scrum e shuhari.
• O Dono do produto é um gerente de produto, não um projeto ou equipe. Aqui está o PO vs. PM.
• Dono do produto e Scrum Master em um único pacote.
• O principal no Scrum é uma Retrospectiva, ou você se deparou com quase isso: Scrum = Retrospectiva (mas uma retrospectiva do que é outra pergunta)!
• ...

Está maduro à luz do que é encontrado na obra, nos comentários, inclusive em Habré.
Scrum é Ken Schwaber, Jeff Sutherland e seu Guia Scrum. Ver Nota Final.
Scrum - é isso que está no Guia Scrum, e não o que você está acostumado a chamar na sua empresa.
Também ainda não temos o Scrum, mas entendemos isso, reconhecemos e sabemos como avançar em direção a ele. Além disso, também entendemos que é absolutamente necessário mudar para lá, pois isso pode realmente trazer grandes benefícios para a organização.

Resumir

Se as notas acima, pelo menos fiz alguém pensar e repensar o que é esse Scrum, e metodologias flexíveis em geral, então assumirei que atingi o objetivo!
A água desgasta a pedra e, talvez, em um futuro próximo, não ouviremos com a mesma frequência que ouviremos agora: "Você está muito empolgado com este Scrum e com base nos resultados de tal e tal equipe (usando o ScramNO de fato) não vale a pena".

Obrigado a todos pela atenção e ficarei feliz em seus comentários e comentários!

Referências

www.scrumguides.org/index.html