Entrevistas para Scrum Master

Em tempos o meu amigo Luis Gonçalves perguntou-me quais eram as perguntas que eu costumava fazer quando entrevistava um candidato para a vaga de Scrum Master.

Apercebi-me no outro dia que o TOP 5 das minhas perguntas foram publicadas no seu blog.

Para quem tiver curiosidade pode ver o meu TOP 5 aqui.

Para quem estiver com pressa aqui ficam (em Inglês) as perguntas:
1.Define me what an empirical process is
2.What is the difference between an iterative process and an incremental process
3.How can you manage risk with Scrum
4.How can you estimate an User Story? What types of estimates do you know? How about scales? And techniques?
5.Explain to me how story points works

Que acham? Difíceis? Fáceis?

Até para a semana. 🙂

 

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.

Codebits 2011

O Codebits 2011 terá lugar no pavilhão atlântico, em Lisboa, entre os dias 10 e 12 de Novembro de 2011.

Depois de ter uma conversa com amigos sobre o possível interesse (ou não) de uma talk sobre Scrum num evento deste tipo, resolvi propor uma.

A maior dificuldade que tive em relação à talk que propus foi não querer falar apenas do Scrum em si, pois é um assunto que já está bastante falado e corria assim o risco da talk ser um pouco monótona, sem nada de novo; gostava de falar de algo mais específico como por exemplo o papel do ScrumMaster e as diferenças para o típico Gestor de Projecto presente noutros modelos, como por exemplo o Waterfall.

Com receio de ter na plateia newbies no Scrum resolvi também explicar de forma rápida o Scrum, o Scrum numa nutshell.

Achei por bem colocar também no âmbito da talk algumas dicas de como começar a usar Scrum e como conseguir “vender” o Scrum numa empresa, pois foi dos tópicos que eu mais gostei de aprender e é dos que mais dá jeito para quem quer fazer um test-drive ao Scrum.

Após ter chegado à conclusão do âmbito tinha de evitar um título que fosse  muito sério e formal, como por exemplo: “O Scrum, o ScrumMaster e as diferenças para o Gestor de Projectos”.

É verdade que este título enquadra-se no âmbito da talk, mas digam lá se não tem bastante mais graça: “The Good, The Bad and the ScrumMaster”.

Este título, como é evidente, é inspirado no clássico filme “The Good, The Bad and The Ugly” ou em Português “O Bom, O Mau e O Vilão”.

O que é que poderá ser o Good? O Scrum ou a equipa por exemplo. O Bad? O Gestor de projectos tradicional, o Waterfall, o Cliente, o Product Owner, etc. O ScrumMaster? Essa é fácil. 🙂

Assim sendo espero no próximo Codebits ter a oportunidade de falar e discutir um pouco sobre Scrum, sobre o papel do ScrumMaster, de como é que o Scrum pode ajudar os projectos a ter mais sucesso e como é que se pode dar os primeiros passos no Scrum.

Fica aqui o link da minha proposta de talk:

http://codebits.eu/intra/s/proposal/209.

Até para a semana.

CSM e CSPO

Já está!

Depois de fazer 2 testes online já posso actualizar o meu perfil no Linkedin com as certificações Certified Scrum Master (CSM) e Certified Scrum Product Owner (CSPO).

Como já tinha dito aqui, fiz ambos os cursos em Lisboa com o Mitch Lacey. E posso dizer que ia com as minhas expectativas elevadas e não foram nada defraudadas!

Os cursos são excelentes, de apenas 2 dias, onde o Mitch Lacey teve oportunidade de mostrar porque é que é considerado um dos grandes experts de Scrum da actualidade.

Não hesitava em fazer os cursos novamente, pois são mesmo excelentes. Só pecam por ser apenas 2 dias cada. Há tanto para falar e tantas experiências para trocar com o Mitch que não tenho dúvida em dizer que toda a gente ficou com pena quando chegamos ao fim dos cursos.

Recomendo os cursos, principalmente se forem dados pelo Mitch.

Fiquei surpreendido quando percebi que não fui o único a fazer os 2 cursos seguidos. Tornou-se, inclusivamente, uma agradável surpresa perceber que o interesse por Scrum em Portugal tem vindo a aumentar consideravelmente.

O curso de CSM permitiu-me tirar todas as dúvidas que tinha relativamente a ser-se um bom Scrum Master bem como estudar a melhor solução para aplicar o Scrum no meu trabalho.

No CSPO como não é a minha principal actividade não tinha grandes dúvidas para tirar mas o curso serviu para abrir os olhos e olhar para o Scrum de uma perspectiva diferente, sob o olhar do cliente.

Por fim posso dizer que tive o privilégio de assistir ao Mitch e ao Pedro (pessoa impecável e com desafios semelhantes aos meus) a fazerem flexões. O ponto que o Mitch queria mostrar é que um dos valores do AGILE é o respeito e não se respeita uma equipa quando se chega atrasado (que foi o caso do Pedro).

Mal posso esperar para fazer mais cursos com o Mitch e sobre Scrum.

P.S: Pedro, a resposta é sprints de 1 semana ou Kanban. Vai para a primeira hipótese que é o que eu vou fazer. 🙂

Até para a semana.

ScrumMaster

Hoje venho-vos falar de uma certificação que, admito, até à bem pouco tempo desconhecia.

O ScrumMaster é a certificação da Scrum Alliance para gestores / responsáveis de projecto.

O Scrum, como alguns de vocês sabem, é uma framework para o desenvolvimento de software segundo a metodologia AGILE.

O princípio por detrás do Scrum é a iteratividade, ou seja, defende o maior numero possível de iterações (sprints) / repetições dentro de um projecto de modo a garantir que um determinado desenvolvimento tem a constante intervenção de todos os stakeholders do projecto procurando que o resultado final surja de forma rápida e o mais aproximado possível das expectativas dos clientes.

Nesta framework são defendidas diariamente:
– reuniões de status da equipa de projecto;
– reuniões de status das sub-equipas de projecto.

E não diariamente mas frequentemente:
– reuniões de planeamento;
– revisões do trabalho efectuado e por efectuar;
– reflexão sobre a reunião de planeamento anterior.

Os artefactos contemplados no Scrum são:
– Product backlog, ou seja, o documento principal do projecto;
– Sprint backlog, que como o seu nome indica é o documento de uma iteração;
– Burn down chart, informação gráfica do trabalho remanescente de uma iteração (sprint).

Existem várias defensores desta framework na medida em que é o completo oposto do velhinho / clássico waterfall model. Pessoalmente é algo que me agrada bastante até porque testemunhei com os meus próprios olhos um projecto completamente arruinado devido ao waterfall model. Por causa de esta experiência passada com sabor agridoce (amargo porque ninguém gosta de participar num projecto falhado e doce porque é com estes projectos que mais aprendemos) sou um defensor intransigente de iterações e auto-estradas de comunicação entre stakeholders.

Até para a semana.