Arquivo da tag: scrum master

1

Não acredite em dogmas ágeis, seja ágil na agilidade

|

Ahhhh, não pode isso, não pode aquilo, só é ágil se for assim, só é ágil se for assado, as vezes agilidade fica parecendo um culto de tantos dogmas. É preciso ser ágil na agilidade, começar por algum lugar e deixar as retrospectivas gerarem a evolução desejada na velocidade possível.

Não confunda debates sobre mediadores e moderadores com a prática diária. A teoria tem a ver com crenças e argumentos, citamos gurus e boas práticas, pesquisas, erros frequentes e fatores críticos de sucesso. Na prática é um passo de cada vez, aprendendo, cada caso é um caso.

Uso como alegoria o uniforme de um time de futebol, o tal manto sagrado tem cores, brasões, o jogo tem regras, mas cada jogador possui biotipo e características que exigem ajustes, talvez uma chuteira diferente que o privilegie, especialmente em função de sua dinâmica de jogo.

A máxima é simples, no lugar de dizer que está errado ou procurar culpados, pergunte: Estamos melhorando? Melhores que 2 meses atrás? Piores que 2 meses a frente? Sim? Siga em frente sem desmerecer o esforço, evoluímos, seja positivo e apoie o time, o caminho é esse.

Sem esquecer da máxima das artes marciais – Shu Ha Ri – pois devemos no Shu começar tentando entender e escolher um método, seguir seus preceitos, para então aos poucos ir adaptando a nossas características, sendo ágeis na agilidade, para então finalmente supera-lo em resultados.

Karasek – Job Strain Model

No mestrado usei o modelo JSM de Karasek, onde pessoas com maior autonomia (controle) sobre seu trabalho (demanda), são mais felizes (satisfeitas). Queremos alta demanda com alto controle, isso é trabalho ativo. Baixa demanda gera acomodação, baixo controle gera frustração.

Acredito no modelo de Karasek, opondo-se a Taylor e Fayol, as pessoas gostam de trabalhar, sentirem-se úteis e competentes, orgulhosos em fazer a diferença. Afinal, estamos vivendo uma era de crescimento pessoal, desenvolvimento de competências, soft skills, empatia em sinergia.

Agile não é religião

Cada vez mais escuto dogmas, se o objetivo é debater métodos e boas práticas, sou parceiro, gosto de me provocar a pensar, mas algumas vezes nem discuto, porque fujo de dogmas. Não discuto com quem só tem dogmas, é porque é ou porque leu, mas não tem fatos e vivências.

Quem já interagiu comigo sabe que sou enfático em minhas convicções, tenho frases intensas, meu objetivo é desacomodar. Mas em cada implantação, cada empresa, área, equipe e pessoas possuem sua dinâmica. É preciso entendê-la para saber porquês e adaptar-se, baby steps.

Demoro um tempo para me posicionar, nunca só pela teoria, porque na prática a teoria é outra. Me ajusto à procura de um primeiro passo, sem ser disruptivo além da conta frente ao status quo, o importante é dar um primeiro passo firme e efetivo, para então irmos evoluindo.

As vezes iniciamos 100% acoplados ao método e já introduzimos boas práticas de interesse, as vezes um mínimo de boas práticas selecionadas para gerar valor no dia-a-dia e garantir algo que nos dê crédito adiante. Nenhum argumento é tão bom para seguir em frente quanto resultados …

. Não trabalhamos para o processo, é o contrário;
. Qual é a cultura da empresa? Qual o perfil dos líderes?
. Quais as restrições, exigências e expectativas reais?
. Está gerando valor? Qual a opinião de todos?
. É preciso acompanhar pessoas em sprints para entendê-las;
. Para avaliar melhor, use os cinco porquês (busque a causa);
. Não é aconselhável, vamos entender a motivação;
. Se eu penso diferente, me explica, se possível me mostra;
. Importante, o que tem aparecido nas retrospectivas?
. Não idealize, não tenha pressa demais, calma, baby-steps.

Mudança tem um tanto de Schein, Schneider, tem a ver com Tuckman e Yerkes-Dodson, impossível adotar Agile sem falar de soft skills, T shape e carreira proteana. Dá uma lida no ebook sobre teorias e modelos essenciais sobre os quais já postei, uma leitura fundamental para quem quiser entender melhor os porquês – Clique aqui para baixar no dropbox!

 

3

Um guia de 12 páginas com o resumo do resumo

|

É preciso ser ágil na agilidade, por um lado tem a ver com a cultura Lean, sermos enxutos e objetivos, também tem a ver com capacidade absortiva e carreira proteana, tanto quanto criar ambientes sustentáveis e positivos. Para isso, precisamos ser criativos, planejar sucintamente, seguir MVP, validar e evoluir, é mais fácil do que parece.

IIAp

Sempre curti criar resumos, esquemas, diagramas, uma forma de fixar conhecimento, desde criança os faço para estudar, instigando minha memória visual e motora. Talvez dai venha minha paixão por registrar tudo o que aprendo e pratico aqui no blog e em livros, guias, encartes, canvas, acima de tudo escrevo para mim.

O guia de uma página A3 criado em 2014 foi crescendo (como esperado), a partir de cada livro, artigos, posts, fui incorporando conceitos e lembretes sobre diferentes métodos, frameworks e propostas, chegando a 12 páginas A3 que estão sempre comigo e compartilho com quem interajo em projetos pelo meu link no dropbox:

https:/dropbox.com/s/hp05qzvks54qad6/Super Guia Rápido.pdf

Já esta tudo aqui nos posts do blog a muito tempo, acessível em seus posts, páginas, BlogMap e links úteis, mas ainda não tinha compartilhado esta versão em pdf, talvez tenha passado desapercebido por quem acompanha os posts e não navega no blog, o conteúdo deste guia é:

  1. Estratégia e adoção Agile
  2. Papéis e carreira
  3. Pré-game e ideação
  4. Business Model Generation
  5. Preparação para o planejamento
  6. Planejamento
  7. Execução SCRUM
  8. Sustentação KANBAN
  9. Management 3.0
  10. Design Thinking
  11. DevOps
  12. Self-Assessment

O link é dropbox porque é lá que mantenho todos os pdf’s que compartilho por aqui, o link do guia A3 original onde este de 12 páginas começou é este aqui:

guiarápidoSCRUM360

0

Acredite, documentação é muito mais que as tais histórias

|

Acredito muito além das sábias palavras do Neil Ford, keynote no Agile Brazil de 2012, pois temos dois tipos de usuários em cada projeto, aquele óbvio, que utilizará e se beneficiará do produto entregue, mas também há um usuário oculto, aquele que dará manutenção, sustentabilidade, continuidade no que construímos, podendo até ser (feliz ou infelizmente) nós mesmos.

Como Agile Coach, consultor ou professor, insisto na necessidade de distinguir o romantismo de muitos livros e artigos de agilistas da realidade ou momentuum de sua empresa, área, equipe, tecnologia. Enquanto evoluímos no quesito de excelência em engenharia de software, devemos ter clareza do custo x benefício relativo a aceleração e redução do processo e custo de sustentação.

A tempo, a solução não é aquela encontrada pela maioria absoluta das empresa, que mascaram a sua ineficiência e péssimas práticas de desenvolvimento voltadas ao imediatismo da entrega a qualquer custo. Gerar uma alta OPEX recorrente para ter uma CAPEX reduzida amplia uma percepção equivocada de ROI, mas é fogo amigo, equivocado e inaceitável.

CAPEX (expenditure) ~ despesas ou investimentos em bens de capital; despesas de capital; aquisições. OPEX (operational expenditure) refere-se às despesas operacionais, recorrentes, continuadas.

Tenho uma extensão à Teoria da Agência, ou você está trabalhando para ficar amadoramente bem na foto e ser promovido ou tem a responsabilidade e transparência de um profissional? A entrega de hoje está gerando mais um legado a ser mantido com doses maciças de custos recorrentes ou tem baixo custo de operação por ter sido corretamente construído e documentado?

O volume reduz-se conforme a evolução de sua excelência em engenharia de software, você segue DDD, componentiza, usa BDD, especifica e automatiza por exemplos, constrói código limpo, segue boas práticas de desenvolvimento na sua arquitetura e plataforma, automação de testes e integração contínua.

Aos poucos a documentação vai se integrando ao ambiente, projeto e produto, mas não é mágico, não só porque sempre teremos registros importantes a fazer, mas porque muitos leem em um artigo que documentação é do mal e sem ter o menor critério ou escrúpulos, passam a defender um go horse documental e tem a desfaçatez de citar grandes nomes que relatam projetos de excelência …

1. Pré-game

Acredito no valor da existência de conceitos como Funil de ideias, Gestão de portfólio, programas e projetos, comitês gestores. Grandes empresas não podem prescindir disso, tanto quanto contam com os préstimos de uma governança corporativa, governança de TI, PMO, gerentes de projetos ou papel preocupado na transversalidade, em aquisições, alocações, indicadores gerenciais.

Todo o tempo e processo existente antes do projeto iniciar sua etapa de execução ou desenvolvimento é conhecido como pré-game, ideias, discussões, submissões, descartes e aprovações, culminando no planejamento que habilita a fase seguinte de game, composta por sprints, especificação, desenvolvimento, validação e entregas. Eu posso oferecer um mix flexível, mas consistente de planejamento:

1.1. Project Model Canvas – Eu utilizo para a explicitação das informações básicas coletadas, um Termo de Abertura visual em uma folha grande e postits contendo o porque o projeto é necessário, o que ele é em sua essência, quem se envolverá e percepções sobre como será planejado, quando e quanto custará. Chamo a atenção para premissas, riscos, restrições e expectativas;

1.2. Elevator Statement – Um ótimo aquecimento, uma abstrair e entender justificativa, quem são os clientes, qual o desafio, problema ou oportunidade, que tipo de solução imaginamos, qual o valor de negócio esperado, o que é utilizado hoje para atender esta necessidade e quais os diferenciais para que o cliente e usuário deixe a solução atual e apoie e use a nova;

1.3. Personas – Quem são os atores envolvidos, seus perfis, necessidades e objetivos. Caso a caso, de 0 a 100, posso apenas caracterizá-los até utilizar de Value Proposition Canvas para identificar seus interesses, dores e expectativas de ganhos. Uma técnica dedicada a gerar empatia, tentar ver pelos olhos de cada parte envolvida, antecipando percepções de ganhos e perdas;

1.4. Customer Journey Map – Uso variações simplificadas desta técnica de mapeamento, convergente a uma User Story Mapping, para entendermos os fluxos de atividades necessárias para as principais jornadas dos usuários da solução em estudo. Cada jornada, passos manuais ou informatizados. Queremos entender o passo-a-passo das personas, identificar funcionalidades do produto;

1.5. Scrum SetUp Canvas – Artefato proposto para explicitar entendimento, combinações sobre tecnologia e metodologia, necessidades prévias/recorrentes a serem consideradas para efeito de modelagem, planejamento, execução ou entrega. Qual a composição de equipe, mapeamento de tecnologia, boas práticas necessárias, métricas, DoR e DoD, atividades e reservas para start e velocidade;

1.6. Release Plan – É a combinação de diferentes técnicas para o planejamento, usando técnicas de estimativa e capacidade baseadas em valor e cronologia. Ao final teremos metas iniciais para cada sprint em relação a construção do produto. Conceitos como Minimo Produto Viável, histórias do usuário e histórias técnicas, culminando com o product backlog, uma lista priorizada e planejada;

2. Game | Sprints | Construção

A construção de software gera produtos e soluções que se perpetuam por muitos anos, décadas, conheço soluções construídas nas décadas de 80 e 90 que ainda hoje sustentam negócios complexos e críticos com sucesso. A maioria delas possui uma documentação excessiva e abrangente, defasada e inevitavelmente comprometida, a psicologia explica, frente a centenas de páginas a maioria acaba rolando e enrolando e fugindo de se atolar e dedicar dias da semana só a isso.

O segredo não é se amotinar, dizer que documentação é do mal, que ela é inútil, porque inútil é o exagero, redundância, complexidade, dificuldade. Como tudo na vida, o equilíbrio é o ideal e em agilidade as retrospectivas precisam fazer seu trabalho, identificar desperdícios e gargalos (Lean), gerar atitude, proposição de melhorias, sempre baseado em fatos e não em paixões e idealizações.

2.1. Para o DoR (Definition Of Ready):

Importante, o registro documental do nosso DoR é rico demais para não receber alguma atenção, talvez um grupo de trabalho que defina o que, como e onde. A documentação de funcionalidades deve ter esta orientação, uma árvore racional que permita rapidamente localizá-la, a orientação para sprints é temporária, a orientação funcional é permanente e deve deter informações cumulativas úteis.

2.1.1. User Stories – Narrativa e critérios de aceite, incentivando o uso de notações. Como <quem><o que><porque> para a narrativa e <dado que><quando><então> para critérios, que representarão de forma atômica diferentes regras, como as de negócio e integração. Uma linha para cada, ao invés de parágrafos embaralhados com várias regras, preferencialmente seguindo BDD.

user stories - sebastien frechina

2.1.2. Protótipos com explicações – Via de regra, na absoluta maioria dos projetos de que participo, materializando a necessidade, exponenciando o papel de um bom UX (user experience), a oportunidade de termos o desenho das telas com diferentes características de navegação e usabilidade, enxuta, simples e objetiva, que norteará de forma efetiva o desenvolvimento melhor possível;

2.1.3. Documento complementar – Diferentes empresas chamam de diferentes nomes, mas é um documento que explicita questões desde regras de integração, SEO, funcionais, alertas ou lembretes que registram questões intrínsecas que poderão gerar problemas futuros se não forem registradas. A regra é bem simples, escreva somente o que precisa escrever, o melhor documento é aquele curto, que explica o que se desconhece, evite explicar o óbvio e já acordado, conhecido (*);

(*) há quem coloque estas informações e regras complementares no mesmo documento da User Story, inclusive o protótipo, e sai por ai dizendo que só usa a User Story e é suficiente … mas só porque está tudo junto não quer dizer que é uma coisa só.

2.1.4. Cenário(s) de testes – Para mim, e é assim que conduzo em todas as empresas por onde passo, a construção pelo menos do cenário principal de testes é essencial. Este cenário fazer parte do DoR é um importante insumo para os desenvolvedores, que os revisarão antes de liberarem a funcionalidade para testes e homologação. Para o DoR eu recomendo garantir o cenário principal, o SQA ou tester pode trabalhar ou não depois os cenários alternativos a seguir;

2.2. Para DoD (Definition Of Done):

2.2.1. Código auto-explicado – Seguir boas práticas de engenharia de software, potencializada por conceitos básicos de aprimoramento do código gerado como paterns, pair programming, code review em suas diferentes formas. O código gerado por equipes ágeis e conscientes de tudo o que falei acima, esforçam-se para gerar código limpo, legível, componentizado, boa OOP;

2.2.2. Testes automatizados – O uso de boas práticas como BDD com o uso de ferramentas para geração de testes, TDD ou pelo menos testes unitários, testes funcionais. Todas estas boas práticas geram informações e conhecimento rastreável e seguro, vivo, que se mantém atualizado sempre. Bem feitos são um manual dinãmico e explicativo orientado a comportamento e engenharia;

2.2.3. Versionamento e integração contínua – A ideia é seguir uma boa arquitetura e engenharia de software, de forma que crie uma matriz e árvore passível facilmente de ser conhecida a partir de sua navegação. O uso de boas ferramentas integradas geram baixo custo de assimilação, facilita troca de responsáveis, acelera novos integrantes, pesquisas e mesmo refatoração;

2.2.4. Gestão de configuração – É uma prerrogativa inalienável a qualquer equipe, na minha opinião quaisquer scripts ou ações relacionadas a promoção daquilo que está sendo feito carece registro, aglutinação e versionamento. Algumas empresas de diferentes tamanhos deixa esta atribuição a tarefas manuais e pessoais, um erro que gera riscos e impede agilidade em ocorrências;

2.2.5. Métricas, indicadores e Status Report – O uso de boas práticas em métricas também envolvem métricas técnicas e indicadores, que devem ser escolhidos com cuidado, como as taxas de cobertura citadas acima, mas também de softwares responsáveis pelos builds e integração contínua, SONAR, a maioria são automatizadas a partir de scripts e mapas apresentados nas Sprints Review, acompanhando entregas e seus status report.

Cada um dos itens acima em teoria foram construídos dentro do próprio processo e mantidos atualizados, após o projeto encerrado é preciso mantê-los vivos, o que demanda mínimo esforço, quer em uma ferramenta ALM robusta, sharepoint, confluence, na dúvida se isso é possível, me manda uma msg …

Manual – Amaldiçoado por muitos, mas ainda úteis em casos específicos como software de prateleira, quer manuais físicos ou virtuais, conforme negócio. As vezes na forma de uma apresentação para replicação de treinamentos, as vezes vídeos, esporadicamente manuais em pdf, seguidamente virtuais, acessíveis durante a navegação, sensíveis a contexto. Pelo menos um FAQuizinho rola.

0

Se fossemos uma lavanderia, poderia ser uma lavanderia SCRUM

|

O blog http://cartoontester.blogspot.com.br não tem novos posts desde 2014, tem um traço muito próprio, mas eu tenho paixão pelo diagrama abaixo, alegoria ao método SCRUM caso nosso backlog fosse um enorme cesto de roupa suja. A beleza da simplicidade, impossível não entender o básico do SCRUM com ela.

É possível discernir facilmente cada etapa, inclusive é possível entender o que é valor, a relevância de um bom Release Plan, o que é o Selected Sprint Backlog, o próprio Sprint backlog, o conceito de sprint, a review e retrospectiva, até o pacote potencialmente entregável, daria para reescrever o guide de forma bem divertida.

Nada disso está no blog do Andy Glover (talvez parente do Danny), mas a primeira vez que olhei para essa alegoria, diagramada como abaixo, foi amor a primeira vista … todos os conceitos de timeboxes e artefatos pulam na frente, muito legal!

Poderia traçar analogia a N situações, acho que até meus avós entenderiam o que é esse tal de SCRUM, backlog, sprint, para ilustrar escolhi um cenário bem simples:

Pré-game: nosso PO chega na lavanderia SCRUM com um imeeeeenso cesto de roupa suja, mostra para a equipe e pede um planejamento para estimar o custo. O cesto é muito grande e a galera pergunta para o PO o que ele tinha ali, qual sua necessidade e expectativas, permitindo a equipe planejar e combinar o projeto.

Com o Scrum Setup Canvas eles percebem que precisarão de uma máquina de lavar, outra de secar e uma bancada de passar, dimensionamento de equipe, exigências de qualidade do serviço, pontos de atenção, cuidados, etc. Estimam que precisarão provavelmente 3 (três) sprint (rodadas na máquinas de lavar, secar e passar), mais 1 (um) de buffer na eventualidade de precisar de sete, pois dependendo do tamanho e peso das toalhas talvez seis fosse pouco.

O nosso PO diz que precisa para a primeira sprint de pelo menos uma toalha grande, pois está sem nenhuma e tem que tomar um banho para ir trabalhar e que até a segunda precisará de determinada calça de veludo, uma camisa azul e roupa de baixo para usar, determinando que para o terceiro precisaria de um smoking completo e roupa de baixo, meias pretas. De posse das informações a equipe planejou os itens a cada rodada de forma a atender as necessidades do cliente.

Ao final, está definido o nosso product backlog, entendido, priorizado, MVP, planejado em sprints, permitindo à equipe começar a trabalhar no primeiro sprint.

Sprint 1 – A equipe realiza o primeiro sprint, seguindo a prioridade do cliente, realizando cada máquina e serviços, mantendo o cliente informado do andamento e tendência. O cliente pôde passar no horário combinado e avalia o trabalho executado, comentando que esperava mais da dobradura de uma camisa, feedback depois discutido entre a equipe para que as próximas fiquem melhor.

Sprint 2 – O PO propõe alterar um pouco o sprint backlog, apontando outra calça como prioridade e incluindo mais uma toalha pequena que trouxe, mas que a equipe acredita que não impacta na previsão e por já ter entregue a toalha grande, avaliam a tendência e avisam o cliente que provavelmente não precisará do buffer. A entrega se confirma e o cliente elogia que a nova dobradura da camisa está muito melhor e a calça de brim escolhida será melhor para seu compromisso.

Sprint 3 – A cada sprint a equipe confirma com o cliente a priorização e condições, executa, entrega e ao final discute os feedbacks e percepções variadas de ocorrências. Já conhecem o cliente e estabelece-se uma relação de confiança, quer pela transparência, pela confirmação, parceria e resultados.

Quer tentar? Fecha os olhos e faça seu story board mental do projeto SCRUM da sua lavanderia com o seu cliente … acho que a galera do Savana Scrum vai abrir uma lavanderia na selva e vou postar algumas tirinhas das suas aventuras  \o/

2

Diferentes quadros para debater cultura e dinâmica de equipes

|

Após o post com variados assessments (avaliações) ágeis, compartilho algumas técnicas de cultura de time baseadas em diferentes canvas. Já postei sobre todos eles mais de uma vez em usos pessoais, sobre produtos, negócios, mas aqui ofereço boas técnicas a serem usadas para estabelecer o máximo de auto-conhecimento coletivo, enxergando uma equipe, das partes ao todo.

Acredito muito em Team Building Games, de forma útil e positiva, com objetivo, mas há também múltiplas técnicas para interação e sinergia, reflexão e auto-conhecimento. Alguns quadros foram criados e se propõem a discutir diferentes aspectos da formação, dinâmica e trabalho em grupo. Alguns deles apresento abaixo, com links de origem, outros são habituée aqui no blog.

1. TEAM CANVAS

O Team Canvas é um quadro proposto por Alex Ivanov e Mitya Voloshchuk com o objetivo de propôr uma ferramenta para discutir a dinâmica de trabalho e interação de um time, impactada tanto pela cultura pessoal de seus integrantes quanto da cultura organizacional. Clique aqui e baixe template A3.

Pessoas e Funções: Nome e função dos integrantes;
Objetivos comuns: Qual o foco comum a todo o time;
Objetivos pessoais: Objetivos individuais dos integrantes;
Propósito: Porque fazemos o que fazemos, qual nossa motivação;
Valores: Quais são os nossos valores;
Forças e ativos: Pontos fortes;
Fraquezas e Riscos: Pontos fracos;
Necessidades e Expectativas: O que precisa e o que quer;
Regras e Atividades: Regras básicas e atividades-chave.

Clique aqui para acessar o site explicativo do Team Canvas e sua técnica.

2. TEAM CHARTER CANVAS

Um modelo mais envolvido com missão e valores, segundo seu autor, é complementar ao Team Canvas explicado e linkado logo acima. No site do autor ele recomenda que antes de preenche-lo de forma colaborativa uma das opções é realizar uma dinâmica de integração e provocação como o Lego Serious Play.

Missão – Qual o porque da existência da equipe;
Escopo – O que é e o que não é escopo do time;
Valores – Como a equipe aborda seus objetivos;
Papéis – Quem é quem na equipe;
Eventos – Como celebra sucessos e como busca aprender;
Objetivos – O que a equipe busca atingir, atender, ser;
Forças – Habilidades e pontos fortes coletivos e individuais;
Fraquezas – O que falta ao time para ser ainda melhor;
Normas – Como a equipe se determina e toma decisões.

Clique aqui para acessar o site oficial e aqui para baixar o template em A0.

3. TEAM CHARTER CANVAS / releitura

4. LEAN TEAM CANVAS

Outro quadro com peculiaridades muito legais, uma espécie de Business Model para o trabalho em equipe onde os campos tiveram uma reinterpretação bastante acoplada, como por exemplo:

Liderança – Quais as características de um líder;
Atividades de time – Atividades desejadas, como feedbacks, reuniões, eventos;
Cultura – Motivação, dinâmica interna, propósito, prioridades;
Valor – Como o time agrega valor, competências essenciais, diferenciais;
Ciclo – Qual o ciclo de vida desejado no trabalho;
Espaço – Modalidades, metodologias, ferramentas essenciais;
Membros – Quem são, função, hard e soft skills que os define;
Custos – Prioridade dos investimentos diretos ou indiretos;
Objetivos – Estratégia, metas, objetivos comuns e prioritários.

Clique aqui para assistir um slideshare completo sobre Lean Team Canvas.

5. SWOT e JOHARI

Duas técnicas poderosas em diferentes frentes, mas também usados para debater o auto-conhecimento de um time, no SWOT (FOFA em português) debatemos forças, oportunidades, fraquezas e ameaças, enquanto na Janela de JOHARI discutimos o quanto nós percebemos e o mundo nos percebe em relação a estes mesmos quesitos, materializando áreas abertas, ocultas, cegas e desconhecidas:

6. CHAx5 (Mapa de Competências)

Este é efetivo e divertido, a equipe lista todos os conhecimentos, habilidades e atitudes que são relevantes ou representam oportunidades para o seu trabalho em equipe, quer em um projeto, sustentação ou operação. Há quem use apenas para conhecimentos, há quem amplie também para habilidade e competências em um espectro mais amplo. O resultado é muito realismo, insights, planos de melhoria.

Tem muito mais, este post foi só para provocar que tem muito mais que projeto e produto, é preciso discutir melhoria contínua inclusive a partir da cultura e dinâmica interna de cada time … opções para a nossa Toolbox 360°.  \o/

2

Assessment (+20) não gera diagnóstico, mas é uma usina de insights

|

Compartilho a seguir alguns assessments que tenho usado na minha estrada como Agile Coach e consultor, a do James Shore eu aprendi com o grande parceiro Alejandro Olchik em 2015, os outros fui  encontrando em meio a milhares de páginas e artigos que fui lendo e compartilhando nos últimos sete anos.

A seguir um mapa geral dos assessments que compartilhei neste post, clique aqui para baixar se quiser te-lo em tamanho A3 como um guia:

ASSESSMENTS

Não acredito em assessments para diagnósticos, mas se bem escolhido frente ao momento do time, é uma ferramenta relevante para ampliar horizontes e fomentar o debate construtivo, aumentar o auto-conhecimento e embasar os próximos passos e planos de ação. Clique nas imagens para ir às páginas e arquivos originais:

1. Roda da Vida

Se você não tem domínio sobre você mesmo, se não dedica algum tempo para auto-conhecer-se, querer fazer isso para o grupo é amadorismo. Pessoas que se conhecem bem pessoal e profissionalmente tendem a se posicionar e propôr soluções mais assertivamente … A roda da vida é uma preliminar pessoal para SWOT, BMY, Johari, CHAx5, antes de discutir sonhos e planos coletivos.

2. Assessment James Shore

Este aqui tem questões muito objetivas sobre valores e boas práticas em áreas como Agile Thinking, Colaboração, Planejamento, Desenvolvimento e Entrega. Em grupos grandes eu divido em sub-grupos de 3 pessoas, que respondem e depois convergimos juntos no entendimento de pontos fortes e fracos, propondo pequenos planos de ação para melhorias:

art of agile - shore map

3. Maturity Assessment Model for Scrum Teams

No site da Scrum Alliance tem este assessment sobre os 12 princípios ágeis, já o utilizei como warmup, antes de uma retrospectiva e gerou bons insights sobre nossos valores ágeis. A proposta original diferencia a opinião de cada um, mas eu normalmente faço uma primeira discussão em sub-grupos de 2 ou 3, depois consolidamos, assim cada coluna passa a representar um grupo e não uma pessoa:

4. Comparative Agility

Eu realizei o assessment online e salvei todas as questões para poder me debruçar e analisá-las com mais calma … até mesmo porque meu objetivo não era nos comparar com outras empresas e equipes, mas proporcionar reflexões sobre quesitos relevantes e montar planos de ações para melhoria contínua:

5. Agilometer PRINCE2

PRINCE2 é um framework tradicional para gerenciamento de projetos que vem se propondo a flexibilizar-se e agregar valor com princípios e boas práticas oriundas do Scrum e Kanban. De toda forma, compartilho um assessment muito simples, é só imprimir colorido e colocar “botões” deslizantes, que podem ser postits:

6. SAFe Team self-assessment

Esse é bem conhecido da galera do SAFe, o que restringe seu uso a poucas e grandes empresas, aquelas que usam o framework para projetos que contam com muitas equipes trabalhando juntas no mesmo release … no início pode parecer um tanto desafiador, e é, mas mais pelo tanto de atitude e realismo que exige de todos:

7. Squad Health Check Model

Esse é muito legal e seu uso é bem mais amplo, podendo ter nas colunas a auto-avaliação do time a cada sprint, uma forma de manter no radar os resultados obtidos com os planos de ação e iniciativas realizadas no transcorrer do projeto. O pdf já disponibiliza os cartões e semáforos, usamos as setas para dar a tendência – www.barryovereem.com/how-i-used-the-spotify-squad-health-check

8. The Unoficial Check-list SCRUM

Já fiz posts sobre este e outros, mas os links são para as páginas originais. Este eu achei muito legal e já usei com bons resultados, lembrando que o meu objetivo nunca é diagnóstico, mas reflexão pelo próprio time durante uma retrospectiva, que decide a partir disto quais as ações melhores a serem priorizadas:

Há uma lista com sugestões de assessments listadas por Barry Overeem, que relaciono abaixo, para estes sugiro o post original e seguir os links abaixo:

20. SCHNEIDER’S CULTURE ASSESSMENT – Para terminar compartilho um assessment lastreado na teoria sobre cultura organizacional de Schneider para descontrair e lembrar do que eu disse no início sobre tudo iniciar na pessoa, sendo assim, também é preciso lembrar que pessoas e times estão imersos em um contexto organizacional que pode ajudar ou atrapalhar se não estiver em equilíbrio. Ela é muito intuitiva e busca estabelecer o debate acerca da orientação cultural em equilíbrio ou não:

1

Uma versão PDF para impressão A3 do Scrum Setup Canvas

|

Compartilho uma versão A3 para impressão e uso do Scrum Setup Canvas. Não é para ser só mais um quadro com postits na parede, ele é vital ao gerar um debate sobre acordos e pré-definições pouco antes da realização de um Release Plan.

É para ser um documento vivo, com combinações e pactos evolutivos, jamais para justificativas, mas para aprendizados e melhoria contínua. A maioria de seus campos são relevantes mas não constam em nenhum outro canvas ou artefato.

Para quem não acompanhou nem os posts anteriores nem as apresentações, o SSC é um quadro que formaliza as combinações e premissas essenciais que balizarão o Release Plan, para planejar é preciso definir as bases sobre as quais o faremos.

Eu gosto mais da minha versão colorida do SSC, mas alguns amigos, colegas e contatos tem me pedido uma versão A3 para uso, então criei uma para ser impresso em tamanho grande, de forma a usar postits pequenos como eu uso.

Arquivo tamanho A3 em pdf no dropbox – https://www.dropbox.com

  • Elevator Statement
  • Equipe e envolvidos
  • Aproveitamento e formato dos sprints
  • Arquitetura e Integrações
  • Indicadores e Métricas
  • Boas Práticas e Ferramentas
  • DoR (Definition of Ready)
  • DoD (Definition of Done)
  • Feriados e Férias
  • Sprint Zero
  • Reserva Técnica (%)

Clique aqui para assistir a apresentação em vídeo no Agile Trends 2017.

Clique aqui para acessar a apresentação em PDF a partir do DropBox.

Espero que seja útil aos que já o utilizam ou querem experimentar, igual fico a disposição no caso de dúvidas, aberto a sugestões ou críticas construtivas 🙂