Certificado da Scrum Alliance

Semana passada recebi meu login da Scrum Alliance... muita emoção quando eu vi aquele e-mail na minha caixa postal :)

Agora mais do que nunca é fazer valer este certificado!!!

Time Box e Sprint Planning

Hoje passei por uma experiência que provou muita coisa a respeito de Time Box na hora de executar o Sprint Planning.

O que aconteceu foi o seguinte: Precisávamos especificar algumas ferramentas para nosso projeto, cada uma destas ferramentas seriam um Product Backlog e então entramos na reunião com o Product Owner, que veio com alguns 'cartões de estória' para cada um destes, e dai retiraríamos então nossos Sprint Backlogs. Já partindo do pressuposto que nossa Sprint teria o Time Box de duas semanas, começamos a ver o primeiro Product Backlog, já priorizado pelo PO.

Começamos a ler cada um dos 'cartões de estória' e tirar nossas dúvidas com o PO, em seguida resolvemos levantar os pontos, que por sugestão do gestor acabou sendo visto em dias, logo vimos que o primeiro item já seria o suficiente para ocupar a nossa Sprint, com uma certa possibilidade (baixa) de sobrar tempo e podermos então pegarmos um novo item. Apesar de avisado sobre isso o gestor resolveu que deveríamos ver todos os outros itens de backlog que o PO já havia feito os 'cartões de estória', mesmo após a argumentação que este conhecimento muito provavelmente seria perdido durante o tempo decorrido, nosso gerente argumentou que deveríamos ver, pois haviam itens que se repetiam nos itens de backlog e isso poderia nos ajudar a ter a visão de criar "dispositivos reutilizáveis".

Bom, mesmo descordando (eu) seguimos (toda equipe) em frente. Gastamos 2,5H pela manhã e 1,5H na parte da tarde. Isso basicamente conversando com o PO e discutindo algumas coisas técnicas com a equipe. Depois disso tudo claro que devíamos ainda analisar os itens vistos e separar em tarefas pequenas que não tivesse mais de 2 dias de trabalho, nesta parte estávamos só nós sem o PO e o gerente. Vimos tudo que foi levantado distribuímos os pontos nas tarefas e então obtivemos a visão de tudo que teríamos que fazer nos próximos dias, como de costume... muuuuito trabalho! :)

Vamos apontar o que esteve errado nisso tudo:

1º - O time box foi totalmente desrespeitado. Partindo do princípio que no Sprint Planning devemos levantar os itens que serão 'atacados' durante a sprint e logo definirmos seus pontos de esforço. Ou seja, deveríamos usar as 4Hs para fazer tudo isso e não perder quase o dia todo em reunião.

2º - Ao vermos tantos Products Backlogs no mesmo dia, quando fomos levantar as tarefas, toda a equipe estava confusa com alguns requisitos de um item para outro. Claro que excesso de informação pode ser prejudicial ehehe

3º - Se um novo integrante entrar na equipe ele vai ter que tirar todas as suas dúvidas com os membros da equipe e com o PO, é claro, mas deixou de ter todo aquele Brain Storn do Sprint Planning. Ou seja acabou lembrando Waterfall!

4º - Reuniões demoradas e sem pausa causam um certa fadiga onde gera falta de atenção e comprometimento dos envolvidos. Desta forma deveríamos ter tido uma leve pausa no período da manhã.

O que eu vejo que deveria ter sido feito:

1º - Para atender o gerente o Scrum Master devería ter analisado o documentos juntamente com o gerente e o PO (se possível), afim de ter a visibilidade dos itens a seguir conforme o solicitado. Isto é possível porque o Scrum Master (eu) possui um perfil técnico que faz parte da equipe como arquiteto/desenvolvedor e ainda conhece do negócio (praticamente um severino). Desta forma o Scrum Master poderia passar para a equipe um visão do que ocorreria nos próximos passos que poderia ser reaproveitado.

2º - Deveria ter sido respeitado o Scrum e feito da maneira correta: 4Hs para toda a Sprint Planning, pois o Time Box é algo que o Scrum bate muito forte para que seja seguido a risca.

3º - Tentar tirar dúvidas técnicas entre a equipe junto com o PO pode ser bem desastroso e tomar o tempo precioso dele. Acho que o PO deve participar de forma bem ativa, mas só até o time ter todo o entendimento do negócio, depois o PO pode ser dispensado e a equipe parte para a divisão das tarefas e devida pontuação, claro que em determinados momentos pode haver dúvidas que devem ser tiradas com o PO.

Por fim, nós acabamos tendo todo este trabalho, creio eu, pelo fato do PO tirar férias daqui a uns 50 dias e por isso o gerente quis adiantar as coisas, mas acabou dando um pouco errado. Penso que o Scrum foi elaborado para ser seguido e algumas de suas partes adaptadas, mas não tudo.

Ainda precisamos arrumar uma solução para esta falta no PO em determinada parte do projeto, pois desta forma perdemos um dos pontos fortes do Scrum que é ter o PO o mais junto da equipe o possível.

Abraços!

Curso CSM com Alexandre Magno (final)

Com toda a empolgação do mundo fui para última parte do curso. Tive que correr um pouco na hora do almoço para poder almoçar, tomar um banho e fazer o checkout do hotel, que me permitiu ficar aqui na recepção até a hora de eu partir de Porto Alegre.

Antes de mais nada, CSM significa Certified Scrum Master e não Curso de Scrum Master... por favor!!! ehehehe 

Na ultima parte do curso tivemos uma verdadeira aula de como escrever User Story, identificar épicos, divisão de tarefas e tudo acompanhado de exercícios práticos. Aliás o estilo do curso foi todo assim vários exercícios e muitos cases para ilustrar e dar um rumo. Vimos também como é possível aumentar a velocidade da equipe adicionando mais membros na equipe, devido ao processo ser interativo... ou seja adeus waterfall!

Outro ponto bacana foram explicações simples de porque não existe uma relação direta entre pontos e horas, as vezes coisas tão básicas como: O sapato numero 40 equivale a quantos cm? Resposta: depende do fabricante! E isso é óbvio não é? Então porque fazer relação entre pontos e horas? ehehehe A quebra de paradigmas é sem dúvida uma dos grandes problemas e outro que é seu complemento é a cultura das pessoas :)

Para fechar o curso... mais um atividade :0) 

E não daria para esperar menos. Foi feito um exercício de Scrum escalável!!! Quatro equipes trabalhando no mesmo projeto, como se fosse uma em cada país. Cada uma possuía seu quadro (Kanban) com seu Scrum Master. 

A tarefa: Ken Schwaber falando o seguinte: "O exército dos Waterfall Wolves" baniu nossos CST`s das principais cidade do mundo. Agora precisamos nos organizar em uma cidade que proporcione um ambiente familiar de trabalho e lazer para todos os Scrummers do mundo. Precisamos construir a Scrumland!", claro que isso é fantasia e o Ken Schwaber não disse isso!

Em cima disto recebemos itens de backlog para fazermos e logo estes foram divididos entre as equipes. 10 minutos para Sprint Planning... itens devidamente priorizados partimos para identificação das tarefas, tendo em vista que teríamos uma sprint de dois dias de 10 minutos e um Daily Meeting de 2 minutos. Ficamos responsáveis por construir a biblioteca e uma loja de post-its... e tínhamos que realmente montar isso tudo e resistir aos testes de qualidade do Product Owner (petelecos nos prédios).

Após o daily, fomos fazer um Scrum of Scrum para sincronizar as equipes onde foi possível identificar gargalo na minha equipe e folga em outra, logo combinamos de ter uma cooperação dos membros ociosos.

No final atingimos o meta estipulada pelo PO!!!

Daqui para frente é aprofundar ainda mais em Agile e Scrum!!!!

Curso CSM com Alexandre Magno (parte 3)

Hoje na terceira parte do curso foi só Scrum. :)

Nesta terceira parte foram desmistificados cada um dos papeis dentro do Scrum. Claro que como em todas as conversas sobre papeis o mais evidenciado foi o do Scrum Master :P

Entramos na famosa discussão sobre ter um Scrum Master que realiza tarefas técnicas dentro da equipe, tal como o que eu faço hoje, sendo Arquiteto, Desenvolvedor e Scrum Master. Foi bom escutar de um profissional bem gabaritado que isso é meio furado, já que em vários momentos eu vou acabar gerando um impedimento na minha tarefa 'técnica' por estar resolvendo coisas da equipe. Espero que com isso eu também não seja afastado do Scrum e sim focado :)

Chegamos numa conclusão muito boa sobre isso tudo, que seria: É ótimo ter um Scrum Master com o pé firme no desenvolvimento pois ele pode ter visão da próxima Sprint e começar a levantar pontos que podem ser críticos para ela e então já tomar medidas para a prevenção. Mas este Scrum Master deve se ater a isto, no mais deve executar seu papel com qualidade, para que o processo seja garantido, para que a equipe esteja realmente protegida, entre outras. O que pode ser feito e isso é uma prática do Scrum é: Terminou suas todas as tarefas que você deve fazer, não tem outras? Então vá ajudar quem precisa! Go Team!!! Ai sim o Scrum Master vai ajudar o desenvolvimento de uma maneira sadia sem fazer com que ele tenha que ser o famoso Jedi!

Outra coisa que foi bem lembrada é que o Product Owner, precisa ser muito bem treinado para que ele saiba transmitir ao time o que o cliente deseja, de maneira clara com uma linguagem única. O que me faz lembrar la da empresa onde trabalho que acabamos tendo um PO por projeto e que muitas vezes complica, pois é mais um trabalho para demonstrar como tudo funciona para que ele entenda como priorizar o backlog e tudo mais. O ideal segundo discussões no curso é termos um único PO que atende os clientes dos mais variados projetos, claro que se o número de projetos for tão grande que o PO não esteja conseguindo desempenhar suas atividades deve haver mais um e então uma divisão destes projetos para cada. Isso seria incrível, ganharíamos uma velocidade com o levantamento das necessidade ou requisitos e ainda poderíamos ter User Stories vindos praticamente prontos do PO.

Tiveram outros pontos apresentados e muita colaboração de todos com várias explicações e casos de sucesso aplicados pelo Alexandre, citando empresas com a Gol.

Logo publico a última parte do evento.

Curso CSM com Alexandre Magno (parte 2)

Depois do famoso almoço executivo :P

Voltamos para o curso e ai sim entramos no processo do Scrum. Cada um dos itens foi passado, superficialmente, e discutido amplamente até que todos estivessem com suas dúvidas sanadas. Isso eu achei muito legal, porque eu já tinha ouvido falar que no curso seria passado como o processo era e pronto. Já neste a única coisa que foi dita é "evitem tentar ficar tirando apenas dúvidas sobre seus problemas ou da sua empresa e tentem absorver o que é o Scrum e o que ele se presta em resolver". Acho que foi mais ou menos isso que o Alexandre falou. O mais bacana foi ver que eu não sou o único a ter este conceito, porque eu sempre entendi sala de aula como isso! :)

Após tudo isso executamos o famoso Scrum 59! Nele nos foi passada a tarefa de construir um 'Flyer', para um Spa de Cães. Executamos de uma forma rápida (59 minutos) praticamente todos os processos do Scrum, lógico que nesta etapa os participantes ainda não tem noções completas sobre como executar o Scrum, mas a intenção era esta! A de acertar errando. Isso porque o ser humano aprende mais errando, é claro! 

É interessante participar novamente de um simples processo onde você se força a trabalhar com outras pessoas que nunca viu na vida e mesmo assim pode ver as coisas funcionando bem em pouco tempo.

Contamos também com a participação do Daniel Wildt da Dell aqui de Porto Alegre (onde estou no momento), que enriqueceu os debates varias vezes com cases e experiências profissionais.

Lamento apenas não poder ficar para o evento de quarta feira sobre Agile. Mas existem coisas mais importantes como a família :)

Amanhã continuo blogando sobre o evento.

 

Curso CSM com Alexandre Magno (parte 1)

Hoje as 09:05 começou o treinamento ministrado pelo Alexandre Magno (CST) da Caelum.

Na primeira parte vimos pouco sobre o que fala o Scrum, mas tivemos uma base excelente sobre método Interativo e Waterfall, onde ele demonstrou que uma das principais razões do Scrum ser de difícil implantação, é por causa da forma interativa de trabalho, que as pessoas custam a entender. Isso tudo claro devido a anos trabalhando com o modelo waterfall. 

O que achei legal foi um fato que ocorreu com ele tentando mostrar isso a um amigo. Ele disse ao amigo que havia encontrado uma maneira de executar Scrum usando Waterfall e então o amigo começou a identificar os mais variados artefatos usados pelo Scrum, dizendo então que daquele forma o Scrum funcionaria e que ele conseguiria ter várias práticas em cada uma das iterações. Lógico que isso foi só uma jogada para que o citado amigo identificasse que o problema na verdade era a quebra de paradigma e que pudesse compreender aquela mudança.

Toda esta primeira parte tivemos muita interação entre os participantes, formando 3 equipes de 4 integrantes e mais uma de 5. 

Demonstrações de métodos ágeis, com atividades, que nos fizeram ter real noção de como a distribuição de tarefas e responsabilidades podem nos ajudar na execução do projeto.

Em fim logo nesta primeira parte tivemos muito sobre agile, gestão, etc. Sem quebra pau sobre PMP, RUP e outros.. o que me deixou mais feliz, porque ficou algo  muito tranquilo e legal de assistir e aprender.

Ahhh e para que acha que é só ficar dentro da sala e pronto.. se engana o próprio Alexandre já falou que se não demonstrar que absorveu, não leva o CSM e ele já fez isso com algumas pessoas :)

Abraços!

O que é trabalhar de forma ágil (Agile)?

Hoje um colega me fez esta pergunta. Na verdade a pergunta não foi bem essa, mas de forma sucinta foi isso. Claro que antes veio todo o cerco por volta de trabalhar usando Scrum, quadro com post-its e tudo mais.

Respondi que trabalhar de forma ágil, usando Scrum, era basicamente cortar as 'gorduras' ou formalismos existentes no dia-a-dia tradicional e que não agregam valor no fim do projeto e ainda entregar partes funcionais do produto antes de ter concluído ele por completo dando visibilidade ao cliente.

Exemplifiquei da seguinte forma: Imagine algo simples como fazer uma banqueta de madeira... no método tradicional eu farias vários desenhos até que um deles agradasse a você, quando estivesse com isso concluído, faria um projeto definitivo da banqueta com medidas precisas, desenhado no autocad e tudo mais que tivesse direito. Agora pare um instante e pense: Para você aprovar um dos desenhos lá se foi um dia por exemplo, para eu passar para o projeto definitivo e autocad, mais um dia. Até agora você não sabe como será a banqueta de verdade, e o pior é que ela nem começou a ser produzida! Este passo de produção seria dado logo após a sua aprovação final do meu projeto no autocad (ehehe). Ai você pensa 'Maravilha! Aprovei o projeto agora é só esperar chegar!'. Em termos seria isso, mas quando chegar você pode ser altamente feliz ou dizer que aquilo que foi materializado a partir de sua ideia, não era bem da maneira que você queria (o que é muito comum) e faz sugestões e ajustes e insere coisas novas como um apoio de pé... e por ai vai.

Agora analisando esta situação temos três equipes distintas: dono do produto, analista/arquiteto e produção. Cada um aqui com tarefas bem distintas, certo? Bom, por isso eles precisam trabalhar tão longe? Não! E isso que a visão ágil vai fazer colar os integrantes juntos nos momentos necessários. Este mesmo processo da banqueta na visão ágil ficaria assim: Você me diz mais ou menos como quer sua banqueta, então produzimos um pé dela, 3Hs depois de termos conversado você estará vendo este pé e ai já pode dizer se quer mudar algo nele, se quiser.. nós já mudamos e enquanto isso a equipe de produção está trabalhando no tampo que é mostrado em 5Hs após a nossa conversa e já com um pé montado com as mudanças solicitadas! Então se tiver algo mais a ser modificado, novamente, mudamos e com estas informações a equipe já está mudando e terminando os outros pés, que no fim do dia você está vendo a sua banqueta quase que totalmente pronta! Faltando detalhes que você ainda pode opinar para ter o produto que você tanto quer! Ou seja no final de 1,5 dias você vai ter sua banqueta como você queria!

Conclusão: Economizamos tempo, pessoas, dinheiro e ainda saímos muito satisfeitos! Pese nisso na modelo tradicional você gastou 2 dias só planejando e com Agile (Scrum) você teve o produto em 3/4 deste tempo!!!

Isso é processo ágil! Isso é pensar ágil! E por fim... o Scrum vai te ajudar e muito com isso.

Pense nisso ;)