Nos últimos dois dias (28 e 29 de maio) tivemos um treinamento sobre Scrum / ScrumMaster com ninguem menos que Boris Gloger aqui em São Paulo, foi um evento fechado apenas para os funcionarios do UOL.
Estamos utilizando, a metodologia a algum tempo, por tanto já tinhamos conhecimento de várias táticas e organização de como as coisas devem funcionar, confesso que comecei o treinamento achando que ia ser apenas mais um falando sobre as mesmas coisas que é facilmente encontrado em livros.
Eu estava redondamente enganado, o treinamento foi extremamente dinâmico, com alguns exercícios práticos relacionado ao tema (claro!).
Boris foi extremamente focado, não repassou perguntas com respostas prontas do tipo: “You decide!”, “You tell me”, “What do you thing?”, pelo contrário, respondeu grande parte das perguntas com respostas práticas, sem rodeios.
Começando pelo começo, ele deu uma explicação resumida sobre, qual o papel do ScrumMaster:
- Break rules;
- Remove impediments for the team;
Também discursou sucintamente a respeito de Scrum, de forma mais resumida, mas muito direto disse:
“Scrum is not a silver bullet! Scrum is a good way to show the problems, but they will not be fixed by the methodoligy”
Foi apresentado uma breve explicação a respeito do fluxo do Scrum.
Como ele mesmo disse, ele adora metaforas, uma delas é que a melhor forma de transmitir a informação, é na forma de histórias, então, inclusive citou o Brasil como sendo o grande contador de historias do mundo, vendendo novelas para todo o globo, nós adoramos contar e ouvir hsitorias.
Falou a respeito do Manifesto Ágil, ainda nao convencido a respeito do valor do treinamento, eu achei que seria mais um bonito discurso sobre motivação, e mais uma vez eu estava completamente enganado.
Ele leu o manifesto e explicou a essencia deste, como é de conhecimento de muitos, alguns “bam-bam-bans” se reunirão para discutir nao sobre qual a melhor técnica ágil de desenvolvimento de software e sim, o que todas tinham em comum, o que todas pregavam como sendo os principais valores, e foi sobre estes valores que foi criado o manifesto ágil.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Scrum Team, mais um conceito do que é o Scrum Team, entre todos os stakeholders que existem na empresa, nem todos fazem parte do Scrum Team, existe apenas 3 papéis:
Gerentes, Supervisores, Vendedores, Usuários finais, todos eles se nao estão inclusos em um dos ters papeis citados acima, não fazem parte do ScrumTeam.
Exercícios de Estimates, foram feitos inclusive clarificado muito bem a respeito de estimation:
“It’s not about the time, it’s about the complexity”
Responsabilidades, no inicio do dia 2, falamos a respeito de responsabilidades, ou seja, em cada etapa do processo, quem sao os responsáveis e quem são os responsaveis por dar suporte:
Nível estratégico
-------------------
- Visão PO TEAM
- Product Backlog PO TEAM
- Priorização PO TEAM
- Sizing TEAM SM
- Releasmanager PO TEAM
Nível Tático
-------------
- Sprint Planning 1 TEAM PO
- Sprint Planning 2 TEAM SM
- Daily Scrum TEAM SM
- Sprint Review TEAM SM
- Sprint Retrospective TEAM SM
Uma breve sugestão de como deve ser organizadas as reuniões dos Sprints
-------------------------------
Sprint 1 |
---------|---|-------------|--|
| | | |
Morning |SP1| Daily Scrums| |
| | | |
---------|---|-------------|--|
| | |RV|
Evening |SP2| | |
| | |RT|
-------------------------------
Alguns comentários:
- Ele não aconselhou fazer a Review Meeting na sexta feira, e sim na segunda feira, pois se algo der errado o time ainda tem o final de semana para acertar.
- A Retrospective tbem não é aconselhado, fazer na sexta feira, por motivos óbvios, especialmente por que o time nao estaria motivado suficientemente para uma conversa franca na sexta feira 
.
Daily Scrum, regra numero 1, não apenas do Daily, mas para todo o Scrum: “Time boxed” a Daily deve ser feita no mesmo lugar, todos os dias, no mesmo horário e nao pode durar mais que 15 minutos.
O principal envolvido é o time, a daily não é simplesmente de acompanhamento dos trabalhos pelo PO ou SM, e sim para o time, inclusive, a presença do SM não é obrigatória, como a do time é.
O SM ou o primeito membro do time não deve perguntar (como dito em várias bibliografias):
- What have you ACHIEVED since last meeting?
- What will you ACHIEVE before next meeting?
E sim:
Claro, nas primeiras dailies, as perguntas devem ser feitas, mas durante o projeto, não é mais necessário, pois todo o time sabe o que deve ser dito na meeting, se ocorrer de alguem “esquecer” o que deve ser feito, basta colocar na parede as perguntas .
Monitoring the Sprint, formas de se monitorar o sprint, utilizando os graficos, que podem ser relacionados a progresso de tarefas, progresso de historias e quantos pontos do product backlog já foi “queimado”.
Scaling / Distributed Teams / Larger Scrum, bom este tópico merece um post só para ele, no entando de forma bem resumida, é posivel ter times em localidades diferentes, para evitar “guerra” entre os times, a idéia é misturar os times, ou seja, time1 com membros da localidade A e B time2 com membros da localidade A e B, assim evita a competitividade entre os times.
Fechando o treinamento fizemos um exercicio de 4 sprints, com cartas, baloes, dados e papel, muito interessante e “fun”.
“Fun” foi algo que o Boris fez questão de perguntar depois de todos os exercícios, “Was it fun?”, e o recado no final foi claro, sempre que o time se sente parte da solução e se diverte fazendo algo, a produtividade e qualidade será bem mais satisfatória para todos os envolvidor.
Após com tradicional comprimento “wulf”, nos tornamos os mais novos Certified ScrumMasters!
+ 
+
