Ágil e Scrum

COMBINANDO O MAPA (DECK DE CARTAS) COM ESTRUTURAS LIBERTADORAS

Wed, 22 Sep 2021 18:04:00 GMT

Recebi no mês passado o Mapa desenvolvido pelo Espírito Criativo! Um deck com 42 cartas divididas em 4 blocos distintos para auxiliar pessoas e organizações a navegarem no mar da inovação.

Se você acha que inovar é caro, não inovar é mais caro ainda. As mudanças estão acontecendo e não acompanhá-las ou mesmo se não antecipar a elas pode ser determinante para o seu sucesso ou fracasso.

No dia em que recebi as cartas, era o último dia do Treinamento de Design Thinking que estava conduzindo de forma presencial e por este motivo não tive tempo hábil para pensar em dinâmicas com o Mapa. Usei apenas algumas perguntas para questionar os protótipos que meus alunos estavam criando.

Na próxima semana terei a oportunidade de utilizar de fato as cartas e claro, retorno aqui para contar para vocês como foi a experiência. Minha ideia foi combinar o deck de cartas com as Estruturas Libertadoras.

Estruturas Libertadoras em conjunto com o uso das cartas podem levar as pessoas a encontrar e a questionar de forma efetiva as soluções encontradas. Uma das melhores formas de libertar o potencial de uma equipe é fazer as perguntas certas para melhorar o aprendizado e explorar diferentes perspectivas.

Neste sentido o Mapa contempla 4 áreas que as equipes que estão em busca de desenvolver novos produtos necessita:

Criação: as perguntas buscam explorar formas de como materializar o que idealizamos. Um dos desafios mais comuns das organizações na hora de inovar é tirar a ideia do papel. Geramos muitas ideias, mas realizamos pouco. Neste bloco encontramos perguntas como essas:

Por que devo fazer assim?

Quem fez isso antes? E se eu for além?

E se tudo mudar de repente?

Imaginação: Neste bloco está a busca pelo conhecimento. Busca explorar o que sabemos e principalmente o que não sabemos. Explorar o problema e investir em uma etapa de sensemaking é essencial para se buscar a iniciativa certa. Ouvir diferentes perspectivas é uma chave para entender o problema de diferentes maneiras. Neste sentido, temos perguntas como:

Onde estão minhas referências?

O que carrego comigo?

O que eu posso ensinar?

Conexão: Buscamos entender aqui como nos conectamos com os desafios que o mundo apresenta. Saímos de um plano mais técnico para explorar os modelos mentais. O Pensamento Sistêmico ensina que precisamos trazer à tona nossos modelos e crenças para entendê-los e fazermos as modificações necessárias. Nenhum modelo mental é certo, inclusive este. Aqui vamos encontrar perguntas como:

Quem se conecta com essa ideia?

E se eu me abrir para os outros?

Por que isso me encanta?

Inovação: recebemos por meio das perguntas um convite para seguirmos em frente. A ideia aqui é a interação. Precisamos encontrar formas para encontrar o próximo passo e atender as necessidades das pessoas. Vamos encontrar aqui perguntas como essas:

O que falta aqui?

E se eu estiver errado?

E se eu olhar em outra direção?

Para combinar este deck de cartas com as Estruturas Libertadoras, basicamente podemos selecionar uma pergunta e pedir que as equipes respondam em conjunto. Temos inúmeras possibilidades. Você pode levar de 5 a 50 minutos para responder a uma pergunta. Isso depende do nível de profundidade que quer atingir e aonde você precisa chegar.

Estrutura: 1-2-4-Todos

Essa estrutura é a que eu mais uso. Ela incentiva a participação de todos. Desde aqueles que falam muito, até os menos comunicativos. O ideal é que todos sejam ouvidos na hora de responder as perguntas.

Como fazer:

Espaço e Materiais:

Mesas e cadeiras opcionais

Papel para participantes tomarem notas

Sequência de Passos:

Antes, selecione a pergunta no bloco de acordo com a sua necessidade.

l min. Reflexão individual silenciosa

2 min. Gere ideias em uma dupla, criando sobre as ideias da auto-reflexão.

4 min. Em quartetos, compartilhe e desenvolva ideia a partir da conversa em sua dupla. Convide a perceber similaridades e diferenças.

5 min. Pergunte, “Qual foi a ideia que se destacou em sua conversa?” Cada grupo compartilha uma ideia importante com todos (repita o ciclo caso necessário)

Desenvolva as ideias a partir dos insights encontrados.

Algumas dicas para a 1-2-4-Todos:

Seja preciso com os tempos e faça outra rodada se necessário;
Em maiores, durante o “Todos”, limite o número de ideias compartilhadas para três ou quatro
Convide cada grupo a compartilhar um insight, mas não repetir insights já compartilhados
Adie julgamentos; apresenta as ideias de forma visual; saia da caixa!
Faça uma segunda rodada se você não aprofundou o suficiente!

Estrutura: Wise Crowds

Essa estrutura existe para explorar a sabedoria de grandes grupos. Ele cria um espaço onde as pessoas podem obter ajuda em um desafio persistente e trabalhar com outras pessoas para desenvolver e praticar comportamentos que ajudam a superar outros desafios.

Como fazer:

Espaço e Materiais

Grupos de 4 a 5 cadeiras, mesas opcionais

Papel para anotações dos participantes

Sequência de Passos:

Convide participantes a escolher uma pergunta e a pedir ajuda, conselhos e recomendações aos demais, que atuarão como um grupo de “consultores”.

Cada pessoa que solicita uma consulta (o cliente) terá quinze minutos da seguinte forma:

2 min. Cliente apresenta o desafio e solicita ajuda

3 min. Consultores fazem perguntas de esclarecimento

8 min. Cliente se vira de costas para os consultores e se prepara para tomar notas

Consultores se fazem perguntas, oferecem conselhos e recomendações, trabalhos em equipe

2 min. Cliente se vira de volta para o grupo e oferece feedback aos consultores: o que lhe foi útil e o que leva da consulta realizada.

Algumas dicas para a Wise Crowds

Convide um grupo diverso para explorar a questão
Relembre sempre aos participantes para tentar permanecerem na direção da experiência dos clientes.
Aconselhe os consultores e se permitirem correr riscos
Convide os participantes a não evitarem desafios complexos que não têm respostas fáceis
Você pode usar ainda a Estrutura 15% Solution para traçar um plano de ação.

Conclusão

Não utilizei ainda os Cards combinados com as Estruturas, mas já utilizei as Estruturas dezenas de vezes. São muitos resultados e insights que são gerados. Organize tudo e compartilhe com as demais pessoas da organização e principalmente com os Stakeholders. Evite criar expectativas e trabalhe sempre com equilíbrio.

Até a próxima!

Rodrigo Zambon

Servidor Efetivo do Governo do Estado do Espírito Santo, integro o time de Transformação Digital do Governo e sou agilista de coração e de profissão.

Scrum, Lean, Agile, Kanban: como eles estão relacionados?

Mon, 29 Jun 2020 13:05:00 GMT

Com frequência recebo perguntas de pessoas sobre como o Agile, Lean, Scrum e Kanban estão relacionados entre si. Para aqueles que não gastaram tempo lendo as histórias de origem, estes termos são apenas palavras soltas. Recentemente me deparei com esta imagem que conta muito bem a história e as relações existentes.

Aqui está com eu interpreto essa figura.

Na área de software, na década de 90 eles estavam buscando novas formas para se trabalhar. Os mais conhecidos são o Scrum e a Extreme Programming. Em 2001, 17 pessoas se reuniram para debater as questões que tinham em comum e foi assinado o Manifesto Ágil, momento em que foi cunhado o termo desenvolvimento ágil de software.

Antes, a indústria de transformação no Japão, fortemente influenciada por Edwards Deming, começou a enxergar diferentes formas de se trabalhar. Isto levou ao Sistema Toyota de Produção (TPS), e depois ao Lean Manufacturing.

O sistema de produção do Japão inspirou o artigo “New New Product Development Game”. Este artigo é considerado o ponto de partida do desenvolvimento do framework Scrum, influenciando fortemente os trabalhos de Jeff Sutherland e Ken Schwaber.

O Desenvolvimento Enxuto de Software é exaustivamente escrito por Poppendiecks. Ele utiliza princípios do Lean da indústria da transformação e aplica no desenvolvimento de software. O resultado desta junção influenciou também o desenvolvimento ágil de softwares.

Kanban tem raízes no Lean, no entanto ele também é influenciado pelo Ágil.

Então o que tudo isso significa? Muitas vezes as pessoas querem saber se você trabalha com Ágil, Lean ou kanban? A partir da imagem acima você pode perceber que não há apenas uma resposta. Estas ideias surgiram basicamente ao mesmo tempo com uma grande movimentação de pessoas, o que, sem dúvida, nos levaram a ideias comuns.

Pessoalmente eu acho que vale a pena ler amplamente sobre Lean e Ágil (bem como as outras ferramentas, a inspiração pode vir de qualquer lugar), e em seguida aplicar o que funciona para você.

Basta manter o básico da inspeção e adaptação:

• Mudar uma coisa de cada vez;
• Dê a mudança uma chance (as vezes às coisas pioram antes de melhorar);
• Meça as coisas importantes para verificar se a mudança ajudou ou não;
• Repita

Autora:

Artigo originalmente escrito por Karen Greaves. Tradução: Rodrigo Zambon

Link original do post: http://www.growingagile.co.za/2013/12/scrum-lean-kanban/?utm_source=ReviveOldPost&utm_medium=social&utm_campaign=ReviveOldPost

Sobre o autor:

Rodrigo Zambon

Servidor público efetivo no Governo do Estado do Espírito Santo, tendo participado de grandes projetos estruturantes ligados a saneamento e obras públicas. Multiplicador da disciplina Gerenciamento de Projetos e Planejamento Estratégico na Escola de Governo (ESESP), e atua como coach nos diversos órgãos públicos e autarquias.

O que é ser ágil?

Wed, 24 Jun 2020 17:38:00 GMT

Recebo frequentemente algumas dúvidas dos meus alunos e de outros colegas na organização me perguntando o que é ser ágil. E é interessante porque na mesma organização temos culturas locais diferentes que tentam se sobressair frente a cultura geral, aquela adotada pela maioria e já internalizada pelo público externo e sociedade. É claro, estas boas práticas setorizadas aos poucos vão aparecendo e sendo compartilhadas com os demais.

Ágil não é uma prática, em que você vai empregar algumas técnicas e esperar que as coisas aconteçam. Implantar o kanban ou fazer as reuniões diárias ou mesmo de retrospectiva ajudam, e podem sim melhorar o processo, porém não nos tornamos ágeis de uma hora para a outra, aliais essa expressão “tornar ágil” é extremamente perigosa.

Uma organização precisa constantemente rever seus processos, e renovar o ciclo de aprendizado com certa frequência. Os indivíduos precisam se adaptar as mudanças de trabalho e dos cenários. Ser ágil é um processo evolutivo, de continuo aprendizado.

Ao contrário do que muitos pensam, ágil não é entregar rápido, ou que a execução estará livre de defeitos e que a qualidade do produto será alta. Se não gerenciarmos estas variáveis, nosso projeto terá os mesmos problemas se comparado a outros métodos.

Sendo ágil você vai responder a mudanças, ou melhor, não se apegar aos planos como se fossem o certo a se fazer. É se adaptar mais rapidamente as necessidades do cliente. Entender que você, sua equipe são um meio para que o cliente possa crescer e obter valor no investimento que está fazendo. Você e sua equipe foram a melhor escolha que aquele cliente poderia fazer e tinha disponível no momento da contratação. É fundamental a parceria e principalmente entregar o que de fato ele precisa.

Uma outra questão associada a mudança é o custo. Não vamos aprovar ou descartar sem se fazer uma análise ou negociar com o cliente. Se nosso foco é entregar cedo o que representa maior valor, será que as mudanças que vão aparecendo no decorrer do projeto compensam ser entregues? Se o que tem mais valor é entregue no início, o que vem depois teoricamente trará menos benefício. Pode ser que em determinada fase do seu projeto, o cliente alcance o valor pretendido e tudo que venha depois agregue pouco ou nada ao negócio.

Sendo ágil você vai entregar valor continuamente, mas o mais importante desta afirmação é o como você entregará e como seu time está integrado com o cliente e com a organização a que ele pertence. A velha concepção de comando e controle também não irá funcionar aqui. A administração, o cliente e a sociedade precisam acreditar na equipe que está trabalhando no projeto. A autonomia do time na tomada de decisões é fundamental para manter a motivação e o engajamento.

Por último, sendo ágil você trará as lições aprendidas para dentro do projeto. Conforme descrito no manifesto ágil “Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.” Isso vai ajudar seu time a melhorar continuamente, sendo de fato um grupo unido, e qual o lugar deste grupo dentro da organização.

Sobre o autor:

Rodrigo Zambon

Iterações: qual o tamanho?

Sat, 20 Jun 2020 00:04:00 GMT

Antes de falar de iterações, vou falar um pouco de escopo e começar com um dado publicado pela Standish Group que diz respeito ao uso das funcionalidades em softwares. Apenas 20% das funcionalidades são utilizadas com frequência, sendo que 80% foram poucas ou nenhuma vez utilizadas¹.

A pergunta aqui é: por que isso acontece?

Não só em software, mas em diversos projetos, percebemos que entregamos coisas desnecessárias para o cliente, itens que agregam tão pouco valor que se não estivessem ali, ninguém sentiria falta.

A definição do escopo na abordagem tradicional é feita no início do projeto, e procura-se esgotar o processo. Muitos stakeholders, classificados em uma longa planilha, são ouvidos. As expectativas são levantadas e muitos imaginam que fazendo uma boa definição de escopo o projeto será um sucesso.

Porém na prática isto é um pouco diferente, ou seja, o mapa não é o território². O quanto antes você encarar a sua realidade melhor. Por isso, no início do projeto, determinar o tamanho das suas iterações pode ser crucial para o sucesso de todo projeto. Pense sempre em primeiro lugar no retorno sobre o investimento do cliente e em segundo, na mitigação dos riscos.

Abraçar cegamente o plano e só ter contato com o cliente no final do projeto certamente é uma estratégia ultrapassada por vários motivos, e como exemplo posso citar os dois principais: só entregar o produto no final e ainda correr o risco de entregar um produto obsoleto.

As iterações mais curtas permitem a equipe do projeto obter feedback mais cedo e consequentemente revisões periódicas com os clientes. Isso irá permitir, primeiro saber se estamos indo para o lugar certo e em segundo se estamos de fato atendendo às necessidades de nossos clientes. A abordagem tradicional atrasa esse tipo de vantagem, até quase sempre, serem irreversíveis. E mais fácil mudar no início onde os custos são mais baratos.

Uma outra vantagem de se ter iterações curtas e adaptadas a realidade do seu projeto é aumentar o foco da equipe. Na abordagem tradicional, faz-se um esforço imenso para se definir é documentar todo o escopo do projeto. Produz-se uma extensa documentação, muitas vezes em processos alucinatórios. Já participei de times que tentavam planejar prazos 5, 6 anos depois da data atual. Acredite 5 ou 6 anos do momento presente em que estamos. Sem dúvida um exercício de futurologia.

Tentar definir todo o escopo antes de se quer iniciar o projeto é um erro. Precisamos levar em consideração no mínimo a premissa que o mundo dos negócios está em constante transformação, muda-se muito rápido. Os cenários que temos hoje, certamente não serão os mesmos que teremos daqui a 5 anos. As necessidades poderão ser outras, mas nós ainda esperamos que os planos não mudem, ou que mudem pouco.

Por isso, empenhe-se nas duas ou três primeiras iterações a estabelecer um período adequado para as iterações restantes. Lembre-se de seguir com o período estabelecido até o final do projeto. Uma boa dica é reservar um tempo para o não planejando e ir ajustando esse tempo com o time. A tendência é que este tempo diminua com a evolução do projeto e com a maturidade do time.

1. Para saber mais sobre este dado leia o post publicado pelo Mike Cohn em https://www.mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used

2. O Mapa não é o território é um dos 5 principais pressupostos da Programação Neurolinguística. O Mapa que no caso é o nosso plano de projetos dificilmente corresponderá ao campo em que vamos executar nosso projeto. O cenário é incerto. Contém riscos, cultura organizacional, mudanças tardias e outras causas que podem tirar o projeto do trilho. Para Robert Dilts os melhores mapas são aqueles que nos oferecem mais escolhas.

Sobre o autor:

Rodrigo Zambon

Ágil precisa ser os dois: iterativo e incremental

Wed, 08 Apr 2020 18:53:00 GMT

Bom, o guia Scrum nos fala que “O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos.”, mas o que vem a ser uma abordagem iterativa e incremental.

Muita gente usa estas palavras sem saber a correta definição. O texto abaixo publicado no site do Mike Cohn é um bom referencial para entendermos a diferença dos termos.

Boa leitura!

O texto abaixo foi originalmente publicado no informativo mensal de Mike Cohn. Se você gostar do que você vai ler, faça sua inscrição para ter este conteúdo entregue na sua caixa de entrada antes de ser postado no Blog.

Scrum, como todos os processos ágeis, é iterativo e incremental. Uma vez que estas palavras são usadas com muita frequência e sem definição, vamos defini-las.

O processo iterativo é aquele que progride através de refinamentos sucessivos. A equipe de desenvolvimento apresenta uma parte de um sistema, ciente de que está incompleto ou deficitário em algumas (talvez muitas) partes. A equipe então refina estas partes até o produto apresentar um nível satisfatório. A cada iteração, o software é melhorado através da adição de um maior nível de detalhe.

Por exemplo, numa primeira iteração, uma tela de pesquisa pode ser codificada para suportar apenas o tipo mais simples de pesquisa. A segunda iteração pode adicionar critérios de pesquisa adicional. Finalmente, uma terceira iteração pode adicionar tratamento de erros.

Uma boa analogia, é escultura. Em primeiro lugar, o escultor seleciona uma pedra de tamanho apropriado. Em seguida, escultor vai esculpir a forma geral na pedra. Neste ponto, pode-se talvez distinguir a cabeça e o torso, e discernir que o trabalho final será o de um corpo humano e não de um pássaro. Em seguida, o escultor refina seu trabalho adicionando detalhes. No entanto, o escultor não vai ter nenhuma área completa até todo o trabalho estar completo.

O processo incremental é aquele em que o software é construído e entregue em pedaços. Cada peça, ou incremento representa um subconjunto completo de funcionalidades. O incremento pode ser pequeno ou grande, talvez variando de uma simples tela de login a um conjunto altamente flexível de telas de gerenciamento de dados.

Cada incremento é totalmente codificado e testado, e a expectativa comum é que o trabalho de uma iteração não precisará ser revisitado. Um escultor incremental iria pegar uma parte do trabalho e se concentrar inteiramente sobre ele até que seja concluído. Ele pode selecionar pequenos incrementos (primeiro o nariz, olhos, boca e assim por diante) ou grandes incrementos (cabeça, tronco, pernas e depois os braços). No entanto, independentemente do tamanho do incremento, o escultor incremental tende a terminar esse trabalho completamente.

Scrum e Ágil são tanto incrementais, quanto iterativos. Eles são iterativos quando se planeja o trabalho de uma iteração, para ser melhorado em iterações subsequentes. Eles são incrementais porque o trabalho concluído é entregue ao longo do projeto.

Para melhor ilustrar as diferenças entre iterativo e incremental, vamos considerar a construção de um site de forma iterativa, mas não de forma incremental. Para fazer isso, a equipe iria construir um pouco de cada parte do site – alteração de perfil, busca, anúncios, etc. A equipe, então, vai rever todas as partes, melhorando cada uma delas.

A equipe deve rever todas as partes, aplicando as melhorias, desta forma todo o site está ficando um pouco melhor.

Em seguida, vamos considerar o desenvolvimento do mesmo site com uma abordagem puramente incremental, não um processo iterativo. Se um site de namoro fosse construído de forma incremental, o time iria construir um perfeito sistema de gerenciamento do perfil antes de começar qualquer outra parte do site. Depois, eles então, iriam construir a segunda área – pesquisa – e passariam para a terceira área. Cada área funcional concluída deve ficar perfeita, antes de se iniciar a próxima.

Nem iterativo e nem incremental são bons isoladamente. Mas juntos – como eles estão no Scrum – são fantásticos.

Texto Original: https://www.mountaingoatsoftware.com/blog/agile-needs-to-be-both-iterative-and-incremental

Sobre o autor:

Rodrigo Zambon

Estimativas ágeis

Wed, 08 Apr 2020 15:35:00 GMT

Recentemente fui chamado para facilitar mais um treinamento de MS Project, e eu recusei. Algumas empresas se orgulham de ostentar na parede um belo gráfico de gantt para representar as relações entre as tarefas, os recursos necessários e a cronologia de entrega dos pacotes.

É impressionante a precisão. Em umas das minhas visitas consegui identificar que daqui a exatos 8 meses, ou seja, no dia 22 de novembro o recurso John Doe estará fazendo cotações de preços para compra de cadeiras, sendo que estará alocado part time no projeto e que para concluir esta atividade, ele depende do layout da sala. Vale lembrar aqui que todos os requisitos desta cadeira estão devidamente definidos aliás, todos os requisitos deste projeto já estão definidos.

Estimativas como as descritas acima são comuns e apresentam um alto grau de precisão, porém o percentual de acerto é baixíssimo. Outras questões são as seguintes: será que os requisitos permanecerão os mesmos? Será que daqui a 8 meses, ao invés de cadeiras não seria melhor comprar bancos ou sofás? E se o projeto for abortado, de que valeu todo aquele esforço de planejamento?

Estimativas sem acurácia são frequentes no planejamento tradicional. Por exemplo, se eu afirmo em meu cronograma, que determinado pacote de trabalho será entregue no dia 02, essa é uma estimativa de alta precisão, independente do dia real de entrega. Entretanto se ele ficar pronto no dia 15, essa estimativa foi completamente sem acurácia e errada.

Muitas de nossas estimativas são passadas sem se calcular o mínimo de esforço necessário para concluir a tarefa. Às vezes, passamos para agradar o cliente, ou não o perder. Talvez porque queiramos agradar o gerente ou até por medo de sair do projeto.

Uma das características do Gerenciamento Ágil de Projetos é que podemos começar o projeto com os requisitos que temos disponíveis. Podemos montar o nosso backlog à medida que avançamos no projeto. O esforço inicial de coleta de requisitos no gerenciamento tradicional leva tempo, e um esforço considerável da equipe, dependendo da complexidade do projeto.

O produto é construído em ciclos de iterações, e em cada um destes ciclos é apresentada uma pequena parte do produto. A primeira sprint, certamente representará o que gera mais valor para o cliente, pois o backlog é priorizado de acordo com o ROI. Os itens na parte superior do backlog são mais detalhados e permitem maior compreensão por parte do time.

O mais comum para se estimar tempo no scrum, mesmo que de forma relativa, são os story points. Na verdade, estão mais voltados para o esforço, do que propriamente tempo. O time de desenvolvimento é o único responsável para definir o tamanho das estórias. As melhores pessoas para estimar o esforço é quem desenvolve o produto. Parece obvio, mas isso é ainda muito ignorado em projetos. Acredite!

Uma alternativa para identificarmos o trabalho que ainda precisa ser feito, e também uma forma visual de acompanharmos o desempenho do time é o gráfico de sprint burndown. O gráfico mostra a quantidade de pontos de estórias no eixo y e no eixo x os dias relativos a sprint atual.

Muitos times ágeis optam por não marcar a linha ideal para evitar cobranças desnecessárias.

Vamos tornar o Mundo mais Ágil. Até o próximo artigo!

Sobre o autor:

Rodrigo Zambon

Responder a mudanças mais que seguir um plano

Wed, 01 Apr 2020 19:52:00 GMT

O título deste artigo é muito familiar, pois trata-se um valor ágil. Está escrito no manifesto. Não significa que não vamos ter um plano, ou ainda que não vamos segui-lo. A questão chave é que se tivermos que escolher entre aplicarmos uma mudança para gerar valor para o cliente, ou seguir cegamente um plano, vamos optar sempre pela primeira opção.

A princípio isso, para o gerenciamento tradicional isso pode soar um pouco estranho: Mas nunca teremos o escopo fechado? Como vou entregar a composição de custos deste projeto ao meu cliente? Mudar sai caro, vou ter que mudar toda hora? E a definição dos requisitos, não está fechada? Mas nós temos a assinatura no termo de abertura.

As mudanças são inevitáveis dentro de um projeto. O gerenciamento tradicional foca no acompanhamento do plano, e principalmente nas restrições de escopo, tempo e custos. O sucesso é medido pela adequação a estas variáveis, deixando para segundo plano a satisfação e o valor para o cliente. No gerenciamento ágil, estamos focados em receber e assimilar as mudanças da melhor forma, conscientes de que elas irão acontecer.

No ágil, vamos inverter a prioridade. A meta é gerar valor e entregar sempre produtos com qualidade. De preferência ao final de cada sprint, para que o cliente possa participar da construção do produto e oferecer feedback frequente. No gerenciamento tradicional a entrega é feita no final e a prioridade é seguir o plano, guiado pelas restrições.

A adaptação do processo e a inspeção do produto são pilares fundamentais para as boas práticas ágeis. Ao final de cada sprint, o time se reúne com o cliente para obter as considerações e ouvi-lo. As mudanças podem ocorrer neste momento, mas precisamos desconstruir o mito de que não há controle. O Product Owner participa e conversa. Negocia se o que o cliente está pedindo faz ou não sentido. Não é só entregar o que o cliente quer, vamos entregar o que ele precisa.

Trazendo para o cenário prático, o que vai determinar um de seus diferenciais no gerenciamento de projetos é a sua capacidade de se adaptar as mudanças. O quão rápido você consegue reagir e flexibilizar seu time para atender uma demanda não antes prevista?

A Declaração de Interdependência diz que “Esperamos incertezas e gerenciamos levando-as em conta, por meio de iterações, antecipação e adaptação.”, ou seja não vamos seguir um plano obsoleto só porque está escrito lá, se tivermos que mudar, isto será feito conforme necessário.

Ainda na Declaração de Interdependência temos a seguinte afirmação “Entregamos resultados confiáveis, engajando os clientes em interações frequentes e propriedade compartilhada”. Isto amplia a participação do cliente, engajando como parte do time, como um colaborador. Diferente do tradicional que o cliente só participa no início quando impõe um requisito, e no final quando recebe o produto, no ágil ele é parte fundamental na construção.

Para finalizar, segue abaixo a conhecida pirâmide das restrições no gerenciamento tradicional e a mudança para o gerenciamento ágil:

Restrições são importantes variáveis, mas não são a meta do projeto.

Vamos tornar o Mundo mais Ágil. Até o próximo artigo!

Para saber mais:

Manifesto Ágil: http://agilemanifesto.org/

Declaração de Interdependência: http://pmdoi.org/

Sobre o autor: