No artigo de hoje vou falar um pouco da história do Scrum e da sua evolução desde a sua criação até hoje e para onde acredito que o mercado está seguindo em termos de agilidade. Essa história é melhor trabalhada no livro Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo de Jeff Sutherland e outras publicações menos conhecidas.
A Inspiração
Vale lembrar que durante a Crise do Software da década de 70 muitos profissionais de projeto e de tecnologia estavam empenhados em criar métodos e processos a fim de aumentar o grau de sucesso dos projetos à época. A Engenharia de Software moderna se originou deste movimento e metodologias tradicionais como o Waterfall e mais tarde o processo Iterativo Incremental se consolidaram neste período como formas “corretas” de se fazer software.
No entanto, conforme a tecnologia avançava, a digitalização das empresas começava a aflorar e os projetos se tornavam cada vez mais complexos e dinâmicos em um mundo globalizado, isso não bastou. Em 1986 a dupla de professores de Harvard, Takeuchi e Nonaka, escreveram o famoso artigo The New New Product Development Game onde relatavam o resultado da sua pesquisa com algumas das mais bem sucedidas empresas à época. Essa pesquisa buscava entender porque os produtos destas empresas se saíam tão bem, uma vez que a maioria dos projetos até então não estavam sendo bem sucedidos.
Não entrarei em detalhes sobre o artigo em si, que linkei acima que você pode ler na íntegra, mas este artigo inspirou engenheiros como Ken Schwaber e Jeff Sutherland a criarem novas formas de fazerem a gestão dos projetos de software. Em 1995, Ken Schwaber submetia o artigo SCRUM Development Process para a OOPSLA daquele ano, uma conferência sobre desenvolvimento orientado a objetos.
Assim nascia o Scrum, mas bem diferente de como é hoje.
A primeira versão do Scrum
Inúmeras são as diferenças da visão inicial de Ken Schwaber em relação ao que o Scrum se tornou anos mais tarde. Primeiro, ele era descrito como um processo de desenvolvimento, o que mais tarde se transformou em um framework. Talvez você já tenha ouvido falar isso, mas você sabe qual a diferença?
Um método ou processo é algo prescritivo, que deve ser seguido nos mínimos detalhes para que funcione. Já um framework é uma estrutura oca, onde você pluga novos componentes e o usa como base para evoluir para algo que supra a sua demanda. Scrum te dá apenas linhas gerais como base, logo não é um processo, caso contrário seria um processo incompleto.
Também nessa primeira versão, que você pode ler aqui, existiam apenas dois papéis: o Manager e o Development Team. O Manager era descrito como um Product Manager, mas que tinha também funções de Project Manager, o que obviamente o tornava quase um deus dentro do time e ao mesmo tempo alguém sobrecarregado. Anos mais tarde, Ken e Jeff quebrariam este papel em dois, além de evoluir suas funções como Product Owner e Scrum Master.
Os artefatos à época eram oito, o que mais tarde se reduziu pela metade:
o clássico Backlog (hoje quebrado em dois) mais as Issues;
Release/Enhacement, atualmente chamado de Incremento;
Packets, Changes e Problems, hoje todos incorporados no Incremento;
Risks e Solutions, não mais evidenciado de maneira diferenciada hoje;
E por fim, uma sprint à época possuía as seguintes fases (hoje cerimônias, eventos ou timeboxes, como preferir):
o Pregame, composto por Planning e Architecture (as mesmas duas etapas da Sprint Planning atual);
o Game, o desenvolvimento da sprint;
o Postgame, com testes, documentação, preparação para release e a dita cuja.
Scrum v1.0
Note como isso não era exatamente um método ágil moderno, uma vez que não previa melhoria contínua (com a Retrospective atual) embora citasse algum grau de transparência com uma menção à Review atual Também não é explícito que estas fases devam acontecer a cada sprint, e entendia que uma vez feito o Pregame, poderiam acontecer diversas sprint de desenvolvimento (Games) e depois um único Postgame para fechar o pacote.
As versões posteriores
Mais tarde, com Ken se aliando a outros engenheiros importantes e com a própria publicação do Agile Manifesto em 2001, o Scrum ganhou força e tivemos uma grande publicação que descrevia sua implementação em mais detalhes, fruto da parceria de Ken com Mike Beedle, o livro Agile Software Development with Scrum, em 2001 mesmo. No entanto, como descrito no livro, o Scrum teria sido criado como uma forma de fazer com que o Extreme Programming (XP) pudesse ser aplicável nas empresas.
Ou seja, Ken Schwaber e Mike Beedle eram fãs do trabalho de Kent Beck, o que mostra como essa galera estava compartilhando conhecimento e bebendo uns nas fontes dos outros naquela época.
Depois em 2004 veio novo livro de Ken Schwaber de como aplicar Scrum na gestão de projetos, o Agile Project Management with Scrum. Diferente do seu antecessor, mais focado em engenharia, este último era para o público de projeto, provavelmente oriundo da incompatibilidade dos métodos de gestão tradicionais com a nova abordagem de desenvolvimento.
Finalmente em 2010 surge o Scrum Guide, o guia que se tornaria a fonte oficial (e enxuta) de informação sobre Scrum. Foi nessa época que aprendi sobre métodos ágeis a primeira vez e quando li o guia, que tinha 32 páginas (hoje tem 19). Aqui o Scrum já estava bem mais próximo da versão atual. De lá pra cá apenas se apararam algumas arestas como por exemplo:
maior foco no Sprint Goal, principalmente na Daily;
o Incremento se tornando um artefato oficial (voltando às origens);
o Burndown Chart deixando de ser um artefato oficial;
Em 2012, o famigerado Software in 30 Days foi lançado por Ken e Jeff. Famigerado porque, assim como “Scrum: Arte de fazer o dobro do Trabalho na Metade do Tempo” de 2014 (este somente pelo Jeff), este livro é muuuito marketeiro, o que gera críticas por fazer um desserviço à comunidade ágil uma vez que ilude manager inescrupulosos, criando falsas expectativas que geram mais pressão sobre os times. Mas enfim.
Em 2016 eu lancei o meu livro sobre o assunto, visando preencher as lacunas que eu fui encontrando ao longo dos anos com técnicas e artefatos de outros autores e que fizeram (e ainda fazem) sentido para os times ágeis que eu liderei ao longo dos anos trabalhando com Scrum.
O futuro do Scrum
Pesquisas como a State of Agile e a State of Scrum indicam que nunca o Scrum foi tão popular nas empresas. Não somente nas que se autoproclamam ágeis, mas também em maior ou menor grau até mesmo em empresas tradicionais, sendo que células independentes de muito empresa jurássica usa Scrum atualmente. Isso mostra o Scrum como um framework mainstream para desenvolvimento de produtos complexos, o que é evidenciado pela tendências apontadas pela InfoQ ano passado, o qual eu reproduzo a imagem abaixo.
InfoQ Trends
Note que o que esta imagem mostra é que os métodos ágeis mais tradicionais, os que estamos acostumados, já estão sendo adotados na categoria de empresas Late Majority. Isso não significa que Scrum está caindo em desuso, muito pelo contrário, que jamais foi tão utilizado na indústria de software.
No entanto, note o quanto de novidades temos à frente de nós e que só o Scrum por si não consegue dar conta. Ao invés de eu ficar especulando o que o futuro reserva para o Scrum, acho que vale a pena você dar uma olhada nestes tópicos aí para ver como as empresas mais tops do mercado estão trabalhando hoje, para quem sabe amanhã você puxar essas novas linhas na sua empresa.
Conforme eu mesmo for estudando e aprendendo sobre estes temas, tenha a certeza que estarei compartilhando aqui no blog.
Atualizado em 16/02/19 com duas traduções de livros e a nova versão de outro!
Desde a criação do Agile Manifesto em 2001 e a consequente popularização dos métodos ágeis no início deste século que eu tenho como o maior ganho promovido pelo modelo a aproximação da área de negócio das empresas com área de TI das mesmas. Essa aproximação se dá em grande parte à obrigatoriedade do papel do Product Owner dentro dos Times Scrum, sendo esse o framework ágil mais difundido no mundo.
No entanto, para que essa conexão produza bons frutos é necessário que o papel do Product Owner seja respeitado e que o mesmo possua as skills necessárias para tanto. Mas que skills seriam essas?
Um Product Owner geralmente é um especialista na sua área de negócio, mas não necessariamente um especialista em métodos ágeis. No entanto, diferente de um Scrum Master ou de um Agile Coach que devem respirar métodos ágeis no seu dia-a-dia, um Product Owner deve respirar concepção e desenvolvimento de produtos de maneira ágil, tema central das leituras que recomendarei neste artigo.
Clique nos títulos ou nas capas para ver o livro na Amazon.
Obra máxima de Eric Ries, A Startup Enxuta (Lean Startup no original) já foi motivo de resenha aqui no blog e dispensa apresentações. Conceitos como MVP (Minium Viable Product), Contabilidade para Inovação e o ciclo Build-Measure-Learn são obrigatórios no repertório de qualquer Product Owner.
Este fantástico livro de Alex Osterwalder (até a edição é excelente, já fiz resenha aqui no blog) introduz o famoso Business Model Canvas, estrutura o raciocínio sobre a ideação de modelos de negócio inovadores e nos traz diversos cases de modelo disruptivos que empresas famosas descobriram para se reinventar.
Outra obra-prima de Alex Osterwalder, desta vez ele nos introduz ao Value Proposition Canvas, uma poderosa ferramenta que auxilia os Product Owners a fazer a conexão certa entre o que os clientes desejam e o que o seu produto realmente deve ser.
Ao contrário do que o nome sugere, este não é um livro de Scrum, mas sim um livro sobre o método usado no Google para testar e aplicar novas ideias em apenas cinco dias. É muito interessante de ler e aplicar, tendo sido escrito por Jake Knapp em parceria com membros do Google Ventures.
ReWork no original de Jason Fried, este livro é a versão parruda e mais moderna do recomendadíssimo Caindo na Real, escrito pelos fundadores do Basecamp. Não apenas promove uma mudança cultural na cabeça de quem lê, ele dá aos Product Owners um passo-a-passo de como orientar a criação de aplicações ágeis e que realmente atendem as necessidades dos clientes com menos pessoas e menos software.
Paulo Caroli é um engenheiro de software e autor brasileiro que ficou famoso no mundo inteiro com a sua Lean Inception, um método de concepção de novos produtos muito alinhado aos conceitos do Lean Startup, permitindo que através dos métodos descritos em seu livro, empresas consigam definir os escopos de seus novos produtos em até uma semana de trabalho.
O mais famoso livro sobre Scrum do mercado (ele aparece na minha lista de 6 livros recomendados para aprender agilidade), o “livro amarelo do Scrum” foi escrito por Jeff Sutherland, um dos criadores do Scrum e uma das figuras mais famosas em agilidade no mundo inteiro. Não é exatamente um livro que te ensina como dominar o framework, mas que te dá a base histórica e teórica do framework, seus princípios e como eles são aplicados em diversos contextos através de todo tipo de case. Essencialmente um livro sobre cultura ágil.
O excelente Running Lean do Ash Mauriya foi traduzido como “Comece sua Startup Enxuta” e traz conceitos de outros livros como o Business Model Generation e o Lean Startup para outro nível, mais focado em produtos digitais e na realidade que os permeiam. Ele ajuda o profissional de produto ou empreendedor a parar de fazer conjecturas e validar suas hipóteses em campo, com ferramental sugerido pelo autor. Se eu pudesse resumir esse livro em uma frase seria: saia do escritório e vá falar com seus clientes.
Esse livro de Steve Blank (um dos maiores investidores e mentores do Vale do Silício) é o avô do movimento Lean Startup, tendo sido Blank o professor do Eric Ries (autor do Lean Startup). Neste livro ele introduz conceitos como Customer Discovery e Customer Development, trazendo à tona questões como a busca pelo Product-Market Fit e tantos outros conceitos importantíssimos para todos profissionais responsáveis pela criação de produtos no século atual. Apesar do nome tosco da tradução brasileira (o original é The Four Steps to the Epiphany ou Os 4 Passos para a Epifania) não é um livro de auto-ajuda e sim um método de validação e desenvolvimento de Product-Market Fit.
Esta é uma obra-prima do guru dos Product Owners, Roman Pichler. É um livro que já foi traduzido pro Português mas que é bem difícil de achar a versão nacional, sendo bem mais fácil comprar o ebook na Amazon, embora um tanto salgado. Mas felizmente vale a pena cada centavo se você está investindo na carreira de PO. Roman fala do MMP (Minimum Marketable Product), fala de grooming, de planejamento de releases e ajuda de uma vez por todas a entender este importante papel dentro de times ágeis.
Esqueci algum livro que você gostaria de adicionar na lista? Me mande nos comentários!
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):
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.
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).
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!
