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):

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.

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

Elementos em comum entre Scrum, XP e Kanban

No artigo de hoje eu quero te mostrar algumas semelhanças entre três dos principais frameworks/métodos de agilidade adotados pelas empresas em seus times de desenvolvimento de software: Scrum, XP e Kanban. Minha ideia não é te convencer de que não há diferenças, mas sim te mostrar que a maior transformação que você pode fazer pelo seu time não está na troca de um método pelo outro, mas sim na adoção dos valores e princípios ágeis do Manifesto, que são justamente a causa desses três métodos terem tantas semelhanças.

Pronto, isso já concluí o artigo. 😀

Scrum, XP e Kanban

Scrum foi criado por Ken Schwaber e Jeff Sutherland na década de 90. Eles juntaram suas experiências liderando projetos de software de todos os tamanhos ao redor do mundo com as teorias popularizadas por Takeuchi e Nonaka no famoso The New New Product Development Game, publica na década de 80 na Harvard Business School. É um framework iterativo-incremental para desenvolvimento de soluções complexas e inovadoras por times auto-gerenciáveis.

Já o Extreme Programming (XP) foi criado por Kent Beck, Ward Chunningham e Ron Jeffries também na década de 90. Eles juntaram suas experiências com engenharia de software para criar uma metodologia ágil que lidasse bem com requisitos vagos que mudavam frequentemente, times pequenos e que colocasse mais disciplina nos desenvolvedores ao invés de mais processos formais. É um método muito focado em qualidade de código, testes e outras boas práticas de engenharia.

E por fim, o Kanban, foi originado no chão de fábrica japonês na década de 50, mas posteriormente adaptado por David Anderson nos anos 2000 para ser usado em corporações, visando gestão do fluxo de valor das empresas, dentre elas as de software. Ele trabalha em cima dos conceitos da manufatura Lean e promove uma postura evolucionária de adoção do método, através de necessidades emergentes.

Note que as três surgiram em meio ao boom dos métodos ágeis, cujo ponto focal foi a criação do Manifesto Ágil em 2001. O quanto o Manifesto influenciou elas ou o contrário, é difícil saber, mas é fato de que existem muitas semelhanças, que é o que vou mostrar agora.

Agilistas do Scrum, XP e Kanban

Começando pelo mais óbvio papel dos métodos ágeis, o agilista, o profissional responsável pela adoção e melhoria contínua de processos ágeis no time.

No chão de fábrica japonês, conforme relata Mike Rother no seu Toyota Kata, já havia se entendido a necessidade de ter uma pessoa focada na melhoria contínua do time (kaizen), observando o fluxo de produção, identificando gaps e ajustando processos. Embora os próprios profissionais de produção também enxergassem gaps nos seus processos, eles não tinham a visão do fluxo de valor completo e muito menos tinham tempo para promover melhorias.

A versão moderna deste profissional é o Scrum Master no Scrum, o Coach e o Tracker no XP e o Service Delivery Manager no Kanban. Note que no XP temos dois papéis exercendo atividade semelhante e ao mesmo tempo com particuliaridades uma vez que o Coach XP é geralmente muito mais técnico do que um Scrum Master moderno e o Tracker XP é focado em métricas do time. Já o Service Delivery Manager foi criado mais tarde como um papel opcional pelo próprio David Anderson, uma vez que ele deve ter percebido que o ditado “cachorro com mais de um dono morre de fome” também se aplica a processos desenvolvimento.

Note que não entro aqui na filosofia por trás de cada papel e me perdoem os mais puristas por isso. Do ponto de vista de atividades, a semelhança é incrível.

Profissionais de Produto do Scrum, XP e Kanban

Outro grande gap identificado nos métodos tradicionais de desenvolvimento de software foi o distanciamento do cliente ao longo do projeto. A falta de comunicação com o mesmo durante todas as fases de desenvolvimento do software faziam com que o resultado fosse um desastroso telefone sem fio (lembra da brincadeira?). Assim nascia a função do profissional de produto dentro dos times ágeis. Seja o cliente ou alguém representando o mesmo no dia a dia, estes líderes de produto tinham como missão garantir o ROI e otimizar o esforço de desenvolvimento rumo ao que o cliente realmente deseja.

No Scrum temos o Product Owner, no XP temos o Cliente e o Gerente e no Kanban temos o Service Request Manager. Todos estes papéis são responsáveis por priorização de backlog, comunicação com o cliente, ROI do projeto/produto, etc. Curiosamente é comum que eles trabalhem com o formato de User Stories para os itens de backlog, que é um formato originário do XP. Também é muito comum que eles trabalhem com o backlog corrente exposto em um quadro de atividades, oriundo do Kanban. Ou seja, é muito comum uma amálgama destas práticas no dia a dia dos times de software.

No XP eu citei os papéis de Cliente e Gerente como sendo comparados ao Product Owner do Scrum e ao SRM do Kanban pois depende da natureza do projeto e das características da sua empresa. Eles são papéis distintos no XP, mas podem acabar sendo aglutinados dependendo do cenário.

Novamente me perdoem os puristas.

Cerimônias do Scrum, XP e Kanban

Ao contrário do que muitos times novatos pensam, passar a utilizar uma metodologia ágil não quer dizer que você vai ter mais reuniões do que já tem. O que acontece é que sim, haverá uma disciplina maior na facilitação e recorrência das mesmas, para garantir o alinhamento e a comunicação, consequentemente aumentando a chance de sucesso do projeto.

O Scrum possui cerimônias muito famosas, logo pegarei as mesmas como exemplo de comparação. No Scrum temos a Sprint Planning, marcando o início de uma iteração (a propósito, Scrum e XP possuem iterações, Kanban não, ele possui cadências). Da mesma forma, no XP teremos o Jogo de Planejamento, sendo que existe o Planejamento de Iterações (tal qual Sprint Planning) e o Planejamento de Releases (semelhante a um Product Increment Planning do SAFe).

Extreme Programming Project
Extreme Programming Project

Já no Kanban é mais parecido com o XP do que o Scrum, pois se quebrou a cerimônia de planejamento em duas. Aqui as cerimônias se chamam cadências e temos a Replenishment ou Commitment Meeting e a Delivery Planning Meeting.

E depois de planejado, mantemos a sincronia do time através da famosa e polêmica reunião diária. Se tem uma coisa que gera polêmica e que ao mesmo tempo é unânime entre os métodos ágeis é a necessidade de reuniões frequentes e rápidas enfatizando a comunicação. No Scrum temos a Daily Scrum, no XP a Daily Stand Up Meeting e no Kanban a Standup Meeting (também com frequência diária).

Curiosamente, no Scrum também se faz esta cerimônia em pé, mas esta é uma regra do XP e do Kanban, e não do Scrum.

Ciclo Scrum
Ciclo Scrum

Findo o desenvolvimento do incremento de software, é hora de revisar o que foi feito e entregar ao cliente. No Scrum chamamos este momento de Sprint Review e no Kanban temos duas cadências para revisar a entrega, denominadas Service Delivery Review e Strategy Review. No XP não temos nada específico para este momento até onde pude estudar, talvez até pelo própria ênfase em entrega contínua (Continuous Delivery), o que obviamente não invalida pequenos pacotes com review do cliente.

E para finalizar, quando o assunto é revisar como o time está trabalhando, o Scrum tem as famosas Sprint Retrospectives, o XP menciona retrospectivas, mas não define algo mais concreto e no Kanban temos uma mescla entre Service Delivery Review (métricas), Operations Review (otimizações no fluxo de valor) e Risk Review (ajustes no processo visando mitigar riscos). Note que apesar do Kanban aparentar ter mais cerimônias, é super comum a mescla entre elas ou a periodicidade assíncrona.

Cadências do Kanban
Cadências do Kanban

Artefatos do Scrum, XP e Kanban

Quando o assunto são os artefatos, aí é que temos uma enorme confusão. Ninguém se lembra qual artefato é de qual método.

Primeiro, usar um board de atividades é muuuito comum em qualquer time ágil, mas ele é originário do Kanban.

Kanban
Kanban

Segundo, escrever os requisitos em formato de histórias de usuário é outra prática comum, mas ele é natural do XP.

User Story Card
User Story Card

Terceiro, métricas como Lead Time e gráficos como o Cumulative Flow Diagram são artefatos do Kanban, embora largamente utilizados em diversos times Scrum e XP.

Lead Time
Lead Time

E por fim, estimar usando pontos em escala de Fibonacci, através de um baralho de cartas não é de nenhum dos três métodos, mas simum artefato inventado pela Mountain Goat Software chamado Planning Poker. Eu sei, no Kanban é mais comum contar atividades do que estimá-las, mas nada lhe impede de estimar em Kanban exceto o radicalismo de alguns agilistas. XD

Planning Poker
Planning Poker

Logo, aqui não temos semelhanças, mas sim um compartilhamento de ferramental que chega a tornar confuso saber o que é oficial de cada framework.

Por hoje é só pessoal. Como já disse no artigo O que é melhor: Scrum ou Kanban, acredito no uso combinado destes métodos para alcançar os melhores resultados com os times.

* 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

Gamification em Modelos de Maturidade

No artigo de hoje vou explicar para quê serve, como criar um e como tornar a experiência com modelos de maturidade mais lúdica e interessante para os times. A ideia não é esgotar o assunto, mas dar ideias e uma introdução a quem busca este tipo de abordagem.

O quê é um Modelo de Maturidade?

Segundo a Wikipedia, em uma tradução livre, maturidade é uma medida da habilidade de uma organização em melhorar continuamente em uma disciplina em particular, sendo que a maioria dos modelos de maturidade certificam pessoas/cultura, processos/estruturas e objetos/tecnologia.

No âmbito de processos de desenvolvimento de sistemas temos modelos de maturidade como CMMI (Capability Maturity Model Integration) e MPSBR (Melhoria de Processos do Software Brasileiro) e mais especificamente dentro dos métodos ágeis temos um exemplo de modelo de maturidade no método Kanban que se chama KMM ou Kanban Maturity Model.

KMM
KMM

Basicamente um modelo de maturidade te guia através de práticas e processos cada vez mais evoluídos para a obtenção de um nível desejado de proficiência e qualidade na execução de suas atividades. Modelos de maturidade são divididos em níveis, onde para se obter a certificação de que você chegou em um nível geralmente tem-se de resolver um desafio ou fazer uma prova.

Por que criar um modelo de maturidade?

Todas empresas e times querem evoluir, certo? Afinal, melhoria contínua é um dos objetivos primários da agilidade. Embora a melhoria contínua orgânica e artesanal tenha o seu valor, muitas vezes as empresas possuem um norte técnico e de processos a ser seguido. Ter um modelo de maturidade claro, coerente e transparente ajuda e muito aos times atingirem esses objetivos, chegar nesse norte.

Se a sua empresa não depende de modelo de maturidade de mercado para conseguir clientes (CMMI é exigido em licitações, por exemplo), criar um modelo de maturidade próprio permite ter algo customizado às suas necessidades.

É importante ter em mente que o objetivo de um modelo de maturidade não é rotular que time é melhor ou pior, mas orientar a todos o caminho que a empresa espera que eles sigam, sendo algo de comum adoção em transformações ágeis e digitais de corporações, por exemplo.

Mas como tornar mais interessante e divertida essa busca por melhoria contínua direcionada através de um modelo de maturidade? Com gamification!

O que é gamification?

Gamificação é o uso de técnicas de design de jogos para enriquecer contextos geralmente não associados aos mesmos. Geralmente atividades gamificadas incluem obtenções de pontos (como em programadas de fidelidade), classificação dos “jogadores” (como em “funcionário do mês”), emblemas de conquistas (como nas insígnias de escoteiros) e muito mais. Note que citando estas características eu já dei vários exemplos de uso do gamification no mundo real.

Ao adicionar elementos de jogos em atividades não relacionadas aos mesmos traz mais leveza à condução destas atividades, torna-as mais divertidas, cria muitas vezes uma competição saudável e aumenta o engajamento do pessoal pois é muito comum as pessoas se engajarem em jogos bem construídos, sejam eles virtuais ou reais.

Como criar um modelo de maturidade gamificado?

Eu vou te fornecer um método, ok? Mas entenda que não é uma resposta para qualquer situação, a popular “bala de prata” que muitos procuram. É apenas um jeito de fazer, que já apliquei e deu muuuuito certo, mas no meu contexto.

Qual era o contexto? Uma corporação financeira com quase 20 anos que decidiu fazer uma transformação ágil e digital na sua TI. Estou falando de centenas de pessoas de todas as skills possíveis que trabalhavam com arquiteturas fragmentadas (ou emergentes, mas sem se conectarem), quase sem processos de desenvolvimento (poucos times usavam PMI e menos ainda usavam métodos ágeis) e muitos, mas muitos desafios, além da vontade de mudar pra melhor, é claro!

O primeiro passo é entender quanto tempo o jogo vai durar. Sim, isso mesmo. Todo jogo tem início, meio e fim. Ninguém aguenta jogar o mesmo jogo pra sempre. Podem haver continuações depois? Sim, mas você precisa ter início, meio e fim no seu jogo ou as pessoas irão perder o interesse, mais cedo ou mais tarde.

No meu caso, a duração do jogo era um ano. Queríamos fazer a referida transformação em um ano.

O segundo passo é entender qual é o final do jogo. Todo jogo tem de ter um final épico, que envolva uma grande transformação dos personagens, a superação de muitos desafios. Onde você espera que sua empresa/times estejam depois do jogo ter terminado?

No meu caso esperávamos que após um ano os times estivessem todos rodando métodos ágeis (Scrum, Kanban, etc) e programando nos padrões da arquitetura corporativa definida pela empresa (stack de tecnologia, padrões de segurança, ferramental de desenvolvimento, etc). Alcançado esse objetivo, entendíamos que a transformação teria sido finalizada com sucesso e de quebra acreditamos que afetaríamos a cultura da empresa positivamente.

O terceiro passo é entender qual a situação atual. Frente ao objetivo proposto para o tempo dado, o quão longe estamos de chegar lá? Note que esta metodologia de racionalizar um desafio não é minha, é do Toyota Kata de Mike Rother, mas isso é papo pra outro momento. Se queremos chegar lá em x meses, quantos passos serão necessários? É viável este salto evolutivo neste tempo?

Toyota Kata
Toyota Kata

No meu caso era viável sim pois as metas eram bem razoáveis. A fotografia atual não era desesperadora, apenas ia dar bastante trabalho. Tínhamos forte patrocínio da diretoria da empresa, o que foi vital para conseguirmos seguir adiante.

O quarto passo é quebrar o desafio em etapas, que seriam os níveis do modelo de maturidade. Você deve quebrar em tantas etapas quanto dê sensação de progresso aos times, mas não tantas que atrapalhe demais eles pois o avanço entre os níveis tem uma série de requisitos.

No meu caso quebramos o ano em 4 trimestres, onde a cada três meses fazíamos uma aferição dos resultados obtidos para ver quais times evoluíram dentro do modelo ou não.

Dependendo do número de níveis e da duração do seu jogo você poderá associar uma temática à ele. Sim, pois todo jogo tem um tema central, certo? Temas possíveis e comuns incluem artes marciais (trocando faixa a cada nível), escalada do Everest (alcançando acampamentos na montanha), treinamento Jedi (de youngling a Jedi master), RPG (que tal os níveis das classes de personagem?) e por aí vai.

Jedi Levels
Jedi Levels

Associar uma temática não é um passo obrigatório, mas altamente recomendável. A temática, se bem escolhida, abre um leque de oportunidades para comunicação dos desafios, premiações e cria uma empatia enorme com os times, principalmente quando se usa elementos muito conhecidos da cultura pop.

No meu caso usamos artes marciais como tema e definimos cores de faixa para simbolizar o nível de cada time dentro da evolução do modelo de maturidade. Apesar de não ser algo que muitos na empresa praticassem, foi algo que encontramos que todos conheciam bem o bastante e que tinha um simbolismo poderoso.

O passo seguinte é definir as regras para troca de níveis dentro do modelo. Sim, você tem de pensar como que os times e a empresa saberão quem está em qual nível e como avançar de um nível pra outro. Avaliações frias como provas não são recomendadas aqui, mas você terá de ter algum tipo de avaliação de qualquer forma, afinal é um jogo e ele possui regras.

No meu caso cada nível tinha uma série de microdesafios. Cada microdesafio era parte importante para se vencer o desafio do nível, que só era alcançado com 100% de microdesafios entregues. Cada microdesafio tinha um nome, uma descrição que dizia como ele era alcançado e uma categoria. Para cada categoria (DevOps, Práticas Ágeis, etc) existia um consultor encarregado que não apenas avaliava os times naquele tema, mas também tinha a função de educar os times de como chegar lá.

D&D XP Table
D&D XP Table

E por fim, a comunicação. O jogo só fará sentido e os jogadores buscarão evoluir dentro dele se houver comunicação eficiente. Comunicação dos prazos, das regras, dos desafios. Comunicação das premiações, que podem ser apenas simbólicas, reconhecendo publicamente os times que vencem cada etapa ou mais materiais como prêmios lúdicos como adesivos com insígnias dos desafios, cartazes e bandeiras para os times, etc.

Evoluir tecnicamente times de desenvolvimento de uma grande empresa não é uma tarefa fácil (no meu caso eram mais de 40 times e 420 pessoas). Nem pra quem está organizando a transformação, nem pra quem está sendo transformado. Comunicar bem sobre o jogo é uma maneira de tornar tudo mais real, mais tátil. Ajuda a garantir o engajamento e a tornar claro o que a empresa espera que os times alcancem.

E você, tem alguma experiência com modelos de maturidade? Alguma dúvida? Alguma sugestão? 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