Transformação Ágil: Passo a Passo

Conforme a agilidade vai devorando o mundo, muitas corporações estão se deparando com a necessidade de uma transformação ágil. Para a maioria, este é um grande desafio, envolvendo muitas mudanças ao longo de vários anos. Se a organização tem sido gerenciada de maneira tradicional, a jornada irá incluir mudanças radicais em atitudes, valores, mindsets, jeitos de pensar e jeitos de interagir com o mundo, ou seja, uma mudança na cultura organizacional.

Transformação Ágil: Passo a Passo é uma série de artigos que será publicada ao longo das próximas semanas que tem como intuito auxiliar quem está pensando ou iniciando este processo. Não tenho como pretensão esgotar este assunto, mas sim dar uma luz ao tema com as minhas experiências e com diversos cases que conheço.

Comentários, dúvidas e sugestões são bem vindas na seção de comentários ao final do artigo.

O mundo corporativo atual

A maioria das corporações atuais não são ágeis. Uma pesquisa recente da Deloitte com mais de 10.000 executivos revelou que menos de 10% deles vêem sua organização como realmente ágil.

Por outro lado, mais de 90% deles diz que “agilidade e colaboração” são fatores críticos para o sucesso da sua empresa. Isto reflete as descobertas da McKinsey & Company de que unidades que usam métodos ágeis dão melhores resultados financeiros do que as tradicionais.

O resultado esperado de uma gestão ágil é claro: a habilidade da empresa de se renovar, adaptar, mudar rapidamente de curso e ser bem sucedida no mundo VUCA em que vivemos, para aproveitar melhor as oportunidades.

No entanto, implementar agilidade é um meio, não o fim. O objetivo é permitir que a organização gere valor em escala com a menor fricção possível, de maneira customizada e incremental, livre de riscos e que as recompensas financeiras sejam equivalentes às obtidas pelas empresas de maior e mais rápido crescimento do planeta: Amazon, Apple, Facebook, Google e Microsoft.

Alguns agilistas não esperam pela alta gestão e começam suas jornadas sem uma autoridade central ou recursos. No entanto, esse não é o melhor jeito de começar, sendo o jeito mais difícil de conseguir todo o conhecimento organizacional e capital social para causar um grande impacto. Quem trabalha ou já trabalhou em corporações sabe do que estou falando: a boa e velha política tem um papel fundamental nesse tipo de iniciativa. Implementações ágeis limitadas a pequenas partes da empresa (como alguns times de desenvolvimento) rapidamente entram em conflito com outras partes da organização que estão se movendo mais devagar e algumas vezes são esmagadas antes que possam tomar maiores proporções.

Não é de se admirar que o progresso de agilidade nos negócios está diretamente relacionado com o nível de liderança dos engajados na transformação ágil. Glória Abreu, Master Coach que foi minha orientadora durante uma de minhas formações, fala que “a melhor estratégia é a do chuveiro, nunca a do bidê”. Quem não sabe ou não lembra, os bidês eram aqueles antigos lavatórios de “baixo pra cima”, para limpeza íntima. Sim, é uma analogia sofrível, a Glória adora fazer o pessoal rir, mas é a mais pura verdade.

Transformações ágeis não são feitas por lobos solitários, você irá precisar de uma matilha, e com machos-alfa…digo, executivos junto. Isso se você não quiser que seja apenas fogo em palha.

Quando iniciei uma de minhas transformações mais bem sucedidas eu tinha o patrocínio do diretor de TI e, mais tarde, do CEO da empresa. Jamais teria tido tanto sucesso sozinho.

Pensando na transformação

Por onde começar? A alta gestão precisa começar considerando como a própria gestão da empresa se relaciona com o mundo da agilidade e quais desafios despontam à frente em uma jornada ágil. Isso irá envolver a absorção de alguns exemplares da vasta literatura sobre este assunto e entender a essência da agilidade.

Isso incluirá descobrir quais princípios ágeis já começaram a enraizar em partes da organização, mesmo sob outros nomes. Embora o movimento Agile seja extremamente abrangente em escopo, a maioria das organizações de todos os tamanhos possuem ao menos alguns focos de agilidade, como um ou outro time. Em 2017, eu liderava um destes times ímpares em um dos bancos gaúchos que trabalhei, responsável pelos Canais Digitais da empresa, por isso que fui “encontrado” e recebi o “chamado” para fazer algo maior.

A alta gestão precisa encontrar esses focos e aprender sobre o progresso que eles fizeram até agora e quais problemas estão enfrentando. A alta gestão precisa celebrar quaisquer sucessos que aconteceram para estabelecer as fundações para o futuro. Os líderes desses esforços iniciais são potenciais aliados e campeões para a jornada ágil que se avizinha.

Citando outro exemplo, quando a alta gestão do Barclays começou a olhar para agilidade em 2014, els descobriram que já existia um movimento alternativo de praticantes ágeis dentro da empresa. Em março de 2015, quando os times de operações e tecnologia anunciaram que se tornar ágeis era uma iniciativa estratégica importante, as muitas ilhas de agilidade dentro da Barclays foram convidadas a saírem das sombras e se tornarem campeões da transformação ágil do banco.

Fazer este estudo também ajuda que a alta gestão aprenda com quaisquer falhas em esforços anteriores antes de lançar uma jornada do tipo na companhia. Por que estes esforços falharam? Quais passos necessitarão ser tomados para prevenir esse tipo de falha recorrente? Quais novos riscos devem ser endereçados?

A organização está preparada?

Os patrocinadores também precisarão entender os riscos e benefícios de iniciar uma transformação ágil exatamente agora.

A escala dessa missão pode ser assustadora. Mas a alternativa – morte corporativa através de falha em adaptar-se continuamente ao mercado – pode ser ainda mais arrepiante. Existe um consenso quase geral de que a única opção real é QUANDO mudar, e não SE devemos mudar.

Também é necessário que seja avaliado o risco do formato de implantação. Se for decidido implementar agilidade como uma “receita de bolo”, forçando as pessoas a adotarem processos ágeis porque os executivos ouviram que funciona na empresa X ou porque eles ouviram isso de alguma consultoria, o risco de resistência institucional aumentará consideravelmente. Em mudanças profundas como agilidade, copiar e colar não funciona. Ao invés disso, a empresa precisa fazer a mudança organicamente de dentro pra fora, para que faça mais sentido. A oposição é inevitável em qualquer mudança organizacional, mas ela será ainda maior se vista como uma iniciativa imposta do topo.

Ou seja, além de considerar quando é o melhor momento para começar a transformação, tem de ser verificado o tamanho e intensidade das batalhas que serão travadas internamente.

Não obstante, tem de ser entendidos os conflitos que possam haver entre os objetivos da agilidade – obsessão em entregar valor ao cliente, por exemplo – e a forma como a empresa funciona hoje. Por exemplo, muitas empresas listadas em bolsa trabalham única e exclusivamente para aumentar o valor das ações e/ou o retorno para acionistas.

A alta gestão também tem de decidir como lidarão com a burocracia tradicional de áreas como orçamento, controladoria, compliance, etc. Embora não seja necessário lutar todas estas batalhas no “dia um” da transformação, a alta gestão precisa saber o que enfrentará à frente, incluindo uma ideia de quando estas batalhas serão travadas.

Algumas empresas decidem, depois de considerar todos os riscos, que não é o momento de iniciar uma transformação agora. Esta decisão não é exatamente ruim, afinal é melhor não ir adiante do que começar uma transformação sem estar 100% comprometido, o que geralmente traz implantações falsas de agilidade, que são ágeis apenas no nome e que geralmente bloqueiam iniciativas futuras de uma real transformação.

Buscando ajuda

Ao ponderar se deve prosseguir, os líderes da transformação podem aprender a partir de outras empresas que estão envolvidas em transformações ágeis. Eles podem visitar empresas que já são bem sucedidas em suas jornadas e aprender sobre práticas-chave que valem a pena ser emuladas e quais que evitar. Eventos podem ser úteis para fazer contatos, embora as apresentações costumem apresentar somente o lado bom destas iniciativas, então foque no networking.

Na prática, o que se vê no mercado é que as jornadas ágeis bem sucedidas estão diretamente ligadas à adoção de um mindset ágil, ao invés de um processo ou metodologia específicos. As visitas realizadas pelo SD Learning Consortium mostraram que algumas empresas estavam implementando todas práticas ágeis “by the book”, mas não estavam obtendo muitos benefícios delas. Por outro lado, algumas empresas estavam demonstrando agilidade nos negócios e obtendo benefícios, mesmo que não estivessem rodando as práticas famosas à risca. O fator de diferenciação entre essas empresas não está nas práticas escolhidas mas no fato das pessoas estarem realmente comprometidas a uma ideia diferente de como o trabalho deveria ser feito. É um jeito diferente de pensar, entender e agir no ambiente de trabalho.

Os executivos tem de aprender que uma transformação ágil não é um projeto ou uma iniciativa, ou um novo processo ou nova estrutura organizacional, mas sim uma jornada sem fim, é empreender com um jeito de pensar que é fundamentalmente diferente da hierarquia top-down de comando e controle típica das empresas do século 20.

Além de tudo isso é importante levar em consideração qual terminologia ágil será encorajada. É comum as empresas descobrirem que existem muitos termos diferentes e confusos no mundo ágil. A empresa precisa decidir quais termos não são interessantes para serem utilizados no seu ambiente, incluindo o próprio termo agilidade, além de todo o vocabulário comum como Scrum, Scrum Master, Lean Startup, Kanban, etc. Pode parecer bobo, mas realmente faz a diferença definir os termos que serão utilizados.

No banco que mencionei antes quisemos descolar de uma série de terminologias e principalmente de um método específico, para evitar ranços e discussões no estilo “sexo dos anjos”. Sendo assim, criamos um framework de agilidade em escala feito sob medida e que era composto por um guarda chuva de práticas definidos por uma comunidade interna de agilistas. Isso nos permitiu por quase dois anos avançar na adoção e transformação, sem os reveses de estar preso a uma única terminologia ou processo, como o proposto pelo SAFe.

No próximo artigo da série, vou continuar o passo a passo. Até lá!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto, onde ensino algumas dinâmicas que você pode fazer com seu time!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Dicas para eventos de Team Building

Team Building no Banco Topázio
Team Building no Banco Topázio

Você sabe o que é Team Building?

Team Building ou Construção de Times é o nome dado a várias atividades com o objetivo de integrar mais as pessoas e melhorar os seus relacionamentos em ambientes profissionais. Basicamente elas ajudam a transformar um grupo de pessoas em um time.

Embora construir times possa ser tão simples quanto organizar churrascos e jogos de futebol, a arte de conduzir dinâmicas específicas para team building aumenta e muito os resultados obtidos quando o assunto é construir times vencedores. Quando são bem executadas, é claro.

Com isso em mente e com a experiência de alguns eventos dedicados a esse assunto no currículo, o artigo de hoje foca em ajudar quem esteja buscando organizar.

Nós vamos falar sobre:

  • Preparação
  • Agenda
  • Local
  • Energyzer e Ice Breaker
  • Objetivo Central
  • Feedback
  • Repertório

Vamos lá!

Preparação

Eu dou aulas e treinamentos profissionalmente desde 2010. Certa vez me perguntaram como que eu conseguia fazer com que meus treinamentos durassem exatamente o tempo combinado, como que eu organizava tudo para que não sobrasse e nem faltasse tempo. A resposta é: planeje para o pior, espere o melhor. E isso começa com a preparação.

Absolutamente todas ocasiões que envolvam diversas pessoas sob sua responsabilidade (afinal, esperam que você conduza tudo com maestria) envolve muita preparação. E um team building não é diferente.

O primeiro passo é entender o objetivo do team building. Claro que, de maneira genérica, sempre podemos citar “construção de times”, mas dependendo do momento do time, você pode querer focar em um ou mais dos objetivos abaixo:

  • fazer as pessoas se conhecerem;
  • definir/redefinir papéis e responsabilidades;
  • aumentar a confiança/segurança/união;
  • aumentar a moral/motivação;
  • aumentar o foco na estratégia/negócio;
  • gerar aprendizados sobre um tópico em ambiente controlado;
  • remover crenças limitantes;
  • ressignificar problemas que o time esteja passando;

Com base no objetivo definido, você irá fazer o seu tema de casa usando os tópicos deste artigo como base. Obviamente nada substitui a sua experiência e minha ideia é apenas lhe ajudar com dicas. Certifique-se não apenas de ler todo este artigo e garantir que fez todo tema de casa citado em cada tópico, mas de realmente colocar o seu coração no team building, pois faz toda a diferença e engaja mais as pessoas nas dinâmicas.

Com base no que você irá fazer, liste todos os materiais necessários (muitas atividades exigem material de papelaria, por exemplo) e compre-os com antecedência. Se o evento durar mais que algumas horas, não esqueça de um pequeno coffee, mesmo que seja apenas água, café preto e biscoitos.

Faça um checklist de tudo que é necessário para o seu team building acontecer com 100% de sucesso. Coloque no papel inclusive o que você espera que gere de resultados no final do dia. Se prepare para imprevistos como ausência de algumas pessoas, estouro de timebox ou dinâmica que acaba antes do que o esperado.

O ritmo de um bom evento de team building é intenso, então prepare-se para poder beber bastante água (eleve uma garrafinha) e usar roupa confortável (principalmente tênis). O evento depende que a sua saúde e disposição estejam 100% e por causa disso, uma outra recomendação que eu deixo para você é pedir ajuda de alguém, não apenas para organizar mas para conduzir no dia.

Se você quiser investir, eu recomendo ter um apito, um passador de slides com laser e um cronômetro de LED. Eu uso os três em meus eventos e faz toda a diferença no profissionalismo e na praticidade.

Agenda

Estruturar uma boa agenda, independente da natureza da ocasião (team building, treinamentos, etc), é como escrever uma boa história. Deve ter início, meio e fim. Deve ter uma introdução que prepare as pessoas para que o vai vir, deve ter o clímax e deve ter um fechamento que maximize a experiência como um todo. Já ouviu falar na Jornada do Herói ou Monomito de Joseph Campbell? Ou então nos 3 Atos de Aristóteles? São estruturas de narrativa para construir boas histórias e podem lhe ajudar com o team building também.

Basicamente construir a agenda consiste em responder às seguintes perguntas:

  • como que vamos explicar o evento?
  • como que vamos começar o evento?
  • como que vamos tirar as pessoas da sua zona de conforto?
  • o que vamos focar neste team building?
  • o que queremos melhorar neste time?
  • teremos alguma pausa para descanso (geralmente no meio)?
  • como que vamos fechar o evento?
  • como que vamos re-energizar as pessoas se for necessário?

Com essas perguntas respondidas, fica bem mais fácil de construir a agenda. Você terá de fazer umas contas de padeiro: pegue o total de tempo que terá disponível e quebre em no mínimo 3 partes: início, meio e fim. Não precisam ser blocos de tamanho idêntico, mas o tempo que você determinar deve ser adequado para a condução de cada atividade, embora muitas atividades sejam “flexíveis”.

Eu costumo colocar esta agenda em um PPT e apresento ela logo no início do evento, para deixar todos cientes e para mostrar que o tempo de execução de cada bloco importa, ou seja, que você vai ser um tanto rígido para que consigam cumprir todos objetivos.

Tempo recomendado?  Você pode combinar atividades de team building simples em todo tipo de evento do seu time, mas se quiser fazer algo dedicado a team building, sugiro no mínimo um turno (manhã ou tarde) inteiro e no máximo um dia inteiro de trabalho. Imersões de mais de um dia são possíveis, mas tendem a diminuir os resultados lá pela metade do segundo dia. Experiência de quem já participou de algumas imersões, de até 4 dias.

Você pode aproveitar a apresentação da agenda para mostrar os combinados do evento também. Não julgar, foco nas dinâmicas, sair do local para atender celular, etc. O que é combinado com antecedência não fica chato de cobrar depois.

Local

Via de regra, sair do local de trabalho é sempre uma boa se você quiser que as pessoas realmente estejam “presentes” no team building.

Falando de infraestrutura, varia muito conforme as dinâmicas que for fazer. Um Marshmallow Challenge, por exemplo, exige mesas. Já um Jogo dos Símbolos, exige cadeiras e um espaço aberto para montar o esquema do jogo. Estude bem as dinâmicas que pretende aplicar para que possa escolher o local adequadamente.

É bom que neste local você tenha um canto para deixar água, café e talvez algo para “beliscar” sempre próximo das pessoas, o que evita que elas se ausentem frequentemente por motivos simples como se hidratar ou se “cafeinar”.

Energyzer e Ice Breaker

Existem dois tipos de dinâmicas que são presença obrigatória em Team Buildings: energyzers e ice breakers.

Os energyzers são para levantar o astral, fazer o pessoal se mexer e geralmente são utilizados quando o dia está meio parado demais, quando sente-se que o ânimo da galera está baixo ou apenas quando se quer “quebrar o padrão”. Qualquer atividade que faça as pessoas levantarem de suas cadeiras e mexerem um pouco (ou muito) o corpo, já resolve. Atividades como Corrente Humana, Campeonato de Jo-Ken-Pô ou dinâmicas com balões já resolvem.

Já os ice breakers possuem o intuito de fazer as pessoas darem risadas, conhecerem umas às outras e criar algum tipo de sinergia entre os participantes, mesmo que seja o primeiro dia deles juntos. Ao contrário dos energyzers que podem ser usados a qualquer momento, ice breakers costumam ser usados no início do dia apenas. Dinâmicas como o Brasão Pessoal, Paulo Pontual o até 2 Verdades 1-Mentira dão conta do recado.

Inclua uma quantidade suficiente destas dinâmicas conforme a duração do seu team building. A sugestão é ter uma de cada, no mínimo, para cada dia de team building. O ice breaker no início da manhã e o energyzer na volta do almoço.

Objetivo Central

Cada team building deve ter um objetivo claro, como já citei lá na preparação. Baseado nesse objetivo você vai construir o núcleo central do evento, geralmente executado após alguma apresentação ou dinâmica menor, que serve de aquecimento.

Para que o objetivo central seja alcançado com sucesso, é importante que a dinâmica escolhida seja poderosa, provoque nos integrantes os sentimentos, situações, conflitos e aprendizados que você deseja para alcançar o objetivo central. Sua escolha é crucial para o sucesso do mesmo.

Com a(s) dinâmica(s) escolhida(s), tenha muita atenção ao briefing que você vai dar, como vai explicar a dinâmica para todo o grupo. Muitas dinâmicas excelentes produzem resultados desastrosos se não forem bem explicadas. Se envolverem algum tipo de competição, pior ainda.

Além do briefing, é importantíssimo o debriefing ao final da dinâmica. Dinâmicas sem aprendizados compartilhados em uma boa sessão de debriefing (boa, não necessariamente longa) acabam virando apenas diversão. E diversão pode até fazer parte do team building, mas não é o objetivo central.

Questione o que eles aprenderam. Como se sentiram. O que fariam de diferente. O que podem fazer de analogias com o que acontece no dia a dia da empresa. O que notaram agora que não tinham notado antes. O seu papel enquanto facilitador aqui é fazer as perguntas certas, para que as pessoas se exponham e todo o grupo ganhe com os aprendizados coletivos.

Marshmallow Challenge
Marshmallow Challenge

Feedback

Pensando em melhorar continuamente (kaizen na veia), é muito importante coletar o feedback dos participantes. Tanto na hora, ao encerrar o evento, quanto mais tarde, com mais calma, via surveys online ou similares.

Nada de mirabolante aqui. Faça um mix de perguntas abertas e fechadas que não tem erro. Agradeça todo tipo de feedback, positivo ou negativo, aprenda com seus erros, considere as sugestões e melhore no próximo.

Repertório

Você deve ter notado que mais de uma vez eu falei nomes de dinâmicas. Talvez você conheça algumas que citei, talvez não. O fato é que ter um bom repertório de dinâmicas é essencial para um agilista (Scrum Master, Agile Coach, etc) ou para qualquer pessoa em função de facilitação, como treinadores, professores, consultores e por aí vai.

O repertório de dinâmicas do facilitador é que nem uma caixa de ferramentas. Quanto mais equipada ela estiver, em mais situações diferentes ela se tornará útil. Abaixo, listarei algumas fontes de inspiração para dinâmicas e ferramentas que uso e se tiver outras sugestões, deixe nos comentários!

Você não precisa saber de cor estas dinâmicas, mas sim saber onde procurar. Pelo menos é a forma como eu trabalho a construção de meus eventos de team building e treinamentos em geral. Espero que esse artigo tenha lhe ajudado a organizar os seus.

Um abraço e até a próxima!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto, onde ensino algumas dinâmicas que você pode fazer com seu time!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Como criar uma Definição de Pronto que funciona?

done

Atualizado em 11/07/19!

Uma Definição de Pronto (Definition of Done, no original) é um artefato Scrum usado para garantir a qualidade do produto desenvolvido a cada iteração (Sprint). Um documento, um contrato entre os membros do Time Scrum e demais envolvidos para que todos entendam o que um produto “pronto” (done) significa.

Mas como criar uma definição de pronto que realmente funcione, que não seja apenas uma burocracia sem sentido no meio de um processo de desenvolvimento que deveria ser ágil?

Vou mostrar algumas ideias aqui no artigo!

Depois, se quiser conhecer mais do meu trabalho com Scrum, dê uma olhada em meu livro sobre o assunto. E se preferir assistir a um vídeo ao invés de ler o artigo, confira abaixo uma amostra gratuita do meu curso online de Scrum e Métodos Ágeis:

Basicamente a definição de pronto é o documento que define o que é considerado, para todos envolvidos no projeto, o que “pronto” (done) significa.

Quais são os requisitos para arrastar um card para a coluna DONE do Kanban? Se um desenvolvedor diz que algo está pronto, o que isso significa? O que o Product Owner espera ver, em termos gerais, durante a Sprint Review?

Essas são algumas perguntas que podem nortear a construção deste documento, que geralmente e um checklist de coisas a serem realizadas/verificada, antes de uma tarefa ser dada como pronta e, como manda o pilar da transparência do Scrum, deve ser visível e conhecido por todos do time. Dica: coloque ao lado do Kanban.

Documento colaborativo

Um primeiro ponto a se considerar é que a criação da definição de pronto deve ser realizada de maneira colaborativa, ou seja, por todos os membros do Time Scrum. Claro, alguns membros possuem mais direitos, e outros mais deveres, como o Time de Desenvolvimento, por exemplo, que será o principal encarregado de implantar os itens da definição de pronto na sua rotina de desenvolvimento. Já o Scrum Master deverá garantir e auxiliar o time na execução do que prega este documento, afinal, ele faz parte do processo Scrum e deve ser respeitado. E por fim, o Product Owner espera que todos os itens dados como prontos e entregues estejam dentro do padrão de qualidade acordado na definição de pronto.

Achou complicado? Não deveria, é mais simples do que parece.

Um bom começo é, durante a primeira Sprint Planning, o time definir a v1 da sua definição de pronto. Pense em uma folha A4 e comece com coisas simples como dizer que “todo item dado como pronto deve ter passado em testes unitários” e depois se aprofunde em itens mais “avançados” como testes de regressão, teste em pares, etc e até mesmo itens difíceis dependendo da disponibilidade do Time Scrum como “aprovar com o Product Owner”. Sim, é bem complicado deste último item ser factível pois geralmente o Product Owner não é (mas deveria ser) tão acessível quanto gostaríamos.

Como tudo no Scrum (pilares da inspeção e adaptação, lembra?), itere e melhore sua definição de pronto a cada Sprint. Pegue o que deu errado na Sprint Review (ela nunca sai 100% como foi planejado pelo Time de Desenvolvimento), aborde na Sprint Retrospective e aplique de maneira aperfeiçoada na próxima Sprint Planning. Comece simples e avance rapidamente. Lembre-se que a função deste artefato é garantir a qualidade, mas lembre-se também de se manter ágil. A dose certa de um e de outro é você que vai descobrir.

E por último, eu sugiro fazer na Sprint Planning pois dependendo dos itens colocados na sua definição de pronto, o tempo para que cada entrega fique pronta pode mudar drasticamente. Tenha a definição de pronto pronta antes de jogar Planning Poker, por exemplo.

Contrato moral

A definição de pronto é algo com o qual o time se compromete a cumprir para garantir a qualidade das entregas. Sendo assim, é um contrato moral. Moral porque estamos falando de pessoas e processos, não há um elemento de software envolvido, lhe cobrando diariamente que cumpra os requisitos do documento, embora o time possa optar por usar algum, como um dos itens da definição, mas nada a substitui.

Sendo um contrato moral e ao mesmo tempo algo colaborativo, o time terá de achar o checklist que agrade a todos, incluindo aqui o Product Owner, que é quem tem a palavra final sobre os itens do Backlog que o Time de Desenvolvimento está trabalhando. Jamais crie uma definição em que não há unanimidade dentro do Time pois caso contrário ela será sabotada, mais cedo ou mais tarde. Caso o time seja inexperiente, como Scrum Master “force” algumas regras pedindo um voto de confiança, explique que esse documento poderá ser alterado na próxima Sprint caso o Time não se adapte.

Mas principalmente: crie um documento que seja útil para garantir a qualidade das entregas que seja executável, exequível. É muito fácil cair na tentação de adicionar dezenas e dezenas de itens de qualidade que jamais serão empregados no projeto como “validar pessoalmente com o cliente final” seja porque não é prático, seja porque realmente e inviável (ex: cliente do outro lado do mundo). Se o Time optar por ferramentas, escolha o menor conjunto delas possível, caso contrário o tempo de desenvolvimento poderá ser enormemente afetado ou a definição enormemente sabotada.

E se você acha que seu Time não dará atenção a um contrato moral, que tipo de time você montou para executar o projeto?

Exemplos e Contra-exemplos

A seguir alguns exemplos de itens que já implementei em Times Scrum que eu liderei como Scrum Master e que sei que funcionam. Obviamente, alguns deles não funcionam dentro de realidades fora das que eu vivenciei, uma vez que a maioria das empresas que trabalhei desenvolviam software para si mesmas (cliente interno). Também obviamente não pegue todos e coloque na sua definição. Use-os como ideias, não tenho intenção alguma definir o que significa “pronto” para o SEU time de desenvolvimento.

Lembre-se que a definição de pronto deve ser clara e não permitir desculpas como “está pronto, só falta testar”…

Toda tarefa de software, para ser considerada pronta, deve…

Ter sido atualizado com o controle de versão e permanecer compilando;

Isto é o mínimo que se espera de algo dado como pronto. Em Times que usem versionamento de código (algum não usa?) o desenvolvedor, após concluir a codificação da tarefa, pegar a última versão do servidor, rodar seus testes (ver abaixo), fazer a fusão (merge) do que for necessário e garantir que, antes de enviar seu código amalgamado ao servidor, que tudo continua compilando. Ponto.

Contra-exemplo: cuidado com o envio de software inacabado (mesmo que algumas features individuais já estejam) para produção. Versionadores de código (como TFS, SVN, Git, etc) possuem recursos como branches e forks que permitem aos desenvolvedores manterem sempre uma versão de produção 100% operacional e livre de bugs enquanto trabalham em outra versão mais instável. Colocar na definição de pronto que o requisito de software desenvolvido esteja rodando em produção é muito perigoso.

Ter passado nos testes unitários com sucesso;

Se você ainda não usa Testes Unitários em sua equipe de desenvolvimento, deveria. A ideia aqui, basicamente, é que, se você testar cada uma das micro-partes que envolvem o seu software (unidades) isoladamente, a probabilidade de que o todo funcione é muito maior, ao mesmo tempo em que lhe obriga a manter um baixo acoplamento do seu software para que ele possa ser testado em micro-pedaços.

Contra-exemplo: colocar TDD na definição de pronto sem que o time tenha experiência com a metodologia. TDD é bem complicado e difícil de ser seguido à risca, mais do que o próprio Scrum.

Ter passado por testes de uso de outro colega da equipe;

Desenvolvedores tendem a ser os piores testadores do mundo quando o assunto é testar suas próprias criações. Certamente temos um gene defeituoso que faz com que auto-sabotemos os testes visando não encontrar bugs. Geralmente outro colega da equipe (chamado cross-testing ou peer-review), que não está preocupado com o trabalho que vai dar corrigir qualquer erro encontrado, é um testador melhor que o desenvolvedor original. E se isso não for suficiente para garantir a qualidade, em casos extremos mude para “teste de uso de quem vai usar a feature”, chamando para o teste de uso o próprio usuário da feature.

Ah, esse teste de uso deve ser em ambiente de homologação. Nada de chamar o colega ou o usuário final pra usar na tua máquina. Isso evita aquela famigerada frase: “na minha máquina funciona!”.

Contra-exemplo: teste de uso automatizado. Isso faz com que você perca a experiência da usabilidade do software. Podem existir testes automatizados, mas eles não devem substituir por completo os testes manuais quando o recurso envolver interface gráfica.

O código encontra-se dentro dos padrões da empresa;

É comum, embora não deveria, desenvolvermos uma v1 de qualquer funcionalidade de maneira meio…porca. O que não é “comum” é que essa v1 seja a versão “pronta” daquele requisito. Refatoração é a chave aqui. Garanta com esse item que o código passe por uma avaliação estrutural para ver se está 100% de acordo com as normas de desenvolvimento da empresa (ex. do Google). Obviamente para que isso funcione, estas normas também devem estar visíveis e serem de conhecimento geral do Time de Desenvolvimento.

Contra-exemplo: empresas que possuam normas de desenvolvimento muito particulares tendem a fracassar ao usar este item na definição de pronto. O que seria algo muito particular? Na minha opinião algo que foge aos padrões de codificações oficiais da linguagem/framework utilizados. Quando escrevo código em Java, uso os padrões da Oracle (Camel Case para métodos, por exemplo). Já quando escrevo código em C#, uso os padrões da Microsoft (Pascal Case para métodos, por exemplo). Isso facilita a vida para todos, inclusive novos funcionários e geralmente a resistência por adotar essa prática é culpa do ego dos veteranos da empresa.

Softwares de apoio e documentação atualizados;

Um último item na definição de pronto deve dar cabo de tarefas burocráticas e pouco interessantes, mas igualmente necessárias, como essas. Todo Time de Desenvolvimento usa algum software para controlar seu progresso (Trello, por exemplo). Mas para garantir que esse software mantenha sua utilidade, ele deve permanecer atualizado com o andamento do projeto e aqui o trabalho do Scrum Master deve ser bem forte, porque o time sempre se “esquece” de atualizar. Cobrar atualizações diárias, sempre antes da Daily Scrum, geralmente resolvem este problema, mesmo antes das tarefas serem dadas como pronto.

O mesmo vale para a documentação do projeto. Eu particularmente sempre gostei de Wikis internos por serem um formato de documentação viva, colaborativa e fácil de usar e manter. Obviamente tem empresas que preferem o bom e velho Word. Encontre o que funciona para você, mas garanta que um mínimo de documentação esteja sempre atualizada e visível, como diagramas da arquitetura, do banco de dados, de implantação, etc.

Contra-exemplo: tão nocivo quanto não ter documentação é tê-la em demasia, então tome cuidado com este item, caso contrário o time pode não se comprometer de verdade, gerando um comprometimento flácido.

Conclusão

Estas foram algumas ideias de como criar ou incrementar a sua definição de pronto. A combinação de uma definição de pronto clara, com objetivos e escopos definidos, tendem a garantir entregas consistentes e de qualidade, levando o projeto ao sucesso.

Associar a sua definição de pronto a acrônimos como DEEP, INVEST e SMART também pode ajudar bastante!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis