O Scrum é uma porcaria.

Notícias de última hora: scrum é ruim.

Matteo Bianchi

Se você está lendo este post, você provavelmente trabalhou seguindo (alguma forma de) Scrum, mas no caso nunca fez: sentar-se e ser meu convidado.

Comecemos desde o início.

O que é Scrum?

O Scrum é um sistema de gerenciamento de projetos ágil que “ajuda as pessoas e as equipes a agregar valor de forma colaborativa”.

Cit. do Scrum.org

Quanto ao Agile, se você nunca leu seu Manifesto (2001), eu defino como uma lista magra de boas práticas a seguir no desenvolvimento de software.

O Agile não é: a Bíblia Sagrada do Desenvolvimento de Software, um conjunto dogmático de regras rígidas, ingressos Jira ou Agile Coaches correndo pela sua empresa.

Dispensador tardio: as definições são falhas, por definição. (agora leia isso novamente)

Eu aceitarei abertamente qualquer crítica sobre a maneira como defini o Scrum, o Agile e qualquer outro termo também.
Só peço que leia todo o post antes de digitar com raiva os comentários!

Teoria vs Prática

O Agile é o oposto da Waterfall, que tem sido a maneira antiga de criar software até os anos 90.

O Agile é iterativo, a cachoeira é sequencial.
O Agile é magro, a cachoeira é pesada.
O Agile é rápido, a cachoeira é lenta.
Agile é o código-primeiro, Waterfall é doc-first.

Eu poderia continuar por séculos, mas eu não vou, você tem.

O Agile vem de um lugar (muito) bom e foi uma revolução que transformou o desenvolvimento de software de um pesadelo sequencial nas toneladas de disciplina de engenheiros, incluindo eu, praticar felizmente hoje.

Eu nunca questionaria a autoridade defendida pelas pessoas que a teorizaram, já que a verdadeira questão é a implementação do Scrum em nosso mundo real e não tão ideal.

Cerimônias

O termo mais fundamental do Scrum é: sprint.
Sprints são basicamente slots de tempo pré-definidos (normalmente com duração de duas semanas). Durante esse período de tempo, além dos ciclos de desenvolvimento, a equipe Scrum é obrigada a seguir algumas cerimônias.

Nota: Eu sempre não gostei desse termo religioso usado para definir esse tipo de reunião, mas ok.

• Sprint Planning – tão simples quanto parece, uma longa sessão (até 4 horas) para planejar itens / histórias de usuários que precisam ser entregues durante o sprint seguinte, envolvendo a equipe Scrum.
• Reuniões diárias de stand-up – uma reunião diária, simples (cerca de 15 minutos), onde a pequena equipe de desenvolvimento (como 3 a 7 pessoas), comunica seu progresso e sublinha problemas de bloqueio, ambos sem entrar em detalhes profundos.Este é o momento em que você pode pedir a Alice para ter uma reunião separada sobre o problema de cache do lado do servidor e para Bob sobre esse parâmetro de data ser uma string e não um tempo Unix.
• Execução de Sprint — As pessoas puxam autonomamente tarefas, depois as executam e resolvem eventuais problemas por meio de reuniões informais, sessões de programação de pares, revisões de código e pasta intensiva de cópia do ChatGPT.
  A testar? Uma parte da execução.
  – O Q-A? – Sim, a saber.
  Documentação? Você sabe a resposta.
  Operações / DevOps / Infraestrutura tarefas? – Adivinha o quê.
• Revisão da Sprint – uma longa reunião (entre 1-2 horas) que visa mostrar o resultado do sprint para as partes interessadas e obter feedback delas.
• Retrospectiva de Primavera – uma análise interna do que foi executado, com foco em impedimentos, a fim de removê-los para futuros sprints e, em geral, melhorar continuamente os processos, práticas e ferramentas para a próxima iteração.
• Refinamento do Backlog – não é realmente uma cerimônia, mas cerca de 10% do tempo que deve ser gasto pela equipe, durante um sprint, no refinamento de backlog para: quebrar, explicar, encontrar lacunas, fornecer uma definição de feito e priorizar colaborativamente as tarefas.

As pessoas

Estes são os indivíduos, ou grupo de, identificado pelo Scrum:

Stakeholders – Eles têm uma participação no jogo, eles querem ser informados, envolvidos e eles se beneficiam do produto, qualquer que seja o “produto” que significa para a sua empresa.
Sim, tudo é um produto se você esticar a definição o suficiente.
Eles podem ser usuários finais, outras equipes ou até mesmo outro negócio.

O proprietário do produto deve atuar como uma ponte entre as partes interessadas e os desenvolvedores de produtos, traduzindo os requisitos em itens acionáveis, entendendo o domínio e o valor do negócio, gerenciando a carteira de pedidos e maximizando as saídas entregues.

Os desenvolvedores devem ser as pessoas responsáveis pelas tarefas operacionais, incluindo, mas não se limitando ao desenvolvimento de software, de forma autogerida, podendo tomar decisões técnicas que direcionem o produto no caminho certo.

Scrum master – deve facilitar a comunicação, monitorar e acompanhar o progresso, determinar e avaliar riscos, educar e treinar a equipe autogerenciada sobre scrum para torná-lo eficaz.

O Scrum está quebrado

– Espera. – Não. Então, essas cerimônias e papéis são tão complexos que um

Ahhh, doce criança de verão.
A resposta óbvia é, em suma: não.

Quer saber por quê?

Nós não vivemos em um mundo ideal onde a teoria acontece exatamente como está escrito nos livros.

Você poderia ter adivinhado pelas frases destacadas nestes últimos parágrafos, mas na prática isso é o que realmente acontece:

O planejamento, independentemente do ferramental, leva anos e você acaba com tarefas pré-atribuídas, medidos em pontos da história.
Esses pontos, que devem estar lá para ajudar a ter uma ideia da complexidade de uma determinada tarefa, são usados para medir o tempo.

– Muito bem, Sherlock!
Sua equipe agora está focada em ocupar o tempo preenchendo sua agenda, em vez de se concentrar em entregar recursos e você não pode sequer medir sua velocidade.
A velocidade deve ser útil para entender, com base em sprints anteriores, qual é a quantidade relativa de progresso do produto que sua equipe pode oferecer.

Ok, mas por que não estamos usando uma escala de Fibonacci novamente? E que tal um jogo de póquer?

Espere, não desistam ainda. Tenho a solução definitiva, juro!
Basta dar a cada tarefa um tamanho de roupa para simplificar a sua medição.

Que ideia maravilhosa.
Nós simplesmente precisamos discutir se isso é que a API gRPC é uma tarefa L ou M, enquanto isso, o único L que estamos recebendo é o tempo que perdemos em escolher um método para essa medição milimétrica improdutiva.

Pensando em um cenário possível: Product Owner e Scrum Master estão fora do escritório.
Um está de licença médica e o outro tem um merecido PTO ou férias.
Sua equipe ainda participa da reunião de stand-up? Eu duvido.

O que foi? Você define a velocidade individual como uma meta para atingir cada sprint?
Esteja preparado para um código de baixa qualidade e testes incompletos, mas ainda automatizados.
Depois de definir uma métrica estática, as pessoas se adaptarão gradualmente para dar a volta.
Ah, e diga adeus à programação e colaboração de pares, todo mundo está muito focado ganhando esses pontos suculentos da história.

Uma tarefa é muito difícil de quebrar e requer uma extensa análise que pode envolver várias equipes e durar alguns dias?
Ninguém vai atribuir essa tarefa a si mesmo, pois temem culpar e parecer improdutivo.

Escrever tickets para tarefas de 10 minutos, como formatar algum arquivo, atualizar um URL e remover importações não utilizadas?
Bem-vindo ao desenvolvimento orientado a ingressos, onde até mesmo a decluttering leva anos.

Hora de um caso bastante comum: alguém encontrou um bug durante o sprint.
Houston, temos um problema, vamos conversar com… quem?

Líder da equipa?
Scrum master?
Lead de tecnologia?
Proprietário do produto?
Proprietário de serviço / gerente?
Gerente de projeto? Sim, eu experimentei ter um PM em uma equipe executando Scrum, não pergunte por que, é muito real e eu tenho provas.

Que liderança fracionada temos aqui!
Tanto para a “equipe auto-gerenciada”, hein?

Imagine que você alinhou todas essas pessoas sobre o seu problema e agora adivinhe a quantidade de tempo necessário para que elas descubram sua responsabilidade e forneçam uma solução.

Boa sorte, vejo-te a seguir o sprint!

O Scrum é frequentemente visto pela administração como um elixir de produtividade e uma cura para qualquer equipe de baixo desempenho, mas a realidade é praticamente o oposto.

O Scrum não resolve problemas de desempenho da sua equipe.

Uma equipe lenta pode se tornar ainda mais lenta e acredite em mim, que o gráfico de burnout será doloroso de assistir.

Whoops, eu quis dizer burndown, trocadilho pretendido.

Existe uma maneira de fazer o Scrum funcionar?

Eu realmente acredito que há um, mas eu nunca vi um único engenheiro feliz com a implementação de sua empresa Scrum.

Bingo (em inglês).

O trabalho deve ser definido em nível de equipe por seu pessoal, não pela empresa.

A profecia ágil finalmente se cumpriu!

• O tempo entre as entregas é finalmente curto e é flexível também!
  Não há necessidade de chamá-lo de “sprint” e fazê-lo parecer uma corrida sem fim contra o tempo.
  A qualidade do software produzido aumentará sensatamente, pois qualquer mudança no escopo está livre das restrições de horários rígidos.
• As estimativas são feitas como pretendido: intuitivamente com base na experiência anterior, validada em nível de equipe.
  No desenvolvimento de software mais do que qualquer coisa, o tempo deve ser considerado como uma medida relativa.
• O planejamento envolve, o gerenciamento à parte, as pessoas que estão realmente executando o que está sendo planejado para que possam discutir e encontrar falhas quando ainda há tempo para lidar com elas graciosamente.
  O trabalho é puxado por cada colaborador individual e não atribuído por qualquer líder/gerente.
• A execução é empoderadora.
  Cada desenvolvedor, baseado na experiência, tem um certo grau de liberdade técnica e sente a responsabilidade comercial em relação ao produto, seus colegas e partes interessadas.
  Redução de dependências, torna sua equipe de desenvolvimento independente e, acredite ou não, de forma mais rápida.
  As atualizações diárias finalmente refletem o status do rastreador de problemas, fluxos de informações e documentação são escritos.
• Os alinhamentos diários são curtos e realmente dão informações sobre o trabalho em andamento.
  Ninguém sente a necessidade de preencher sua lista de todos com pequenas tarefas de preenchimento ou mentir sobre ficar preso ou antes do previsto.
• Os bloqueios são resolvidos dentro da equipe, como uma equipe, sem interagir com a gestão em camadas de lasanha e tomando posse de cada decisão, seja qual for o resultado.
• Os resultados são compartilhados em total transparência e realmente mostram o status até mesmo para as partes interessadas mais difíceis (normalmente clientes “top”). Objetivo é procurar um feedback real, não para headpats.
• A revisão do que foi executado é honesta e irrepreensível para que as pessoas possam parar de manipular os dados para fazer parecer que fizeram um trabalho relativamente bom e começar a se concentrar em resolver as causas profundas dos problemas encontrados.
• O backlog é finalmente uma responsabilidade compartilhada e um esforço contínuo.
  Você ficará surpreso com o impacto desta bala simples (mas não trivial).

A correção

• Leve a retrospectiva a sério, como um momento para refletir com uma mente clara, sobre o que acabou sendo uma boa estratégia, como iterar sobre isso e elogie a equipe pelo trabalho feito.
  Sim, é claro que você também precisa pensar sobre o que deu errado, por que e como melhorá-lo.
• Peça conselhos sobre como melhorar em vez de feedback.
  As pessoas adoram dar conselhos (às vezes mesmo sem aviso rápido, mas isso é uma história diferente), ajuda a evitar o feedback vazio como em “tudo de bom” ou “tudo ruim”, quando você receber um bom conselho será imediatamente acionável, pedir conselhos a alguém para se sentir mais confiável do que quando eles são solicitados a dar “apenas” um feedback.
• Confie na equipe, seja honesto e pare de tentar microgerenciar.
  Tente delegar mais e ser flexível, você verá que dar liberdade resulta em um ambiente mais saudável, onde é mais fácil aprender a ser responsável, mesmo quando o gato (também conhecido como gerenciamento) está longe.
• Esteja ciente de que as métricas estarão em algum momento, se você não olhar para dar uma olhada crítica neles, não caia no viés de confirmação usual.
  Hora de uma das minhas citações favoritas: “se você torturar os dados por tempo suficiente, ele confessará a qualquer coisa” – Ronald H. Coase (em inglês).
• Incentive erros, possuí-los e corrigi-los sem medo de passar por avaliações de desempenho. Pare de examinar e questionar esse desenvolvedor que cometeu um erro durante o sprint anterior, só piorará seu desempenho e criará um ambiente tóxico para trabalhar.
  Você deve examinar o erro, mas nunca a pessoa.
  Vês um desenvolval a lutar? Tente perguntar-lhes como eles estão, dar-lhes algum tempo e olhar para os resultados sobre a próxima iteração.

Sei que alguns de vocês pensam que o que eu disse é uma treta.
Se você escrever esse comentário irritado neste momento, eu não vou culpá-lo.

Vamos ler o Manifesto novamente:

Indivíduos e interações sobre processos e ferramentas

Software de trabalho sobre documentação abrangente

Colaboração com clientes sobre negociação de contratos

Respondendo à mudança sobre o seguimento de um plano

Desta vez, você não pode dizer que o título foi um clickbait:

O Scrum realmente é uma porcaria.

A não ser que você faça isso ágil.

O que significa: flexível, adaptável, colaborativo, construído em torno de pessoas e focado em resultados, em vez de métricas.

Tempo de auto-ad! (sopppable)

Atualmente, ofereço serviços de engenharia para empresas que precisam de um Consultor Nativo em Nuvem (DevOps/Cloud/Kubernetes) e para startups que precisam de um consultor.
Sinta-se livre para entrar em contato no LinkedIn, até mesmo para me indicar alguém que você conhece.

Para qualquer referência bem-sucedida, ofereço 10% do valor pago pela primeira fatura (por exemplo, IVA) em dinheiro ou doado a uma instituição de caridade de sua escolha ?

Eu também ofereço coaching e orientação para indivíduos, por isso, se você quiser saber mais sobre Engenharia de Software, DevOps, Nuvem, Kubernetes ou mesmo se você quiser que eu revise seu CV / LinkedIn ou carreira, entre no meu perfil MentorCruise!

Você não deve ser um tomador de decisão nem ter uma (grande) participação nessa empresa de referência para escolher a opção de caixa:
– um investidor refere-me a uma startup em seu portfólio (você não precisa do dinheiro!)
– CEO da X me refere a Tesla – desculpe Elon.
– um empregado (não C-level, Director ou similar) refere-me à sua empresa
– CEO do Google me remete para a Microsoft

Comente, compartilhe e marque-me para discutir!
Encontre todos os meus links ? aqui.

Isso é tudo por enquanto, ciao 🙂

Fonte: Medium