Série Scrum Remoto: Primeira Sprint – falhou e agora?

Olá Pessoal,

Mais um post da série Scrum Remoto e chegamos ao final do primeiro Sprint que falhou. Mas por que? Alguns podem pensar porque o time estava remoto. Será?

Lets go…

Começamos falhando

Fico feliz que a gente não começou diferente de alguns projetos Scrum que falham no primeiro Sprint. E umas das razões que já vi em projeto presencial com Scrum foram:

  • Estimativas;
  • Não saber a velocidade do Sprint;
  • Time aprendendo Scrum;
  • Blockers longos;
  • Comunicação;
  • Não saber o timebox do Sprint.

Quando falham em um projeto com Scrum remoto, muitos vão dizer o seguinte: “falhou porque o time não estava presente fisicamente”. Será? Ou estamos buscando uma desculpa para não enxergar os erros?

E porque falhamos aqui na ITSLabs?     

Falhamos por todos os problemas que há no Scrum Presencial, exceto um. O de comunicação. Por incrível que pareça, por estarem remotos o time se comunicava com maior frequência via chat, call, fazendo share da tela e pedindo ajuda do outro. Tudo isso em tempo muito curto comparado com o que já vi em times presenciais. O problema real, foram  os demais pontos e isso eu já esperava, na verdade eu ficaria muito surpreso se a estória e o Sprint fosse entregue com qualidade. Um dos pontos foi não saber qual o tamanho do Sprint ideal. Começamos com 2 semanas e não deu muito certo, pois parte do time ficou ocioso e houve desperdício de tempo no final do Sprint 0. Tentamos de 1 semana, e a Sprint falhou porque o time teve bastante blocker e tinha que parar a task em development para resolver e depois retornar para task e alguns blockers duraram quase 6hrs do dia. Ruim, heim? Fora quando tinham que ser dois devs trabalhando no mesmo blocker para tentar resolver rápido, ai era pior eram dois membros parados em função de um problema.

O final

Isso já sabemos, né? Todos com aquele feeling ruim por não terem entregue o Sprint como acordado e pensando em como resolver os problemas. De qualquer forma foi uma Sprint rica de aprendizado. O time se comportou muito bem em se adaptar e responder aos problemas mais criticos e ajudar o outro colega que ficou blocker. O espírito de team e foco no projeto e não na “minha entrega” era algo forte e isso me deixou muito feliz ao término do Sprint.

Veja como ficou o gráfico do Sprint 1:

scrumremotoburndownsprint1

 

E como foi a sua primeira Sprint ? Comente sua experiência… 🙂

Abraços, see ya!!

Série Scrum Remoto: Terminado a Sprint 0

Olá pessoal,

Vamos ver hoje como foi a Sprint 0. Será um post rápido.

Lets go…

Como foi o Sprint 0

Conforme já falei em outros posts da série, foi nessa Sprint que definimos o Sprint 0 como uma Sprint de setup e discussão sobre quais tecnologias eram ideais adotar para o projeto. Como por exemplo: vamos de Sprint MVC ou Vraptor? Fora outras discussões de infraestrutura, arquitetura inicial, etc. Claro que não definimos tudo aqui e pronto, mas o básico que precisamos para iniciar o Sprint 1, visando o baixo risco de ter que trocar amanha a versão ou framework escolhido por algum motivo específico, então vários pontos são analisados e discutidos com a equipe. Outro ponto interessante é que muitos membros do time criam POCs para mostrar o quanto a tecnologia X que ele defende pode ajudar. A única coisa requerida é que você apresente argumentos que convença o time da escolha da tecnologia, se conseguir ela é adotada e não precisa entrar em processo nenhum (que vai para “aquele cara” que em algumas empresas é considerado “o deus” que vai ter que dar o ok). Removi isso, não existe isso aqui. Odeio qualquer coisa que seja engessada. É o time técnico que define. Claro, nada impede de consultar especialistas, etc, mas no final é o team que decide as tecnologias que eles vão trabalhar nos próximos N Sprints que estão por chegar. O case aqui é de um projeto que participei em julho/2013.

A seguir o Burndown do Sprint:

scrumremotoburndownsprint0

Podemos ver que foi um Sprint bem apertado, mas a equipe conseguiu entregar bem na trave. Então concluímos ela acreditando que tudo que foi entregue já nos permite começar a Sprint 1 e meter a mão na massa na primeira estória. Vamos ver o que acontece no Sprint 1.

A retro do Sprint 0

Fizemos a retro usando a realtimeboard. Encontrei essa ferramenta por acaso e achei muito bacana para time remoto. Uma das funcionalidades que acho show é não precisar compartilhar a tela e a atualização é em tempo real para os convidados. Possui um chat e na versão free permite criar tres projetos privados. Olha o que rolou:

 scrumremotesprint0retro

Vou ficando por aqui. Espero que tenham gostado do post.

Abraços, see ya!!

Séri Agile: Como calcular pontos em uma Sprint?

 

Olá Pessoal,

O post de hoje da série Agile trata-se de um assunto que não é fácil para o scrum master, equipe e product owner: definir a quantidade máxima de um ponto que um Sprint pode suportar, ou seja, quantas estórias do backlog podem fazer parte do sprint backlog? É isso que veremos neste post. Claro que o que abordaremos aqui não é a única forma e mais adequada para ser implementada em qualquer projeto, porém é bem utilizada por scrum master mais experientes, como o Crisp :).  Eu particularmente gosto de ter os cases do Crisp como referência.

Lets go…

Definir prazo, quantidade de trabalho dentro de um número X de dias, não é uma tarefa fácil. Claro que quanto mais experiência vamos adquirindo, as chances de erros tendem a diminuir, mas não quer dizer que não podemos errar em estimativas e sabemos que esse tipo de erro gera grandes impactos, até porque o cliente está diretamente envolvido, já que prometemos entregar em uma Sprint 5 novas features, mas conseguimos apenas concluir 3, por exemplo e isso é frustrante. Então como podemos evitar isso? Vamos ver como Kniberg nos ajuda entregar tudo aquilo que prometemos e manter uma boa saúde da equipe.

Lá vem a pergunta: como uma equipe define as estórias que vão para um Sprint?

1         Pode ser por sentimento ou instinto: essa aqui é bem comum e pode ser a primeira opção a ser adotada. É errado? Não. Tudo depende da equipe e auto-confiança da mesma nas estórias definidas no backlog do product owner.

2         Estimativas de cálculo de velocidade:  essa aqui é um pouco mais matemática e não envolve sentimento ou instinto. E o objetivo final da “velocidade” ajuda a saber a quantidade de trabalho que pode ser adicionado ao sprint.  Porém temos duas formas de  fazer o cálculo:

Forma 1 – Tempo de Ontem: é assim que é chamada, onde olhamos para o Sprint anterior e somamos os pontos do que foi entregue e podemos ter uma margem para próxima Spring.

Forma 2 – Fator foco: é onde uma estimativa de como a equipe é focada para achar o fator foco, então o calculo para encontrar esse “fator foco” seria:

fator foco(%) = soma das estimativas

homem-dia

Agora, calculando os pontos por estória para o Sprint, é só pegar o percentual do fator foco anterior e multiplicar pela quantidade homem-dia do Sprint seguinte, assim chegamos ao total de pontos que o Sprint a seguir deve atingir, para garantir a entrega. Se o resultado for 20 pontos por exemplo, então esse será o valor máximo que o Sprint backlog pode ter. Cálculo:

Pontos = fator foco(%) * homem-dia

O que é homem-dia ?

Se nunca viu este termo, homem-dia é quantas pessoas teremos disponíveis para aquela Sprint e o cálculo não é por “cabeça” e sim por disponibilidade. O fato de ter 3 pessoas não quer dizer que temos elas 100%, podemos ter o seguinte cenário:

Camilo: 20 dias

João: 20 dias

Maria: 10 dias

50 homens-dia disponiveis

Vamos considerar que seja um Sprint de 20 dias, então no cenário acima, apenas 2 dos 3 tem disponibilidade 100% para toda a Sprint, e isso tem um grande impacto na quantidade de estórias para o backlog.

Simulação

Supondo que tivemos 40% de fator foco no Sprint anterior, quantos pontos máximos devemos ter na próxima Sprint, com base no homem-dia anterior ?

Pontos = 40 %* 50 = 20

Então sabemos que  não podemos ultrapassar o valor de 20, do contrário já estaremos comprometendo  a entrega de estórias do Sprint.  Vamos supor as seguintes estórias  no backlog:

  • fazer página login (7)
  • autenticação DB (6)
  • Test de Perfomance (5)
  • Popular DB (3)

As estórias  acima atingem 21 pontos. O que fazer? Colocar apenas por causa de 1 ponto? É possível pensar assim, mas a melhor escolha poderia ser escolher o menor número, ou seja, até 18 pontos  (no caso acima) e evitar ultrapassar  o limite de pontos para o Sprint. Em alguns casos pode colocar o item que sobrou, como se tiver um tempo de folga e for possível ser implementado, mas o product owner não pode contar com aquela estória ao final da Sprint.

E quando não temos nenhuma Sprint para fazer os cálculos?

Isso acontece quando vamos para primeira Sprint. Então que fator foco adotar? Ai é questão de análise do ScrumMaster conhecer sua equipe e ter uma ideia do escopo. Você vai encontrar livros Scrum que falam 70%, 50%, 80% , enfim, fica a seu critério, eu adotaria 70%, por não ser algo muito alto, nem tão baixo.

Vou ficando por aqui com mais um post Agile e espero que tenham gostado. Não deixe de compartilhar sua experiência. 🙂

Abracos, see ya!

Scrum:Definindo as estórias para o Sprint Backlog


olá Pessoal,

Demorei um pouco, pois os ultimos dias tem sido corrido, mas está aqui mais um post da série Scrum, hoje vou apresentar como é que a equipe define quais estórias estarão no Sprint Backlog do Sprint que inicia amanhã. Vimos em um dos post anteriores que o PO é um cara importante no planejamento do Sprint. Então chegou a hora de discutir de como tirar as coisas que estão no Product Backlog e trazer para nossa “mesa”. Antes de começar o post queria compartilhar com vocês um vídeo muito interessante desenvolvido pela FIAP. Não é fazer propaganda da instituição, pelo contrário o vídeo foi feito com objetivo informativo sobre o mercado de TI. Vejam:


Lets go

Como a equipe define as estórias que vão para um Sprint?

Essa é uma pergunta clássica. Eu já ouvir alguns comentários que talvez o PO ou SM deveria fazer isso. Eu acho que se Scrum fosse um framework que funcionasse com base em quem tem o nível mais alto(para não dizer função) é quem define as coisas, talvez faria sentido. Mas, como não é assim, o conceito de time, equipe, pessoas etc, é de fato mais importante que os papeis apenas. Enfim, apesar do PO ter escrito toda história e em alguns casos ser o responsável pelo investimento no projeto, com Scrum isso não dar o direito de dizer: “a estória já está escrita, priorizada e o escopo é aquele. Se não entendeu algum ponto, por favor, deixe me saber, mas não vou mudar o escopo, porque eu quero assim”. Não é bem por ai. A questão é quem tem a bola da vez aqui é o time, ou seja, todos estão envolvidos e não apenas o PO. Não é porque ele é dono do produto que tudo vai acontecer como ele deseja sem questionamentos. Se temos um problema como esse é sinal que seu cliente não entendeu como Scrum funciona e ai é um outro problema que precisa ser tratado antes de pensar quando vai acontecer a reunião de planejamento.Eu diria que até antes do cliente apresentar o produto, ele já deveria saber o porque vai rodar Scrum e saber que as coisas funciona em um trabalho de equipe e cada um tem suas responsabilidade e limitações. Se isso não está claro para o seu cliente, não inicie nada, do contrário terá problemas e discussões que talvez não compense. Agora vamos ignorar o cenário anterior, trouxe apenas fazer uma citação do mundo real :). Então, Camilo como escolher a estória que vai para o Sprint Backlog?

Por sentimento ou instinto. É isso mesmo não há mágica nem ferramenta que vai ti dizer: “pega a história X, e sim a equipe que vai contribuir para isso”. Normalmente o ScrumMaster pergunta para equipe se a estória que está no top da lista(aquela que tem mais importância para o PO) dar para entregar naquela Sprint. Aquelas que ficarem com dúvidas e incertezas da entrega fica de fora (com o aval e negociação com PO) do Sprint.

A seguir temos um exemplo, pratico de um Product Backlog:

Imagem do livro Scrum and XP from the Trenches

Note: Claro, que vamos seguir sempre a ordem de importância definidas pelo PO e não pegar as estórias aleatórias.

Vamos supor que o PO não gostou porque a história D está fora, já que a velocidade da equipe só permite entregar até a C. O que fazer?

Primeiro: O PO não pode obrigar à equipe pegar(de novo, para você não esquecer). Então ele tem duas opções:

  1. é alterar o escopo, possivelmente quebrando e o time re-estimar e ver se é possível.

  2. ele mudaria a ordem de prioridade levando a estória para acima do C, daí o team é obrigado a pegar. Porém, a estória C ficaria de fora. Mas, o framework Scrum não diz que temos que pegar a estória com maior prioridade?

Sim. Pegamos a estória que está no topo da pilha do product backlog, mas ao olhar ela identificamos que é grande demais e não cabe dentro do Sprint de duas semanas, ou seja, é pouco tempo para muita coisa(escopo grande) em uma única estória. Lembre-se, as estórias deve ser do tipo INVEST.

  • Independente: a estória não pode ficar bloqueada durante a implementação, ela precisa ter vida por si só;
  • Negociável:uma estória precisa ter um escopo que pode ser alterado sem perder toda a essência do que se pretende e algumas coisas podem ser postergadas para um dos próximos Sprint tranquilamente.
  • Valioso: deve agregar valor ao produto, ter um valor de importância dentro do produto
  • Estimável: se não conseguimos estimar com base no que está escrito para estória, é porque temos alguma problema no que ela se propõe atingir. Então precisamos ver com o PO o que ele está querendo dizer;
  • Small: não precisa ter todas as funcionalidade em única estória, sendo assim pode ser pequena para que fique dentro do Sprint.
  • Testável: toda estória precisa ter uma forma de validar se ela foi implementada corretamente. Então os critérios de aceitação devem existir, para que podemos nos certificar que fizemos algo de acordo com o esperado.

Então era isso pessoal que eu tinha para apresentar para vocês quando estiverem pegando as estórias do Product Backlog e trazendo para o Sprint Backlog. Não se esqueçam que a responsabilidade de analisar e estimar uma estória é da equipe.
O que foi escrito pelo PO para estória é o que ele desejaria(nem sempre querer é poder) de ver pronto, mas nem sempre é possível, pois há vários fatores que contribuem para isso tais como: velocidade da equipe, nível técnico, interrupções etc. Não é uma tarefa fácil, mas com uma boa comunicação entre a equipe e o PO, sempre terminamos no contexto ideal.

Vou ficando por aqui espero que tenham gostado.

Abraços, see ya!!

Scrum: A importância do Product Owner no planejamento do Sprint

Olá Pessoal,

Mais um post da semana seguindo o ritual da serie Agile/Scrum ;). Hoje vamos ver a importância do Product Owner no planejamento do Sprint. A pergunta é: O quanto é importante a presença desse camarada? Vamos descobrir.

Lets GO…

Product Owner no planejamento do Sprint

Sem o product owner na reunião de planejamento não há Sprint. O PO é a chave para o inicio de qualquer Sprint, Há três pilares importantes: escopo, estimativa e importância. O escopo e importância são do PO, mas a estimativa fica com a equipe. Como a reunião começa com os itens mais importantes, se a estimativa for diferente do que o PO pensou isso pode fazer ele re-pensar no nível de importância, o mesmo pode acontecer com a equipe, se o escopo mudou a  equipe deve re-pensar nas estimativas novamente. E assim cada parte envolvida responde as mudanças e se adapta a elas.

Se o PO não puder aparecer este pode nomear um intermediário, com os poderes de exercer o papel de PO, mas se não houver o PO o lançamento do Sprint é adiado até a disponibilidade dele. Quando falei, de uma pessoa representar e ter poderes de PO como intermediário, isso não é só ter a pessoa como alguém presente na reunião de planejamento e sim com permissões de mudar níveis de importância das estórias, escopo etc. E uma vez definido o intermediário, o Product Owner oficial não poderá alterar tudo que foi feito pelo seu intermediário após já ter dado inicio ao Sprint (claro que há exceções se as mudanças forem com base nas regras de negócio, mas o fato da mudança não pode ser com base porque o Product owner enviou um intermediário). Mas, se o PO Oficial resolve mudar tudo, então voltarmos à ter um novo planejamento do zero e jogamos fora tudo que foi feito e acabamos desperdiçando tempo, porém de quem foi a responsabilidade?!. Atenção deve ser tomada aqui, pois há product owner que pode enviar um intermediário somente para iniciar de imediato o Sprint, pois ele já sabe que sem um representante nada inicia, mas depois vai querer mudar tudo e como sabemos isso vai ferrar o Sprint e ninguém quer isso. Deixe transparente, que se mudar tudo, haverá um re-planejamento.

Há dois tipos de qualidade em projeto Agile que são extremamente importantes:

  1. Qualidade externa: aquela que o usuário tem acesso, como a interface, o design.
  2. Qualidade interna: aquela que é da equipe, ou seja, como a equipe faz aquilo. Algo que tem um profundo efeito de manutenabilidade do sistema, como refactoring, cobertura de testes etc.

Claro que um sistema com alta qualidade interna pode ainda ter baixa qualidade externa, mas um com baixa qualidade interna raramente terá uma qualidade externa alta, não dá para construir algo bom, se a base está podre. Então à qualidade interna, simplesmente não é negociável.

E assim finalizo mais um post da série Agile/Scrum, no próximo veremos como lidar com estimativa e escopo com o cliente, esse aqui sempre gera discussões nas reuniões.

Abraços, see ya!!