Get best of the week

Qual é o significado oculto dos autores no Guia SCRUM. Parte 1. Sobre o processo

Fale sobre magia e unicórnios SCRUM-a?

imagem

Não é segredo que muitos tentaram implementar o SCRUM em suas casas, mas nem todos conseguem, e muitos não entendem de onde a mágica pode vir.

Concordo imediatamente, o único manual do SCRUM é o Scrum Guides , ele muda e é atualizado, portanto, aconselho a relê-lo regularmente.

Esta série de artigos não substituirá a leitura do manual, mas será uma adição ao guia com algumas adições pessoais do autor.

E provavelmente começaremos com o que está escrito na última página do manual:

os papéis, eventos, artefatos e regras do Scrum são imutáveis e, embora a implementação de apenas partes do Scrum seja possível, o resultado não é o Scrum.

(Funções, eventos, artefatos e regras do Scrum não mudam . E embora a introdução de apenas partes do Scrum seja possível, o resultado não será o Scrum.)

O que isso me diz, que já tem um calo na testa do rake que estávamos atacando, após 4 transformações na empresa.

Sobre isso - se queremos obter gasolina A95, provavelmente precisamos seguir rigorosamente os padrões de produção, aquecer o óleo na coluna de ratificação a uma temperatura estritamente definida, levar os vapores a uma certa altura, adicionar componentes não "a olho", mas observar o último ponto a mãe dele! processo tecnológico. Para que o resultado final seja A95, e não algum tipo de peso corporal que estrague seu carro.

Mas por que? Por que um gerente (clássico) típico, que de repente decidiu implementar o SCRUM em casa, acredita que o “processo tecnológico” não está em sua empresa. Seu povo é diferente, suas mãos são diferentes ou suas pernas, o código está escrito no lugar errado? E, em geral, parece que não me importo com todos os 30 anos de evolução das abordagens gerenciais. Há um milhão de razões para inventar sua bicicleta pela primeira vez em um milhão e, em seguida, escrever orgulhosamente sobre isso em um hub, ou até mesmo escrever um livro sobre seu “scrum preto” . Ao popularizar que a “bodygirl”, através das dores e lágrimas dos desenvolvedores, destruiu o processo clássico estabelecido com o qual a empresa havia vivido por várias décadas antes e, como resultado, não funcionou.

// SCRUM é - simples de entender


Então é isso que eu quero dizer. O que poderia ser mais simples que o SCRUM: planeje, gaste cinco minutos pela manhã e depois de duas semanas colete todos e deixe que mostrem o resultado (geralmente não é mais necessário) e aguarde o produto, que traz dinheiro, alegria e orgulho para todos! Simplesmente? Vamos implementar, digamos gerentes!

Esse "gancho" geralmente aparece entre jovens e não experientes, porque os experientes (leitores) já sabem que não é tão simples.

// SCRUM é difícil de dominar


Você sabe o que Jeff e Ken esconderam nessas 19 páginas do guia? Uma verdade simples é que quanto mais um gerente / gerente / supervisor se preocupa com sua equipe, pior a equipe com auto-organização, pior o resultado de seu trabalho.

Todo mundo sabe que o mau gerente (com o qual a equipe está se degradando) é:

  • não pode delegar
  • ele mesmo distribui o trabalho, ele aceita o resultado
  • monitores diários
  • Requer relatórios constantes, documentação, preenchimento de cronogramas (horários de atendimento)
  • não confia na equipe
  • impõe suas decisões

(Espero que ninguém se reconheça aqui)

Essa é a mesma “hiper preocupação”, ou é o sentimento de “ancião”, “pai”, “mais responsável”, “eu só preciso disso”.

Com um comando, isso necessariamente faz mágica ruim:

  • a equipe perde a capacidade de pensar. (Seu gerente para de filosofar aqui, mas me diga o que fazer)
  • a equipe trabalha em tarefas, não no resultado, às vezes "fingindo" estar ativo. (Realizamos a tarefa 1, a tarefa 2, a tarefa 3 e o produto caiu, deixe os administradores / devops entenderem.)
  • a equipe está ocupada relatando, documentando, mas não funcionando. (Escrevo relatórios meio dia na segunda e sexta-feira, não faço tarefas.)
  • a equipe resiste a qualquer inovação. (Quais são os testes automáticos? Vamos concluir a tarefa.)

Não é estranho, mas o SCRUM apenas "limita" a equipe de tal "hiper-controle" pelos "pais mais velhos".

Precisa de prova? Mantenha tudo de acordo com o Guia Scrum:

Standup, apenas para a equipe de desenvolvimento!


Todo mestre do Scrum sabe que, assim que o "gerente" chega, mesmo o proprietário do produto "nosso amigo", o stand-up instantaneamente se transforma em um "relatório de status". A equipe não discutirá mais o que fazer para alcançar os objetivos do sprint, mas de repente eles começam a "dançar na frente do ancião" para contar o que eu fiz e como estou bem em todos os detalhes. E acredite, isso leva imediatamente muito mais que 15 minutos, e o mais triste é que é uma perda de tempo absolutamente inútil para todos os membros da equipe.

No guia, não é à toa que está escrito -
O Daily Scrum é uma reunião interna da Equipe de Desenvolvimento. Se houver outras pessoas, o Scrum Master garante que não atrapalhem a

reunião (Daily Scrum é uma reunião interna da Equipe de Desenvolvimento. Se houver
existe mais alguém, o Scrum-master garante que eles não interfiram na reunião)

Mas os ex-gerentes, que geralmente se tornam o Product Owner no novo processo, odeiam quando não são convidados a se apresentar. E a primeira coisa que quebra no processo tecnológico da SCRUM é que todas as empresas de stand-up visitam, porque “o controle está acima de tudo”.

Nas reuniões com o Dono do produto, a equipe não passa mais de 10% do tempo e não mais que um minuto


(Refiro-me àqueles em que o PO está presente, a equipe sempre pode recorrer ao PO, se necessário).

Por um sprint de duas semanas, são três reuniões estritamente regulamentadas:

  • Máximo de 4 horas no planejamento da Sprint
  • máximo 2 na revisão do Sprint
  • e 1,5 horas Sprint retro

E isso é tudo, em duas semanas, o Dono do Produto, de acordo com os regulamentos, tem apenas 7,5 horas, nas quais não há absolutamente tempo para "controle". Nos 90% restantes, a equipe trabalha com o objetivo de correr. (Mas você considerou o quanto sua equipe realmente pode codificar?)

Na realidade, é claro, nosso ex-gerente não tolerará isso e quebrará essa “bagunça” com alguns relatórios e comícios intermediários .

A equipe deve implementar as necessidades do cliente, não os objetivos pessoais do Dono do Produto.


Porque em nenhum lugar está escrito que o Dono do Produto deve escrever os requisitos para o próprio produto, mas está escrito o que priorizar e torná-los compreensíveis para todos.

Um bom mestre do Scrum sabe que, para garantir a "transparência", é imperativo convidar clientes da História do Usuário cuja prioridade é se reunir com a equipe. Estabelecer comunicação direta com o cliente. Porque, dada a promessa ao cliente, oh, quanto motiva a equipe.

3 princípios do SCRUM: Transparência, Pesquisa, Adaptação

Mas que "gerente" sensato permitirá? Acontece que a "verdade gerencial" está sendo questionada pelo ego, essa é a chance da equipe de "negociar" e quebrar todos os planos de crescimento na carreira e captura do universo.

Não, o SCRUM é um pesadelo para o gerente clássico, e as pessoas costumavam viver em "processos".

Portanto, eles geralmente tentam interromper todo o processo SCRUM, adicionar mais controle, menos transparência e sem adaptação, desenvolvimento.

Como resumo: A melhor maneira de enterrar o SCRUM é nomear o Dono do Produto, projetos anteriores ou seus próprios gerentes.

  • PO, não um líder.
  • O PO deve ser uma pessoa com habilidades únicas - para ver o empilhador onde outros não o vêem.
  • O PO deve entender onde mais e onde menos dinheiro / valores e priorizar.
  • O PO deve poder levar o empilhador para a equipe, onde a própria equipe já venderá seu produto.

e mais
— ? , Scrum , , .

Deixe as pessoas boas lerem bons artigos :)

More articles:


All Articles