A introdução definitiva ao gerenciamento ágil de projetos

O breve

Você está encarregado de entregar a maior e mais recente iniciativa da sua empresa que vai mudar a face da “Widgets International” para sempre. É um projeto de software que envolverá e encantará seus clientes, facilitará a vida de seus colegas e fará a empresa faturar milhões. Há uma grande quantidade de antecipação, fervor, excitação e expectativa. Você precisa fazer isso o mais rápido possível para que sua empresa possa começar a colher os benefícios. O sucesso futuro da empresa depende de você. Todos os olhos estão em você. Você não pode falhar.

No começo, você pensa consigo mesmo: “Que legal, estou pronto para o desafio. Vamos fazer isso!” Você faz uma pausa por um momento, dá um passo para trás e pensa consigo mesmo: “Ok, então como vamos fazer isso?” Você começa a conversar com seus colegas e colegas. Você gasta tempo procurando as melhores práticas de desenvolvimento de software e técnicas de gerenciamento de projetos, mas as opções e abordagens são inúmeras. Existem siglas e metodologias em abundância. Os notáveis ​​chegam ao topo. A dúvida surge. Qual devemos usar? Como posso garantir o sucesso? E se eu tomar as decisões erradas?

Quando se trata de gerenciar projetos de software, há uma mistura inebriante de opções apoiadas por inúmeras opiniões. Vozes dos cantos da sala sussurram: “Tente fazer assim”; outros gritam: “Esta é a única maneira de fazer isso”; e o resto apenas choraminga: “Não administre nada, apenas continue com isso”. Na realidade, todas essas vozes falam alguma verdade. Mas o importante é descobrir o que é certo para suas necessidades, sua equipe, sua empresa e seus clientes.

Preparando a cena

Houve um tempo em que o gerenciamento de projetos de software se encaixava em um dos três campos. Havia as estruturas pesadas que permitem que você tome decisões sobre como executar e entregar, oferecendo uma estrutura para manter o controle e a governança. Havia metodologias sequenciais prescritivas, como cascata, que forçavam você a planejar projetos longos, entender e se comprometer com todos os seus requisitos, projetar e aprovar sistemas complexos, escrever muito código e depois testar (tudo antes que seu cliente o veja pela primeira vez Tempo). E, finalmente, os ciclos de vida de desenvolvimento de software (SDLC) menos prescritivos, mas iterativos, que incentivam a prototipagem rápida ou sistemas maiores a serem projetados, construídos e entregues em etapas incrementais, cada um sendo construído em cima do outro.

O desenvolvimento de software ágil e o gerenciamento de projetos ágil nasceram das inadequações da cascata e dos benefícios das abordagens iterativas para a entrega de software. Eles podem traçar suas raízes até a década de 1950, liderança de pensamento nos anos 70, maturidade nos anos 90 e adoção até os anos 2000. Em 2001, um grupo de praticantes e especialistas criou o Manifesto Ágil, com o objetivo de definir 4 valores e 12 princípios orientadores que buscam incorporar o espírito do desenvolvimento de software Ágil e incentivar sua evolução. E definitivamente evoluiu.

Agora, simplesmente chamar algo de Agile não é particularmente útil. A palavra, mesmo em um contexto de software, significa coisas diferentes para pessoas ou organizações diferentes. Existem muitas facetas, definições, implementações e interpretações. Cada corpo que adota o Agile tende a tentar dar-lhe sua própria definição.

Basta dizer que o desenvolvimento de software ágil e o gerenciamento de projetos são um grupo de comportamentos, estruturas, técnicas e conceitos relacionados que favorecem fundamentalmente a entrega do software de trabalho certo o mais cedo e com a maior frequência possível.

Mencionei anteriormente que o Agile, aplicado ao desenvolvimento de software ou gerenciamento de projetos, pode ser coisas diferentes. Em poucas palavras, o desenvolvimento de software ágil cuida do desenvolvimento de um ótimo software em um business as usual (BAU) ou contexto de projeto. O gerenciamento ágil de projetos, por outro lado, cuida da governança e do controle necessários para entregar projetos complexos, incluindo, entre outros, software.

Existem muitos métodos de desenvolvimento de software Agile disponíveis, como Scrum, Kanban, XP e Lean Software Development. Mas assim como o jogo de rugby é mais do que o scrum, o Agile também é. Isoladamente, esses paradigmas ágeis não abordam todo o ciclo de vida do gerenciamento de projetos necessário em projetos complexos, como governança, recursos, financeiro, gerenciamento de riscos explícito e muitos outros conceitos importantes de gerenciamento de projetos. Para isso, você pode considerar o PMI Agile ou o PRINCE2 Agile – pense nisso como “Agilidade Governada”.

Por que precisamos ser ágeis?

Há muito tempo, percorríamos a terra para reunir comida e abrigo para sobreviver. Eram necessidades simples, mas bastante ágeis. Algum tempo depois, países e economias cresceram e prosperaram com a Revolução Industrial. Este foi o nascimento da gestão e controle e a perda de agilidade. Agora estamos na Era da Informação ou Revolução, onde as empresas empregam trabalhadores do conhecimento. Os trabalhadores do conhecimento são você, seus parceiros e seus colegas e colegas, que se esforçam para criar ótimas soluções para problemas de clientes, negócios, sociais, econômicos e mundiais. Os trabalhadores do conhecimento aplicam a análise, o conhecimento, o raciocínio, a compreensão, a experiência e as habilidades às necessidades frequentemente definidas e mutáveis. Essas empresas e trabalhadores precisam de métodos e técnicas que não podem ser atendidos pelos processos e procedimentos da antiga Era Industrial. Agile suporta interações.

Praticamente nenhum projeto de software pode começar com confiança e saber tudo o que precisa para entregar um software valioso e funcional sem alterações. A mudança apresenta oportunidades e riscos para o sucesso de um projeto. Oportunidades não gerenciadas podem significar a diferença entre uma grande empresa e uma empresa incrível. Risco não gerenciado significa desastre e ruína. Ágil gerencia a mudança.

Adotar o Agile permite que você responda às mudanças ou novos requisitos. Ele capacita as equipes de desenvolvimento a serem especialistas e tomarem decisões apoiadas por um negócio engajado, confiável e informado. Ele permite que você entregue aos clientes o que eles realmente desejam. Em última análise, ele coloca você e sua organização no controle da entrega de software valioso e de alta qualidade, que atende às necessidades e expectativas do cliente, enquanto extrai um retorno sobre seu investimento o mais cedo possível. Ágil cria valor.

Há um custo para adotar o Agile. Não vem de graça. A transformação para uma abordagem ágil para entrega de software pode ser um caminho difícil de seguir. No entanto, se você internalizar a filosofia Agile, agir com cuidado, envolver a equipe certa com a atitude certa, dividir as coisas, torná-las alcançáveis ​​e realistas e responder ao feedback, colherá recompensas. Agile enfatiza a colaboração.

A seguir, listamos alguns benefícios que você pode esperar:

• Velocidade para o mercado
• Geração de receita antecipada
• Entrega regular de valor real
• Proteção para o seu investimento
• Dados, dados, dados
• Melhor qualidade do produto
• Expectativas gerenciáveis
• Maior satisfação do cliente
• Equipes de maior desempenho
• Melhor visibilidade do progresso
• Previsibilidade, transparência e confiança
• Risco gerenciável

O sucesso não é definitivo, o fracasso não é fatal: é a coragem de continuar que conta.

Winston Churchill pode nunca ter dito isso, mas acho que é um bom resumo do Agile. Sabemos que o Agile é o melhor caminho para a maioria dos projetos. Ele encoraja você a lutar pelo sucesso, mas sempre repetimos e continuamos desenvolvendo isso. O Agile irá incentivá-lo a falhar, mas falhe cedo e siga em frente. Ter a coragem de continuar e construir a solução certa com base no insight informado pelo seu cliente é o que traz a recompensa.

A coisa a ter em mente é que você pode adaptar o Agile às suas necessidades. Use o método e a governança adequados para o seu negócio. Onde quer que você comece, seja fiel ao conteúdo, contexto e espírito do método que você usa – mantenha-o simples. Se você está apenas começando, aprenda . Se você já faz isso há algum tempo, entenda . Se você está se tornando incrível, aplique . Finalmente, se seu negócio e seus projetos são complexos e interdependentes, governe . Com o tempo, você e suas equipes descobrirão o que funciona melhor para o seu negócio.

Viabilidade

Então agora você está pensando: “Ok, entendi. Como eu começo? Por onde começo?” Bem, com todas as coisas boas, começamos do começo. E com o Agile, é perguntando a si mesmo “Qual valor de negócios eu quero entregar?” Afinal, é por isso que empreendemos projetos, para gerar valor ao negócio. Para determinar se vale a pena empreender o projeto para obter o valor do negócio, você precisa entender se é viável.

Visão

Seu projeto foi projetado para aumentar a receita, entrar em um novo mercado, adquirir mais clientes, melhorar a percepção do cliente ou facilitar a vida de um determinado problema que você identificou? Com isso em mente, você pode declarar sua “visão”.

• Sua visão pode vir de diferentes fontes – sua própria startup ousada para resolver um problema comum, estratégia de gerenciamento de negócios, projeto de estimação de seu CEO, uma equipe de produto específica ou até mesmo as necessidades de seu cliente.
• Tente dar um passo para trás de seus próprios sapatos e “ver” como será o futuro com seu novo produto ou serviço nas mãos de seus clientes.
• Envolva seus stakeholders – o CEO, o cara do produto e os clientes. Workshop, não tente isso isoladamente. Desafie suposições e valide argumentos.
• Anote, mantenha-o curto. Foco no valor do negócio.
• Refine-a até que todos concordem que a visão ressoa com todos e atende a uma interpretação comum que indica para onde você está indo.
• Sua visão, se válida, raramente muda. Como você chegar lá certamente vai.

As pessoas não compram o que você faz, ou como você faz. Eles compram o “por que” você faz isso. Isso é o que cria a conexão emocional entre sua empresa e seus clientes. A visão ajudará a ilustrar isso.

É viável?

A viabilidade vem em pelo menos alguns tons. Normalmente, você desejará entender se sua visão de um futuro melhor para seus negócios e clientes é tecnicamente viável e se é viável para sua empresa fazer isso acontecer.

• Se sua visão é fazer viagens para qualquer lugar do mundo em menos de uma hora, você pode ter um problema com a viabilidade técnica. Como a ciência, a física e a tecnologia ainda não alcançaram esse sonho, sua solução técnica pode não ser viável em nada além da teoria. Além disso, se sua solução fosse nova, isso iria muito além da ideia de um produto mínimo viável (MVP).

• Para testar a viabilidade técnica do seu produto, considere explorá-lo ainda mais em um projeto de protótipo do Discovery ou executar um pico nos estágios iniciais do projeto. Você saberá qual método usar pensando na escala ou complexidade da solução que tem em mente.

  “Alguns dos melhores conhecimentos que minhas equipes adquiriram para entender a viabilidade técnica vieram da realização de um pico. E muitas vezes, é a solução mais simples que vence!”

• O segundo tom de viabilidade a ser considerado é se você, sua equipe ou sua empresa têm as habilidades e a motivação para fazê-lo funcionar. Usando um exemplo, se você é ótimo em fazer bolos em casa para o aniversário de seus filhos, isso é ótimo. Mas se você quiser transformar isso em um negócio que vende os melhores bolos para o mundo, você precisa entender se você pode escalar, lidar com o negócio e com a produção, gerenciar a distribuição e o atendimento e cuidar do atendimento ao cliente.
• Esse tipo de visão pode ser alcançável a longo prazo. Mas, por enquanto, possivelmente não. Então reduza, pense pequeno, pegue um pequeno pedaço que pareça realista e concentre-se em entregar a melhor aspiração menor que puder. Se isso conseguir envolver e encantar seus clientes, faça com que eles voltem para mais e conte aos amigos e, em seguida, aumente a partir daí usando o feedback do cliente como guia e bússola.
• Além disso, você precisa saber se o seu projeto é viável em termos de orçamento e prazo. Sua empresa pode dar ao luxo de entregar este projeto? O prazo é alcançável? Tempo e dinheiro são duas das três restrições em um projeto Agile que são fixas. Nosso objetivo é entregar dentro de um determinado tempo fixo e dentro de um determinado orçamento fixo.
• A qualidade de um produto refere-se ao produto final que seus clientes usam e às práticas de engenharia que sua equipe usa para entregar um software excelente, robusto e confiável. A qualidade também é algo que não deixamos de lado. Os critérios de qualidade, por outro lado, podem mudar. Se você não pretende construir uma Ferrari, o produto pode não ter uma percepção de alta qualidade. Se você não está construindo foguetes espaciais, as tolerâncias alcançadas em termos de produção podem ser muito maiores. Defina o tom e a expectativa apropriados desde o início.

Então agora você confirmou que seu sonho é mais do que fantasia de chocolate, comece a testar suas suposições e provar às pessoas que vale a pena investir nesse empreendimento.

Justificação

Agora, dependendo de suas circunstâncias, a justificação virá de diferentes formas. Mas, essencialmente, você quer provar que esse projeto satisfará os critérios de sucesso do cliente, tem chance de sucesso, agregará valor e é acessível.

• Declare suas suposições com base na necessidade do cliente e, em seguida, valide-as. O Lean Startup oferece ótimas orientações para identificar e provar que seu produto é necessário para seus clientes e criará valor.

• Escreva, teste e valide seu plano de negócios. Agora, isso não se parece em nada com os que seu banco ou seu especialista em negócios e finanças lhe disse para produzir. Não os use — eles estarão desatualizados antes que a tinta seque. Em vez disso, confira o Business Model Canvas. Este é essencialmente um plano de negócios de formato curto que mantém seu foco em sua proposta de valor, seus clientes, receita e custos. Use-o para validar se você tem um negócio que vai dar certo.

  “Ignorei esse conselho uma vez e passei muito tempo escrevendo um longo plano de negócios tradicional de 50 páginas. Não me levou a lugar nenhum. Todas as suposições que fiz eram infundadas e todas as projeções que fiz não puderam ser validadas. Foi uma experiência dolorosa e cara que me ensinou a nunca mais fazer isso.”

• Se você estiver em um negócio maduro com portfólios de projetos sendo entregues em um ambiente complexo, a modelagem financeira pode ser necessária. Se for necessário, faça isso somente depois de provar o que foi dito acima.
• Uma vez que você tenha construído seu MVP, pode haver um caso para criar um plano de negócios mais tradicional – por exemplo, se você tiver que buscar financiamento ou seleção dentro do portfólio de projetos e recursos concorrentes de sua empresa. Mas este será um plano de negócios baseado e informado pelas ferramentas usadas acima. Será mais leve também.
• De qualquer forma, use essas ferramentas como artefatos vivos e respirantes. Use-os como seu guia e guia. Eles nunca são estáticos. Consulte-os e revise-os à medida que seu projeto ou negócio evolui.

Uma vez que você tenha sua justificativa e todos os seus stakeholders estejam a bordo, você estará em chamas.

A fase de viabilidade é normalmente realizada uma vez na vida do seu projeto. Você pode descobrir que revisita a visão e a viabilidade do projeto, especialmente se seus dados, clientes, mercado ou negócios indicarem isso. No mínimo, eles serão suas luzes guias por toda parte.

Iniciação

Impressionante. A decisão está tomada, o projeto tem luz verde e você está pronto para construir. Bem, quase. Eu sei que você está pensando: “Vamos lá, sério? Se não fizermos isso agora, nunca faremos. Vamos colocar esse show na estrada!” Mas considere isso: o Agile não é nada além de entregar valor cedo e com frequência, enquanto encanta seus clientes ao longo do caminho. Levar algum tempo para descobrir a melhor maneira de entregar seu projeto é a melhor base para o sucesso.

O time

Nos esportes, ao pensar em seu jogo de equipe favorito, você será capaz de reconhecer os principais papéis que permitem que a equipe tenha o desempenho que desempenha. Tradicionalmente, você encontrará um técnico, um capitão e o resto do time. Fora isso, você encontrará treinadores, fisioterapeutas, nutricionistas e uma variedade de funcionários de apoio. Mas se olharmos para o jogo de rugby, há uma equipe dentro de uma equipe: os jogadores que compõem o scrum. Este pacote é composto por jogadores designados cujo trabalho é recuperar a bola e continuar jogando. Quando um scrum está em jogo, os jogadores de cada lado trabalham, sem líder, como uma única unidade da forma mais colaborativa, comunicativa e eficiente possível para recuperar a bola. É o jogo de rugby que inspirou Jeff Sutherland a nomear sua metodologia de desenvolvimento de software “Scrum”.

• Scrum não é o único método de desenvolvimento de software no manual do Agile. Mas é a que melhor descreve o conceito e os comportamentos Ágeis de trabalhar em equipe, motivando indivíduos, criando relacionamentos de confiança, auto-organização, liderança servidora, comunicação, transparência e colaboração.
• Sua equipe será formada em grande parte pelas circunstâncias em que você se encontra. Você pode ter desenvolvedores disponíveis para você. Alguns, nenhum ou todos eles podem estar familiarizados com o Agile em graus variados. Você pode querer contratar uma nova equipe ou parceria com um terceiro.
• Outras funções também serão necessárias, mas as discutiremos mais tarde.
• Foi dito que se você forma sua equipe de desenvolvimento, então você escolheu sua tecnologia. Dependendo de onde você reunir sua equipe, eles virão com conjuntos de habilidades específicas. Portanto, pense com cuidado em como você forma sua equipe de desenvolvimento e se precisa realizar uma avaliação técnica antes de chegar a esse ponto de sua jornada.
• Isso nos leva a equipes multifuncionais. As equipes funcionam melhor quando trabalham juntas, quando os indivíduos se juntam para fazer o trabalho, independentemente do cargo. Tente construir uma equipe que seja auto-suficiente e indivíduos que assumam mais de uma função.
• Construa um ambiente, cultura e centro de relacionamento - um lugar onde a equipe possa entregar, livre de restrições ou restrições. Dê à equipe as ferramentas, pessoas, recursos e espaço para ser eficaz e ter desempenho.
• Mantenha o tamanho da equipe em não mais que sete ou oito. Se você precisar de muito mais desenvolvedores, divida a equipe em várias novas equipes. Cada equipe pode então ser responsável por uma determinada área funcional. Se você tem várias equipes em vários locais, considere realizar um Scrum de Scrums. E onde eles são numerosos em ambientes complexos, use o gerenciamento de projetos Agile.
• Garanta que a equipe, os negócios, as partes interessadas e até os clientes tenham acesso uns aos outros. Certifique-se de que eles se comuniquem e colaborem, e remova qualquer coisa que atrapalhe o progresso. A comunicação diária é a melhor cura para as doenças do projeto. Quando as pessoas falam, elas fazem as coisas.

Há muitas maneiras pelas quais uma equipe pode ser reunida para entregar software.

Resumo do projeto

Na etapa de viabilidade, você descobriu o “porquê” do seu projeto e construiu sua confiança para avançar com sua startup ou obteve apoio para prosseguir. O resumo do projeto é o documento vivo que reúne o “porquê” com o “o quê” e “quando” e “quem”. É “viver” porque, à medida que você progride, seu conhecimento, compreensão e caminho podem mudar. Deixar este documento uma vez escrito e nunca mais voltar a ele apenas remete seus pensamentos a um ponto no tempo. Em um mundo ágil, sua referência pontual pode mudar semanalmente ou até diariamente no início, por isso é importante mantê-la atualizada.

• Uma ótima ferramenta para encapsular e manter o resumo do seu projeto é algo que Jonathan Rasmusson chama de “inception deck” em seu livro The Agile Samurai . Aqui, você encontrará ótimos conselhos para garantir que todos os interessados, afetados ou envolvidos com seu projeto estejam na mesma página.
• O maior inimigo da entrega de projetos é ter um entendimento pouco claro, inconsistente ou simplesmente diferente do que é o projeto e quais “requisitos” devem ser atendidos. Se mesmo uma parte interessada importante tiver uma compreensão ou visão diferente do que você está fazendo, as consequências podem ser substanciais.
• Um bom briefing de projeto comunica:
  1. Uma expectativa comum e acordada entre as partes interessadas e os membros da equipe.
  2. Um entendimento do projeto, com o mesmo entendimento em todas as partes.
  3. A meta, visão, objetivo, escopo e contexto do projeto.
• Você terá muitas informações boas para o resumo coletado da viabilidade. O resumo do projeto irá ajudá-lo a definir e encontrar as respostas para as perguntas de pesquisa. Ele reunirá as partes interessadas, sua razão de ser , escopo de alto nível, riscos, solução-alvo, orçamento, cronograma, expectativas e prioridades.

Um colega me parou em um corredor uma vez e me perguntou onde ele poderia obter o resumo do projeto. Eu brinquei 'Nós não precisamos de um briefing, nós somos Agile'. Ele parecia confuso, como se estivesse questionando minha sanidade ou autoridade. Ele estava certo em fazê-lo.

Antes de prosseguir, certifique-se de que todos estão na mesma página, faça um workshop, faça as perguntas difíceis e prenda-o em algum lugar onde as pessoas possam parar, ler, comentar e ajudar a revisá-lo.

Cultura e Formas de Trabalhar

Você conhece a maneira como sua empresa funciona e sua cultura, a maneira como ela gosta de fazer as coisas. Ágil, por sua própria natureza, pode desafiar algumas dessas formas de trabalho que sua empresa cultivou ao longo dos anos. Não espere que o Agile seja implementado e que todos o adotem com amor desde o início. Algumas pessoas podem achar confuso e vê-lo apenas com pavor e medo. Algumas pessoas podem se recusar abertamente a se envolver nisso. Estes são desafios e percepções que você deve superar. Mas em seus primeiros dias, não saia por aí acenando com o bastão Agile batendo em qualquer um que não queira ouvir com ele. Isso não construirá confiança, adoção ou engajamento.

Eu era fã de agitar grandes bastões proverbiais uma vez, e isso me rendeu muita imprensa negativa. Eu o virei, mas não antes de sofrer uma dor considerável primeiro.

Ao iniciar seu caminho de adoção, pise com cuidado, respeito e empatia. Se você estiver em um negócio tradicional e decadente, talvez não seja a melhor abordagem para alinhar todo o negócio. Comece pequeno e gradualmente ganhe respeito e reconhecimento. Comece apenas com sua equipe. Quando você começar a fornecer software mais rápido com melhor qualidade do que nunca, as pessoas começarão a notar e desejarão vir jogar seu jogo. Quando o fizerem, ofereça-lhes a bola, leve-os para um café e leve-os para o seu novo mundo. Ajude-os.

Com sua equipe, agora que eles sabem do que se trata o projeto e seus planos para a adoção do Agile foram acordados, deixe a equipe decidir como deseja se comportar e operar como uma equipe.

• Guie sua equipe para identificar os conceitos, técnicas, comportamentos e estruturas ágeis que você acha que atendem às suas necessidades coletivas.
• Aceite solicitações dos membros de sua equipe sobre quais requisitos eles têm para ajudá-los a ter o melhor desempenho possível. Algumas dessas solicitações, você poderá resolver imediatamente. Outros, você pode precisar de um orçamento ou ajuda externa. Faça o que puder para que isso aconteça.
• Estes são os primeiros passos para se tornar um verdadeiro líder-servo.
• Considere organizar algum treinamento apropriado nos conceitos e técnicas que sua equipe está escolhendo adotar. Essa é a melhor maneira de garantir que todos os membros de sua equipe, até mesmo as partes interessadas, estejam na mesma página e recebam a mesma mensagem. Trabalhe com uma organização fornecedora que possa adaptar sua oferta às suas necessidades.
• Seja prudente. Ninguém será um ninja ágil depois de alguns dias em um workshop aprendendo como se tornar ágil. Seu caminho será longo. A palavra “tornar-se” é bastante definidora. Somente quando você realmente abraçar o Agile você verá seu valor. Deve excitar você. Se isso te excita, então vá excitar os outros também.
• Agora que sua equipe concordou com os conceitos e técnicas, teve seus desejos atendidos e está em treinamento Agile, volte a atenção de sua equipe para si e para o que eles esperam de você, da empresa e uns dos outros.
• Definir algumas formas de trabalhar (WoW) dentro e pela equipe ajuda a construir confiança, relacionamento e expectativas. O WoW não é Guerra e Paz . Deve ser curto e direto ao ponto, entre sete e dez frases com marcadores. Essas frases afirmam claramente como as pessoas se comportam, se comunicam, colaboram, apoiam, entregam e atuam juntas. Também deve indicar o que a equipe espera do negócio.

• Agile é tanto uma mentalidade quanto princípios e conceitos orientadores. Ele ajuda você a se desenvolver na maneira como se comporta, pensa, negocia, interage, se comunica, atua e melhora. Baseia-se em indivíduos motivados apoiando uns aos outros para alcançar um objetivo comum, juntos como um só. Existe um provérbio africano:

Até agora, sua equipe deve estar super animada, energizada e motivada. Agora, envolva-os ainda mais com seu backlog de histórias de usuários.

Backlog

Não tenha dúvidas em sua mente de que há incerteza envolvida em seu projeto. Você não pode saber exatamente o que será necessário para construir o produto certo para seus clientes tão cedo em sua vida. Você não pode olhar melancolicamente para uma bola de cristal e prever o futuro.

O “backlog” ou “product backlog” é onde estão seus requisitos. O Agile favorece a escrita de declarações curtas e concisas que capturam a essência de um “requisito”. O backlog é simplesmente uma longa lista de entradas, cada entrada definindo um único e discreto “requisito” como uma história de usuário. E a partir de agora, usaremos a palavra história do usuário, e não “requisito”. Você provavelmente está perguntando “por quê?” Esta é uma boa pergunta. Pelo que parece uma eternidade, declarar os recursos ou facetas necessárias em um projeto de software por um cliente sempre foi referido como um requisito. Essa palavra tem uma interpretação que não tem valor no Agile. O dicionário Oxford define como:

Uma coisa que é necessária ou desejada. Ou, Uma coisa que é obrigatória; uma condição necessária.

E, infelizmente, se nos propusemos a definir qual deve ser a nossa solução, afirmando que as coisas são “obrigatórias”, vamos acabar em apuros. É muito fácil dizer que todas essas histórias de usuários são obrigatórias. Se adotarmos essa visão, corremos o risco de ultrapassar o cronograma e o orçamento na tentativa de entregar todo um determinado escopo. Não é um problema dizer que, para este produto, essas histórias são necessárias para que a solução seja viável, apenas queremos evitar a interpretação dessa palavra em particular.

• Sempre escreva histórias da perspectiva de uma persona. Uma persona representa um usuário ou parte interessada da solução. É uma boa ideia desenvolver essas personas antes de iniciar um backlog.
• Nesse estágio, escreva apenas declarações curtas e simples que basicamente sugiram um lembrete para ter uma conversa mais profunda sobre a história do usuário quando for a hora certa.
• Pessoas reais pensam em termos de tarefas que precisam ser feitas para atingir um objetivo. Escreva suas histórias da perspectiva da persona e em termos do que elas precisam fazer.
• Você não precisa escrever o backlog completo — apenas escreva o quanto você puder imaginar que seus clientes precisarão para que seu produto seja viável.
• Você descobrirá mais tarde ao longo da vida do produto que as histórias do usuário mudarão, se tornarão mais ou menos importantes ou poderão ser excluídas completamente. Liberar com frequência, obter feedback e avaliar o que é uma prioridade informará esse comportamento.
• Não escreva histórias isoladamente. Envolva sua equipe, partes interessadas e até mesmo seus clientes. As histórias podem ser atualizadas a qualquer momento na vida de um projeto, mas devem evitar ser alteradas após o início do trabalho de desenvolvimento.
• Algumas de suas histórias podem ser consideradas “épicos”. São histórias grandes que cobrem muito e serão divididas mais perto do momento da entrega em histórias menores.
• Considere usar o modelo INVEST, uma lista de verificação para validar a qualidade de uma boa história de usuário.
• Qualquer um pode adicionar uma história ao backlog. Deve ser colocado na parte inferior ou em um “estacionamento” especialmente criado. Essa história adicionada serve como um prompt para discutir com a equipe e os negócios. Se o negócio e a equipe o apoiarem, ele poderá ser estimado e priorizado
• Você também pode considerar as partes do sistema que são mais arriscadas. Se você tiver uma história de usuário ou recurso complexo, novo ou tecnicamente desconhecido, priorize-os no topo de sua lista de pendências. Dessa forma, você não tentará entregar as partes desafiadoras e críticas do seu produto apenas algumas semanas antes do seu primeiro lançamento.

Depois de ter um backlog que atenda às suas necessidades, você pode estimar as histórias nele, classificá-las em ordem de prioridade e criar um plano de lançamento.

Estimativa e priorização de alto nível

A estimativa de alto nível é o processo de dimensionar seu backlog. Quão “grande” é o projeto e que valor ele entrega? A priorização é o processo de decidir quais histórias são mais importantes para você, a viabilidade do produto e os interesses de seus clientes. Queremos entregar os itens de maior valor o quanto antes para entregar o maior valor ao negócio, obter feedback do cliente e não se preocupar com as pequenas coisas. A saída será um backlog ordenado que é classificado em prioridade e dimensionado adequadamente.

• As histórias no topo são consideradas as mais valiosas. Queremos entregar os itens mais valiosos o mais rápido possível.
• Existem muitas técnicas para dimensionar e estimar, mas neste ponto, você só quer ter uma boa ideia indicativa do tamanho de uma história.
  • Use tamanhos de camiseta, tamanho relativo, dias ideais ou pontos de história.
• Você também não terá todas as informações disponíveis neste momento, e tudo bem. Apenas corra com ele.
• Envolva seus stakeholders de negócios ou gerente de produto, se você tiver um, e a equipe que fará o trabalho.
• Queremos que aqueles que irão projetar, desenvolver e testar o trabalho o dimensionem, porque as melhores pessoas para estimar são os especialistas.
• A equipe pode começar a dividir as histórias em partes menores. Se isso acontecer, escreva histórias mais granulares, mas discretas.
• A equipe também pode começar a classificar algumas histórias, pois naturalmente algumas coisas precisam ser entregues antes de outras para apoiar a tecnologia ou uma determinada jornada do usuário.
• Entre você e a equipe, você também pode começar a encontrar lacunas no backlog que precisam ser preenchidas. Basta preencher esses buracos com novas histórias e estimar e priorizar conforme apropriado.
• A priorização é realizada mais facilmente usando uma análise MoSCoW. MoSCoW é uma técnica simples que ajuda você a decidir quais histórias são “obrigatórias” para que seu produto seja bem-sucedido.
• Você pode fazer um passo de priorização antes do início da estimativa. No entanto, o dimensionamento de determinados elementos também pode determinar uma decisão sobre a prioridade e o valor real do negócio. Então jogue estimativa e priorização um do outro, mas não brigue sobre isso!
• Nenhuma história pode ser tão importante quanto a outra. A história no nível 1 é mais importante ou valiosa do que a história no nível 2.
• Uma ótima maneira de demonstrar a importância ou o valor de uma história é adicionar um valor monetário a ela. Se, por exemplo, se pensa que a história A gera $ 5.000 de receita extra, e a história B pode atrair $ 100, então a história A é mais valiosa. Da mesma forma, se a história C economiza mais para o negócio do que a história D, a história C é mais valiosa.
• Depois de dimensionar seu backlog, você ficará com um número. Quando chegarmos ao planejamento de lançamento, esse número nos ajudará a entender quanto pode ser entregue por nossa equipe dentro de um determinado prazo.

Remember that you don't need to know all your user stories up front. Also, remember that it's not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

Release Planning

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

Adaptive Planning

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

Sprinting

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• Trabalhar em pequenos incrementos tem um enorme benefício. Isso significa que você está se concentrando apenas no futuro imediato da entrega e, com novas contribuições, feedback e aprendizado, você pode responder às mudanças em um curto ciclo iterativo.
• No início de uma versão, execute um sprint 0. Isso permite que a equipe, o negócio e a versão do projeto sejam preparados e definam a mentalidade para uma entrega bem-sucedida. Desenhe a estrutura técnica básica e a arquitetura que dará suporte à base para o lançamento. Configure ambientes, contas e ferramentas. Execute picos para entender problemas difíceis ou desconhecidos. Elabore suas histórias de usuário em prontidão para o sprint 1. O Sprint 0 é sobre se preparar.
• Durante uma liberação, continue refinando o backlog. À medida que você entende mais ou aprende algo novo, suas prioridades podem mudar, novos requisitos podem surgir e o que você pensava anteriormente ser um ótimo recurso pode ser removido completamente.
• Não comece um trabalho que não tenha chance de ser concluído em um sprint. Se não puder, divida-o em pedaços menores. E não inicie um novo trabalho quando o trabalho iniciado anteriormente não tiver sido concluído. Você não cria valor iniciando muitas coisas que não podem ser consideradas completas. Além disso, evite a alternância de contexto. Esta é a atividade de iniciar uma tarefa, ficar perturbado, iniciar outra e, na sua forma mais problemática, também não concluir.
• Limite a quantidade de trabalho que está em andamento pela equipe a qualquer momento. Por exemplo, se você tiver três desenvolvedores e um testador, poderá colocar um limite de WIP nos desenvolvedores e no testador.
• Nunca adicione mais trabalho a um sprint depois de planejado. Nunca pare um sprint no meio. As exceções a isso são:
  • Se você teve um desempenho mais rápido do que o esperado, considere pegar a próxima história do topo da lista de pendências, desde que esteja devidamente preparada.
  • Se o sprint estiver com um desempenho tão ruim que não será concluído. Isso geralmente só acontece onde houve uma catástrofe de alguma descrição.
  • Se o objetivo do sprint não puder mais ser suportado devido a mudanças imediatas nas necessidades do negócio.
• Se você cancelar um sprint, faça-o com elegância, reserve um tempo para reorientar e inicie um novo sprint como faria com qualquer outro.
• Perto do final de um lançamento, considere um sprint de lançamento final. Nenhum novo recurso é escrito, alguns bugs podem ser limpos e os preparativos podem ser feitos para realmente lançar uma nova versão do seu produto para seus clientes. Isso não quer dizer que você não possa fazer lançamentos incrementais para o cliente nesse meio tempo - é apenas que esse é um mecanismo de lançamento controlado, medido e sustentável.
• No final de um lançamento, você pode considerar um sprint de uma semana. Neste sprint, você pode trabalhar com a equipe para detalhar algumas novas ideias ou descobrir alguma nova tecnologia. Essas são ótimas ferramentas que beneficiam os negócios e dão à equipe algum espaço de briefing para pensar e ser criativo. Não é para brincar e ainda vai criar valor. Da mesma forma, todos precisam de uma pausa. Tirar férias neste momento ajuda a manter sua cadência e velocidade em boa forma quando você está no meio do lançamento.

Definindo Concluído

Definir o que “feito” realmente significa é muito importante. Existem muitas versões de “concluído” na vida do seu projeto – o que significa estar “concluído” com uma história, lançamento ou projeto inteiro. Tudo se resume ao que você, sua equipe e a empresa considerarão completo no nível certo de qualidade para satisfazer a prontidão para envio.

Para sua equipe, a definição de uma história “concluída” será algo como todo o código completo, revisado por pares, atende aos critérios de aceitação definidos, testado por unidade, UAT'ed e enviado para seu repositório de código. Para permitir a passagem de uma história do designer para o desenvolvedor e para o testador, as definições de “pronto” terão que ser aceitas pela próxima pessoa na cadeia. O proprietário do produto terá expectativas sobre o que isso significa para eles, a fim de liberar o incremento do produto para seus clientes. De qualquer forma, todos devem estar cientes do que significa “feito” e ser uma parte responsável em garantir que seu significado seja cumprido. Defina sua definição de “feito”, comunique-a, concorde com ela e desenvolva-a. Pronto pronto.

Medição Contínua

Se você não pode medi-lo, você não pode gerenciá-lo. O mesmo vale para melhorias. A necessidade de coletar dados empíricos em um projeto Agile é quase tão vital quanto ter sangue correndo nas veias! Como você sabe o que precisa ser gerenciado, corrigido ou melhorado se não houver dados? Bem, simplesmente, você estará confiando na intuição e na suposição infundada, que desmorona rapidamente sob escrutínio. E dependendo de quem está fazendo o escrutínio, este pode ser um lugar bastante desconfortável para se estar. Portanto, desde o início de seu projeto, certifique-se de saber como demonstrar o progresso e por quais medidas os outros verão seu sucesso.

Felizmente, o Agile vem carregado com ferramentas e técnicas úteis. A primeira coisa a fazer é voltar ao Manifesto Ágil, digitar as seguintes palavras em seu processador de texto favorito, ampliá-las para 96pt, imprimir e aplicar na parede para que todos vejam:

Seu maior poder demonstrável na entrega de software é mostrá-lo às pessoas trabalhando, fazendo o que deve ser feito. Isso não apenas deixará seus clientes satisfeitos, mas também fará com que sua equipe ganhe muito respeito e lubrifique as rodas para uma maior adoção por meio dos negócios.

Aqui estão algumas outras ferramentas:

• A reunião diária: Existem algumas variações dessa cerimônia, mas a essência é fazer com que todos os membros da equipe conversem cara a cara: seja breve, focado e leve. Se alguma coisa precisar de uma longa discussão, estacione-a para uma conversa mais longa entre aqueles necessários após a apresentação. Se houver impedimentos, escreva-os como uma história, adicione-os ao seu backlog e resolva-os o mais rápido possível. Qualquer coisa que esteja impedindo sua equipe retarda seu progresso e será demonstrável em velocidade reduzida e software que não atende às expectativas.
• Velocidade: É uma ferramenta histórica. É um pouco como aqueles avisos financeiros que você recebe que dizem que o desempenho passado não é garantia de desempenho futuro. Mas no caso do Agile, esperamos alcançar uma velocidade de equipe que seja bastante suave. É a velocidade que nos permite projetar o desempenho futuro e a confiança em nossos planos. Pode haver influências fora do seu controle que podem diminuir o número de saída de pontos de história para um determinado sprint. Se isso acontecer, você provavelmente poderá se recuperar. Nunca use a velocidade como um bastão para vencer seu time; não lhe renderá nenhum favor. Uma coisa com certeza é que a velocidade será irregular nos primeiros 2 a 4 sprints. Em algum lugar nesse período de tempo, porém, você deve começar a ver consistência e estabilidade. Se sua velocidade oscila de um extremo a outro, você tem um problema que precisa resolver com sua equipe.
• O gráfico de burndown: Agora, essa medida de progresso é espinhosa. Por esse motivo, não dei um link para descobrir mais - você terá que fazer sua própria pesquisa e concordar como equipe e empresa que funciona para você. O motivo de ser espinhoso? Bem, nenhum recurso conta a mesma história! Uma coisa acordada é que ele mostrará, dentro de um sprint ou lançamento, como você está se saindo em relação ao seu timebox. Se mantido diariamente, ele mostrará se você está no caminho certo ou se desviando. Algumas equipes o usam para representar quanto valor resta a ser criado, na maioria das vezes, outros o usam para mostrar quanto trabalho resta a ser concluído. A primeira é uma celebração do sucesso e da geração de valor, a segunda é menos inspiradora e motivadora.
• O gráfico de burnup: Se você precisar mostrar as taxas de conclusão do trabalho, use o gráfico de burndown para isso. Mas usar o gráfico de burnup permite mostrar quanto valor foi criado e quanto valor a mais você planeja criar até o final do sprint. Uma ferramenta muito mais motivadora para uma equipe demonstrar ao negócio o que foi feito (ou pouco, se as coisas não estão indo tão bem...) e o que eles ainda têm em mente. De qualquer forma, use os gráficos para identificar onde o progresso não está sendo rastreado conforme o esperado e procure padrões ou desvios e supere-os para corrigir o problema subjacente o mais rápido possível. Atualize-os diariamente para sprints e uma vez no final de um sprint para gráficos de versão de lançamento.
• Quadros de tarefas: são ótimos radiadores visuais para demonstrar o valor que está sendo criado. Quando atualizados diariamente, ou a qualquer momento do dia, eles mostram imediatamente o progresso que está sendo feito. Se combinados com o Kanban, também são ótimas ferramentas para visualizar fluxos e bloqueios no sistema. Se você puder ver que muito desenvolvimento foi concluído, mas os testes não são tão produtivos, você pode ver o problema acontecendo e responder de forma adequada e rápida.

Outras ferramentas a serem consideradas são valor agregado Agile, tempo de ciclo e diagramas de fluxo cumulativos (CFDs).

Mantenha essas medidas, gráficos e outras ferramentas visíveis, de preferência alto e orgulhoso em uma parede para que todos possam ver. A equipe, as partes interessadas e outras partes interessadas podem ver imediatamente o status de um projeto. É transparente e serve como uma valiosa ferramenta de comunicação. Se você não puder colocar esses artefatos em uma parede, use ferramentas que sejam compartilháveis ​​e colaborativas e certifique-se de que aqueles que desejam acessá-los o tenham.

Melhoria continua

Ao longo de sua vida ágil, procure identificar e aprender onde melhorias podem ser feitas. As lições não são capturadas e aprendidas no final de um projeto. É como passar no teste de direção e tentar fazer sua primeira viagem sem um instrutor. Você saberá o que funciona e o que deve fazer, mas com o tempo você adaptará suas habilidades e capacidades de condução, aprendendo novas técnicas. Você vai até pegar maus hábitos. Procure-os, entenda-os e encontre maneiras de melhorar.

Existem muitas oportunidades para identificar o que não funciona e aplicar soluções. A abordagem integrada para isso no Agile é a retrospectiva. Esta é a principal ferramenta para reflexão e ajuste. No final de cada sprint, reserve um tempo com a equipe para melhorar como o trabalho é feito, como a qualidade é entregue, como a eficiência pode ser maximizada, como o desperdício pode ser minimizado e como a capacidade é aumentada. Ao identificar medidas de melhoria, não fique tentado a resolver todos os seus problemas imediatamente. Identifique os que terão maior impacto e podem ser implementados no próximo sprint. Medir e observar. Se teve o impacto desejado, tranque-o, escreva-o em suas formas de trabalhar e definições de feito. Se não funcionar, pense novamente. Quaisquer lições aprendidas que não forem colocadas no próximo sprint podem ser estacionadas e priorizadas para atenção no próximo sprint.

Adapte o processo. Remova qualquer coisa que não funcione. Remova os impedimentos. Sua maturidade como uma equipe ágil não terá limites se você permitir.

Além do gerenciamento ágil de projetos

É importante saber o que acontece depois que o projeto é entregue. O suporte e a manutenção são fundamentais para garantir que, uma vez que o projeto esteja nas mãos dos clientes, ele permaneça com bom desempenho; o feedback do cliente pode ser levado em consideração em versões futuras; e os problemas dos clientes são tratados adequadamente. Um projeto é um empreendimento único e limitado no tempo. O produto que ele entrega tem vida após a dissolução da equipe do projeto. Certifique-se de que você é capaz de oferecer suporte ao produto quando ele estiver ativo.

Projetos ágeis coexistem com abordagens mais tradicionais. Equilibrando os requisitos de controle orçamentário e visibilidade das partes interessadas com os objetivos ágeis de flexibilidade e capacidade de resposta.

Uma estrutura de governança ou modelo de governança Agile é usado em conjunto com processos Agile padrão, como Scrum. Eles funcionam de duas maneiras específicas:

• Eles fornecem um wrapper para um projeto Agile, esclarecendo os processos que ocorrem fora das iterações de desenvolvimento (sprints). Isso inclui fornecer critérios claros para a conclusão bem-sucedida do início do projeto e validação adequada das decisões e do plano.
• Eles mudam a ênfase de partes específicas do processo Agile padrão e destacam princípios e técnicas particulares que precisam de governança ou suportam a governança.

No mundo em constante mudança de hoje, organizações e empresas desejam adotar uma abordagem mais flexível para entregar projetos e querem se tornar mais ágeis. No entanto, para organizações que entregam projetos e programas, e onde já existem processos formais de gerenciamento de projetos existentes, a informalidade de muitas das abordagens ágeis é assustadora e às vezes é percebida como muito arriscada. Essas organizações focadas em projetos precisam de uma abordagem ágil madura — agilidade dentro do conceito de entrega de projetos — gerenciamento ágil de projetos .

Aprenda e cresça com a adoção do Agile. Faça apenas o que sua equipe se sentir confortável, certifique-se de que sua voz seja ouvida e atue de acordo com suas solicitações. Incentive sua equipe a adotar técnicas novas e mais valiosas quando for a hora certa. Negocie com os negócios e os incentive a entender o que significa ser uma organização Ágil.

Aproveite a viagem.