1

NÃO entregar valor NÃO é opção em uma sprint

A cada dia em um projeto SCRUM é preciso relembrar Pareto (80 x 20), bem como buscar inspiração na técnica de caminho crítico. Desde o release plan, product backlog e sprint backlog, daily e pós-daily, review e retrô, o discurso de valor é legal, mas só vale se entregarmos valor.

Quando cito Pareto em projetos, tem o estratégico pela necessidade do cliente e usuários, o tático na complexidade e capacidade, tem o operacional de cada dia, a nível de tecnologia, requisitos, funcionalidades, regras, … temos então nossa rede mental e caminho crítico.

Pareto: A regra dos 80/20 ou Lei dos poucos vitais para muitos triviais, afirma que aproximadamente 80% dos efeitos vêm de 20% das causas. Um dos ícone do Lean, a lenda Joseph Moses Juran, sugeriu este princípio e o nomeou em homenagem a Vilfredo Pareto e seus estudos.

Áreas de Convergência/Divergência: O caminho crítico é uma sequencia de atividades que representa o caminho mais longo de um projeto. Área de Convergência é quando várias atividades devem concluir para outra iniciar, Área de Divergência é quando uma é pré-requisito de várias.

Assim como um bom gerente de projetos, uma equipe ágil lida diariamente com a possibilidade de tomada de decisões relacionadas a riscos, rede, fragmentação, inclusão e exclusão de atividades, paralelismo e sequenciamento, recursos essenciais para auto-organização e sucesso.

Em uma liberdade poética, trago uma rede e seu caminho crítico propostas pela UniversoProjeto para discutir conceitos de caminho crítico, não representa a estratégia de histórias e tarefas em uma sprint mas é didática quanto a caminho crítico e áreas de convergência e divergência:

Em Agile, cada história possui sua rede no sprint, gerando um desafio tático diário ao time, como na abstração que montei logo abaixo … a entrega do mínimo valor (vitais) de qualquer história não pode ser comprometida em função de entregas triviais de outras histórias:

Diariamente, a cada novo fonte, objeto, classe ou método é preciso perceber o caminho crítico e lembrar de evitar triviais antes de vitais, valorizando eliminar gargalos e garantir entregas antecipadas, parciais, essa é a nossa missão: Entregar valor!

As vezes usamos de dissonância cognitiva para justificar o porque não vai ser possível, esquecendo de se utilizar de uma visão holística, onde o todo é composto de partes … equipes ágeis de alta performance esforçam-se em entendê-las e tomam decisões para garantir entregas e valor.

Acredite, adaptar-se não é resignar-se a inevitabilidade das mudanças, é diariamente mitigar, contornar, fracionar, eliminar ou reduzir áreas de convergências e divergência, focar na essência, de forma que a adaptação não seja a negação do valor, mas a confirmação dele.

Cada SPRINT é um pacto por valor a ser entregue

Planejado na inception e materializado no product backlog, a sprint backlog é um pacto gerado pelo time entorno do mix de domínio, conhecimento, expertises e percepções de todos, levando em condição valor, prioridade, complexidade, riscos e oportunidades.

A cada Daily e pós-Daily, nossa missão é repactuar o sucesso de nossas entregas, mitigando riscos, sempre focados no mínimo entregável de valor suficiente, sempre investindo no vital e questionando o trivial, justificando assim o porque do método ágil que praticamos.

Na medida que o sprint avança, a responsabilidade e necessidade de planos de ação e responsabilidade na aplicação de árvores de decisões vais tornando-se cada vez mais premente. No 1° dia, 2° e 3° temos mais opções, a partir do 4° e do 7° temos menor margem para manobras.

Estudo de caso: Em um cenário adverso, no segundo dia foi discutido opções e assumidos certos riscos, no quarto dia já é preciso concentrar esforços e no sétimo dia muitas vezes temos que tomar decisões difíceis, mas responsáveis frente ao compromisso de entrega de valor.

Para ser mais claro, quando falamos no sprint planning sobre compromisso com a excelência combinada, características funcionais otimizadas, regras, automações, camadas, etc, isto NÃO pode ser mais importante que a entrega, validação com o cliente, fluxo e cadência.

Se decisões tiverem que ser tomadas, ok, vamos depois discutir o porque foi preciso, vamos aprender com elas, vamos nos esforçar por melhorar nos próximos sprints, vamos incluir a discussão sobre o resgate e refatoramento do gap entre o que foi previsto versus o que foi feito.

Falando em valor e sprints, cuidado com o que promete, pois és responsável por quem cativas e NÃO entregar o máximo de valor a cada sprint NÃO é opção! O desafio e a solução todos terem este princípio em mente, sem stress, mas antenados ao máximo de entregas de valor.

Nossa linguagem ubiqua foca em valor para o cliente, se você mesmo assim não abre mão de atrasos por excelência técnica, em detrimento de valor antecipado, validação e aprendizado – PDCL – Desculpa, mas talvez seja uma linguagem ambigua e não ubiqua.

Se leu até aqui, tenho certeza que vai curtir ler esse outro, garantcho:  https://jorgeaudy.com/2014/11/04/divida-tecnica-um-mal-necessario-mas-nao-e-um-carma/

0

Um debate diferente no 14º Congresso do PMI-RS

Dando uma navegada dominical, vejo que a foto do meu debate sobre convergência Agile e gerenciamento tradicional de projetos com o Leandro Vignochi no último Seminário PMI-RS está na capa do evento … aí não pude deixar passar e vou registrar aqui no blog este privilégio.

Esta foi a minha quarta participação, contando com duas palestras, um relato de caso sobre adoção SCRUM e uma pareando com meu eterno guru Paulo Caroli sobre Team Building Games, dois workshops, sobre SCRUM e PDCA, mais este debate diferentão e provocador.

O formato foi muito instigante, baseado em palavras avulsas, algumas propostas pela platéia – auto-organização, lógica, construção, essência, negentropia, propósito – com ótima mediação conduzida pelo Juliano Freitas da Silva.

Um bom debate, com direito a interação com a platéia, com perguntas e sugestões, não sobre um tema definido, mas palavras que nos remeteram a diferentes interpretações, com um saboroso feedback corpo-a-corpo após o encerramento.

Menções honrosas a participação e contatos feitos com profissionais de grandes empresas com quem interagi desde que vim para a DBServer, como da Grendene, Sicredi, GVdasa, HCPA, PUCRS, Banrisul, entre outros, com quem rolou uns papos-cabeça.

Não é um evento qualquer, é um dos maiores eventos sobre gerenciamento de projetos da América Latina, a mais de uma década, já na sua 14ª edição ele reune entre 500 e 1000 profissionais, muitos deles de TI, sempre com grandes nomes nacionais e internacionais.

A página oficial do evento deste ano é http://www.congresso.pmirs.org.br, a seguir faço uma retrospectiva das minhas participações anteriores.

2012 – O primeiro apresentei um story telling sobre o case de adoção SCRUM que realizamos na equipe de produtos digitais do Grupo RBS. Um relato a partir da volta do Agile Brazil de Fortaleza em Julho/2011, plano de ação, treinamento de 74 colegas, a atuação como Scrum Master. Acertos e erros, os detalhes e características de uma adoção de sucesso. Publicação de um artigo deste Blog, sobre Ser Feliz! no trabalho e na carreira, na NewsLetter do PMIRS:

       

2013 – Naquele ano, tive o privilégio de ministrar um curso de SCRUM e de parear com o grande Paulo Caroli em uma palestra sobre os fundamentos do Gamestorming como instrumento de trabalho no desenvolvimento de times de desenvolvimento de software. Quais os princípios comuns utilizados em momentos e cotidiano de um time ágil para gerar um ambiente instigante e energizado:

game2game1imagem 32
curso

2014 – Este ano falei sobre a relevância de levar para as áreas usuárias, de negócios e corporativas as boas práticas e crenças que usamos nas nossas equipes ágeis. Isso, porque técnicas colaborativas e auto-organizadas de visão, planejamento, execução, acompanhamento diário, checagem e aprendizado não é e não originou-se na TI, está na hora de disseminarmos para todos.

10689872_10202292215338624_6592253085703391183_n4

 

1

Ao iniciar, mapeie seu contexto técnico, humano e metodológico

Um planejamento de Releases é feito em alto nível de abstração, baseado na percepção de complexidade sobre algo minimamente conhecido, mas para fazê-lo com sucesso é preciso estabelecer prévias combinações sobre tecnologia, humanas e metodológicas. No início, mapear quem somos e o que temos, maior será a probabilidade de cumprir entregas de valor. Muitos focam em histórias e Sprints, mas o que mais vejo pegar é pacto de time, transparência, autoconhecimento com realismo, desarmar egos e máscaras.

Usar metodologias ágeis não isenta da responsabilidade com o que está a sua disposição e que faz a diferença. Domínio? Restrições? Riscos? Tecnologia? Mapa de competências e expertise? Oportunidades? Expectativas? Buscar conscientemente o ponto de equilíbrio disso tudo. David Hussman propôs a Lei de Dude [Value = Why / How], se fizermos uma analogia com futebol, para jogar é preciso saber as regras e a mecânica de jogo, habilidades necessárias para montar um time, treinar fundamentos, acima de tudo é um exercício de trabalho em grupo.

dude-s-law

1. Dedique um turno para discutir e explicitar um diagrama de blocos ou mapa de tecnologia, esclareça arquitetura, ferramentas, boas práticas, método, como vocês irão construir software de qualidade e valor, cada opção tem riscos e oportunidades, acelera ou contêm. Isso pode ajudar a planejar Sprint Zero, Provas de Conceito, Spikes, incluir Buffers, parear com especialistas, treinamento, técnicas possíveis e factíveis, enquanto alguns preferem “ter pressa” e mascarar, auto-enganar-se por medo ou arrogância, alguns assumem, outros vão enrolando.

2. De posse de um mapa tecnológico, na forma que for, de blocos, hierárquico, floco de neve, podemos nele próprio identificar riscos e plano para aceitação, mitigação, transferência, o que evitar ou explorar, uma das opções é desdobrar em um mapa de competências. Uma técnica vencedora foca em todas estas competências em um time, quer conhecimentos, habilidades, atitude, cognição, modelos lastreados no interesse em sermos sinceros e realistas com o que somos e sabemos, alimentando planos de ação (use postits pequenos verdes, amarelos, vermelhos).

3. Finalmente, como regra para equipes ágeis que pretendem planejar um projeto, é preciso estabelecer formalmente os acordos sobre os quais balizaremos nossas estimativas e técnicas de planejamento, de forma assertiva sempre, clara, realista. Minha sugestão é o artefato abaixo, um canvas para as combinações iniciais, vivas, que sustentarão o racional para uma inception ou técnica que se escolha para planejamento. O objetivo não é um contrato, mas consenso naquilo que é mais importante, porque tecnologia em projetos também devem ter seu MVP.

Uma dica importante, evite incluir em um mesmo início de projeto novidades demais, se uma equipe idealizar demais assumirá o risco de nada entregar, pode até ser desejável, mas não é responsável. Garanto que as equipes que não procedem desta forma, sempre acabam achando como solução culpar alguém, um arquiteto, gestor, cliente, PO, SM. Não há agilidade que resista a só quando tudo der certo.

Agilidade é antecipar e acordar o que fazer com cada risco e oportunidade, não é disputa nem transferência, é convergência responsável! Um bom quebra-gelo pode ser uma SWOT com a imagem do barco (forças/fraquezas) com o iceberg (riscos) e a ilha (objetivo), desconheço o autor original, talvez o Paulo Caroli, mas eu curto muito a plasticidade da imagem.

 

0

Desculpa, mas agile não é trincheira … pronto, falei!

A maior quebra de paradigma do nosso tempo não é usar design thinking, lean startup ou métodos ágeis, nem Angular, NodesJS ou microserviços, o desafio é termos profissionais mais conscientes, colaborativos, transparentes e realistas.

Mudar de método de trabalho e adotar novas práticas é sim um desafio, porém se não mudarmos o modelo mental e hábitos ancestrais, será tão somente um novo processo de trabalho para servir de zona de conforto, cada um no seu quadrado.

A pergunta não é se somos ágeis, mas se trabalhamos para nos tornarmos equipes de alta performance, porque agilidade é meio, trabalho em equipe, valoroso, colaborativo, sustentável, positivo, os resultados são o fim.

Nossa crença é que esse meio, com ambientes e equipes ágeis, suscitaremos melhores resultados a todos. Sem resultados e valor, sua agilidade não se sustentará muito tempo.

Trincheiras

Mesmo entre aqueles que se dizem ágeis, muitos misturam “reclamação” com transparência, apontar culpados com “eu fiz a minha parte”, “alertam” problemas esquecendo que nosso papel é mitigar, contornar, resolver … ver um problema é só o primeiro passo.

Eu acredito muito na frase “Esperamos que as retrospectivas façam o seu trabalho!” mas, se o resultado recorrente de uma retrospectiva é listar problemas dos outros, não é retrospectiva, é trincheira.

Muitos agilistas reclamam de problemas que eles próprios viram começar, crescer e se estabelecer, apenas assumindo o papel de arautos da verdade dos outros, apontando o dedo e deixando o seu projeto ir pro beleléu, mesmo com opções de contorno.

Construção

Há uma estrada longa para colher o que não plantamos ainda, caso ainda não usemos Lean Business Analisys, DDD, BDD, clean code, XP, DevOps, haverá muito o que fazer e consolidar para aos poucos estabilizarmos nossa realidade.

Muitas vezes eu escuto de equipes que o seu cotidiano é estressante, mas ao averiguar, não é nada além do cotidiano de uma área que lida com a complexidade inerente a software e ao imediatismo no caso de problemas em produção (legados).

Se vamos trabalhar 8 horas por dia em projetos que mexem com os destinos de empresas, áreas, produtos, serviços, mas ainda não temos um bom pack de boas práticas, querer que não hajam momentos de tensão é impossível, temos que saber lidar com eles enquanto evoluímos.

Poupança

Muitas vezes eu comparo uma empresa ou equipe que começa a adotar Agile como alguém que abre uma poupança, teremos que fazer vários depósitos pequenos para hora dessas termos um montante legal … não é imediato.

Projetos e tecnologia é igual, temos um débito técnico gigantesco, legados, falta de boas práticas variadas a cada passo, mesmo assim muitos acham que o simples fato de decretarem que se tornaram ágil esse histórico desaparecerá …

Desculpa aí, mas é o mesmo que um eu de repente decidir usar calça número 39, para isso acontecer vou ter que me empenhar a baixar do 42 para o 39, melhorar hábitos alimentares, academia, retomar os percursos diários de bike.

Adotar Agile para o modelo de fluência do James Shore pode exigir de 4 a 5 anos de dedicação, porque envolve cultura, envolve gente, hábitos, costumes, é preciso crença e dedicação, flexibilidade, jogo de cintura, é preciso ser ágil na agilidade.

Agile é valor entregue

Se há algo errado, propomos alternativas, qual a melhor delas e argumentos, mesmo assim, quem decide as vezes pensa diferente, reclamar e emburrar não é solução, só piora, é preciso tentar fazer dar certo … o que estiver ao nosso alcance!

Toolbox, foco na entrega de valor, o objetivo é sempre buscar uma técnica que melhor enderece, o que pode ser feito para resolver ou mitigar? Se necessário, excepcionalmente, stop the line e replanejar.

Trabalhar em equipe ágil não quer dizer unanimidade de opinião, mas debate e tomada de decisão coletiva e colaborativa … depois é trabalhar nos termos que ficaram definidos, mantendo um ambiente positivo e profícuo.

Quer saber? Gostaria de ser uma mosca e poder assistir incógnito alguns agilistas de boutique se “adaptando” as idiossincrasias de suas empresas, contratos e clientes … porque agilidade na vida real exige muita resiliência até que teoria e prática se encontrem. Agilidade, sustentabilidade e sinergia não são disciplinas que acontecem por decreto … é algo que construímos aos poucos, um passo de cada vez, as vezes para a frente, as vezes para os lados ou mesmo para trás. Ficar idealizando, de mi-mi-mi, só empata mais ainda. Pode demorar anos, enquanto isso, temos que ir lá e fazer, ganhando créditos, avançando, baby steps, menos mi-mi-mi e mais pés no chão por favor!

mosca

Post difícil, tabu, dá vontade de escrever mais 2 laudas, mas até aqui já expressa por alto meu sentimento.

2

Microgerenciamento leva à Paralisia de Análise

De onde saem meus posts? De minha inclinação a filosofia, sexta estava conversando com a Ana Hermann e ela citou o conceito de analysis paralysis em jogos. Acabei dedicando a noite de sexta à leitura, reflexões e derivações que me fizeram refletir sobre microgerenciamento.

“gestão com controle ou atenção excessivos nos detalhes” – Merriam Webster’s

“gestão ou controle com excessiva atenção aos menores detalhes” – Reference.com

“atenção a pequenos detalhes na gestão: controle de uma pessoa ou situação prestando extrema atenção a pequenos detalhes” – Encarta

“A noção de micro-gerência pode ser estendida a qualquer contexto social em que uma pessoa adota uma abordagem agressiva ao nível de controle e influência sobre os membros de grupo. Frequentemente, esta obsessão com os menores detalhes causa uma falha de gestão direta na habilidade de focar nas questões maiores” – Harry Chambers em My Way or the Highway (2004)

Inexiste agilidade lastreada em microgerenciamento, impossível falar de auto-organização e equipes de alta performance sem pressupor liderança ágil e delegação. Microgerenciamento destaca o líder, porque suas equipes acabam sendo dependentes, com medo de errar.

Você já ouviu falar no “Dilema da Centopéia” como alegoria ao equivoco de tentar controlar algo que deveria ser fluido, dinâmico e descentralizado? O cérebro consciente deve decidir sobre a direção, mudanças, não sobre a posição de cada dedo do pé conforme o terreno.

Qualquer controle não deveria impedir que decisões do dia-a-dia sejam tomadas, centralizando decisões de trabalho. Aquelas atividades que deveriam acontecer naturalmente não devem exigir esforço de adivinhação ou auto-proteção, acarretando desperdício de tempo e recursos.

O Dilema da Centopéia

Um poema do século XIX fala de um sapo espertinho que pergunta a uma apressada centopeia que passava ao largo: Qual a próxima pata que ela iria mover? A centopeia faceira ao tentar racionalizar seus movimentos para responder a pergunta, tropeça e cai no charco.

Líderes não deveriam recorrer a microgerenciamento, declarando não confiarem na capacidade de seus liderados, apenas na sua própria decisão. Nestes casos, aos times resta tentar antecipar o que o líder vai decidir ou tropeçar, “cair no charco” com atrasos e retrabalho.

Microgerenciamento

Meu estudo no mestrado usou o modelo Job Strain Model de Karasek, que estabelece trabalho ativo como aquele onde há alta demanda e autonomia do executor sobre a forma como melhor pode realizar, o oposto é trabalho passivo, reduzindo o controle e gerando desperdício.

O microgerenciamento gera trabalho passivo e zona de conforto, mesmo não transparecendo, o foco é entregar aquilo pelo qual vai ser cobrado, evitar riscos e pró-atividade, pois ela pode não ser bem aceita, uma situação que é a antítese de equipes auto-organizadas.

A obsessão por controle cria feudos (silos) e demonstra desconfiança da liderança na capacidade e qualificação de suas equipes em fazer o seu trabalho e tomar decisões cotidianas, gerando um ciclo vicioso de comando-controle, ações reativas, stress, atraso e zona de conforto.

Paralisia de Análise

Chamamos de paralisia de análise situações que poderiam ser fluidas, dinâmicas, seguindo pressupostos e modelos que mostram que profissionais do conhecimento necessitam de espaço e alçada para fazerem seu trabalho da forma melhor e otimizada, ainda mais em equipe.

O overhead gerado por muitos controles e restrições em atividades e tarefas do dia-a-dia gera apenas demora nas tomadas de decisão, coisas simples e imediatas geram tensão e dúvidas, não sobre o que é o melhor, mas o que o gerente espera ou exige de fato naquela situação.

É o oposto dos princípios iterativo-incrementais-articulados propostos pelos princípios e métodos ágeis, baseados em equipes auto-organizadas, até mesmo porque comando-controle e pressão só é eficiente em atividades braçais, repetitivas, onde o capital intelectual não é o diferencial.

Reflita, com o passar do tempo deixamos de ouvir falar sobre CMMI e MPS-Br, enquanto é crescente e onipresente DevOps, Management 3.0, Agile e TI-Bimodal, temos o PMBOK Ed 6 e seu apêndice ágil, estudos cintificos crescentes sobre Agile Governance e Agile PMO – porque será?

 

2

Ao invés de perguntar sobre documentação, aprenda com ela

Que tal um Doc Journey Map, como um Customer Journey Map inspirado em 5w2h e SIPOC?

Conforme o porte da empresa, envolvem-se Governança, PMO, área de processos e representantes das equipes, trata-se de uma necessidade e responsabilidade da organização estabelecer alguns padrões e GQA necessário.

Lembra SIPOC, trabalha uma espécie de 5w2h de origem a destino de cada artefato, incluindo uma reflexão sobre custo (empenho), confiabilidade, redundância e validade, quer temporária ou permanente.

Como todos os canvas e artefatos ágeis, são experienciais, o objetivo não é seguir o roteiro, mas estabelecer uma discussão focada em desperdícios e valor, assertiva, da melhor forma possível, caso-a-caso.

Não se preocupe com o número de campos, o preenchimento é orgânico, preencher é fácil e rápido se as pessoas envolvidas estiverem presentes, promovendo um debate não sobre certo e errado, mas uma auto-avaliação, momento e necessidades.

DOC JOURNEY MAP II

Baixe o canvas acima em tamanho A3

Em startups e pequenas empresas nunca usei, nunca precisou, esta é uma técnica para grandes empresas, quando há áreas de processo, governança e PMO, pois a discussão sobre métodos ágeis sempre envolve também documentação.

Um exercício que pode gerar muita empatia e sinergia, todos buscando potencialmente passar a gerar artefatos com maior conhecimento do processo, o mínimo realmente necessário, considerando origem, destino e relevância.

Eu sempre começo pelo processo, é quase um aquecimento, de forma simplificada, garantindo sempre que seja divertido e descontraído, direto no quadro branco. O resumo é o passo-a-passo da documentação em questão, eu coloco inclusive os nomes da galera.

Artefato – Nome do artefato
GT – Grupo de trabalho
Data – Datas de discussão

Quem cria – papel ou equipe
Onde/como – ferramenta e repositório
Conteúdo/objetivo – informações
Custo/energia – Tempo e envolvimento
Redundância – Único ponto ou não

Quem usa – papel ou equipe
Quando/porque – momento e para que
Valor agregado – qual o seu valor
Validade – temporário ou permanente
Confiabilidade – é confiável, timing

Processo – fluxo simplificado de manipulação desta documentação
Meta/futuro – qual a projeção, melhoria, mudanças, novas práticas, substituição

Não tem um roteiro rígido, mas bom senso, eu uso uma folha para cada artefato utilizado ou proposto, preenchendo com postits pequenos, pelos olhos de quem faz e quem consome … estruturando um mapa de docs na parede, da esquerda para a direita representando tempo.

Uma folha para cada documento ou artefato, entre as pessoas interessadas, em um GT, não impondo certo ou errado, mas provocando uma reflexão e debate sobre cada oportunidade, construção e manutenção, custo x benefício.

No mercado tem uma variedade de artefatos e documentos, alguns bem tradicionais, alguns ágeis, muitos em transição – Visão, análise de negócio, casos de uso, ER, histórias do usuário, product backlog, BDD, protótipos, cenários de testes, …

Não é um autor que vai dizer o que é bom ou não para o momento de vocês, afinal estamos todos em transição, os livros, artigos e debates em fóruns e CoP’s ajudam a ter maior discernimento neste debate sobre o que manter, mudar, abandonar, um passo cada vez.

O campo de meta/futuro é exatamente identificar alternativas futuras para substituição ou mesmo eliminação, quem sabe boas práticas como histórias do usuário, seguindo DDD, partindo de BDD, código auto-documentado e clean code, uma boa orientação a serviços, automação de testes funcionais, etc.

Documentação é inversamente proporcional às suas boas práticas ágeis
Acredite, documentação é muito mais que as tais histórias do usuário

1

Guia de uso para o SSC – Scrum Setup Canvas – Ed 5

Fiz um manual(zinho) para iniciantes, justificando cada campo do Scrum Setup Canvas, exemplificando estas definições pouco antes da realização de um Release Plan. Elas poderão mudar, mas precisam ser conscientes para embasar o planejamento e execução.

Boa sorte, customize, me avise se fizer alterações pois eu mesmo já o alterei bastante desde a primeira versão, agradeço a oportunidade de melhorá-lo ou pelo menos de saber de variações existentes. Clique aqui e baixe o manual, com modelo em A3.

  • 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 gravada por colegas no Agile Trends 2017.