Publicado em

Você sabe que é ScrumBut !?

O Scrum é um framework que oferece um conjunto de recursos para que possamos desenvolver software de uma forma mais organizada (papéis, regras, timebox e etc).

Quem nunca viu situações aonde se declara a utilização do Scrum “mas” (ScrumBut), frequentemente ouvimos aquelas famigeradas declarações:

  • Nós usamos Scrum “mas” não não fazemos daily todos os dias;
  • Nós usamos Scrum “mas” fazemos os testes fora da Sprint;
  • Nós usamos Scrum “mas” terminamos a sprint, só falta testar;
  • Nós usamos Scrum “mas” mudamos sempre o escopo da sprint durante sua execução;
  • Nós usamos Scrum “mas” não fazemos Review, é muito chato;
  • Nós usamos Scrum “mas” achamos a Retrospectiva uma perda de tempo;
Muitas vezes vemos a pseudo utilização do Scrum, é uma jornada que muitas vezes fazem parte de um processo de aprendizagem, continue em movimento com objetivos estabelecidos rumo a sua meta.

Dá pra continuar essa lista até amanhã, muitas vezes vemos grupos “adaptando” o Scrum para “facilitar” sua utilização quando na verdade estão dificultando já que o Scrum colabora para revelar os problemas de forma que possamos identificar e agir inspecionando e adaptando, porém para tanto, precisamos exercer a transparência.

Quando se faz uso deste expediente do ScrumBut, estamos na verdade ocultando as disfunções existentes no processo o que torna as coisas bem mais complicadas, enfrente seus medos e diga não ao ScrumBut.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Surgimento de novos requisitos na Sprint Review, como tratar !?

A Sprint Review acontece ao final de cada Sprint encerrando o evento, essa reunião tem o intento promover principalmente:
 Demonstração do incremento produzido.
 Obter aprovação do Dono do Produto.

A meta da Sprint precisa se alcançada, devem ser demonstrados na reunião apenas os itens que foram executados, ou seja que alcançaram a definição de pronto, todo o trabalho não terminado deve voltar ao backlog para replanejamento.

A Sprint Review é cerimônia que deve ter observada seus objetivos, novos insights devem aparecer durante a reunião, porém se organize e não se perca.

O próprio time deve fazer a demonstração e deve se organizar para a tarefa respondendo todas as dúvidas que surgirem na reunião, os dois valores do Scrum que são determinantes nesta reunião são a Inspeção e Adaptação.

Durante a reunião novas ideias e requisitos irão aparecer e isso deve ser considerado com positividade, podem ser discutidas considerando porém o objetivo da cerimônia, as ações de melhoria identificadas devem ser endereçadas nas próximas sprints, o momento de detalhamento destas ações é posterior a review, mantenha o foco no objetivo da reunião.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Definição de Preparado, use com bom senso !!!

A definição de preparado (Definition of Ready) é um acordo entre o product owner e o time de desenvolvimento que serve para orientar quando uma história está pronta para ser executada em uma Sprint.

A boa prática orienta que o Product Owner tenha um “estoque” de histórias preparadas equivalente a 3 sprints conforme a velocidade medida historicamente do time, assim quando houver algum imprevisto que evite a elaboração e o refinamento de novas histórias, não se corre o risco do time ficar parado.

Entretanto precisamos tratar com cuidado esse tema, pois o que se vê em algumas situações é o time utilizar a definição de pronto como escudo, afirmando que algo não pode ser iniciado devido a falta de alguma condição determinada na DoR, isso afeta a colaboração entre o time de desenvolvimento e o product owner.

O time scrum deve exercitar os valores do Scrum como Abertura e Comprometimento para que a colaboração seja efetiva, não deixe que .
O time scrum deve exercitar os valores do Scrum como Abertura e Comprometimento para que a colaboração seja efetiva.

É necessário que se use o bom senso, uma definição de preparado pode ser estabelecida como um contrato e servir como uma referência. Porém não quer dizer que se alguma demanda não alcançar todas as características determinadas nesta lista, não se deva trabalhar na demanda.

Se o time tiver o entendimento sobre o que precisa ser feito com as informações disponíveis para execução, devemos seguir. Aproveite os benefícios da utilização da definição de preparado (DoR), mas não deixe que isso se torne uma parede entre o time e o PO.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Product Owner novo na área, o que fazer ?!

O ideal é que o Product Owner conheça do negócio do lugar aonde ele vai atuar, mas caso seja novo na área que vai atender, não é o fim do mundo, fique frio(a) e siga o procedimento.

O primeiro passo é começar a construir um relacionamento com os stakeholders, se reúna com as pessoas que possam falar sobre o tema que você vai precisar tratar, procure capturar com a maior precisão possível as expectativas do negócio.

Analise o mercado e esteja ciente das tendências, identifique os principais competidores, sendo eles diretos, indiretos, potenciais ou substitutos, conforme as características como qualidade dos times, marca, base de usuários e etc.

Comverse com as pessoas, e busque as informações disponíveis, assim será bem mais fácil, perguntar não ofende!!

Analise o backlog atual caso exista, conheça o time de desenvolvimento converse com eles, fornecerão informações valiosas para que você consiga montar sua visão sobre o cenário do qual está integrando. Trabalhando em conjunto com os stakeholders e o time de desenvolvimento o processo deve ser acelerado, boa sorte.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Velocity x Débito Técnico

É comum times que priorizam a velocity (soma dos pontos entregues ao final de uma sprint) não considerando qualidade e a completude dos itens no afã de entregar tudo que foi planejado.

Quando isso acontece, a velocidade atribuída ao time não é real, pois no caminho os débitos técnicos surgem se acumulam gerando um backlog informal que em algum momento precisará se resolvido, afetando exatamente a velocidade do time já que a capacidade de entrega será diminuída, com o passar do tempo.

Tipicamente ao implementar as histórias subsequentes existirá a necessidade de fazer trabalho adicional relacionado aos débitos técnicos existentes conforme a evolução dos trabalhos.

Na maioria dos casos a falta de transparência no time scrum permite que o débito técnico seja criado e mantido durante o projeto.

Ou seja a velocidade “oficial” passa a não ser real pois devido aos problemas que deverão ser tratados durante as sprints, em algum momento o planejamento não poderá ser mais cumprido, e se chegará a conclusão que itens entregues no passado não estavam realmente prontos, é melhor controlar o passo agora para não tropeçar depois, mantenha a transparência.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Utilização da Meta da Sprint

A meta da sprint (Sprint Goal) é o objetivo determinado para uma Sprint a ser executada acordado entre o Product Owner e o Time de Desenvolvimento, tipicamente durante a Sprint Planning.

Vemos alguns times que não definem a meta para a sprint, veja que com a meta da sprint o time pode se orientar sobre quais atividades são mais prioritárias para que o time alcance o resultado esperado, o trabalho planejado no início da sprint é um forecast e muitas vezes apesar não concluir tudo o resultado estabelecido na meta pode ser alcançado.

Algumas vezes pode acontecer de o time não considerar uma meta para sprint realística e permitir que mesmo assim seja estelecida, é necessário que todos participem ativamente para que todas as questões sejam resolvidas de forma consensual estando bom para todas as partes.

A meta da sprint deve ser clara e inequívoca para todos os participantes do time scrum

O Scrum Master deve promover a transparência e ajudar a revelar quais são as questões que precisam ser resolvidas de forma que não haja problemas entre o time de desenvolvimento e o product owner, seja imparcial e use o bom senso.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Como lidar com Product Owner ausente !?

O Product Owner faz parte do Scrum Team e tem atribuições como criar o produto através da escrita de histórias priorizando a mesmas conforme a prioridade sempre levando em consideração o que faz mais sentido no momento, ele precisa estar disponível para ajudar o time a entender o trabalho que precisa ser executado conforme a necessidade dos usuários garantindo o maior retorno de investimento.

A disponibilidade do product owner é fundamental e quando isso não acontece diversos problemas podem acontecer impactando diretamente a equipe e o resultado, é necessário ter foco (que é um valor do scrum), sua presença é obrigatória em Reviews e Plannings por exemplo.

Descubra as dificuldades de atender os compromissos e colabore com o PO para a remoção dos problemas.

Como resultado disso podemos ter algum tipo de animosidade entre o time de desenvolvimento e o product owner, não tome nenhuma ação antes de ter certeza de que sabe o que está acontecendo e os possíveis motivos para o que está ocorrendo, não tome partido para nenhum lado.

O Scrum Master deve ouvir e entender os envolvidos, e em conjunto com todos colocar os fatos na mesa, sempre de forma respeitosa e produtiva, para buscar em conjunto uma solução de consenso, procedendo sempre desta forma o grupo vai se tornar um time.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Ágil garante por si só a utilização mais eficiente dos recursos ?!

Isso é um engano muito comum, uma falsa expectativa que é criada e alimentada muitas vezes de forma irresponsável, fechando os olhos para todos os outros aspectos que deveriam ser monitorados e passíveis de acionamentos em alguns casos.

O framework Scrum entrega uma série de ritos dos quais os times devem usar para se organizar, porém a simples adoção não garante sucesso já que diferente de uma metodologia, o framework diz o que, mas não como fazer, as pessoas precisam estar preparadas para assumirem seus respectivos papéis e isso não é uma coisa trivial.

Não se iluda, tome todas as providências para que a nova forma de trabalho prospere, as coisas não aconteceram por osmose, é preciso agir e monitorar.

Tipicamente o framework foca na eficácia, em uma review pode-se pensar que não é eficiente levar todo o time por exemplo, entretanto é muito eficaz pois todos tem o feedback tornando o time mais coeso com o passar do tempo.

É fundamental que todos tenham ciência que a simples adoção de uma nova forma de trabalhar, seja qual for não é garantia de nada, isso se trata de uma ilusão, na verdade o que acontece geralmente mesmo fazendo tudo certo, é que as coisas piorem, até que todos possam se adaptar com a nova forma de trabalho como um grupo, tem que perseverar, precisa ter coração forte, aguente firme.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Faça gerenciamento de riscos no ágil !!

Muitas vezes vemos que a atividade de monitoramento dos riscos não é realizada como se deve quando não é completamente ignorada, saiba que dependendo da natureza do projeto, precisamos ter um plano para o gerenciamento dos riscos como em projetos tradicionais, é necessário identificar, categorizar e criar respostas em caso de materialização do risco.

É importante que haja verificação recorrente dos riscos identificados, e determinar o status de cada item de forma que se tenha o entendimento se é necessário tomar algum tipo de ação para eliminar, mitigar, transferir ou aceitar o risco e seus respectivos impactos no projeto, além da identificação de novos e determinar como serão tratados caso a caso além da atribuição de um responsável para o acompanhamento, tem que ter CPF.

As informações relacionadas aos riscos devem estar atualizadas e se possível em algum lugar aonde todos possam visualizar.

É fundamental que haja um responsável dentro do projeto por cada risco, essa pessoa deve acompanhar e fazer os devidos alertas quanto necessário além de relatar o status atual do risco nos eventos recorrentes com esse objetivo, essa rotina deve estar prevista como uma das atividades do projeto.

Apesar de não estar incorporada de forma explícita a projetos ágeis temos que considerar o gerenciamento de riscos, deve ser feito durante todo o projeto com a cadência adequada, isso talvez não te livre de todos os problemas, mas vai evitar de ser pego de calça curta.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Existe o tamanho ideal para o time ?!

Tipicamente o que é recomendado como boa prática sobre o tamanho de um time ágil é a quantidade entre 3 a 9 pessoas devido a questão do número de canais de comunicação e o custo de coordenação envolvidos, quanto mais pessoas, mais canais de comunicação para gerenciar.

Isso não significa que se o time tiver 11 pessoas por exemplo, não irá funcionar bem, existem vários fatores envolvidos nesta questão como experiência do time, maturidade em relação aos processos vigentes, nível de conhecimento sobre o assunto tratado no projeto, dentre outros.


Quanto mais pessoas mais interconexões de canais de comunicação .

A outra opção seria dividir o time, o que também gera custos adicionais de coordenação e tratativa de dependências. Como abordagem pode-se pesar os prós e os contras mediante ao cenário em que o time se encontra e deixar que o próprio time tome a decisão sobre qual caminho deve ser adotado, sempre com o devido suporte.

Adicionalmente, pode-se executar algumas sprints com a configuração adotada e ver o que acontece, assim o time terá o histórico do que houve para poder decidir como trabalhar, lembrando sempre da questão do empirismo, a observação é fundamental para que se possa decidir como proceder com segurança.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!!