Agile Team Poker DBC, um Assessment para Times Ágeis

O Agile Team Poker é um método para auto-avaliação de times sobre diversos atributos que compõem um time ágil, independente de metodologia de trabalho. Foi desenvolvido pelo Enterprise Agile Coach da DBC Dionatan Moura em 2019 e já aplicado em dezenas de times e clientes DBC. Categorias e atributos avaliadas no Agile Team Poker:

Categorias e Atributos de Avaliação de Times Ágeis

O assessment avalia a efetividade do time no momento, e traz uma previsão do que está melhorando, estável ou piorando atributo a atributo. O assessment então serve como forma de criar um plano de ação de melhorias pelo próprio time, com auxílio da gestão e lideranças. Evite o termo “maturidade” do time, porque pode parecer pejorativo. Utilize os termos de “efetividade” do time, ou “saúde” do time.

A base dele foi inspirada em outros assessments tais como o Squad Health Check Model do Spotify [1] e diversos artigos científicos sobre características de times tais como do que faz um time efetivo realizado pelo Google [2]. Estes atributos estão divididos em categorias tais como Negócio, Agilidade, Time e Formação de Time.

Gestão Visual dos Resultados

Após todo o time realizar a dinâmica do Agile Team Poker, o resultado é construído de uma forma visual e de fácil entendimento a todos. Gestores e lideranças do time também participam. É essencial a participação deles, até porque eles fazem parte do time.

O resultado fica como verde para atributos que estão indo bem, amarelo para quando não estão bem mas nem tão ruim assim, e vermelho quando não está nada bom. As setas mostram a tendência do atributo do presente para o futuro próximo. Seta para cima mostra que o atributo está evoluindo, que ações estão sendo feitas. Seta estável mostra que o atributo não piora nem melhora, e que nenhuma mudança ou ação de melhoria existe. Seta para baixo é quando o atributo está piorando, e que ações imediatas precisam ser feitas. O triângulo vermelho com um “!” mostra pontos de atenção, que são atributos que não estão indo bem e nada está sendo realizado de ação de melhoria. Resultado visual do Agile Team Poker DBC:

Agile Team Poker DBC Resultados

Como Funciona o Agile Team Poker DBC

Cada membro do time, incluindo o gestor e lideranças, possui um deck com um sinal verde, amarelo ou vermelho. E uma seta subindo, estável ou descendo. Cada membro joga às cegas (por isso o nome poker) na mesa, para que não influencie os outros membros do time. Após todos terem jogado as cartas, o time todo desvira as cartas ao mesmo tempo. A partir daí o time precisa discutir os pontos de vista e entrarem num consenso sobre qual é o resultado do atributo avaliado. Há uma carta para cada atributo onde o facilitador vai trazendo aleatoriamente (para não influenciar no resultado). Confira o deck individual de cada membro. (Design por Rafael Oliveira, UX Lead na DBC):

Agile Team Poker DBC Deck

A dinâmica dura de uma hora e trinta minutos a três horas. Dependerá do tamanho do time, e de quanto já vem conversando sobre esses itens em outros momentos.

São nove as possibilidades de cada avaliação individual de atributo. Preste atenção nos seis pontos de atenção. Possibilidades de cada avaliação individual de atributo:

Agile Team Poker DBC Deck Completo

Assessment Online

Ok, mas e agora que a maioria dos times estão trabalhando remotamente? Os mesmos atributos são avaliados por respostas num formulário online. Google Forms é uma ferramenta gratuita e excelente para isso. Cada indivíduo responde as perguntas, incluindo o gestor e liderança do time.

O resultado do time fica como a seguir, exibindo as médias das categorias dos atributos e as médias das respostas individuais dos atributos. O resultado deve ser sempre compilado por time, e nunca individualmente.

Resultado de Avaliação de Times Ágeis

O questionário possui uma afirmação para cada atributo do Agile Team Poker DBC:

  1. O planejamento de entregas do time é realizado de uma forma organizada numa frequência ideal.
  2. O trabalho realizado pelo time entrega alto valor ao negócio.
  3. Há uma alta qualidade tanto nas entregas quanto na solução desenvolvida pelo time.
  4. Existe uma ótima colaboração e comunicação do time com o cliente, e do cliente com o time.
  5. O time consegue responder às mudanças sempre que necessário, conseguindo se adaptar rapidamente.
  6. As atividades do time são claras.
  7. Os papéis dos membros do time são bem definidos.
  8. O time busca a simplicidade nas soluções.
  9. Há aprendizado e troca de conhecimento entre o time.
  10. O time possui ferramentas e infraestrutura adequadas.
  11. Há uma excelente comunicação entre os membros do time.
  12. O processo de trabalho melhora continuamente.
  13. O time possui uma boa auto-organização.
  14. O time possui uma boa sinergia entre os membros.
  15. O time possui um ritmo sustentável de trabalho.
  16. O time possui suporte da gestão.
  17. O time possui um ambiente seguro para discutir ideias e realizar melhorias.
  18. O time possui conhecimento técnico suficiente para realizar o trabalho necessário
  19. O time possui conhecimento de negócio suficiente para realizar o trabalho necessário
  20. Os membros do time buscam a multidisciplinaridade. Ou seja, cada especialista busca entender outras áreas de conhecimento relacionadas ao trabalho.

As respostas ficam em escala Likert, e o membro do time responde se concorda ou discorda com a afirmação. O que gera uma porcentagem de 0 (0%) a 4 (100%).

Escala Likert qualitativa sendo quantificada

Após os resultados serem compilados, crie um plano de ação com o time, gestão e liderança olhando cada categoria e atributo.

Licença para Utilização

A licença do Agile Team Poker e do Assessment Online é a Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional (CC BY-NC-SA 4.0). Você pode utilizar livremente em seu trabalho, nunca vender o material, e se modificá-lo, deve atribuir sempre à DBC. https://creativecommons.org/licenses/by-nc-sa/4.0/deed.pt

Referências

[1] Squad Health Check model – visualizing what to improve
https://engineering.atspotify.com/2014/09/16/squad-health-check-model/

[2] The five keys to a successful Google team https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/

Framework de Transformação Ágil

Transformar a cultura, produtos e processos da organização com os valores e práticas da agilidade.

Premissas para uma Transformação Ágil eficaz:

  • Produtos (e serviços) ágeis são resultados de uma cultura ágil com processos ágeis;
  • Focar na transformação ágil apenas em processos ágeis será ineficaz;
  • Produtos já maduros desenvolvidos de uma forma não ágil podem ser a maior dificuldade na transformação ágil;
  • O porquê da transformação é aprimorar os produtos, através de processos e cultura ágeis, num fluxo de cima para baixo na pirâmide, e não o inverso (evitar o antipadrão Ágil Pró-Forma);
  • A transformação não deve ter um fim, num processo de melhoria contínua.
Framework de Transformação Ágil

Guia Oficial Kanban Método em Português

A Kanban University lançou o Guia Oficial Kanban Método em Português!

Faça download gratuito em https://resources.kanban.university/kanban-guide/#1614210664834-29216f47-3032

Ou diretamente pelo link https://resources.kanban.university/wp-content/uploads/2021/04/The-Official-Kanban-Guide_Portuguese_A4.pdf

Ou por esse backup:

Mentoria em Método Kanban?

Conheça mais em https://dionatanmoura.com/mentoria-para-agilistas/

Não Existem Rituais ou Cerimônias Ágeis

Um pedido que tenho: parem de utilizar os termos “rituais” ou “cerimônias” ágeis.

Parem. Por favor, parem.

Por quê? Rituais e cerimônias trazem o significado que é um culto, algo religioso, algo que deve ser feito sem questionar. Ágil não é uma religião, não somos “xiitas” em seguir diariamente os mesmos processos.

Lembre-se do primeiro valor do Manifesto Ágil: “Indivíduos e interações mais que processos e ferramentas”. O processo sim é importante, mas é um meio para indivíduos trocarem conhecimento e alinharem seu trabalho através de interações. Não são ritos, nem cerimônias a serem repetidas sem questionar.

Lembre-se do primeiro princípio do Manifesto Ágil “Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.” Nossa maior prioridade não é, absolutamente não é, seguir o processo.

Utilize os termos reuniões ágeis, workshops, encontros, open spaces.

Busque melhoria contínua sobre reuniões. Reflita e adapte frequentemente o próprio processo.

Em nenhum lugar do Guia do Scrum se fala em cerimônias ou rituais. Apenas reuniões. XP, mesma coisa. Método Kanban? Idem.

Lean para Potencializar a Qualidade no Software – Palestra na InfoQ Brasil

Saiu na InfoQ Brasil a palestra que fiz na trilha de Testes do TDC 2014! Nesta palestra, falo de como o Lean pode potencializar a Qualidade no Software. Segue o link:

http://www.infoq.com/br/presentations/lean-para-potencializar-a-qualidade-no-software

Lean Thinking: Mentalidade Enxuta para Desenvolvimento Ágil de Software

Qual a relação do Pensamento Enxuto e o Desenvolvimento Ágil de Software? Posso dizer que possuem a mesma essência. 🙂 Na Quarta do Conhecimento na PROCERGS em abril de 2015, a Jamile Alves e eu palestramos sobre Lean Thinking, Mentalidade Enxuta para Desenvolvimento Ágil de Software, fazendo a relação entre o mundo Lean e o mundo Ágil.

Seguem o vídeo compacto da palestra:

E os slides:

“Be lean, be agile!”


Conheça mais sobre o livro de eXtreme Programming

livro xp

Link para o livro www.casadocodigo.com.br/products/livro-xp-extreme-programming

Scrum e Kaizen (Melhoria Contínua): uma relação de epifitismo

BromeliasEpifitas
Relação de epifitismo de uma bromélia com uma árvore. Fonte: meioambiente.culturamix.com

O Scrum precisa de Kaizen (melhoria contínua) numa relação de epifitismo, do mesmo modo que uma bromélia precisa de uma árvore para se sustentar. Uma relação epífita é quando uma espécie A precisa de outra espécie B para sobreviver, mas não prejudica a espécie B. A foto acima mostra uma bromélia que precisa de uma árvore como base.

Vamos às definições:

Scrum (n): Um framework no qual as pessoas podem resolver problemas complexos adaptativos, enquanto de uma forma produtiva e criativa entrega produtos do mais alto valor possível. http://www.scrumguides.org/

Kaizen: Melhoria contínua de um fluxo completo de valor ou de um processo individual, a fim de se criar mais valor com menos desperdício. http://www.lean.org.br

Scrum é um framework, não é metodologia, nem processo. O objetivo de ser um framework está em trazer práticas de gestão ágil para se encaixarem outras práticas (de gestão e de engenharia). As principais práticas do Scrum são:

  • Trabalhar em Sprints (iterações)
  • Realizar Reunião de Planejamento
  • Reuniões Diárias
  • Realizar Reunião de Revisão (entrega)
  • Realizar Reunião de Retrospectiva (na minha opinião é a prática mais essencial pois é o evento para a melhoria contínua)
  • Ter um papel responsável pelo valor do produto (Product Owner)
  • Ter um papel responsável pelo processo (Scrum Master)
  • Ter um papel responsável pelo desenvolvimento (Time de Desenvolvimento)

Note que o Scrum atua apenas no nível de gestão. O framework é simples de entender, mas não é fácil de utilizá-lo, por isso é essencial a melhoria contínua em sua adoção. Um dos motivos de que um time passa por problemas na adoção do Scrum é porque o time utiliza apenas o framework (que é de gestão) sem utilizar outras práticas ágeis, principalmente de engenharia. Nas reuniões de retrospectiva, utilize a melhoria contínua para evoluir nisso, tanto para práticas gestão quanto de engenharia. Algo muito interessante de investir são em práticas emergentes.

Veja que Scrum não é somente para software, tanto que em seu guia nada se diz sobre software. Ou seja, Scrum não define user stories, integração contínua, ou qualquer outra prática ágil de desenvolvimento de software. Essas práticas estão no XP (eXtreme Programming), que é uma metodologia ágil de desenvolvimento de software, sendo mais prescritiva que o Scrum (obviamente).

Muito se fala que se não adotar o Scrum exatamente, então está se fazendo ScrumBut. Ano passado (2014) no Agile Brazil em Florianópolis, eu estava trocando uma ideia no estande da Adaptworks quando falei que o “Scrum é But por natureza” (querendo dizer que devemos adaptar inclusive próprio Scrum). No mesmo momento, o Alexandre Magno falou: “Não! Scrum é Inspect&AdaptBut!”. Realmente, O Scrum define um mecanismo de inspeção e adaptação, mas proíbe que seu framework seja modificado.

Melhoria contínua no Scrum foi um dos assuntos da palestra O Julgamento do Scrum do Alexandre Magno no Agile Brazil 2013, por sorte eu estava lá assistindo, em Brasília! Essa palestra me fez reconhecer que precisamos refletir a utilidade do Scrum em cada contexto, assim como qualquer outra abordagem ágil. Seguem os slides desta palestra:

Adicionalmente, o Alexandre Magno traz a ideia de Práticas Emergentes, de resolver o problema existente com práticas criativas. Eis a palestra:

E seguem os slides dessa palestra Práticas Emergentes:

“Não é necessário mudar. A sobrevivência não é obrigatória.” William Edwards Deming


Conheça mais sobre o livro de eXtreme Programming

livro xp

Link para o livro www.casadocodigo.com.br/products/livro-xp-extreme-programming