Depois de ser um dos 200 seleccionados para fazer o novo exame beta do Certified Scrum Professional (CSP) da Scrum Alliance e de ir a Madrid para o fazer (em Outubro)… Passei.

Pertenço aos 70% dos candidatos a ser Certified Scrum Professional (CSP).

Esta certificação é a certificação que atesta a experiência profissional em metodologias AGILE, mais concretamente Scrum.

O exame não foi fácil mas deu para mostrar o que eu valia/sabia. Foi a primeira vez que fiz um exame e não desgostei da experiência apesar de ter terminado o exame cansado.

Acho curioso, em mais de 10 anos de carreira, só este ano ter obtido certificações (nunca se tinha proporcionado) e logo 3 (CSP, CSM e CSPO).

Quis fazer as certificações em Scrum porque é neste momento a “forma” de gerir projectos em que mais acredito.

Para o ano espero planear (criar um roadmap) mais certificações: PMP, ITIL, PRINCE2… you name it.

Foi um ano muito bom (tanto a nível pessoal como profissional) este de 2011. Tenho tudo para acreditar que 2012 ainda será melhor.

Bom ano para todos.

Até para a semana.

Este ano foi o primeiro ano em que assisti ao evento. E não sei se por não ter nenhuma expectativa ou se por não ter pensado muito em como seria o evento tenho de admitir que fiquei completamente maravilhado.

Posso dizer sem hesitar que foi o melhor evento de TI a que assisti em território Português.

Foram 3 dias em que se respirou e transpirou (literalmente) tecnologia, com talks e um concurso de programação à mistura.
A Sapo está de parabéns, pois o evento não podia ter corrido melhor: desde o ambiente proporcionado, ao branding discreto, à alimentação e comodidades fornecidas, tudo foi perfeito.

O Celso Martinho (CTO da Sapo) disse que este tinha sido o melhor Codebits de sempre e pelo que eu vi, apesar de não ter assistido aos anteriores, não disse mentira nenhuma.

Os únicos pontos menos bons, na minha opinião, foi a (aparente) ausência de reciclagem, a pouca assistência às talks (pelo menos foi a ideia com que fiquei) e a dificuldade em obter um badge “Friend of Meo” (private joke ).
O ponto alto do evento foi sem dúvida os “nuclear tacos”. É uma experiencia pela qual todos devemos passar, pelo menos uma vez na vida, e que quero repetir.

Acho que um dos “major achievements” do evento foi sem dúvida criar um ambiente com um “brand free” feeling mas com as marcas bem presentes: Sapo, TMN, Meo, O’Reilly, Microsoft, Lego, Sony Ericsson, etc.

A ideia dos “badges” também estava muito bem conseguida.

Resumindo, foi um evento excelente ao qual quero voltar para o ano que vem.

Até para a semana.

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.

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.

O resultado está à vista de todos, temos tido muitos menos bugs nos testes finais de aprovação o que acaba por ser curioso pois como não existem praticamente bugs o cliente sente-se com confiança para pedir sempre alguns melhoramentos. Algo que antigamente com mais bugs era impossível, quer por falta de tempo ou por falta de confiança nos desenvolvimentos.

Após algum tempo a praticar scrum não tenho dúvidas que trouxe melhorias significativas no trabalho, principalmente a nível processual.

Não me canso de dizer que estou rendido ao scrum.

O único (grande) aspecto do scrum que ainda não estou, de todo, convencido é a utilização de sprints em desenvolvimentos web.

Os nossos clientes têm um time-to-market extremamente agressivo e não é concebível que tenham de esperar 2, 3 ou 4 semanas por um package de desenvolvimentos quando podemos ter várias releases durante esse período de tempo disponibilizando de forma gradual e mais atempada as novas features ou correções de bugs.

Eu costumo dizer que o melhor scrum é o nosso scrum. Não é o scrum que vem nos livros mas sim a forma como adaptamos o scrum à nossa realidade. Se forem vocês a adaptarem-se ao scrum, então o objectivo principal do scrum está logo desde o início a falhar. Deve ser o scrum a adaptar-se a vocês e não o contrário. O scrum procura melhorar o funcionamento de uma equipa e não mudá-lo completamente ignorando o meio onde esta equipa está inserida.

É como alguém uma vez disse: “Don’t ask what you can do for scrum, but what scrum can do for you!“. Não foi bem esta frase mas era algo do género.

Até para a semana.

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.

Para quem não sabe, vão ocorrer duas formações em Lisboa (oficias da Scrum Alliance):

- Certified Scrum Master: (CSM)

- Certified Product Owner: (CPO)

Tanto uma como a outra serão dadas pelo Mitch Lacey.

As inscrições “early bird” terminam no final deste mês por isso recomendo-vos vivamente a reflectir na vossa presença (ou não) nestas duas formações que não ocorrem todos os dias em solo nacional.

Eu vou tentar lá estar. Tanto numa como na outra.

Para meu grande espanto, o PMI resolveu virar as suas agulhas para o Agile e vai lançar ainda no decorrer deste ano a sua primeira certificação sobre os princípios e conceitos Agile (PMI Agile Certification). Podem ler tudo sobre esta certificação aqui.
Esta é a prova provada que as metodologias Agile estão a ganhar cada vez mais peso na gestão de projecto e a conquistar mais e mais adeptos.

Como podem ver, este é um ano muito bom para começarem a pensar em tirar uma certificação em Scrum / Agile.

Já não há desculpas, pois a oferta já é bastante boa.

Eu vou-me já inscrever.

E vocês do que estão à espera?

Até para a semana.

Mudou e continua a mudar.

Estamos hoje em plena web 2.0 e a começar a ouvir aqui e ali sobre a web 3.0.

Ora as pessoas, nos seus locais de trabalho, também mudaram.

Gosto de dizer que hoje estamos na era do recurso humano 2.0.

O RH 2.0 difere dos restantes em termos das suas convicções, necessidades e expectativas.

Convicções: Todas as pessoas têm as suas convicções e crenças. O recurso humano 2.0 é o recurso do século XXI. As pessoas têm que acreditar na empresa que representam. Um colaborador que acredita na empresa que representa e na sua marca é um colaborador mais eficiente em prestar serviços ao seu cliente. O recurso humano 2.0 é uma pessoa que “veste a camisola” da sua organização.

Necessidades: Todos temos necessidades. E um colaborador de uma empresa não é excepção. O recurso humano 2.0 é um indivíduo que necessita de se sentir valorizado, acarinhado e apreciado. Todos os recursos humanos trabalham de forma mais eficiente e eficaz a partir do momento em que o seu trabalho é reconhecido. Só depois do reconhecimento é que aparecem as necessidades monetárias e restantes regalias.

Expectativas: O recurso humano 2.0 quando aceita o desafio de trabalhar numa empresa, cria uma série de expectativas. Expectativas que não estão implícitas no contrato de trabalho mas que são igualmente importantes de serem cumpridas. A própria entidade patronal também cria as suas próprias expectativas relativamente ao novo colaborador. As expectativas do colaborador deverão ser percepcionadas pela organização de forma a irem ao encontro delas. Para o recurso humano 2.0 as expectativas são tão ou mais importantes do que o que está explicito no contrato de trabalho.

As principais qualidades do recurso 2.0 são: Assertividade, Perseverança, Equidade, Determinação.

E agora as perguntas que cabe a cada um responder são:
- Os vossos colaboradores são rh 2.0?
- Como é que podem ajudar os vossos colaboradores a chegar lá?

Até para a semana.

O primeiro contacto da equipa com o Scrum não foi muito pacífico (embora também não tenha sido nenhuma desgraça), pois apesar de ter transmitido que a presença de um quadro com as tarefas de um projecto não tinha como propósito ser um “big brother”, a verdade é que senti alguma resistência à mudança, pois o white board era encarado como uma ferramenta de controlo/subjugação. Constatei que o white board (inicialmente) em vez de se tornar um facilitador tinha-se tornado uma fonte de stress.

Mas na verdade, e tal como esperava, após a equipa habituar-se à presença do white board (uma questão de dias), bem como das daily scrums, o trabalho começou a fluir de uma forma muito interessante e sem dúvida que nos tornamos bastante mais eficientes.

Com as nossas daily scrums e com o white board conseguimos de forma rápida e simples aferir em que ponto do projecto estamos, que dificuldades estamos a sentir no desenrolar das actuais tarefas, o que está feito, o que está por fazer e o que está realmente feito (validado).

Inclusivamente tivemos um projecto em que o cliente quis fazer uma versão beta e como tínhamos todas as tarefas claramente identificadas foi muito simples definir que features seriam possíveis para uma versão beta e que features apenas estariam disponíveis para a versão final. E é neste tipo de situações em que o Scrum se torna uma mais valia e se destaca das demais metodologias de gestão de projectos.
Apenas deixamos de utilizar o white board quando entramos em fase de testes. Aí usamos uma ferramenta open-source, chamada redmine, para fazermos toda a gestão do fluxo de reporting de bugs (desde o momento em que o bug é reportado até à sua resolução e validação por parte do cliente).

Neste momento estou muito satisfeito com o Scrum e a equipa também já o perfilhou. Estamos todos (a equipa) satisfeitos com o Scrum. As “coisas” mudaram para melhor e somos hoje uma equipa mais eficiente.

Gostaria só de deixar um aviso à navegação: o Scrum não é uma silver bullet, ou seja, não é a solução para todos os males de uma equipa. É apenas uma excelente forma de gerir e desenvolver projectos. Li uma frase na internet que explica da melhor forma o que acabei de escrever: “A great team will have great success with or without Scrum. A shitty team will still produce shit with scrum. Just that the shitty scrum team will see it earlier than the shitty no-scrum team”.

Até para a semana.

Agora se imaginarem um projecto como sendo uma história da Disney, existem sempre “os bons” e “os maus”. Ora se “os bons” são todos estes que acabei de referir, “o mau” (o vilão) é sem dúvida nenhuma o scope creep.

O scope creep é a pessoa que basicamente passa o tempo todo a tentar alterar o âmbito acordado e a forçar a inclusão de novas features sem mexer no prazo e no custo. Soa-vos a alguém familiar? É muito provável que sim, pois todas as histórias (neste caso projectos) têm sempre um vilão.

A sorte é que em todas as histórias existe sempre alguém (um herói a.k.a. “o bom”) que faz frente ao mau e que geralmente leva sempre a melhor. Inclusivamente muitos deles fazem parte da nossa infância: o batman, o spiderman, o capitão américa, o hulk, etc.

Num projecto quem costuma ser o herói que tenta salvar o mundo (projecto) do scope creep?

Adivinharam! É o gestor de projectos!

O project manager apesar de não ter capa, de não andar com as cuecas por fora das calças e de não ter propriamente poderes sobrenaturais, deve a todo e qualquer momento lutar intransigentemente pelos interesses do projecto, o que implica “derrotar” o scope creep.

E como?

Blindando a equipa de projecto de todo e qualquer contacto com o scope creep e relembrando constantemente ao vilão o âmbito acordado do projecto.

Não quer dizer com isto que alterações ao âmbito do projecto sejam de evitar. As mudanças devem ser encaradas com naturalidade e são de salutar. O que não é de todo de saudar é alterações de ultima hora, “em cima do joelho”, sem medirmos o real impacto no projecto e comunicadas de forma pouco clara e pouco oficial. E é desta forma que um scope creep tenta alterar o âmbito de um projecto. A tentar incluir uma pequena alteração aqui, uma pequena feature acolá, destruindo aos poucos toda e qualquer hipótese do projecto ser bem sucedido.

Atenção aos scope creeps. Eles andam por aí! A sorte é que temos sempre um super herói para salvar o dia.

Até para a semana.

Nota: Scope creep pode também ser definido como o fenómeno de alterar o âmbito e não como a pessoa que tenta provocar a alteração.