Métricas que todo Scrum Master deveria estar olhando

Sempre costumo dizer em meus treinamentos que “ágil não é bagunça”. A prova disso é a disciplina necessária para conseguir pôr em prática as 19 páginas do Scrum Guide, fora a quantidade de estudo que demanda as técnicas complementares como User Stories, Pair Programming, Kanban, Planning Poker e muito mais. Mas algo pouco debatido e muitíssimo importante é a parte de métricas ágeis do time.

Mas porque eu preciso de métricas em times ágeis?

Para que exista um plano de melhoria contínua concreto em execução junto ao time.

Sem métricas o time simplesmente pode rodar o ágil na sua forma mais básica, mas não estará melhorando continuamente o que é um grande risco. Estudiosos dos processos japoneses de manufatura, de onde o Lean surgiu (Toyota) e de onde o Scrum foi baseado, são categóricos em afirmar que todo processo enxuto de produção (logo os processos ágeis também) sofrem deterioração ao longo do tempo se não estão sempre em contínuo esforço de melhoria. Ou seja, ser ágil é uma jornada, não um destino.

Logo, se para me manter ágil devo sempre estar buscando a melhoria contínua e para que possa melhorar continuamente de maneira sustentável e assertiva, preciso de métricas. Isso fica ainda mais evidente quando você como Scrum Master full-time ou Agile Coach (meu caso) deve estar olhando para mais de um time ao mesmo tempo, mas não subestime o poder de ter métricas sob constante vigilância mesmo em times pequenos e avulsos.

Velocidade (Velocity)

Essa é a métrica mais básica que todo Scrum Master tem de mensurar. Qual a capacidade de entrega do seu time?

Não importa qual a unidade de medida que você utilizar: número de cards, Story Points, T-Shirt Size (número de itens P, M ou G que o time entrega por Sprint) ou horas. Você tem de conhecer o passo do seu time para que seja possível fazer ajustes quando há variação pra menos ou quando se quer acelerar o time. Além disso, ter a métrica de velocidade auxilia na previsibilidade do roadmap do Product Owner, obviamente sempre respeitando o bom senso e a máxima de que “a única constante em software é a mudança”.

Como medir a velocidade do time? Os métodos ágeis são empíricos, logo, baseiam-se em experiência prática passada para poder tirar conclusões sobre o futuro próximo. Sendo assim, o único jeito de saber a velocidade do time é fazendo com que ele rode de uma a três sprints, de preferência com a mesma formação, para ter uma média e poder descobrir essa métrica.

Muito importante ressaltar que a velocidade de um time é reflexo de todo um contexto que envolve: tecnologia, perfis de pessoas, experiência do time, quanto tempo trabalham juntos, o quanto conhecem do projeto, etc. Qualquer alteração nesse sensível contexto irá provocar oscilações na velocidade.

Mais importante ainda é ressaltar que jamais você deve comparar a velocidade de dois times. Medimos a velocidade de um time para compará-lo sempre com ele mesmo, jamais com os outros.

Na ferramenta Azure Devops a velocidade (Velocity) é calculada automaticamente no Product Backlog, desde que você use o campo Effort dos Product Backlog Items/User Stories (dependendo do seu template) corretamente. Você encontra esta informação no canto superior direito da tela, na visão de Product Backlog. Também é possível adicionar um widget Velocity no dashboard do time.

Velocity
Velocity

Tempo por Lead e Tempo por Ciclo (Lead Time e Cycle Time)

Lead time na área de supply chain é o tempo total de um pedido ser feito por um cliente até o mesmo ser entregue a ele e a ideia aqui não é diferente. É uma métrica que geralmente está associada ao uso do Kanban e dá um pouco mais de trabalho para ser medida dependendo das ferramentas que você tem à disposição. Basicamente o Lead Time é o tempo que leva de uma tarefa que foi criada no backlog até ela chegar no estado DONE ou seja, o tempo total de vida de um item de backlog (não necessariamente de desenvolvimento).

Já o Cycle Time é o tempo de desenvolvimento de uma atividade, ou seja, desde quando ela entrou em DOING/In Progress, até ela chegar em DONE, sendo sempre menor ou igual ao Lead Time.

Ambas métricas vão te dar um número de horas ou dias para finalizar cada atividade, sendo que para o cliente, o que importa é o Lead Time (total, desde o pedido).

Times ágeis devem buscar quebrar seus itens de backlog em pedaços executáveis dentro de um espaço de tempo razoável. Obviamente razoável varia de time para time, mas algumas boas práticas recomendam que o lead time de uma história não seja maior do que uma sprint. Também podemos incluir nas boas práticas que o lead time de uma tarefa (lembrando que uma história pode desmembrar em várias tarefas) não deveria levar mais do que um ou dois dias.

Assim, cravando alguns objetivos desejáveis ou apenas medindo o histórico vs situação atual, podemos analisar itens que possuam variações grosseiras de lead time e de cycle time e ajustar onde que está o problema no seu pipeline de desenvolvimento. Esse processo de melhoria contínua do Lead/Cycle Time é tema do famoso Improvement Kata da Toyota (onde o Cycle Time é chamado de Takt Time), onde objetivando chegar em uma visão ideal, partimos de uma condição atual para condições-alvo mais próximas rumo ao objetivo, aplicando PDCA a cada ciclo para melhoria.

No Azure DevOps é possível ver todo o ciclo de vida de uma tarefa indo na aba History dela, como no exemplo abaixo.

Task History
Task History

Analisando o tempo entre a troca de estados da tarefa é possível perceber que o gargalo dela foi no Code Review, que demorou 15 dias para acontecer, contra apenas 2 dias de desenvolvimento e 2 de espera para entrar em desenvolvimento. Assim, temos um Lead Time de 17 dias e um Cycle Time de 16 dias. É óbvio o problema aqui e onde devemos colocar nosso esforços, muito diferente do que apenas tentar melhorar a velocidade de codificação do programador, quando não é nisso que reside o problema.

Obviamente que analisar tarefa por tarefa não é uma tarefa muito prática e por isso é recomendada a instalação da extensão de Analytics no Azure DevOps, para ter à disposição aos widgets de Lead Time e Cycle Time que podem lhe ajudar muito nos seus dashboards. Apenas analise individualmente as atividades que tenham fugido grosseiramente do Lead/Cycle Time e que possam ser a razão de suas sprints não estarem rolando tão bem.

Lead Time
Lead Time

Como o Lead Time não é tão bem rastreado pelos times quanto o Cycle Time (que é bem representado nas colunas do Kanban), recomenda-se para tarefas cujo lead time não tenha sido satisfatório o desenho do processo de pré-jogo (antes de entrar pra sprint) com as estimativas de tempo em cada etapa para entender onde está o gargalo. É bem comum os times se focarem em otimizar o cycle time quando muitas vezes o gargalo é antes disso, em processos de análise, especificação, etc.

O desenho abaixo que mostra um processo de pedido de software até a sua entrega na nuvem mostra como muitas vezes o maior tempo é o de espera entre cada uma das etapas do desenvolvimento, em especial (mas não somente) como acontece no modelo waterfall.

Processo de Exemplo
Processo de Exemplo

Neste processo, enquanto que o desenvolvimento levou 3h, o teste 30min e o deploy 4h, o Lead Time da demanda custou um mês de espera pra empresa. O que você faria neste caso, pediria para os desenvolvedores programarem mais rápido? Você investiria pesado em um sistema de deploy automatizado?

Lead/Cycle Time Manual

Caso você não tenha à disposição uma ferramenta como o Azure DevOps ou o Jira Software e tenha de cuidar manualmente do Lead/Cycle Time do time, não desista, é possível e você tem duas maneiras de fazer isso.

Primeiro, a maneira 100% manual, no papel. Neste modo, você vai precisar imprimir um Lead Time Control Chart, como na imagem abaixo (no final do artigo você encontra para baixar), onde você tem as entregas no eixo x (horizontal) e o Lead Time (em dias) de cada entrega no eixo y (vertical).

Lead Time Control Chart
Lead Time Control Chart

A cada entrega DONE realizada, você avança na linha horizontal (é apenas uma sequência linear de entregas, busque a próxima linha vazia) e sobe na vertical buscando o número de dias que demorou para entregar esta demanda, fazendo um ponto preto na intersecção entre a linha dos dias e a linha da entrega, como mostra a imagem abaixo, onde uma demanda qualquer foi entregue em 4 dias.

Lead Time Preenchido
Lead Time Preenchido

Após várias entregas realizadas, você vai ter uma matriz de dispersão cheia de pontinhos, mostrando a tendência de tempo das entregas. O próximo passo é calcular a previsibilidade do time considerando o histórico do mesmo.

Para fazer isso, descubra o maior lead time do time, que na imagem abaixo é 9 dias e trace uma linha imaginária no lead time imediatamente inferior (8). O número de dias na linha de corte é o tempo médio (ponderado) de entrega do time.

Linha de Corte
Linha de Corte

Mas Luiz, teve entrega que demorou mais de 8 dias e entrega que demorou apenas 3 dias. É certo dizer que o time leva 8 dias?

Sim, mas com uma chance, uma probabilidade disso acontecer. Para calcular a confiança nessa previsão em %, conte quantos itens foram entregas na linha de corte e abaixo. Na imagem, temos 7 itens.

Depois, divida esse número de itens (7) pelo total de itens entregues, que nesse caso é 8 (tem apenas um item acima da linha de corte), o que nos dá 0,87 o que significa 87% de confiança que esse time entrega uma demanda comum em até 8 dias. Bacana, não?

Mas e se o time tiver de entregar mais rápido, qual a chance de ser bem sucedido? Movendo a linha imaginária para baixo, no lead time exigido para esta entrega, basta refazer o cálculo considerando o novo posicionamento da linha imaginária. Por exemplo, em 3 dias temos 12% de probabilidade de entregar uma demanda comum ou 50% de chances se tivermos apenas 7 dias para trabalhar na demanda.

Ao invés de usar o lead time control chart impresso, outra opção que você possui é registrar o lead das entregas no Excel ou Google Sheets e depois fazer só o cálculo manual da probabilidade (que eu não sei fazer automaticamente no Excel). Abaixo você confere uma imagem de como fica essa ferramenta, que eu disponibilizo para download no final deste artigo.

Lead Time no Sheets
Lead Time no Sheets

Nela, a coluna Lead Time calcula Fim – Início +1 (para arredondar para cima, tendo como 1 dia o lead time mínimo de qualquer demanda) e o gráfico gerado é uma matriz de dispersão, considerando a coluna Demanda como eixo x e a coluna Lead Time como eixo y.

Bem simples e prático. Na imagem acima, este time entrega em 5 dias com 70% de confiança.

Uma última dica: o time deve buscar uma confiabilidade de 85% nas suas entregas. Se estiver mais alto que isso, diminua a linha de corte. Se estiver abaixo disse, suba a linha de corte ou espere ter mais demandas entregue para o histórico fornecer uma boa amostragem para cálculo.

Outras métricas

Algumas literaturas consideram o Burndown Chart como uma métrica também,  assim como Burnup, embora eu não irei incluir aqui para não chover no molhado. Você também pode querer medir a quantidade de incidentes que entram por sprint e agrupar as razões do mesmo, para fazer uma sustentação adequada e assertiva no seu time (chega de paliativos!).

Dependendo do background do Scrum Master, outras métricas podem ser incluídas como Test Coverage e Bugs por Sprint. Se o time for responsável por manter a operação do produto que desenvolvem, métricas de disponibilidade como Uptime/Downtime podem ser adicionadas, mas sinceramente eu não acredito que tais métricas sejam responsabilidade do Scrum Master, mas sim do Time de Desenvolvimento, a menos que o Scrum Master também vista o chapéu de líder técnico do time, o que já fiz muito no passado.

Algumas dessas métricas são facilmente coletadas e apresentadas em dashboards caso você use o Visual Studio Online, seja com os widgets ou com as queries. Caso você seja mais oldschool e use quadros físicos, a coleta e apresentação terá de ser manual, o que pode desmotivar um pouco a prática constante. Nestes casos eu recomendaria uma apuração mais sazonal, principalmente quando as retrospectivas mostram que algo poderia estar indo melhor na produtividade do time.

E você, quais métricas usa em seus times ágeis?

* 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

Carreira em Agilidade

Quando comecei com agilidade, em agosto de 2010 (curiosamente na mesma época em que a primeira versão do Scrum Guide foi lançado), não se falava em nada próximo a “carreira com agilidade”. Todos éramos analistas (meu caso), desenvolvedores, gerentes de projeto, etc e que havíamos nos interessado por métodos ágeis de desenvolvimento de software. Geralmente dividíamos nossas horas estudando entre nosso cargo “de verdade” e nosso recém adquirido papel: Product Owner ou Scrum Master, dependendo da sua função na época.

Era um movimento um tanto hippie, uma contra cultura dentro da engenharia de software, da análise de requisitos e da gestão de projetos, temas sempre tão rígidos e geralmente associados a “pessoas de sucesso” usando terno e gravata.

Mas esses tempos passaram.

Agilidade deixou de ser um tema indie e se tornou mainstream (assim como a cultura nerd, aliás). Com a adesão de cada vez mais empresas ao “agile way” de trabalhar, a demanda por profissionais especializados em atividades como Product Ownership e Scrum Mastering cresceu muito, gerando até mesmo um terceiro nicho de atuação mais estratégico ligado a Agile Coaching. O fato é: hoje você não tem apenas a opção de seguir uma carreira em papéis ágeis como o próprio mercado está demandando isso. Existem vagas especificamente com estas descrições e o “passe” desses profissionais está extremamente valorizado diante do cenário econômico e tecnológico que tem obrigado as empresas a mudar seus paradigmas de trabalho para algo cada vez mais próximo a startups digitais.

Quer você goste ou não do que agilidade se tornou, para mim e para muitos outros profissionais apaixonados pelo tema, poder “viver de agilidade” é algo indescritivelmente bom. Não apenas pela profissão ou pelo tema em si, mas porque realmente acreditamos que é possível criar times de alta performance, entregar valor para os clientes e de quebra aumentar a eficiência das empresas. Tudo isso às claras, com aval da alta gestão, sendo contratado para fazer isso ao invés de ter de ficar forçando a barra com seu gestor para conseguir fazer o setor usar um kanban.

No artigo de hoje quero falar sobre a minha percepção do mercado para Scrum Masters, Product Owners e Agile Coaches, fechando com dicas de como eu me mantenho atualizado e competitivo neste mercado.

Este é um artigo extenso, sugiro usar os links abaixo para avançar para o que mais lhe interessa (cada tópico está cheio de referências também):

Você também pode assistir parte desse conteúdo no vídeo abaixo, presente no meu canal do Youtube:

O mercado para Scrum Master

Ok, talvez você não goste deste nome. Talvez você não goste de Scrum.

Pense neste papel como o agilista da linha de frente, da operação, que toca o dia a dia com os times para ajudá-los a melhorar continuamente e realizar entregas com fluidez (sem impedimentos). O Scrum é o framework ágil mais utilizado no mundo (e suas variações, obviamente), então não sinta-se ofendido quando eu chamar um agilista padrão de Scrum Master, é apenas o nome mais comum para designar este papel nas empresas que usam métodos ágeis e é justamente o nome mais reconhecido no mercado para esta função.

Existem correntes defendendo nomes como Agile Master ou querendo designar que todo agilista é um Agile Coach, mas são movimentos pequenos e na grande maioria das vagas você ainda verá Scrum Master por algum tempo, mesmo que a empresa não rode somente Scrum. Sobre Agile Coach x Scrum Master, falarei disso mais tarde.

Fugindo das nomenclaturas, o Scrum Master é de longe o papel com o maior número de vagas. Todos já ouviram falar de histórias em que a empresa X adotou o framework Scrum e melhorou suas entregas, sua qualidade, o engajamento das pessoas, etc. Isso faz com que naturalmente se busque profissionais que em tese consigam o mesmo feito. Iniciar uma transformação ágil em pequena escala usando apenas Scrum Masters não é apenas perfeitamente possível como é a prática mais difundida de transformação ágil no mundo, segundo a pesquisa State of Scrum de 2017-2018 que relata como sendo eles os principais líderes de transformações apenas atrás da alta gestão das empresas.

Para se dar bem nesta carreira é importante ter domínio de no mínimo um framework básico como Scrum, Kanban ou XP, e conhecer o básico deles três. Embora este seja um tema um tanto polêmico, é inegável que ter certificações em métodos ágeis faz uma diferença enorme em seleção de currículos. Ter certificações em métodos ágeis não garante sua experiência na aplicação prática dos mesmos, mas garante o conhecimento essencial e atesta o seu real interesse nessa carreira, uma vez que está investindo em certificados específicos para ela. Quando o assunto é prática, vale citar as experiências nos times em que pôde atuar nessa posição, mesmo que part-time.

Aqui você confere algumas vagas para Scrum Master ao redor do mundo e seus salários. No vídeo abaixo, falo dessa carreira também, extraído do meu curso de Scrum e Métodos Ágeis:

O mercado para Product Owner

Este não é um cargo tão popular quanto Scrum Master, mas que vem crescendo em força nos últimos anos.

Muitas empresas possuem outras funções mais tradicionais da área de produtos e/ou projetos que por vezes incorpora alguns elementos de Product Ownership do Scrum no seu dia a dia. Os exemplos mais clássicos são os Product Owners que na verdade são Gerentes de Projeto (Project Managers) ou Analistas de Negócio (Business Analysts) utilizando métodos ágeis (eles costumam representar o cliente dentro de empresas de software) ou o caso dos Gerentes de Produto (Product Managers), figuras tradicionalmente detentoras da responsabilidade e ownership de um ou mais produtos da empresa que acabam se apropriando de práticas ágeis.

Assim como no caso Scrum Master x Agile Coach, não é incomum em grandes organizações existir uma diferença entre os papéis de Product Owner e Product Manager. Não é incomum o Product Owner ser a linha de frente do desenvolvimento de produtos, derivando a estratégia de um Product Manager em um plano tático a ser executado com um time de desenvolvimento. O guru Roman Pichler fala muito sobre isso nos materiais que ele escreve e vale dar uma lida se o assunto Product Ownership x Product Management lhe interessa.

Independente do nome e/ou múltiplos papéis para produtos, é fato que a divisão em departamentos completamente isolados que se tinha no passado deve cair em desuso pois não faz mais sentido. TI e Negócios tem que trabalhar o mais próximo possível e o jeito que as empresas vem encontrando para fazer isso acontecer é ter um representante de negócio em cada um dos times, geralmente associando a esse profissional o papel ou até o cargo de Product Owner, em alusão à essa mesma figura presente no Scrum Guide.

Quer você seja um Product Owner literal ou um analista com uma pegada agile, para se dar bem como Product Owner você tem que ir além da análise de requisitos que fazíamos no passado. Você tem de realmente entender o negócio, ser propositivo, trabalhar com uma cultura de desenvolvimento de produtos e não de projetos. Você tem de ter uma capacidade muito acima da média de negociação e gestão de expectativas dos stakeholders. Aqui, apesar de também existirem certificações e cursos, nada supera os produtos que você participou da construção. Bons cases de Product Owners são aqueles em que produtos do zero (se tiver sido uma proposição do P.O. melhor ainda) foram criados com um baixo custo e que deram um excelente retorno. São aqueles cases em que o Product Owner era responsável pela gestão de um produto “carro-chefe” de uma empresa, liderando um ou mais times de desenvolvimento para sua construção.

Ter certificados como Product Owner até podem ajudar, mas muito menos do que no caso do Scrum Master e ao invés dominar frameworks ágeis específicos, é muito mais vantagem você dominar técnicas como Lean Startup, Lean Inception e Business Model Canvas (e suas variações).

Aqui você confere algumas vagas para Product Owner ao redor do mundo e seus salários.

O mercado para Agile Coach

Um primeiro ponto para deixar claro é que, independente de hoje eu ser um Agile Coach, eu fui Scrum master durante muitos anos e venho estudando este mercado há muitos anos também. Minha percepção é que, independente do que você acredite em termos de hierarquia, senioridade, agilidade, etc temos como fato que, para o mercado, um Agile Coach não é apenas um agilista que usa vários frameworks como algumas pessoas falam. Ele é visto e procurado, pelas grandes empresas principalmente, como um agilista muito sênior, que já viu e aplicou muita coisa, de literaturas diferentes, passou por várias empresas, tem certificações variadas e já foi Scrum Master por alguns anos, possuindo uma visão mais holística e sistêmica da agilidade em escala (i.e. aplicada a muitos times que precisam coexistir e colaborar para fazer grandes entregas).

Ou seja, embora você possa contratar Agile Coaches para colocar na linha de frente, com cada um dos seus times, este talvez não seja o melhor uso que você possa fazer deste profissional, a menos que sejam vários times ou times muito complexos (em termos de sizing, entregas, desafios, etc). Via de regra, contrata-se Agile Coaches para: formar novos agilistas e estruturar grandes transformações em empresas. Em empresas em que se tenha a necessidade de Scrum Masters e Agile Coaches (ambos papéis), os primeiros estarão na operação, enquanto que os segundos estarão na estratégia ou no âmbito tático, dependendo da importância da agilidade para a empresa.

Em empresas muito grandes e muito complexas, é natural que ainda exista um terceiro papel de agilista, o de Enterprise Agile Coach ou simplesmente Enterprise Coach, uma figura mais executiva e estratégica para o qual os demais agilistas respondem administrativamente inclusive.

O que quero dizer com tudo isso é: se você não tem uma vasta experiência como Scrum Master, não domina pelo menos dois ou três frameworks, não tem algumas certificações que atestem o seu conhecimento e compromisso com essa carreira, não diga que é um Agile Coach apenas porque não quer ser chamado de Scrum Master. Fica feio.

Isso é igual programador junior falando que é engenheiro de software. É pior que analista de sistemas dizendo que é arquiteto de software. Fundador de microempresa se chamando de CEO (essa eu já fiz, hahaha). Sem desmerecer ninguém, mas estou te ajudando a não passar vergonha frente a um mercado cada vez mais exigente.

Atualmente existe uma corrente que tem defendido fortemente que o Coach no nome deve ser respeitado e seguido, que o Agile Coach deve realmente ser um coach, ter prática com o método de coaching profissional até para conseguir fazer transformações mais profundas nas pessoas. Não consigo afirmar que isso está de fato sendo exigido pois é minha primeira experiência como Agile Coach, mas te garanto que ajuda e muito no dia a dia do trabalho desse profissional. Fazer uma boa formação em coach profissional pode te ajudar não apenas no âmbito profissional, mas no pessoal também. Logo, se vai seguir carreira como coach ágil, começar sendo um bom coach faz bastante sentido.

E por fim, tenha cases. Grande parte das contratações de agile coaches são para liderar transformações ágeis. E se você até hoje nunca transformou nada (nem um punhado qualquer de times), como confiar que você conseguirá dar conta deste desafio? Ter passado por momentos difíceis profissionalmente, grandes realizações com times, implantações de novos processos em múltiplos times, superado desafios de grandes entregas, etc são todos atestados de experiência prática, principalmente se feitos sob o papel de Scrum Master, que seria a porta de entrada para esta carreira.

Vale ressaltar também que, diferente de Scrum Master e Product Owner, que às vezes são apenas papéis de pessoas em outros cargos (menos que no passado, mas ainda existente), Agile Coach é na maioria dos casos um cargo dentro das empresas, raramente sendo associado como um papel complementar de outro cargo, embora não seja impossível. Já ví líderes de inovação usando o chapéu de Agile Coach e já vi, em startups, Gerentes de Produto atuando como Agile Coach.

Caso se interesse por essa carreira em específico, eu tenho esse outro artigo ensinando como se tornar um Agile Coach e aqui você confere algumas vagas para Agile Coach ao redor do mundo e seus salários.

Como se manter competitivo no mercado de agilidade

Acredito que eu tenha obtido uma competitividade bem interessante de uns anos pra cá. Hoje é bem comum eu receber ofertas de trabalho de grandes empresas dentro e fora do meu estado para conduzir transformações semelhantes à que estou liderando no Agibank (na verdade eu sempre recebi muitas ofertas, mas mais pelas minhas skills como analista/programador).

Esse resultado positivo que venho tendo é fruto de uma série de iniciativas conscientes de minha parte uma vez que não trabalho contando com “sorte”. A ideia deste tópico é lhe dar algumas ideias de como você, aspirante a Product Owner, Scrum Master ou Agile Coach pode fazer para se tornar mais competitivo em um mercado que tende a ficar cada vez mais concorrido e ao mesmo tempo mais convidativo.

Primeiro, nutra sua presença online, seu marketing pessoal na Internet. Ter um perfil no LinkedIn não é mais opcional e você ainda tem de garantir que ele seja ativo em temas relevantes para a função que procura. Outros canais que você possa usar com cunho profissional, como páginas no Facebook, também podem ser usados com o mesmo propósito e se conseguir escrever regularmente para algum portal ou seu próprio blog, melhor ainda. Curiosamente as pessoas tendem a atribuir uma imagem de experts à pessoas que escrevem sobre algum assunto.

Segundo, falando de perfil ativo, é importante que você compartilhe conteúdos (seus ou de outros autores) que tenham relevância como a função pretendida. É um ganho duplo: ao estudar sobre agilidade e compartilhar o que estuda, você passa também a imagem de estudioso naquele assunto. Você ganha o conhecimento e ainda faz o marketing pessoal. Recomendo artigos do Serious Scrum, Paulo Caroli, Roman Pichler, David Anderson entre outros autores (como eu).

Terceiro, quem não é visto não é lembrado. Você tem de se organizar, de alguma forma, para ir a eventos, cursos, conferências, meetups, etc. Aqui novamente é uma relação de ganho duplo uma vez que você estará adquirindo mais conhecimento e estará fazendo networking. E networking é a chave para as melhores oportunidades, além de facilitar a entrada nas empresas que você deseja trabalhar. O networking entre os agilistas é muito poderoso para vagas de emprego, saber de outras oportunidades como cursos e conseguir até novos negócios como parcerias e prestação de serviços. As comunidades que participo são muito receptivas e sempre aprendo muito com elas.

Recomendo o meetup.com para meetups de agilidade e o Sympla como plataforma para achar cursos pagos. Falando de eventos, o TDC roda algumas capitais do país e sempre possui trilhas muito boas de agilidade, além dos eventos imensos como Agile Trends e Agile Brazil, que infelizmente estão cada vez mais caros e estão deixando de se tornar uma opção para novos entrantes nessa carreira.

E quarto, na mesma linha do marketing pessoal, se você está buscando uma posição de senioridade em um papel ágil (como no papel de Agile Coach, por exemplo), você tem de ser reconhecido como tal. Ao invés de simplesmente participar dos eventos, organize ou palestre em um deles. Ao invés de simplesmente ler artigos sobre agilidade no Medium, crie o seu blog de agilidade lá. Posicione-se como referência ao invés de apenas seguir referências.

Isso não quer dizer “pare de estudar”, longe disso, mas coloque-se em uma posição de quem sabe o que está falando e fazendo, tomando uma atitude mais ativa na comunidade ágil ao invés da tradicional passiva, comunique-se com a comunidade em duas vias. Sabia que escrever um livro não é um bicho de sete cabeças?

Claro que nada disso pára em pé sozinho se você não for um bom profissional, mas vou entrar no óbvio, ok?

Espero que este artigo te ajude a trilhar uma bela carreira com agilidade. Ficou com alguma dúvida? Deixe nos comentários!

* 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

Os 12 princípios do manifesto ágil e dinâmicas

Agilidade, no contexto de desenvolvimento de software, é algo difícil de definir e de mensurar. No entanto, é unânime que sua formalização e, provavelmente suas principais características, estão documentadas no Manifesto Ágil, o documento criado e assinado em 2001 por 17 das maiores autoridades em desenvolvimento de software mundial à época.

Embora existam correntes modernas tentando redefinir o que é agilidade ou até desacreditá-lo enquanto ideal a ser buscado, ainda acredito humildemente que tem muita sabedoria em suas palavras e que ainda é um caminho muito válido a ser perseguido por times de desenvolvimento.

No artigo de hoje, gostaria de dar uma breve visão sobre cada um dos 12 princípios do software ágil, parte fundamental do Manifesto, e dar algumas ideias de dinâmicas envolvendo os mesmos, para ajudar a educar e melhorar times em torno do mesmo. No final do artigo você pode baixar um baralho com os mesmos, para ajudar nas dinâmicas.

Princípios Ágeis
Princípios Ágeis

#1 – Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

Gerar valor para o cliente é o primeiro princípio e não é à toa. Substitua a palavra software pelo produto do seu trabalho (independente do setor) e você tem o clássico posicionamento de “cliente no centro da empresa”. Todo time deveria se focar em entregar valor continuamente (e não apenas uma vez no final do projeto) e de maneira adiantada (o que gera mais valor, primeiro).

#2 – Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

Se tem uma expressão que pode ser usada como sinônimo para agilidade é “reagir a mudanças”. O calcanhar de Aquiles do waterfall sempre foi justamente sua inflexibilidade: uma vez fechado escopo, prazo e custo (os três pilares clássicos da gestão de projeto), é só ladeira abaixo. Times ágeis tentam manter um lead time baixo e ciclos curtos de entregas (sprints, por exemplo) justamente para poder aceitar mudanças de requisitos de maneira mais fácil, com menos atrito.

#3 – Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.

Em uma era de DevOps e Entrega Contínua (CD) esse princípio pode soar ultrapassado se levado ao pé da letra. No entanto, mude o trecho “software funcionando” por “valor ao cliente” e novamente nota-se que não “chegamos lá”. Apesar da engenharia de software moderna lhe permitir entregar software todos os dias e até várias vezes no mesmo dia, entregar valor pro cliente em ciclos curtos não é assim tão simples e é algo que os times devem estar sempre atentos.

#4 – Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

Esse princípio originou uma série de papéis novos em times ágeis como o Product Owner no Scrum, o Service Request Manager no Kanban e o Cliente no Extreme Programming. Desde muito tempo notou-se que um dos maiores gaps na entrega dos projetos era o popular “telefone sem fio” e que uma maneira de atacar este problema diretamente era alocando um profissional de negócio dentro do time ágil, para trabalhar requisitos e dúvidas diariamente com os desenvolvedores.

#5 – Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

Esse é um dos mantras do Management 3.0, popular framework de gestão ágil. O criador do método alega que não se deve fazer gestão de pessoas, mas gestão do entorno destas pessoas, garantindo um bom ambiente, suporte e motivação, para que as pessoas consigam se auto-organizar e realizar o trabalho necessário. Um apelo contra o microgerenciamento, uma prática que sempre destruiu mais valor do que gerou.

#6 – O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

Tido como um princípio polêmico em uma era de home office, times distribuídos e trabalho remoto, parece insanidade forçar todo mundo a conversar cara a cara, certo? Errado. Pelo menos no meu entendimento. Lembra do primeiro valor do Manifesto? Indivíduos e interações entre eles mais que processos e ferramentas! Incentivar e perseguir conversas diretas e o mais próximas possível de “conversa cara a cara” sempre será algo eficiente e sadio. E sim, você pode usar Skype pra isso se a outra pessoa está há kilômetros de distância…

#7 – Software funcional é a medida primária de progresso.

Novamente, troque “software funcional” por “entrega de valor” e você tem um princípio à prova de métricas de vaidade. A principal métrica de sucesso de qualquer time deve ser o quanto de valor ele entrega para a empresa. Afinal, de nada adianta um lead time baixo se o time entrega rapidamente software inútil pro cliente, não é mesmo? Um mau condutor em um carro veloz ainda será um mau condutor. Seja criativo, existem muitas maneiras de mensurar valor.

#8 – Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

Esse princípio vem lá do pensamento Lean, onde é chamado de Muri (sobrecarga). Para garantir a entrega contínua de valor, o time deve ser capaz de trabalhar constantemente em um ritmo saudável. Eventuais picos de trabalho acontecem nas melhores empresas, mas salas de guerra todos os dias são uma exclusividade das piores.

#9 – Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

Esse princípio é contra-intuitivo para alguns gerentes mas é uma máxima do desenvolvimento de software e até mesmo do pensamento Lean: faça uma coisa bem feita na primeira vez, e não será necessário trabalhar de novo nesse mesmo item tão cedo. Débito técnico, ferramental ruim, ausência de pipeline automatizado e os famigerados bugs acabam com a capacidade, velocidade e moral de times técnicos. Não deixe isso acontecer.

#10 – Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

Você já ouviu falar no Princípio de Pareto? O famoso 80/20 é aplicado a muitas coisas e em software não poderia ser diferente. 20% das features de um software geram 80% do seu valor para o usuário e/ou são usados em 80% das vezes. Então porque perder tempo fazendo 100% do software? Ou melhor, porque você primeiro não faz os 20% que importam?

#11 – As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

Dê uma missão clara e com propósito a um time de especialistas e deixe-os trabalhar. Bons times técnicos buscam a excelência por natureza e você não precisa dizê-los como fazer o seu trabalho.  Obviamente, quanto mais distante de um time maduro você tiver, mais próximo você vai ter de gerenciá-los e isso vale pra tudo, não apenas arquitetura, requisito e design.

#12 – Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Melhoria contínua é um processo, um método e se você quer ter resultados reais, precisa se dedicar a ela. Como dito no Toyota Kata, todo processo tende a se tornar ineficiente com o passar do tempo e temos de buscar a melhoria contínua se quisermos nos manter competitivos no mercado.

Dinâmicas com os princípios ágeis

Existem vários dinâmicas possíveis de serem realizadas usando estes princípios, seja no formato de baralho que estou disponibilizando logo abaixo, seja apenas escrito em post its mesmo. Em momentos como Retrospectivas, treinamentos e team buildings, você pode trazer esse assunto à tona para estimular a autocrítica, a reflexão e o amadurecimento enquanto time ágil.

Abaixo, três dinâmicas envolvendo o baralho com os 12 princípios.

Agile Clock

Cole os 12 princípios na parede, formando um relógio do princípio #1 ao #12.

Se for apenas um time que estiver participando da dinâmica, divida-o em duplas ou se for muito pequeno, deixe os indivíduos separados. Se for mais de um time, forme times menores mesclando os indivíduos.

Para cada princípio, o facilitador lê em voz alta e instiga as pessoas (em time, ou individualmente, dependendo da configuração) a tentarem resumir o princípio a uma palavra, no máximo duas. Para que consigam chegar nessa síntese, o time terá um tempo para discutir o princípio e definir sua palavra.

Faz-se isso para cada princípio. Ao término, o próximo passo é, dentre as palavras dos diferentes times para o mesmo princípio, deve ser escolhida apenas uma para ser colocada no relógio, em cima ou ao lado do respectivo princípio. Par se chegar na palavra final de cada princípio, os times terão de debater com uma timebox fixa controlada pelo facilitador.

Agile Clock
Agile Clock

Note que não existe uma resposta certa pois o entendimento dos princípios pode variar conforme o contexto dos times. No entanto, cabe ao facilitador presente instigar e provocar, sem nunca expor suas opiniões de maneira afirmativa, mas sempre interrogativa, para não se sobressair aos demais.

Dinâmica vista durante o PACC do Andy Barbosa.

Prós e Contras

Esta é uma outra dinâmica bem interessante, por ser contra intuitiva ter uma utilidade interessante especialmente com gestores. Divida o grupo da dinâmica em dois (grupo PRÓ e grupo CONTRA), ou faça divisões por princípios, dependendo do volume de pessoas.

Crie um painel em 2 linhas e 12 colunas (ou o contrário) colocando nas linhas a legenda PRÓS e CONTRAS e nas colunas pode colar cada carta dos princípios (baralho para download abaixo).

O grupo PRÓ deve elaborar em post its bons motivos para seguirmos os princípios ágeis. Coisas boas que eles trazem, o lado positivo das coisas.

O grupo CONTRA deve elaborar em post its razões para não seguirmos os princípios ágeis. Coisas que eles podem atrapalhar, riscos que eles podem trazer, o lado negativo das coisas.

Durante as apresentações, intercale um princípio de cada vez, pedindo que as pessoas apresentem os prós e contras e discutam brevemente sobre cada um para espalhar as percepções. Não é um trabalho de convencimento, mas de compreensão e empatia.

Os objetivos dessa dinâmica são dois: primeiro, entender que sim, existem riscos e que os princípios não são bala de prata e segundo, que para cada item identificado pelo grupo CONTRAS, podemos definir ações para mitigá-los.

Um terceiro e oculto objetivo é o agilista identificar o mindset das pessoas do grupo (em especial os gestores) para identificar principalmente os seus medos e temores quanto ao ágil em seus times. O resultado do grupo CONTRAS é muito mais importante neste caso e é ali que você vai ter insumos de como vender e aplicar o ágil corretamente nessa empresa.

Dinâmica vista durante o PACC do Andy Barbosa.

Quadrante Mágico

Essa dinâmica eu aprendi no blog do mestre Jorge Audy. Ele teve a ideia de usar o conceito de quadrante mágico do Gartner para refletir com o time sobre sua adoção e entendimento dos princípios ágeis.

Divida um painel em quatro quadrantes, traçando uma cruz no centro dele. Da esquerda para direita, de cima para baixo, nomeie cada quadrante com: Não Acredito mas Faço, Acredito e Faço, Não Acredito e Não Faço, Acredito e Não Faço.

Peça que um membro do grupo pegue uma carta de princípio aleatória e leia em voz alta, dando o seu entendimento sobre o princípio. Na sequência, incite uma discussão para decidir se esse princípio é acreditado pelo grupo e se o grupo o faz na prática, para posicionar a carta nos quadrantes. Obviamente o quadrante mágico é o topo direito (Acredito e Faço), mas não deixe nada ser colocado lá se não for consenso de que aquele princípio de fato é acreditado e aplicado.

Dinâmica dos Quadrantes
Dinâmica dos Quadrantes

No final, o time pode definir ações para alguns itens que não ficaram no quadrante mágico (Acredito e Faço), sendo a escolha baseada nas prioridades que o agilista tem para o time (por exemplo, vamos nos focar em fazê-los acreditar antes de fazer? Ou fazer para depois acreditar?)

Curtiu o artigo? 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