[Open Source] Entrevistas para Scrum Master – Todas as perguntas

Depois do último post onde revelei um top 5 de perguntas que faço quando entrevisto um candidato para a vaga de Scrum Master… resolvi ir um pouco mais além… e escrever um post com todas as perguntas que costumo fazer numa entrevista.

Enquanto andava à procura do meu ficheiro com as perguntas acabei por “esbarrar” no meu material de training, de workshops, etc… que constituem o meu toolkit de Agile… e achei que faria todo o sentido disponibilizar o meu material à comunidade.

Já recebi tanto da comunidade Agile que decidi fazer um contributo para mostrar todo o meu agradecimento.

Vou tornar o meu material “Open Source”… ou seja… vou disponibilizar todo o material que nunca tornei público, em ficheiros editáveis (exemplo: word, excel, powerpoint), para utilizarem da forma que melhor acharem. 🙂

Assim sendo vou disponibilizar 4 tipos de conteúdos:

  • Perguntas de entrevista
  • Formação
  • Workshops
  • KPIs

Hoje ficam online as perguntas (e as respostas) aqui.

Nós próximos posts disponibilizarei os restantes conteúdos.

Até para a semana.

(Nota: As imagens que eu utilizei no meu toolkit não são de minha autoria… e é perfeitamente normal que reconheçam conteúdos de outros autores.)

Será o Product Owner uma galinha?

Foi hoje publicado, na Scrum Alliance, mais um artigo meu. 🙂

O artigo explora a posição do Product Owner (PO) dentro da equipa de Scrum tendo em conta duas escolas de pensamento: a escola de pensamento que acredita que o Product Owner é uma “galinha” e a outra escola de pensamento que defende que o PO é um “porco”.

Para quem não sabe / não se recorda da história do porco e da galinha pode ver aqui.

No artigo faço também referência ao modelo de Tuckman e às suas etapas: Forming, Storming, Norming,  Performing.

Até para a semana.

 

Spoiler: Na minha opinião todos os papéis / roles prescritos no guia do Scrum são porcos… e não galinhas.

 

Scrum Master Toolbox Podcast

A semana passada tive o prazer de ser convidado pelo meu amigo Luis Gonçalves (co-autor do livro Getting Value out of Agile Retrospectives) para participar no podcast Scrum Master Toolbox.

Falou-se de vários temas relacionados com Scrum e com situações que qualquer Scrum Master (mais cedo ou mais tarde) se depara ao longo da carreira.

O podcast decorreu durante uma semana, de segunda  sexta, e todos os dias respondi a uma pergunta diferente.

Deixo-vos ficar com os links para os dias:

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.

como o scrum mudou a minha vida

Cheguei à conclusão que sinto um enorme afecto pelos post-its que durante a noite caem do quadro, e tenho de os colar de manhã quando chego ao escritório, obrigando-me saber de cor e salteado todas as tarefas de todos os projectos ao ponto de saber exactamente de onde cada post-it caiu (projecto/sprint e respectivo estado).

O scrum enquanto ferramenta de tracking de projectos é excelente. O que para mim é o mesmo que dizer: “Bye bye Microsoft Project!” 🙂

E não ajuda apenas o project manager / scrum master. De forma inconsciente toda a equipa tem presente todas as tarefas que estão feitas, por fazer e em progresso.

Não vou dizer que o scrum é muito melhor que os mandamentos do pmbok mas a verdade é que o scrum é mais prático enquanto o pmp é mais teórico.

Como já disse repetidas vezes, o scrum por si só não é a solução para o problema… agora que o ajuda a resolver lá isso ajuda.

Eu sei que sou suspeito, mas neste momento estou bastante mais fã da utilização do scrum do que do pmbok. Agora é como tudo, o scrum é especificamente vocacionado para o desenvolvimento de software (embora há quem diga que pode ser usado em outras áreas) enquanto o pmbok pode ser usado nas mais variadíssimas áreas. Daí a minha inclinação para o scrum. E verdade das verdades, o scrum é divertido!

Até para a semana.

scrum na optimus

Comecei há cerca de um mês a fazer scrum aqui na Optimus.

Não é um scrum bíblico mas posso dizer que é o scrum à nossa moda! 🙂

Quase que dava uma receita.

Aqui ficam os ingredientes:
1 quadro branco (obtido de forma caricata);
100 post-its (amarelos);
1 caneta para o quadro (para identificar as sprints e fazer separações);
1 scrum master (cabe-me a mim a honra);
1 product owner (cabe-me novamente a mim a honra);
várias equipas de projecto;
boa disposição (de toda equipa) q.b..

E a preparação:
Primeiro colocamos o quadro branco (scrum board) num local bem visível para toda a equipa.

Depois com a caneta separamos o quadro em 5 colunas: “Todo”, “In progress” (que subdividimos em “Going” e “On hold”), “To verify” e “Done :-)”. Inicialmente não tínhamos a coluna “In progress” dividida mas assim que tivemos um post-it bloqueado sentimos logo a necessidade de criar uma coluna que nos diga quando uma tarefa está parada. Qualquer post-it ali parado não é bom sinal e requer a nossa atenção. Na coluna de tarefas terminadas recomendo o smile “:-)” porque qualquer post-it que chegue a essa coluna é motivo de satisfação de toda a equipa.

De seguida colocamos em linhas as nossas sprints (que são os nossos projectos) escrevendo o nome da sprint e o respectivo código interno (código que utilizamos para identificarmos os emails relativos à sprint/projecto).

Passamos agora para a estimativa de cada sprint (temos várias a decorrer) e as suas user stories. As nossas estimativas são orientadas à user story e não à sprint, pois desta forma é só colocar os post-its, na coluna “Todo”, com o nome de cada user story e com a indicação da sua estimativa no quadro.

Todos os dias, logo ao início da manhã, fazemos a nossa standing meeting/daily scrum, ou como gosto de lhe chamar, os nossos 5 minutos intensos de reunião diante do quadro branco. Durante uns breves 5 minutos fazemos, de forma animada, informal e descontraída, o status diário da sprint onde abordamos o que foi feito no dia anterior, o que iremos fazer hoje e dificuldades com que possivelmente tenhamos em mãos.

Após todas as reuniões do dia abrimos um excel onde tenho a burndown chart de cada projecto e actualizo com o status obtido. Desta forma conseguimos visualizar o progresso e principalmente o ritmo do projecto. Estamos atrasados? Estamos adiantados? Com que ritmo estamos a trabalhar? A nossa burndown chart tem resposta para todas estas questões.

O resultado final são sprints/projectos terminados a tempo e horas altamente orientados ao cliente e aos seus requisitos. No fim garantidamente ficamos todos felizes, a equipa por ter a performance desejada e o cliente por ter os resultados esperados.

Recomendamos servir o vosso “cozinhado” acompanhado de Extreme programming (XP), principalmente pair programming (2 developers a trabalhar no mesmo computador), de Test-driven development (TDD) (programação orientada aos casos de sucesso e insucesso que se pretende testar) e de Coding standards (regras e/ou boas práticas de programação).

Por fim polvilhem tudo com metodologias AGILE a gosto.

Claro que existem muitos pontos que podemos melhorar e/ou fazer de forma diferente, mas sou da opinião que o Scrum é uma receita de autor, onde cada um o aplica de acordo com a sua realidade. A implementação do Scrum não é por si só um objectivo, mas sim um meio para atingirmos o verdadeiro objectivo que são projectos bem sucedidos.

E vocês também fazem Scrum?

Até para a semana.