0

Jogo Scrum da Torre de Papel

Folhas de jornal para cada equipe, que deve planejar e executar a maior torre possível que sustente no topo uma bandeira vermelha. Uma jornada de planejamento – como construirá em 4 jornadas de trabalho com 3 minutos cada. Cada equipe ganha 2 metros de fita e você só mostra e fornece a bandeira se alguém pedir ou no final.

A bandeira, assim como no Marshmellow Challenge Ágil, é um critério de aceitação oculto, que via de regra ninguém pede ou pergunta – “Como será avaliada a qualidade ou o valor da torre?” – O que gera uma boa discussão sobre fazer o que pediram/mandaram ou fazer o que é preciso para resolver a necessidade real.

Temos bônus no caso de cumprimento e penalidades, como para baixa qualidade, padronização ou material mal aproveitado. Tanto bônus quanto penalidades valem mais ou menos 5 pontos. A entrega final mais alta com a bandeira afixada com sucesso ganha 5 pontos e a mais firme outros 5 pontos.

A bandeira deve ter uma haste ou mastro e possuir volume e peso, ser de papelão ou de uma dimensão maior (um bandeirão), devendo a estrutura mesmo assim ficar de pé sem que ninguém a sustente e sem fixação no chão ou em objetos.

Estabeleça papéis (PO, SM, Eq), cada grupo organizando um Release Plan para valor e entregas esperadas em três sprints, em cada sprint confirmar a meta, executar, fazer a entrega, retrospectiva, buscar estabelecer capacidade, velocidade, cadência em meio a diversão  \o/

Assim como nos demais jogos Scrum, ao final do planejamento cada equipe deve apresentar o que pretende fazer em cada iteração, quantas cartas pretendem usar e como pretendem usá-las, gerando uma grade de sprints versus metas iniciais propostas.

Importante após a 1ª ou 2ª iteração de 2 minutos, parar para refletir papéis, se estão contribuindo, como está o valor entregue e qualidade. Cada iteração inicia com uma confirmação do planejamento, encerra com uma apresentação ao cliente daquilo que foi feito (review) e retrospectiva para análise do trabalho.

É importante estabelecer uma competição saudável, saber qual dos times construirá o mais alto castelo, assim provavelmente o mindset padrão será fazer de qualquer jeito para ganhar em centímetros ao invés de se preocuparem com a expectativa de valor do cliente.

0

Jogo do Castelo de Cartas SCRUM

Um projeto SCRUM em que cada equipe fará um planejamento de iterações de 2 minutos cada, recebendo no início um baralho, projetando e executando um castelo de cartas, daqueles que coloca-se um par de duas cartas em cunha para cima lado-a-lado e uma carta sobre ambas, fazendo um primeiro andar e subindo mais alguns.

Um jogo Scrum fácil que só exige um baralho de cartas para bons insights sobre planejamento, execução iterati-incremental-articulada, papéis, timeboxes, artefatos e regras. Além de ser muito divertido, porque a qualquer momento pode surgir o imprevisto se não houver paciência e responsabilidade, porque o castelo pode ruir.

O jogo pode ser condizido igual a todos os jogos SCRUM, com papéis (PO, SM, Eq), cada grupo organizando um Release Plan para valor e entregas esperadas em três sprints, em cada sprint confirmar a meta, executar, fazer a entrega, retrospectiva, buscar estabelecer capacidade, velocidade, cadência em meio a diversão  \o/

Assim como nos demais jogos Scrum, ao final do planejamento cada equipe deve apresentar o que pretende fazer em cada iteração, quantas cartas pretendem usar e como pretendem usá-las, gerando uma grade de sprints versus metas iniciais propostas.

Importante após a 1ª ou 2ª iteração de 2 minutos, parar para refletir papéis, se estão contribuindo, como está o valor entregue e qualidade. Cada iteração inicia com uma confirmação do planejamento, encerra com uma apresentação ao cliente daquilo que foi feito (review) e retrospectiva para análise do trabalho.

PRINCÍPIOS: Ao final, valorizar o planejamento, qualidade, produtividade, se todos sentem-se úteis, sinergia e se estão claros os papéis, se foram impostos ou fruto de diálogo.

DICA: Se quiser, pode estabelecer uma competição saudável para saber qual dos times construirá o mais alto castelo, descontando um centímetro para cada “bug”, representados por cartas excessivamente desalinhadas ou tortas que comprometam a estabilidade ou estética do castelo.

2

Cleber da Silveira – storytelling de arquitetura em um projeto de software

Alunos e profissionais que foram no TecnoPUC ou PUCRS no final de tarde, sala 306 do prédio 32 (Escola Politécnica) onde rolou uma storytelling imperdível com Cléber da Silveira, arquiteto de referência da DBServer com 15 anos de experiência em projetos de SW.

Ele relatou o passo-a-passo de um projeto no tocante a arquitetura, pipeline, integração contínua, devops e o necessário para apoiar máxima fluidez, consistência e garantia de qualidade a uma equipe de desenvolvimento de software …

  • Microservices x domínios
  • Deploy contínuo
  • Análise de vulnerabilidade
  • Validação contínua do MVP
  • Autonomia do time
  • Entropia (ADE)
  • Quality Gate
  • Telemetria
  • Circuit Breaker
  • Escalabilidade e roteamento
  • Database Migration
  • Isolamento
  • GitLab … feature branch
  • Inspeção contínua
  • Testes de Unidade e integração
  • Provisionamento
  • Pipeline
  • Fitness function
  • Agilidade

Em meio a tudo isso, uma hora intensa, com bastante interação com um dos melhores arquitetos do Brasil, um show de informações sobre grandes players, auto-scale, pipe e escalabilidade de infra como código, back-pressure, everything fails overtime, etc.

Em 2016 tive o privilégio de contar com a presença do Sr Lincolm Aguiar, em 2017 um storytelling com o Matheus Alagia, em 2018 com o Cleber da Silveira, com certeza três dos maiores profissionais de TI com quem trabalhei em mais de 30 anos de profissão, centenas de projetos, dezenas de empresas.

A seguir, outra apresentação feita pelo Cleber, desta vez sobre OAuth2:

 

3

Virada Ágil 2016 – ToolBox 360° (Banco Intergaláctico) – Dia 1

O treinamento proposto e executado na Virada Ágil 2016 com a colega DBServante Marina Bellenzier em uma agenda contigua ao Agile Brazil Curitiba 2016, é um curso ToolBox usando o Banco Intergaláctico como fundo de cena. São 16 horas de muita fundamentação, teorias, exercícios e exemplos práticos, não é um curso leve, tem muito conteúdo, cada jogo, dinâmica e momentos de diversão são equilibrados em meio a muita informação.

Tem muita teoria, mas o tempo passa rápido, exercícios de elicitação em pré-game, diferentes Canvas, planejamento e estimativas, execução ágil em equipes auto-organizadas, gestão do conhecimento e um bom tanto de boas práticas. Como sempre, quer com o Mário Bros, Picachú ou Darth Vader … não é recreio, é mais um curso denso que precisa momentos de descompressão para aliviar o cérebro.

darth-vader-virada-agil-2016-ufpr-ii

darth-vader-virada-agil-2016-ufpr-iii

darth-vader-virada-agil-2016-ufpr

A seguir o 1/3 de páginas da apresentação que resumem a essência da essência do que o curso apresenta e exercita. Limpei porque ao todo são quase 70 telas com conteúdo, conceitos, exercícios e muito mais. Nas paredes foram pipocando em uma dezena de folhas de flipchart coladas lado-a-lado, diferentes dos meus diagramas, ciclo duplo com DoR e DoD, Scrum Setup Canvas, pirâmide de abstração, alçada, entre outros.

toolbox-360-core

Ainda estamos no meio do curso, tem mais um dia, amanhã complemento o post 🙂

4

O mini-Pokecurso foi um sucesso, agora quero as Pokedex

Foi muito bacana, os três primeiros a chegar ganharam o livro ToolBox 360 e uma boa charla sobre assuntos de interesse, os seguintes puderam tomar um cafezinho, suco e biscoitinhos oferecido pela DBServer e bater um papo de aquecimento. A noite foi quente, pelo menos para mim, porque aquele Kigurumi de Pokemón de pelúcia estava ligado no Hot e o calor humano ativava ainda mais meu entusiasmo em uma noite de 9° lá fora.

Obrigado!

Contei com a parceria da Marina Bellenzier, com quem pareei em diferentes momentos de um curso focado em passar a essência do método SCRUM … conseguimos passar princípios, técnicas complementares, conceitos adicionais a prática e variados exemplos do cotidiano de equipes ágeis.

Foram três horas sem intervalo nem tempo para respirar, quem já conhecia um pouco dos paranauês interagiu bastante, enriquecendo o passar do tempo, mas meu objetivo secundário de construir 14 Pokedex (uma por bancada) não foi possível. Prioridade para o objetivo principal, alinhado no início, que era ser um Mini-curso sobre fundamentos, princípios e práticas de equipes SCRUM.

13882548_1186144551438493_8873534412291288131_n

Fossem 4 horas e sairíamos com as Pokedex, igual, o feedback foi muito legal e fiquei pilhado para uma revanche … no próximo vai ter Pokedéx!  \o/

1. Introdução com um quebra-gelo, cada grupo (bancada) desenhou sua Pokedex em EVA, apresentei a análise causal, porque usar Agile e a importância de não idealizar ou superestimar a que o Agile se dispõe, seus pilares e sustentação:

Pokedex-01

2. Trago sempre a pirâmide Lean do grande Samuel Crescêncio, essencial, e o papel de um profissional de TI (sempre falo de planejamento de carreira). Depois iniciamos a entender o negócio com um Business Model Canvas:

Pokedex-02

3. O que é a base dos processos criados a partir do framework SCRUM e a vital discussão inicial e importância do Prof Finocchio através do Project Model Canvas para um termo de abertura com premissas, restrições, riscos, expectativas:

Pokedex-03

4. Papéis do SCRUM e sua prática, a técnica de inception e User Story Mapping, valorizando sobremaneira o uso desta técnica durante toda a fase de pré-game para ir modelando funcionalidades e necessidades de forma visual:

Pokedex-04

5. A técnica ou mindset mais relevante para estimular a colaboração e efetividade em times ágeis através de mapas mentais, do conceito da pirâmide de abstração frente ao ciclo de vida SCRUM … aspecto importante para entender e praticar:

Pokedex-05

6. O que são e exemplos de parâmetros de projeto e a importância na clareza deles para irmaos adiante no planejamento. A técnica de Customer Journey Map e Release Plan para a assertividade visual e alinhamento permanente:

Pokedex-06

7. A formalização e fixação de nosso Release Plan de forma visível e permanente para usá-lo como diário-de-bordo de nosso projeto, mudanças, ocorrências, a prática de Sprint Planning e a relevância de Sprints Reviews:

Pokedex-07 5

8. Um exercício de desenvolvimento de uma tela fictícia para certificação na tecnologia PTC (papel-tesoura-cola), construíndo nossa primeira tela da Pokedex, quadros kanbans e fluxos de trabalho em exercícios práticos:

Pokedex-07

9. Retrospectiva, daily Standup Meetings, Reviews e uma revisão geral do framework, uma noite pegada, repleta de detalhes e exemplos práticos, com muitas P&R … todos saímos com novos insights e caraminholas na cabeça  \o/

Pokedex-08

Ahhhhh, a customização do Kigurumi da minha Luisinha ficou massa, o fundo de cena Pokemón deu um astral legal e as brincadeiras e sutilezas mantiveram um mini-curso especialmente denso um pouco mais leve … amo muito tudo isso!

13681058_1186144614771820_1446465454195221154_n

Até a próxima!

 

4

Relato do 1° workshop ToolBox 360º

Registro da primeira edição do workshop ToolBox 360°, um Sábado inteiro de compartilhamento em que o objetivo era demonstrar os diferentes usos e oportunidades dos 70 tópicos descritos no meu terceiro livro. O treinamento teve um custo de R$100, recebendo uma unidade do livro com seu encarte sintético e mais de oito horas de práxis e exercícios.

Só tenho a agradecer o apoio da DBServer ao acreditar no valor que meus livros poderiam agregar a nosso ecossistema. Foram iniciativas independentes que contaram com diferentes formatos de patrocínio ou aquisição de até 25% da primeira edição com o objetivo de viabilizar os projetos – SCRUM 360°, JOGOS 360° e TOOLBOX 360°.

A primeira edição do workshop TOOLBOX 360° só se viabilizou pela logística proporcionada mais uma vez pela DBServer. Se o livro é um guia de 70 boas práticas em projetos, operações e escritório, o treinamento busca explicar como juntar as peças, alguns roteiros conforme contexto, riscos e oportunidades.

mural-fotos-toolbox-1
Fotos: Claudio Dias Junior

A programação foi seguindo a ordem proposta pelo livro, iniciando pelas premissas e modelo mental, seguindo com uma primeira layer de cada uma das metodologias-base que usamos (SCRUM, Kanban, Lean, Design Thinking e Lean Startup) para falar de princípios, colaboração, empatia e outras paradas.

Nessa viagem, falamos um pouco de cada estação, técnicas e artefatos para ideação, visão, estratégia, modelagem, planejamento, discovery e delivery, fechando com um tanto de gestão do conhecimento, desde retrospectivas a comunidades de prática, com o bom e velho Modelo Seci dos meus gurus máximos – Takeushi & Nonaka.

Os participantes foram: Adriana Germani, André Luis da Silveira, André Santos, Augusto, Carlos Giovani Rodrigues, Cássio Antoniazzi, Catarina Nogueira, Catarina Nogueira, Claudio da Silva Dias Junior, Cristiane Nogueira dos Reis, Denise da Silva Dariva, Eduardo Oliveira, Francielle Vareira, Gabriela Antunes, Gustavo Nogueira dos Reis, Henrique Zmuda da Silva, Joao Vicente, Luiz Carlos Santos Jr, Manoela, Marcelo Meruvia, Michel Gomes da Silva, Rafael Szarblewski, Renato Severo, Rodrigo Boehl e Thiago pinheiro.

Além destes, tive o prazer da presença dos colegas Cássio Trindade da PUCRS, Denize Vásques e Jonatan Baptista da DBServer, sempre parceiros de viagem.

A foto abaixo não contou com todos porque foi tirada apenas após o término, mas me dei conta apenas após alguns já terem ido embora … mas nas muitas fotos padrão profissionais tiradas pelo Claudio Dias Junior, acho que todos aparecem.

unnamed

Menção honrosa para o Business Model You do Batman, só podia ter DBServantes no meio dessa equipe  🙂  rsrsrsrsrsrsrsrs

BMY do batman

O maior insight que tive foi a oportunidade de em futuras edições fazer turmas segmentadas, com pessoas com interesse de igual interesse. Essencialmente interessados em projetos e operações relativo a desenvolvimento de software e outros como startups e iniciativas não TI, pois assim aprofundaria alguns temas.

1

Agile Game – Construindo Cidades

Construindo cidades é um jogo incrível, com versões usando papel colorido, sucata, lego-lego e outros materiais. Na opção mais simples, um jogo que pode ser conduzido de forma a que cada equipe receba de material uma folha de flipchart para montar sua cidade, 2D ou 3D, apenas com uma régua, duas tesouras, fita adesiva, além de canetinhas coloridas.

Aqui no Tecnotalks tivemos um evento em 26/02/15 que contou com a Georgina Reategui da ADP Labs que aplicou a versão 3D. Há uma opção bem mais sofisticada, queconheci quando participei do Ágiles Latino Americano 2011 em Buenos Aires com a Agile Coach Alejandra Alonso, mas farei um post específico sobre ele. É bem mais complexo, com user stories em cartões com critérios de aceitação, valor em pontos, com requisitos que exigem tesoura, papel colorido e cola, impondo mudanças, treinando sistemas puxados em ciclos porretas iterativo-incrementais-articulados.

Nesta modalidade que primeiro compartilho, o facilitador divide o grupo em equipes com cinco pessoas em cada, equipes que devem se organizar, definir papéis, acima de tudo, deverão trabalhar dentro dos preceitos do método SCRUM. Um deles será o product owner (representante do cliente), um será o scrum master (facilitador) e os demais devem decidir quem será engenheiro, executor e controle de qualidade.

A própria equipe pode decidirá o release plan de sua cidade, escolhendo o que precisa colocar nela e a prioridade, havendo alguns ítens obrigatórios, mas o time podendo sugerir novos. Coisas pequenas como pessoas, árvores, carros e casas devem ser feitas aos pares, grandes como prédios, fábricas, aeroporto, avião, podem ser feitas apenas uma. O facilitador media.

construindo cidades

Importante alertar que o product owner, representando o cliente, irá definir os critérios para a construção da cidade. Cada equipe tem 4 jornadas de 5 minutos, intercaladas com replanejamento. O primeiro passo é o pré-game, quando cada equipe definirá seu planejamento do que pretendem fazer a cada jornada, contando com os recursos que tem, pensando no cliente.

Uma vez definido o planejamento no pré-game, antes da primeira iteração é para o cliente esclarecer com o facilitador os critérios para sua proposta de construção para a primeira iteração. Enquanto isto a equipe se organiza e se prepara para iniciar os trabalhos, fazendo testes e analisando a folha que servirá de base para a cidade pronta para receber as construções.

A cada início de iteração o product owner discute com a equipe os requisitos (histórias) e critérios de aceite. Depois a equipe parte para a construção, enquanto isso o product owner mostra ao facilitador o que vai ser feito na próxima iteração. Ao final de cada iteração, cada equipe apresenta o que construiu e reorganizam-se para a próxima iteração de cinco minutos.

PRINCÍPIOS: Na retrospectiva discutir pontos como sistemas puxados ou empurrados, estimativa, valor, qualidade, sustentabilidade, liderança natural ou imposta, trabalho em equipe ou descontrole, multi-disciplinaridade, vale muito a pena cada insights e percepção dos participantes.

DICA: Eu não sou muito chato com os tempos, mas é importante e inevitável que errem no planejamento e replanejem-se para a próxima iteração. Errar faz parte e deve gerar aprendizado, controle os tempos e a qualidade.