Artigo de Sara Alvez, Agile Coach da Massimus

Auto intitular-se “agilista” soa tão moderno como:  ser campeão olímpico, um campeão do UFC ou uma celebridade, mas o que realmente significa ser ágil?

Quando o conceito aterrissou em terras brasileiras, muitos interpretaram que estávamos livres de toda e qualquer documentação, o fim oficial da burocracia na TI! Entretanto, nos transformamos na documentação da aplicação, para toda vida. É possível argumentar que código também é documento. Fato, mas em que mundo paralelo temos tempo de analisar ou reaproveitar o nosso próprio código ou o de outro desenvolvedor com eficiência?  Não confie em sua memória, ela sempre falha.

Muitos refutaram as metodologias ágeis, alardeando que até os mínimos detalhes deveriam ser registrados em forma de documentação. Uma tonelada de papeis é extremamente cara, não roda como código, não é prática para consultar quando enfrentamos bugs em produção, não produz entrega de valor ao seus stakeholders. Entendimento do problema é só meia entrega, se é que isso existe.

Árduos defensores do SCRUM alegam que temos os backlogs, os gráficos de burndown e as cerimônias. Todas essas ferramentas não o transformam em um experiente “agilista” por milagre ou mágica. Há quem diga que, com essas ferramentas, temos gestão a vista, gerando transparência, portanto somos capazes de prever todas as incertezas do projeto. Talvez, mas as incertezas que ignoramos ou desconhecemos sempre nos surpreendem ou nos aterrorizam.

Dizem que só há duas certezas na vida: a morte e os impostos. Durante os jogos olímpicos foram adicionadas mais duas: Michael Phelps e Usain Bolt. Ambos aposentaram se. Não confie em seu ego, ele sempre falha.

Gosto muito de uma citação de Wyatt Earp[1]: “Fast is fine, but accuracy is everything. In a gun fight… You need to take your time in a hurry.”. Em uma tradução livre – Rápido é bom, mas exatidão é tudo. Num tiroteio …se está com pressa, vá devagar.

Temos nossas ferramentas e realizamos nossas cerimônias. Em analogia a frase de Earp, identificamos a arma e o tipo de munição adequados. Porém, também é igualmente importante conhecer outras condições para acertar o alvo. Precisamos conhecer as necessidades e desejos dos clientes, resolver o que impede a produção do time, estabelecer harmonia entre clientes e times – nem sempre falam a mesma língua, negociar e resolver conflitos a tempo e de modo satisfatório. Tudo isso é exatidão.

Há muitas interpretações e tropicalizações dos métodos Ágeis. Adaptar artefatos ao SCRUM, que atendem as necessidades dos stakeholders, não é um mal em si. Entretanto, exatidão também consiste em evitar o que largamente é praticado pelo mercado e que permite abrigar grandes distorções – SCRUM BUT. Tal adaptação gera um modelo híbrido confuso e ineficiente, unindo debaixo do mesmo teto modelos essencialmente divergentes: Cascata e Iterativo.  Pagamos caro e com consequências nefastas: Apagando fogo em Produção ou Perdido na Documentação.

[1] Wyatt Berry Stapp Earp (19/05/1848 – 13/01/ 1929) foi um jogador no Velho Oeste Americano, xerife do condado Pima e delegado adjunto da cidade Tombstone, Arizona.

Segundo Nassin Taleb, um Cisne Negro é um evento raro, exerce um impacto extremo e só conseguimos desenvolver explicações após sua ocorrência, tornando-o explicável e previsível.
São alguns exemplos de Cisne Negro: o ataque de 11 de setembro às torres gêmeas em Nova York, o estouro da bolha do subprime nos Estado Unidos em 2008 e a recente queda do preço dos comodities, como por exemplo, a queda do preço do barril do petróleo, um dos fatores de que exerceu um grande impacto em nossa economia. Sim, estamos diante da imprevisibilidade.

Como os Cisnes Negros afetam os projetos da TI? Estamos blindados em relação a tais eventos ou qual a nossa resiliência quando ocorrem?
Proponho a análise de alguns eventos comuns e previsíveis, mas que são ignorados na análise de riscos do projeto, apresentando um turbilhão de justificativas após a sua ocorrência.
Quantos projetos foram entregues dentro do prazo, sem ultrapassar o orçamento, atendendo as necessidades dos clientes? Qual a nossa assertividade na sagrada relação Prazo x Custo x Escopo?
Qual a distorção em outra relação, Planejado x Realizado?

Tais indicadores assombram gestores de projeto, o time de desenvolvimento, os solicitantes e os patrocinadores. Mas, é mesmo possível planejar com exatidão os projetos de TI que durarão acima um ano?
Apoiamos o exercício de nossas previsões na analogia com projetos da construção civil. Justificamos a utilização dos mesmos paradigmas, mas até que ponto consideramos a natureza distinta entre eles? Na construção civil, estamos prevendo e planejando resultados de um produto tangível e mesmo assim, tais projetos não estão imunes aos Cisnes Negros.
Durante o planejamento de um projeto de TI, a fim de entregarmos um “cronograma” que deixará nosso indicador verde no escritório de projetos, chutamos prazos, adicionamos alguma gordura ou adotamos um percentual de gordura institucionalizada, como se pudéssemos minimizar incertezas. Entretanto, concluído o cronograma, observamos sua transformação em clausula pétrea ou dogma. É inadmissível e imperdoável alterá-lo. Admitir atrasos, mais custos ou corte do escopo? Não!!!! Muitas metas serão comprometidas ao ousarmos tanto. Como o pecado original, esta é a gênesis das frustrações, noites em claro e cancelamentos dos projetos de TI.
Quantos sistemas são construídos, raramente utilizados ou até esquecidos, ocupando espaço nos servidores? Quantos outros, obsoletos na entrega, perderam o time to market das organizações? Considere também a adoção de critérios dúbios, para corte de escopo, quando o projeto se arrasta em atrasos.
Assim como no mercado financeiro, nós simplesmente não podemos prever.
“Acho escandaloso que, apesar do histórico empírico, continuemos a projetar o futuro como se fôssemos bons nisso, usando ferramentas e métodos que excluem eventos raros. Previsões são firmemente institucionalizadas em nosso mundo.
Temos uma queda por aqueles que nos ajudam a navegar pela incerteza, sejam eles adivinhos, acadêmicos (chatos) “bem-publicados” ou servidores civis utilizando matemática fajuta.” [Taleb]

O coaching e os treinamentos da Massimus são dedicados a boas prática do SCRUM.

O SCRUM nos permite planejar de forma iterativa, quebrando o paradigma do modelo cascata para o desenvolvimento de software; mantém o foco do time e dos stakeholders no produto a ser construído – pensamos o produto muito cedo.
Um dos fatores de sucesso em projetos que adotam o SCRUM é importante que o PO – Product Owner esteja comprometido com o projeto e com produto. Não basta criar uma lista de users stories – muitos Backlogs me surpreenderam com a ousadia de chamar aquilo de user story – sortear a ordem de priorização e estabelecer números aleatórios para o tamanho das mesmas. Esta é a fórmula certa para sermos atingidos por qualquer imprevisto e totalmente abatidos por Cisnes Negros.
Um Backlog estruturado e bem administrado é fundamental. As principais características que o qualificam como bem estruturado são: user estories que entregam valor aos stakehoders; priorização e tamanho das users stories realistas.
Durante as cerimônias de planejamento, atribuímos prioridade alta para as users stories com valor para o cliente, mas não podemos colocar no início do Backlog users stories carregadas de incertezas técnicas e/ou de negócio, já vi isto também.
Backlog estruturado e bem administrado nos permite encontrar o MPV – Minimum Viable Product, em português, o Produto Mínimo Viável.

Não podemos prever, mas o SCRUM possui ferramentas para mitigarmos incertezas e a Massimus pode e vai ajudá-lo nessa empreitada.

Sara Alves é Agile Coach da Massimus.

Taleb, Nassin Nicholas, 2007, A Lógica do Cisne Negro o impacto do altamente improvável, BestSeller, Rio de Janeiro.
Picheler, Roman, 2010, Agile Product Management with SCRUM, Addison-Wesley, Canada

Nada mais comum, ao chegar em casa azul de fome, e diante da preguiça ou outro motivo, simplesmente
apelamos para o bom e velho miojo. Por quê? Porque é rápido e mata a fome.

Aí preparamos em 5 minutinhos o nosso macarrão instantâneo. Nossa, que delícia!
E 4 minutos depois, já comemos tudo! Agora estamos alimentados, podemos tocar a vida.
Primeiramente, nada contra o miojo, ele resolve o problema da fome naquele momento num curto intervalo de tempo.

Agora, ele é um alimento nutritivo?
Se você puder comer uma boa macarronada suculenta, você escolheria ele?
Você está sempre com pressa? Vixi, seu problema aqui é gestão do tempo.
Quando quer algo mais saboroso, nutritivo, você encaixará uma salada, uma proteína, um suco natural…
E este preparo requer dinheiro, tempo e mão na massa. E, ao final, você terá uma ótima refeição, com QUALIDADE.

Este é o ponto que chamo atenção: Agile não está ligado à pressa, correria, afobação…

O Agile não abre mão da refeição saborosa, e isto requer investimento. Sim, a vida é cruel, as vezes somos obrigados a fazer um macarrão em 3 minutos para matar a fome.

Agile prima pela qualidade, sabor, prazer e entrega de resultado nutritivo.

Então, onde esta a agilidade do Agile? Na resposta à mudanças, ciclo curto de feedback, colaboração intensa…

Quer aprender a cozinhar no estilo Agile? Que tal um mestre cuca internacional?
Que te mostra os ingredientes…
Que te ensina a usar os temperos…
Que já percorreu muitas cozinhas por aí…
Preparou muitos pratos…
Que entende a cultura de cada cozinha…

Venha pra Massimus e conheça nosso mestre cuca – Heitor Roriz

Invista em qualidade!

Como mudar o pensamento das pessoas para depois instituir o método ágil?

Recebemos o seguinte comentário de um usuário em nosso blog: “Desenvolvemos todas as nossas atividades (desenvolvimento softwares) aqui na empresa, utilizando o método Srum há pelo menos dois anos. O que pude perceber em todo este período foi a dificuldade em implantarmos o método em sua plenitude, todo o processo está baseado apenas ao Kanban, apesar de adotarmos todas as cerimônias estabelecidas no Scrum. Isto ocorre por diversas razões, exigência de documentação, cultura dos colaboradores, por estarem habituados aos métodos antigos, o próprio cliente não entender seu papel. Como mudar o pensamento das pessoas para depois instituir o método ágil?”

A adoção de métodos ágeis requer a quebra de paradigmas e a mudança do mindset dentro de toda a organização. Falamos para um público heterogêneo, com interesses e metas dirigidos por objetivos e políticas divergentes, até mesmo conflitantes. Portanto, o discurso precisa ser diferenciado para as abordagens top down e a bottom up.

Abordagem Bottom up
Ao adotarmos a abordagem bottom up devemos considerar a capacitação dos membros das equipes em métodos ágeis, quebrando os mitos relacionados ao SCRUM.
O cliente faz parte do projeto e seu envolvimento se dará a partir de sua capacitação como PO.
Os métodos antigos carregam um viés burocrático que, em últimas consequências, comprometem o escopo, prazo, custo e qualidade do que é promovido ao ambiente em produção.
As User Stories, consolidadas no backlog, formam sólida documentação, acomodando as inevitáveis mudanças de modo eficiente. O backlog deve ser vivo. Também precisamos considerar a adoção de ferramentas para a manutenção das users stories, como por exemplo, uma simples planilha Excel. Deste modo, geramos evidências para atender as exigências de compliance.
O conflito entre a gestão tradicional de projetos e a gestão ágil se acentua quando construímos uma EAP (Estrutura Analítica do Projeto) com base no modelo de desenvolvimento cascata, onde as entregas estão intrinsecamente associadas as disciplinas da engenharia de software: Requisitos; Análise; Codificação; Testes e Implantação.
Uma EAP eficiente dever refletir os entregáveis, ou seja, precisamos construí-la apresentando releases e as funcionalidades associadas as mesmas.

Abordagem Top down
A abordagem top down é destinada aos gestores da organização, os que liberam os recursos financeiros para o desenvolvimento do projeto. A criação de indicadores que reflitam o retorno do investimento, redução de custos, redução de bugs são eficientes para organizações onde a área de TI é estratégica.
Por fim, é fundamental conquistar um sponsor entre os gestores da organização. Uma vez conquistado, esse gestor viabilizará e consolidará a utilização de métodos ágeis nos projetos da organização.

Sara Alves
Product Owner
Massimus C&T

Pensando em cometer um crime contra o Scrum Guide? Cuidado! Temos um Juiz implacável: Heitor Roriz.

Segue abaixo crimes cometidos contra o Scrum, em claro desrespeito à nossa Constituição Federal: Scrum Guide 2016.
ACUSAÇÃO: NÃO FAZER DAILY

Réu: João Carlos – Scrum Master – Autor: XYZ Enterprise
Defesa: Não é necessária e toma muito tempo do time, pois passa de 1 hora.
Condenação: Sentencio o réu a fazer daily, cumprindo o timebox de 15 minutos para comunicação do time e identificação de impedimentos.
P.R.I.C.
SÃO PAULO, Outubro de 2016
Juiz do Scrum Guide

ACUSAÇÃO: BAIXA DISPONIBILIDADE PARA O DEV TEAM

REQUISITOS NÃO DETALHADOS

Ré: Maria Antonieta – Product Owner – Autora: Porcaria S/A Construções
Defesa: Não tem tempo para tirar dúvidas do time, está muito ocupada com a implantação do ERP(Excel) e as estórias estão detalhadas, exemplo: Cadastro de Torres
Condenação: Sentencio a ré a passar 2 horas diárias com o Dev Team, e participar de um Workshop de Escrita de Estórias de Usuário
P.R.I.C.
SÃO PAULO, Outubro de 2016
Juiz do Scrum Guide

ACUSAÇÃO: NÃO PRIORIZAÇÃO DO PRODUCT BACKLOG
Ré: Maria Antonieta – Product Owner – Autora: Porcaria S/A Construções
Defesa: Os stakeholders não chegam num consenso, dificultando o trabalho do PO, e o diretor é quem manda no Backlog
Condenação: Sentencio a ré a ler o Scrum Guide durante 60 dias, a fazer trabalho voluntário de apoio ao Dev Time. Como criminosa reincidente, dobro a pena.
P.R.I.C.
SÃO PAULO, Outubro de 2016
Juiz do Scrum Guide

ACUSAÇÃO: SIMULAÇÃO DE RETROSPECTIVA
Réu: Eduardo Galo – Scrum Master – Autor: AgileTudo Inc
Defesa: A Retrospectiva é efetuada ao final da Sprint, como manda a lei, todos falam, anotamos tudo e as melhorias demandam botar a mão no bolso.
Condenação: Sentencio o réu a assistir a Retrospectiva do Faustão durante 5 anos, a fazer um curso de priorização e a realizar imediatamente os itens de melhorias sugeridos através da retrospectiva.
P.R.I.C.
SÃO PAULO, Outubro de 2016
Juiz do Scrum Guide

Em tempo, PRIC quer dizer:
P- PUBLIQUE-SE!!!
R- REGISTRE-SE!!!
I- INTIMEM-SE!!!
C- CUMPRA-SE!!!

Artigo de Fernandes – Facilitador Agile
Certified Scrum Master – Scrum Alliance
Certfield Scrum Product Owner – Scrum Alliance
Agile Certified Professional – IC Agile
Scrum Master Accredited Certification – Scrum Institute
Kanban Management Professional – Lean Kanban University

blog: canaldevbr.wordpress.com
Twitter: @canaldevbrAgile

As Bruxas do Agile

Hoje é dia das Bruxas! Então, nada mais normal do que vê-las soltas por aí…
Tentando aterrorizar o mundo corporativo!

-GP com medo de perder o papel para o Scrum Master.
O trabalho do GP continuará existindo, por exemplo, no tocante a custos, controle do planejamento em conjunto com o PO e apoiando na comunicação. Somatória de esforços, meu amigo GP.  Não confundir gerenciamento de projetos com o papel de GP.

-Medo de Agile ferir a governança
A equipe Agile fará seu trabalho de execução, estimativas e divisão das histórias de usuários em tamanho menores. Os artefatos Agile gerados, devem ser compilados para o modelo de governança. Sendo assim, precisamos de um profissional para fazer esta tarefa.

-Gestor com medo da auto-organização do time
O time será focado em atingir a meta do Sprint, não medindo esforços para isso. Então a auto-organização tem como centro: uma meta a ser cumprida. O trabalho será realizado, fique tranquilo gestor. E lembre-se: a autoridade é sempre presenteada, nunca roubada.
-Gestor com medo da bagunça generalizada

No Scrum, cada papel tem suas responsabilidades:
– Scrum Master cuidando das pessoas e dos processos
– Product Owner, cuidando dos releases, priorização e Gerenciamento dos Stakeholders
– Dev Team, fazendo e realizando micro gestão das tarefas.

Todos fazem gestão, ou seja, tudo muito claro
Estes medos citados, são apenas alguns, existem outros pavores.
O mundo Agile está focado em produzir resultados, somente isso já espanta muitas bruxas.
E viva o Halloween!

Post convidado por Fernandes – Facilitador Agile
Certified Scrum Master – Scrum Alliance
Certfield Scrum Product Owner – Scrum Alliance
Agile Certified Professional – IC Agile
Scrum Master Accredited Certification – Scrum Institute
Kanban Management Professional – Lean Kanban University
canaldevbr.wordpress.com

Agile – O Resgate da Energia no Trabalho

Temos uma variedade enorme de empresas e ambientes de trabalho,  com seus conceitos, verdades e estruturas. Porém muitos destes apresentam velhos problemas:

– Comunicação ineficaz

– Distância do cliente

– Ausência de colaboração

– Grupo desmotivado

Não existe fórmula mágica, mas o primeiro passo é ter consciência do problema. E depois? Tentar um caminho diferente.

Qual caminho ? Um deles é o Agile.

A filosofia Agile reúne conceitos e práticas no dia a dia de trabalho, durante a execução do projeto, marcado por reuniões e outros eventos recorrentes, que dão a sensação de continuidade, onde ao realizá-las você traz uma comunicação mais efetiva, um envolvimento maior por parte do cliente, um envolvimento na definição, refinamento e estimativa por parte de todos os envolvidos do Dev Team provocando assim um maior comprometimento e consequentemente uma maior colaboração entre os membros do time e uma atuação forte da liderança facilitadora com responsabilidade do Scrum Master para criar um ambiente produtivo e funcional com foco em gerar um ambiente com indivíduos motivados.

A questão da comunicação é melhorada, através do diálogo rápido e cotidiano com objetivo de sintonizar todos os envolvidos.

Quanto à distância do cliente, simples, nós incorporamos ele no processo, ou seja, passa a fazer parte, priorizar, acompanhar, sugerir e fornecer feedback. Feedback é vida.

A ausência de colaboração, nós deixamos claro que é essencial, primordial e que promove resultados. Colaboração é a nova queridinha das empresas inteligentes.

E o grupo desmotivado? Primeiro, tentamos convertê-lo em time (com um objetivo comum), dizemos a meta (plantamos o desafio) e apoiamos para que alcancem os resultados. Neste contexto, o desafio pode ajudar a motivar pessoas, desde que a liderança contribua.

A motivação  é responsabilidade direta da liderança, vem em conhecer bem e cada vez melhor cada integrante do seu time, saber o que motiva cada membro do seu time, avaliar possibilidades para implementar algumas dessas melhoras para o time, mantendo o time blindado quando interferências e riscos de projeto!

Fornecer estas condições promove uma injeção de ânimo no time. Também nos preocupamos em disseminar a colaboração, cordialidade e respeito para todos.

A filosofia Agile tem sim esta característica de RESGATE. Ela lhe estende as mãos. Apenas faça o mesmo.

Agile é vida nova!

Artigo de Fernandes (Facilitador Agile da SPH) e Fabiano Milani (Agile Coach da Massimus C&T)

Requisitos de Software, perfeitos!

João Bom de Requisitos de Souza é diretor comercial de uma empresa de medicamentos, e contratou uma fábrica de software, para fazer um aplicativo para os vendedores externos.

Segue abaixo a descrição do aplicativo, encaminhada à fábrica de software:

“Precisamos de um aplicativo para que os vendedores possam efetuar pedidos no smartphone, consultar a ficha cadastral do cliente e verificar pedidos a serem entregues.

Seria bom também, se pudéssemos fazer os pedidos off-line e depois integrar com o SAP”.

A fábrica contratada tomou as seguintes providências, após receber a solicitação:

– Agendou uma reunião com o diretor João, tirou as dúvidas

– Discutiu com o seu departamento de requisitos e os Devs

– Validaram as ideias com o João

– Elaboraram o orçamento

– João aprovou os custos/prazos

– A fábrica criou o aplicativo

– Agendou uma reunião com João para demonstrar e entregar o aplicativo.

Durante a reunião, João ficou muito surpreso, pois o aplicativo tinha diversas coisas que ele não havia pedido inicialmente:

Alguns comentários de João:

“Nossa! Vocês fizeram a opção de desconto para os clientes com milhagem”

“Que tela bacana este dashboard, não tinha pensado nisso, mas ficou ótimo”

“Ah, esta opção de pagar o pedido na hora via maquininha de cartão também ficou excelente”

“Olha que coisa! Funciona também sem bateria e debaixo d’água”

“Puxa, realmente vocês me surpreenderam, criaram muito mais do que esperávamos. Parabéns! Ficou perfeito o aplicativo”

Ah, nós da fábrica de software (REQUISITOS DO FUTURO), ficamos felizes que o senhor tenha gostado do produto, mas sempre fazemos isso: impactamos o cliente, entregamos no prazo e fornecemos mais itens do que o inicialmente previsto, afinal, temos um método de análise de requisitos excepcional: chama-se PREMONIÇÃO.

Este método, nos permite adivinhar com precisão milimétrica o que o cliente realmente quer. É imbatível!

Se você trabalha na fábrica de software REQUISITOS DO FUTURO, sorte sua, pois consegue adivinhar. Agora, se você é um mero mortal, terá que usar outras ferramentas para identificação e detalhamento de requisitos. E estas ferramentas podem ser a aplicação do mindset Agile.

Fernandes – Facilitador Agile e Colunista Massimus
Certified Scrum Master – Scrum Alliance
Certfield Scrum Product Owner – Scrum Alliance
Agile Certified Professional – IC Agile
Scrum Master Accredited Certification – Scrum Institute
Kanban Management Professional – Lean Kanban University
Blog: canaldevbr.wordpress.com
Twitter: @canaldevbrAgile

Projetos Ágeis – Proclamação do novo regime

Entre a ruptura do regime vigente e a chegada do novo regime, um histórico de fatos de ambos os lados se sucedem de maneira intensa.

Esta batalha tem extremistas de ambos os lados, cada qual com suas razões e verdades.

Seria o modelo vigente tão ruim assim? Apenas defeitos? Problemas? Estaria de fato desgastado?

E o modelo novo? O senhor certinho? Infalível? Regado a entusiasmo? Salvaria tudo e todos?

As dúvidas são muitas… Mas diante da iminência de um novo regime, por que não pensar diferente?

Por que não mudar o Mindset em pleno 15 de Novembro de 1889… ops, Fevereiro de 2001?

Assim como a nossa proclamação da República, o Manifesto Ágil foi um divisor de águas. Um novo olhar é necessário de agora em diante.

E a monarquia? Ops, Gestão Clássica? Diferentemente da história do Brasil, continua sendo uma opção válida.

O que diriam os mais visionários? Por que não juntar monarquia + república? Heresia? Claro que não!

Enquanto isso, nesta 3a feira, feriado da Proclamação da República, 15/11, vale lembrar do Manifesto Ágil como uma tentativa de adotar medidas diferentes, para resolver velhos problemas.

Esta tentativa tem produzido bons resultados e boas discussões,  jogam luz no verdadeiro problema: como entregar projetos para impactar nosso cliente.

Não percamos tempo com Reis ou Presidentes, vamos trabalhar de maneira colaborativa e produzir resultados.

Conheça a consultoria Agile Coaching da Massimus.

Fernandes – Facilitador Agile e Colunista Massimus

Os limites da Vida e os eventos Scrum.

Por que temos limites na vida? Por uma questão de segurança.

Temos limites para:
– Maioridade
– Velocidades nas rodovias/avenidas/ruas
– Carga na bagagem de mão
– de endividamento para compra de imóveis
– horas por dia para trabalhar

Nossa vida é repleta de limites.
Nosso foco aqui é jogar luz no limite, na verdade do limite de tempo dos eventos ( ou cerimônias).
O framework Scrum, possui, além dos papéis de Scrum Master, Product Owner e Dev Team, artefatos, regras e os eventos (cerimônias).

Estes eventos (cerimônias) ocorrem dentro da Sprint

São elas:
– Planning
– Daily
– Review
– Retrospective

São reuniões que possuem um OBJETIVO, a ser cumprido dentro do LIMITE de tempo estabelecido. E evitam outras reuniões.
Aqui são feitos paralelos com os limites da vida, são para não fugirmos do controle.

Exatamente isso, o Scrum define estes tempos máximos para cada evento(cerimônia), pois como os ciclos (sprints) são curtos, observar este limite, nos ajuda a manter a agilidade e focados

E se não tivesse os limites, os timeboxs seriam “ad eternum”, ou seja, as pessoas ficariam discutindo sem chegar num consenso. E o objetivo da sprint dificilmente seria alcançado.

Por isso, impor o limite de tempo, nos ajuda a manter o foco no objetivo.

Não é somente o limite de tempo, cada evento(cerimônia) tem um objetivo claro. E reforçam os pilares do Scrum: Transparência, Inspeção e Adaptação.

Pois sem limites, estaríamos desgovernados!

Entregar resultados em ciclos curtos e de maneira frequente é um grande desafio, requer disciplina, limites, colaboração, comunicação e foco

Ainda bem que no Scrum, os limites “timebox” estão lá, devidamente registrados no Scrum Guide.

Reflexão de Fernandes – Facilitador Agile e Colunista Massimus

Certified Scrum Master – Scrum Alliance

Certfield Scrum Product Owner – Scrum Alliance

Agile Certified Professional – IC Agile

Scrum Master Accredited Certification – Scrum Institute

Kanban Management Professional – Lean Kanban University

Blog: canaldevbr.wordpress.com

Twitter: @canaldevbrAgile