como sabotar o Scrum

Uma forma interessante de perceber, ou explicar, o Scrum é sem dúvida expolo através de um sentido negativo, ou seja, através das suas fraquezas. Apesar de apregoar o Scrum, como é óbvio, ele também tem as suas fraquezas.

Depois de ler um artigo interessantíssimo do Mike Cohn (pode ser lido aqui) achei por bem fazer a minha lista de passos para sabotar um projecto que use Scrum. Vamos lá ver se esta lista serve mais para o bem do que para o mal.🙂

Feita a introdução vamos a isto:

1 – Fazer uma cara feia no dia-a-dia: Não existe nada pior do que uma pessoa contrariada a trabalhar. Se não concorda com o Scrum tente passar este sentimento para o resto da equipa, pois o Scrum como ainda é recente e as empresas ainda o encaram com alguns receios/desconfianças nada melhor do que a própria equipa mostrar-se pouco crente na framework. Lembrem-se que o Scrum investe essencialmente nas equipas auto-geríveis e empowered… se a equipa não acreditar no Scrum… vai ser impossível o projecto correr bem.

2 – Chegar atrasado às daily meetings: Ao chegar atrasado às daily meetings, ou melhor, se chegar no fim da daily meeting dificilmente um projecto Scrum irá correr bem. Se chegarmos durante a reunião podemos desestabilizar a mesma. Se chegarmos depois da reunião nem sequer chegamos a partilhar com a equipa o que temos feito e as nossas preocupações. A informação que deixamos de partilhar, e que é vital para o bom funcionamento da equipa, vai prejudicar a performance o suficiente para não se conseguir terminar os objectivos da sprint.

3 – Não comunicar com a equipa: Se não tiver forma de cumprir o ponto 2, simplesmente não diga o que lhe vai na alma. Não comunique com a equipa. Esconda o que está a fazer (mesmo que não esteja a fazer nada) e quando a sprint chegar ao fim as suas coisas estarão por fazer e os seus issues só serão levantados tarde de mais. Não facilite neste ponto porque como no Scrum as equipas são cross-functional, muito rapidamente qualquer elemento da equipa pode pegar nas “suas” tarefas. Finja que está ocupado para não deixar a sprint progredir.

4 – Esquecer-se de tarefas (e potenciais problemas) durante a Sprint planning meeting: Como no início de cada sprint existe uma reunião onde são escolhidas as User stories e decompostas em tarefas se “acidentalmente” se esquecer de anunciar algumas tarefas ou até mesmo um problema que poderá surgir durante a sprint o resto da equipa irá ser apanhada de surpresa e possivelmente a sprint irá correr mal. Lembre-se que como existem reuniões diárias esses esquecimentos podem ser detectados. Tente cumprir o ponto 2 para ninguém se aperceber destes esquecimentos.

5 – Nas retrospectivas por sempre em causa o Scrum: Se existe uma reunião para avaliarmos o que tem corrido bem, o que tem corrido menos bem e o que poderá ser feito para melhorar o rendimento da equipa, é nesta mesma reunião que se pusermos em causa o Scrum iremos “sabotar” os pilares do Scrum: Inspect and Adapt; Se não dermos deixarmos a equipa analisar o que foi feito e se não dermos oportunidade de melhorar estamos no bom caminho para que o projecto não tenha sucesso.

6 – Pôr em causa o ScrumMaster: se num projecto tradicional o project manager é uma figura autoritária, no Scrum o ScrumMaster é um enabler e não um “chefe”. Aproveite esta diferença para tentar afastar o ScrumMaster da equipa de forma a garantir que o Scrum não é praticado correctamente e que não exista ninguém por perto para ajudar a equipa a desbloquear problemas.

7 – Não entender os Story points: Como no Scrum existem duas unidades de medida, horas para as tarefas e story points para os requisitos, diga que não faz sentido haver story points. Ignore que o objectivo dos story points seja medir esforço/quantidade de trabalho e diga que é uma unidade de medida desnecessária. Dessa forma os requisitos (user stories) são logo estimados em horas e como não existe detalhe suficiente para serem estimados em horas a equipa não irá conseguir fazer um correcto comprometimento com as user stories a incluir na sprint. Com um pouco de sorte até terão de fazer umas noitadas para tentar terminar todas as stories. Nessas noitadas diga que tem o cão doente e que não pode ficar até tarde.

8 – Não se comprometer com nada: Como é a equipa que escolhe que user stories cabem numa sprint tente fugir de qualquer compromisso. No Scrum a equipa compromete-se no inicio de cada sprint a concluir todas as user stories que escolhe para a sprint. Se não se sentir comprometido se as coisas não estiverem a correr bem não se rale e vá para casa enquanto o resto da equipa corre atrás do prejuízo. Idealmente até deve insistir para a equipa se comprometer em demasiadas user stories para garantir que a sprint não corre bem.

9 – Não fazer testes: O compromisso que o scrum tem é que todas as user stories obedecem a uma Done list onde estão todos as condições para que uma user story esteja terminada e seja aceite. Ao não verificar a lista e ao não fazer testes as funcionalidades que deveriam estar prontas na realidade não estão. Parece-me previsível o que irá acontecer no final da sprint não é verdade?

10 – Arruinar a demo: Nada melhor do que em frente aos stakeholders o projecto ficar com má imagem. Ao cumprir com o ponto anterior a pessoa que for fazer a demo aos stakeholders ou tem um cuidado extremo para não clicar em nada que “crashe” ou então a aplicação irá arrebentar como se um lançamento de uma nova versão do Microsoft Windows se trata-se. Nada melhor do que passar uma vergonha das antigas para se descredibilizar e abandonar o Scrum.

11 – Abdicar de rituais do Scrum: Reuniões todos os dias? Retrospectivas? Reuniões de arranque de sprint? Product backlog? É tudo uma cambada de buzz words (chavões) que não devem ser levados à letra. Antes de verificar se o Scrum lhe serve comece logo a fazer alterações e tweaks de forma a deixar o Scrum e comece a praticar o famoso Scrumbut (num próximo post explico o que é). Dessa forma se as coisas correrem mal pode culpar o Scrum embora na verdade não o esteja a praticar, pois adulterou a framework.

12 – No planning poker não dar a sua opinião: Como no Scrum uma das técnicas de estimar é o planning poker, onde todos os membros da equipa dão a sua opinião através da amostragem de uma carta com o número de story points que estimam para story, tente guardar a sua opinião só para si. Lembre-se que não pode ser rápido a mostrar a sua carta. Espere sempre 1 segundo ou 2 de forma a mostrar uma carta consensual para não lhe fazerem perguntas sobre a sua estimativa.

13 – Não actualizar o quadro (scrum board): Nada melhor do que não actualizar o quadro em Scrum. Desta forma não só não vai ser possível ter as burndown charts actualizadas como também não vai ser possível perceber o que está feito e o que está por fazer.

14 – Sugerir que o ScrumMaster seja um acumular de funções: dessa forma não terá um ScrumMaster a tempo inteiro como também não terá um elemento da equipa (programador/tester) a tempo inteiro. Será mais complicado de arranjar tempo para tudo e possivelmente essa pessoa não terá tempo para nada. Irá cair na tentação do multitasking e atrasar o projecto. Uma das boas práticas do Scrum é tanto o ScrumMaster como o Scrum Product Owner serem full-time jobs e não part-times. É importante que uma pessoa esteja 100% focada/dedicada a cada uma destas funções.

15 – Baralhar os post-its: Na sexta, ao final do dia, garanta que é o último a sair do escritório e baralhe os post-its todos. Passe os feitos para a secção de por fazer, os que estão em progresso coloque na coluna de pronto para testes, etc. Dessa forma na segunda feira a equipa passará toda a manhã a tentar reorganizar o quadro. Como sabem no Scrum usamos quadros com as tarefas representadas por post-its para sabermos se a tarefa está por fazer, em progresso, em testes ou terminada. A ideia de usar um quadro e não uma aplicação de gestão de tarefas prende-se com o facto que um quadro é algo permanentemente visual. Não é preciso abrir um aplicação para ver o status do projecto, está sempre ali, visível, bastando levantar os olhos do ecrã e olhar para a parede.

Como podem ver existem várias formas de prejudicar/sabotar o Scrum. O Scrum não é perfeito nem sequer a solução para todos os males de um projecto.

Obviamente o objectivo deste post não é na verdade ensinar a sabotar o Scrum mas sim explicar o Scrum de uma forma diferente, original. Podem ver que em todos os pontos explico qualquer coisa relativamente ao Scrum.🙂

Espero que esta lista vos seja útil… de preferência para fazer o bem.🙂

Até para a semana.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s