22
mai
12

Saúde do Daily

Um dos desafios de um time scrum é manter seu daily meeting efetivo, e quando digo isso estou falando da presença, do timebox, da qualidade da informação passada alí. De nada adianta ter um daily que é feito sempre no mesmo horário, termine no tempo certo, todos ‘movimentem’ suas tarefas e ninguém se lembre do que foi dito um minuto depois. Mas, como gosto de resolver um problema por vez, vamos começar com o (teoricamente) mais fácil.

Presença do Daily!

Em um dos times que trabalhei a algum tempo atras, observei que o Daily Meeting frequentemente não acontecia com todos os membros do time. O time não percebia o impacto de suas faltas ou atrasos no Daily Meeting. Na verdade, eles não necessariamente percebiam quem faltava e com que frequência. Alguns tinham que faltar um dia por semana para dedicar-se ao mestrado ou uma outra atividade alinhada com o time e com a empresa e a percepção de presença do Daily acabava recaindo nessas pessoas. E eu me faço a seguinte pergunta: “Quando ninguém tinha compromisso externo, a presença era alta?” Não necessariamente. Opa! Então precisamos dar visibilidade do que está acontecendo, para poder melhorar o que chamei de ‘Saúde do Daily’.

A minha primeira ação foi deixar visível, no quadro, um calendário que era gerado no Sprint Planning, contendo os compromissos do time durante aquele período, incluindo as ausências conhecidas. Surgindo qualquer novidade no sprint, esse calendário seria atualizado ali mesmo no quadro por qualquer um, imediatamente após o daily.

Prá ajudar ao time a ter uma visão melhor de suas presenças, propus uma dinâmica muito comum (que não é novidade desde o tempo da minha avó). Uma chamada. Isso mesmo! Como a titia da escola fazia. Mas é muito importante que essa informação/ferramenta seja do time, e somente para ele. O seu propósito não é controlar, mas dar visibilidade de um ponto que podem melhorar.

Coloquei então, em um lugar reservado no quadro do time, as iniciais de cada um (obviamente incluindo as do PO e SM), aonde qualquer um do time poderia, ao termino do daily, adicionar a presença, atraso ou falta de cada um.

Nesse time definimos assim: “.” nos presentes, “-” nos faltantes (faltas programadas ou não) e um “+” nos atrasos (1 minuto começado o para terminar).

Ao fim do Sprint, eu agregava as informações do quadro em uma planilha, que gerava algumas informações que analisávamos na retrospectiva.

Os dados exibidos nesse exemplo são fictícios, mas poderiam representar a realidade de qualquer time.

Na parte inferior da planilha você pode ver a tabela estruturada a partir das informações do quadro. É exatamente a transposição dessas informações.

Ao preencher essas informações, o time terá a visão de presenças por membro do time.

Nela, você pode ver por exemplo, que o Obi-Wan foi o único do time a estar presente em todos os dailys, e que o Chewbacca precisa melhorar sua pontaria no horário.

Além de ser possível ver como cada um está com relação a presença do daily, a planilha também gera a informação percentual do time. Dessa forma o time poderá determinar metas de melhorias na retrospectiva.

Outra visão bacana, é o quanto o time esteve todo junto. Nesse exemplo abaixo, você pode observar que somente em dois dias desse sprint todo o time esteve presente no daily. Em um desses dailys (o daily 8) somente duas pessoas do time (25%) estiveram presentes. Obi-Wan e Yoda, como você pode ver na tabela.

É sempre bom mostrar esses gráficos para o time na retrospectiva, além de compará-lo com o sprint anterior.

Só prá ressaltar, essa é uma ferramenta para o time e não externa. Isso deve ficar muito claro para eles. A intenção é que eles vejam como está a saúde de seu daily e possam tomar ações para melhorá-lo.

Eu fiz a planilha no Numbers, mas aparentemente não consigo fazer upload desse formato, então exportei prá Excel e curiosamente funcionou de primeira. Se você quiser no formato original, deixe um comentário com seu email que envio.

Espero que possa ser útil para você que está lendo, como foi prá mim.

13
nov
09

Feira de ciências – o melhor review

A alguns Sprints, estávamos percebendo que nosso Review não estava atendendo a seu princípio básico que é pegar feedback sobre o que foi desenvolvido, nós estávamos ao contrário apresentando as histórias em um projetor, com POs, SMs, Time e clientes sentados ouvindo o que estava sendo dito por um ou dois membros do time, na maioria das vezes os ouvintes sequer se pronunciavam durante a apresentação, mesmo eventualmente tendo sugestões ou até percebendo alguma coisa errada.

Foi quando o Danilo (e o Igor) deu deram uma excelente idéía, que aproximou o cliente (e todos os interessados) das histórias que estavam sendo entregues nesse Sprint.

A idéia da dinâmica surgiu a partir do livro Agile Project Management with Scrum do Ken Schwaber (Sprint Review Meeting: páginas 56-57), e é realmente similar a uma feira de ciências, aonde cada um mostra o que fez e explica seu projeto bem de perto.

Em uma sala grande, colocamos cinco mesas com computadores, papel, caneta e é claro post-its. Os membros do time foram distribuídos nas mesas e apresentavam as histórias a quem estivesse naquela “bancada”, os participantes poderiam livremente navegar no computador para utilizar a solução, eventualmente tirar dúvidas e a partir daí escrever nos post-its sugestões de melhorias a serem avaliadas pelo PO posteriormente.

A proximidade das pessoas durante o review trouxe um clima muito mais colaborativo do que tinhamos nas apresentações, realmente surgiram melhorias, não só nas histórias mas também no processo, identificamos alguns pontos, discutimos na retrospectiva e conseguimos aplicar no sprint seguinte.

26
abr
09

Diversos times, mesmo projeto.

Estamos a alguns meses trabalhando em um grande projeto na globo.com, envolvendo diversos times Scrum. A maneira que estamos trabalhando se difere um pouco do que haviamos feito no passado quando existia a necessidade de escalar a entrega de um projeto e ainda não trabalhavamos com Scrum.
Impulsionado por isso, resolvi fazer o um dos meus trabalhos de mestrado abordando esse tema,  li alguns artigos que gostaria de compartilhar dois deles:
O primeiro Hyperproductivity In Large Projects Though Distributed Scrum fala de um projeto da SirsiDynix e StarSoft Development Labs envolvendo 56 desenvolvedores espalhados nos EUA, Canadá e Russia. Ele descreve algumas praticas essenciais para um projeto distribuído.

  1. Daily Scrum meetings of all developers from multiple sites.
  2. Daily meetings of Product Owner team.
  3. Hourly automated builds from one central repository.
  4. No distinction between developers at different sites on the same team.
  5. Seamless integration of XP practices like pair programming and aggressive refactoring with Scrum.

O segundo, Reaching Hyper-Productivity with Outsourced Development Teams do Jeff Sutherland e Guido Schoonheim fala do projeto Xebian e de algumas questões do projeto da SirsiDynix e da sua visão de como trabalhar nesse tipo de projeto.

O Jeff Sutherland fala de alguns pontos interessantes como o ScrumButts, “We are doing Scrum, but…”. Que é quando você faz Scrum, mas uma coisa ou outra você resolve não fazer, ou fazer de forma “diferente”, acredito que o maior erro daqueles que querem fazer Scrum, é não querer faze-lo integralmente, são justamente os pontos que não são tão simples de entender que fazem a diferença.
Outro ponto que ele levantou como falha no projeto da SirsiDynix foi “Builds were stable only at Sprint boundaries”, somente próximo ao fim da interação eles possuíam algo pronto para produção, além de uma cobertura ruim de testes. Builds diários, visíveis por todos os times envolvidos, e com uma excelente cobertura de testes são primordiais para o sucesso de um projeto com diversos times.

Se os times de sua empresa, trabalham em projetos grandes, mesmo não distribuídos em diversos países como no exemplo da SirsiDynix, aconselho a dar uma boa olhada nesses dois artigos.

10
dez
08

scrum na globo.com

Pensei em escrever um post sobre o Scrum aqui na Globo.com, mas com certeza vou me tornar repetitivo, uma vez que Guilherme Chapiewski, Phillip Calçado e o Danilo Bardusco já escreveram. Mas acho bacana aproveitar para espalhar a apresentação que o Danilo fez no Falando em Agile.

Vale muito a pena conferir!


video


slides

Não sei porque, algumas pessoas não estão conseguindo ver o vídeo e os slides no próprio post, então coloquei os links prá facilitar!

06
mar
08

Qual é o papel do Scrum Master?

Na maioria dos casos, o gerente de projeto ou líder técnico assume o papel de Scrum Master quando uma organização ou uma equipe passa a utilizar Scrum.

Talvez seja por esse fator que em alguns casos, surge uma confusão sobre o real papel do Scrum Master.

Quando você é um líder técnico e torna-se um Scrum Master é natural que você ainda tente dar soluções técnicas para determinados problemas, ou diga para o time o que deve fazer (ou que é impossível fazer), ou acaba até executando uma tarefa ao invés de ajudar o time a executá-la.

Em outro cenário, se você é um gerente de projeto e torna-se um Scrum Master, naturalmente você irá tender a se comprometer com prazos de entregas, forçar o time a entregar nesse prazo custe o que custar, a dizer quem irá executar determinada tarefa ou em quanto tempo…

A missão do Scrum Master é facilitar o dia-a-dia do Time, removendo tudo aquilo que está atrapalhando o seu progresso.
É garantir que o time siga os valores e práticas do Scrum, protegendo para que ele não se comprometa excessivamente com aquilo que é capaz de executar dentro de um Sprint.
É aprimorar a produtividade do time da melhor maneira possível.

Li um artigo do Mike Cohn no Scrum Alliance muito interessante que falava sobre seis atributos de um bom Scrum Master, vou colocar aqui um resumo, mas vale a pena ler na íntegra.

Um Bom Scrum Master é:

  1. Responsável
  2. O Scrum Master não assume a responsabilidade pelo sucesso do projeto (essa responsabilidade é do Time), em contra partidaele é o responsável na adoção e prática do Scrum pelo Time.

  3. Humilde
  4. Um bom Scrum Master não é cheio de si. Seu sentimento deve ser “Olha o que eu ajudei a fazer” ao invés de “Olha o que eu fiz”.
    Ele está disposto a fazer o que for necessário para que o time alcance seu objetivo.

  5. Colaborativo
  6. O Scrum Master deve ajudar a gerar uma atmosfera colaborativa no time, facilitando o surgimento de debates entre os membros do time.

  7. Comprometido
  8. O Scrum Master deve ter o mesmo comprometimento que o time tem com o objetivo do Sprint, além do compromisso na resolução das barreiras que estão impedindo ou poderão impedir o time de alcançar esse objetivo.

  9. Influente
  10. O Scrum Master precisa exercer influência dentro e fora do time.
    Influenciando o time por exemplo em práticas como Test-Driven Development ou Pair Programming.
    Em geral o Scrum Master deve ter habilidades em “política coorporativa”, isso pode ser um trunfo para o time.

  11. Entendido
  12. O Melhor Scrum Master tem o conhecimento necessário para ajudar o time a buscar seu objetivo.

Não imagine que estou escrevendo isso afirmando que tenho todos esses atributos. Muito pelo contrário, confesso que peco em vários deles.
O Bom é que lendo algo do tipo conseguimos ver aonde estamos errando e aonde podemos melhorar.

Espero que vocês encontrem nesse post o mesmo valor que encontrei ao escrevê-lo.

01
fev
08

Como se tornar um Scrum Master Jedi

No meu último post, falei sobre a visita do Boris Gloger a Globo.com e os treinamentos programados para essa visita.
Nos últimos dois dias os nossos ProductOwners tiveram a oportunidade de aprender mais sobre seu papel no Scrum e hoje foi a nossa vez de aprender um pouco mais.

Durante todo o dia fizemos o treinamento “Teaching Scrum – Train the Trainer”. A idéia do curso é dar uma visão de como ensinar Scrum.
Inicialmente eu pensei que seria algo próximo a um “how to” ou um guia previamente preparado, mas não era nada disso. O treinamento foi muito além. O Boris nos mostrou algumas das suas “tecnicas Jedi” para montar o nosso próprio treinamento: como organizar os tópicos, as diversas maneiras de apresentar a mesma informação, quais os Jogos podemos usar para exemplificar os conceitos de Scrum, como conhecer seu publico, como lidar com algumas situações durante o treinamento…. e acima de tudo, auto conhecimento, para trabalhar no seu próprio estilo de ensino.

Para aqueles que já fizeram o treinamento de Scrum Master com o Boris (ou o de Product Owner) sabe bem como é o seu entusiasmo ao falar de Scrum. Vocês não fazem idéia o que entender de onde vem tudo isso. O desafio agora é mostrar esse entusiasmo em nós.

Ao fim do curso cada um de nós disse o que tinha achado e qual era nosso estado de espirito naquele momento. Foi visível que todos nós estavamos realmente empolgados em replicar o conhecimento, principalmente agora que sabemos um pouco mais como faze-lo.

Enfim, agora é preparar nosso material e replicar o conhecimento!

yoda May the force be with us! Wuff!!

mais fotos no flickr!
fotos do site do Boris

31
jan
08

Boris Gloger visita a Globo.com

No fim do ano passado tivemos aqui na Globo.com o treinamento para certificação ScrumMaster com o Boris Gloger, um dos Papas do assunto. O treinamento foi excelente e gerou uma revolução na nossa maneira de pensar. Mas o propósito do treinamento foi formar Scrum Masters, e um pensamento veio em seguida: não seria muito interessante treinarmos também nossos Product Owners? E foi essa a missão do Boris nos últimos dias aqui no Brasil. Treinar nossos Product Owners e nos ensinar a replicar o conhecimento de Scrum com o restante do Time.

Mas a motivação para criar esse post não foi exatamente falar dos treinamentos, e sim da “visita do Papa” a Globo.com. É isso mesmo. Recebi uma ligação do Danilo Bardusco dizendo que o Boris estaria na Globo.com em 15 minutos. Meu primeiro pensamento foi correr para o whiteboard e ver o eu poderia fazer para não “passar vergonha”, afinal, não é todo dia que o Papa vem a sua “casa”. Bom, não tinha muito o que fazer, na verdade não tinha nada o que fazer. Melhor, porque posso ver o que estou fazendo errado e ajustar, afinal isso é Scrum, ajustar a cada momento.

Assim que ele chegou, tirou sua câmera da bolsa e fez uma foto do nosso humilde whiteboard (xiii agora está registrado!).

Durante seu “passeio” aos projetos, ele pode fazer algumas observações (positivas e negativas) a respeito de nossos Sprints e BurnDowns, tudo o que podia ser visto e merecia algum comentário.

Além disso, tivemos a oportunidade de tirar algumas dúvidas ligadas diretamente ao Sprint que estamos trabalhando.

Enfim, além de uma boa surpresa, foi uma oportunidade única.

(outras fotos aqui)




Seguir

Obtenha todo post novo entregue na sua caixa de entrada.