O termo DevOps surgiu em 2008 em uma palestra do Patrick Debois, no Agile Conference de Toronto e seu principal objetivo era simplificar e diminuir a dificuldade de interação entre as áreas de desenvolvimento, operações de TI, engenharia da qualidade e segurança.
Entretanto, antes mesmo dessa cultura ser criada (sim, DevOps é uma cultura), algumas empresas já praticavam a aplicação em seus times, principalmente as que buscam maior qualidade nas entregas e redução de retrabalho e falhas de comunicação.
Antes do DevOps, os times de Desenvolvedores, Operações e TI, eram separados e causavam diferentes atritos entre a comunicação das equipes e falhas tremendas na entrega dos produtos.
Com o surgimento do DevOps, as equipes que trabalhavam separadamente passam a ser uma só, aumentando melhorias na entrega e agregando ainda mais valor aos produtos dos clientes.
“Todo mundo vê DevOps como um bicho de 7 cabeças, mas não é nada de outro mundo.”
DevOps é uma cultura que tem como principal objetivo facilitar as práticas dentro dos times de TI, melhorar a comunicação entre os membros da equipe e trazer melhorias contínuas como utilização de ferramentas, melhores práticas nos fluxos de deploys, com a intenção de entregar mais valor aos clientes.
Em uma pesquisa realizada pelo Gitlab, 83% dos profissionais de desenvolvimento estão conseguindo liberar seus códigos muito mais rápido e cerca de 60% estão conseguindo implementar muito mais códigos em um único dia, após a adoção do DevOps.
Os pilares do DevOps
A cultura DevOps é sustentada por 3 pilares, sem a aplicação deles a sua estratégia com a metodologia pode dar errado.
Integração contínua: transparência e compartilhamento de conhecimento e experiência entre os times de Desenvolvimento e Operações.
Implantação contínua: liberação mais rápida e contínua das novas versões de projetos, produtos e serviços
Feedback contínuo: feedbacks frequentes com os times envolvidos em todas as fases de produção do projeto/produto
Por que ter DevOps no time?
Existem inúmeros benefícios de implementar a cultura DevOps nos times, principalmente em equipes que desenvolvem produtos e negócios digitais. Entretanto os principais são:
Segurança
As ferramentas aplicadas com a cultura DevOps fazem com que ações sejam definidas e concluídas mais rápido para que a produção aconteça imediatamente. Após os testes realizados é possível garantir segurança operacional com os processos.
Facilidade em intervenção proativa
Ao começarem a trabalhar em conjunto, os times possuem mais facilidade na hora de comunicar e acompanhar o processo do projeto do início ao fim, dando oportunidade para os membros dos times colaborarem com melhorias no processo.
Colaboração entre os times
Como já foi dito acima, a colaboração passa a ser de um para o outro e não somente entre um desenvolvedor ou um operador. O time passa a trabalhar em conjunto para melhorar as entregas e agregar mais valor no produto do cliente.
Processos simples e automatizados
As práticas adotadas pela cultura DevOps tem como objetivo transformar os processos em algo mais simples e automatizado, sem muita burocracia, para facilitar que o time como um todo consiga enxergar as etapas do projeto de acordo com o que a equipe faz.
Entregas com mais velocidade e qualidade
A cultura DevOps vem com o intuito de automatizar certos processos para que o profissional possa dedicar o seu tempo e energia a outras demandas do projeto. Com isso, a qualidade do produto final melhora e o time consegue realizar mais entregas para o cliente.
O papel do DevOps na transformação digital
Cada vez mais, as empresas que querem ser mais inovadoras e estar a frente no mercado, estão buscando e passando por processos de transformação para ser mais digital.
Isso porque essa transformação visa o crescimento das organizações através da tecnologia, para serem mais modernas, mais inovadoras e mais conectadas com seus clientes, tendo processos automatizados e ágeis.
Pensando nisso, DevOps é uma ferramenta essencial para que negócios digitais alcancem seus objetivos e melhorem seus resultados.
Sendo assim, o papel do DevOps é super importante nesse processo para auxiliar os times de desenvolvimento, operações e TI para que haja melhores entregas e mais evolução nesse dia a dia de trabalho.
Durante nossos processos de consultoria e coaching, muitas vezes nos deparamos com um cenário no qual surgem frases ou dúvidas como:
– Quero tentar mudar alguma coisa, mas não sei o quê…
– Da forma como estou fazendo não sou tão efetivo, mas o que mudar?
– Já consumimos muito conteúdo, mas será que é o suficiente?
– Acho que preciso de mais gente na equipe, mas como convencer a diretoria a fornecer budget?
– Quais os papéis necessários para que eu tenha um time adequado?
Basicamente, os líderes querem entregar mais resultado, ter times eficientes e eficazes, e sempre surge a hipótese de que métodos ágeis ajudariam nessa produtividade. Mas não sabem como e nem em qual ordem: “Primeiro contrato ou arrumo o processo?”; “Se tenho que ter pessoas, qual o papel que tenho que contratar?”; “Ou antes eu revisito o processo?”; “O que vem primeiro?”.
Então, o que fazer?
Não tem uma resposta pronta e vou falar de forma geral, pois cada caso é um caso.
Primeiro ponto é que, às vezes, é muito nítido que tem uma skill faltando. O problema é tão grande, tão gritante, que nem é preciso rever o processo, mas sim já contratar uma pessoa. Veja se você tem algum caso gritante!
Caso contrário, quando não é tão nítido a falta de uma pessoa:
Primeiro aconselhamos a empresa analisar seu processo atual – entender o que está acontecendo, se dá para fazer mais resultado com as mesmas pessoas. E, somente depois, analisar a necessidade de contratar mais pessoas.
Por que revisitar o modo de trabalhar é importante?
Muitas vezes as empresas não tem um processo bem definido e esse, por sua vez, possui gaps, gargalos, indefinições e desperdícios. Uma outra dúvida muito comum é: “E se contratar mais pessoas e continuar tendo dificuldades de entrega?”
Bom, se não tiver o processo correto e bem definido, existe a chance de colocar mais pessoas e amplificar ou “mascarar” o problema, por exemplo:
Mascarar o problema: você coloca 160h (1 pessoa) a mais, mas no final você aumenta sua produtividade real em 40h. Sendo que as outras 120h acaba sendo improdutivas – isso acaba mascarando o problema
Amplificar o problema: você coloca mais pessoas no time e a produtividade cai no final, pois a complexidade do time aumenta e algo que não estava bom, fica pior.
Em outras palavras, rever o modo de trabalho consiste em ter uma jornada ágil para sua área, com processos ágeis bem desenhados e definidos, para seu time entregar mais.
Como funciona normalmente?
Durante a revisão do processo, o primeiro ponto que tentamos responder é: “hoje, é claro nosso processo? Ele está bem definido?” Ou seja, é preciso ter clareza do processo e não estou dizendo que tem que ser engessado, mas sim, claro para todos.
Outra pergunta que fazemos é: “Seu processo é burocrático? Tem como ser mais Lean, ou seja, mais enxuto?”
Com essas perguntas, começamos a revisão propriamente dita, a fim de descobrir a eficiência atual com métricas e identificar os principais gargalos. Em nossa consultoria, nós definimos o modelo AS IS (como funciona hoje) e o TO BE (como deve ser um processo no futuro, bem definido e ágil, com um fluxo mais otimizado).
Pontos chaves durante a revisão de um processo, que fazem um time produzir mais:
PRIORIZAÇÃO E GESTÃO DE DEMANDAS
Durante a revisão do processo, é comum identificarmos, por exemplo, que pelo menos 50% dos requisitos solicitados por Negócios não são necessários. A correta priorização dos requisitos é fundamental, para depois você alocar um time para desenvolver o sistema. Para cada requisito, devemos ter com relativa clareza o propósito do negócio, qual o valor de negócios que se busca, para o desenvolvimento criar o código.
REFINAMENTO
Os itens requisitados não estão em uma boa granularidade, na qual o DEV precisa perder tempo tentando entender o que tem que fazer e obtendo mais retrabalho.
QUALIDADE
“Tem pontos que preciso melhorar na minha política de qualidade, para eu ter menos retrabalho?”; “O produto acaba tendo muitos bugs e o backlog de correção e sustentação é grande?”; Identificar essas questões melhoraram o aspecto da qualidade e ajuda muito na economia de trabalho.
ARQUITETURA
“Tenho problemas arquiteturais no meu sistema, o que faz que eu demore para desenvolver algo?” Esse é o famoso cenário de backlog técnico, no qual é tão necessário um refractories.
OTIMIZAÇÃO
Tem alguém com alto índice de retrabalho, ou sobrecarregado, ou com partes do processo desnecessários? Tem etapas onde está demorando muito a execução das tarefas? Esse também é um ponto muito importante a ser revisado!
Aí então, busque a contratação
Tendo mais controle sobre o processo e ele sendo otimizado e ágil, aí chega o momento de você buscar saber como fazer mais:
– Contratar mais pessoas, novos skills
Durante essa análise, você pode identificar que o time precisa de uma competência inexistente para ser mais produtivo. Por exemplo, ter uma pessoa Engenheira de QA ou Devops. Nessa fase, você consegue saber quais papeis precisa para ter uma equipe multidisciplinar produtiva, com skills que não podem faltar.
– Colocando mais pessoas – mesmo skill para ganhar mais vazão
Acontece quando você otimizou seu processo e apresenta um cenário no qual o time consegue atacar X coisas por mês, mas a necessidade de Negócios é de mais de X. Neste caso, você contrata pessoas com os mesmos skills, para ganhar mais vazão.
Formação da equipe também é algo importante
Às vezes é necessário até mexer na estrutura organizacional da empresa ou mexer na organização dos times… Mas isso é feito de forma gradual.
“Ter um component team ou um feature team?”; “Organizar por value stream?”; “Juntar ou separar os skills?”; “Separa novos desenvolvimentos do time de suporte?”… Se a sua dúvida é alguma dessas (como estruturar seu time), você precisa repensar a formação da sua equipe.
Conclusão
A decisão de contratar mais pessoas ou revisar o processo, depende muito de cenário para cenário, mas, primeiro, aconselhamos você definir a sua jornada ágil, revisitar seu processo, e depois dessa otimização, aí você pensa em contratação de pessoas.
Se quiser ajuda com a sua jornada ágil,revisar o processo ou até mesmo ter pessoas qualificadas para ter um time mais eficiente, podemos te ajudar!
Ter mais performance, mais produtividade e ser mais ágil é um dos principais objetivos de diversas pessoas atualmente, em qualquer área, não é mesmo? Você sabe que precisa trabalhar de forma diferente, quer ter entregas que atendam realmente o cliente e atingir da melhor forma os objetivos da organização… Mas o ponto é: para poder chegar até lá, é necessário o apoio de consultoria? Preciso treinar minha equipe, e em quais treinamentos? Como monto esse quebra cabeça entre treinamento, consultoria ou contratação?
E a nossa resposta é: depende muito do estágio que você está! Em alguns momentos é possível fazer alguns treinamentos e aprender técnicas e maneiras de resolver estes desafios. Em outros, é necessário ter um apoio de um especialista externo para ajudar a incorporar e colocar em prática todo esse ensinamento.
Para ajudar a entender melhor, vou sugerir a seguir alguns cenários bem comuns para você tentar se identificar em alguma situação e entender em qual passo você está e como a Agilidade pode te auxiliar, seja com treinamento ou consultoria. Confira:
1 – “Ainda não conheço sobre métodos ágeis, só ouvi falar.”
Se você ouve muito falar sobre Agilidade mas não entende muito bem sobre esse assunto, existem algumas literaturas que podem te ajudar, como: “A arte de fazer o dobro do trabalho na metade do tempo”, do Jeff Sutherland e “Scrum e XP direto das Trincheiras”, do Henrik Kniberg. Esses dois livros são indispensáveis para quem está começando nesse universo! Agora se você precisa de um material mais rico, e contar com o apoio de uma pessoa que te ensine na prática, sanando as dúvidas mais específicas, treinamentos como o Professional Scrum Foundations te proporcionarão esse conhecimento rápido e aplicável, e além disso, você ganha um voucher para fazer a prova PSMI oficial da Scrum.org.
2 – “Pesquisei sobre, sei um pouco, mas tenho dúvidas se funciona na minha realidade.”
Se os métodos e conceitos ágeis já não são mais um bicho de sete cabeças, mas você ainda sente dificuldade em incorporar ao seu dia a dia, você pode destravar essa oportunidade com a ajuda de um profissional experiente no assunto. Isso é bem comum de acontecer e pode ser facilmente resolvido com um diagnóstico rápido. Entre em contato com a gente, que agendamos uma reunião sem custo para fazer esse diagnóstico.
Outra forma de saber se aplica na sua realidade é ver esse vídeo – explicamos sobre como implementar os princípios ágeis em qualquer time, seja na área de Marketing, Recursos Humanos, Financeira, Jurídica, Operações, entre outras, principalmente fora da TI. Clique aqui e assista!
3 – “Li bastante, mas não sei se estou aplicando da melhor maneira.”
Você já reorganizou seu time para usar Scrum e outros conceitos ágeis, leu alguns livros e aprendeu algumas dinâmicas, mas ainda percebe que essa não tem sido a melhor maneira ou que tem itens a melhorar para deixar o time mais efetivo? Calma que dá pra melhorar e ajustar muito mais o método para o seu dia a dia. É ideal sim buscar esse conhecimento de forma empírica, aprendendo e melhorando diariamente, mas se você precisa acelerar esse processo para ter melhores resultados, minha dica é investir em conhecimento prático.
E isso pode ocorrer de duas formas: com um curso de Fundamentos com técnicas práticas e avançadas para sua empresa, para capacitar um grupo de pessoas através de treinamentos in company. Ou ter o apoio de uma consultoria especializada para aumentar a maturidade ágil dos envolvidos. Dessas maneiras citadas, você vai descobrir o melhor jeito de implementar os métodos ágeis em seu dia a dia, tendo benefícios visíveis a curto prazo.
4 – “Quero aprender mais, mas tenho dinheiro limitado.”
Ok, se o momento não é apropriado para um grande investimento em capacitação de pessoas dentro de sua empresa, há diversas opções de treinamentos individuais que podem ser feitos de acordo com a área de atuação de cada pessoa. Esse é o momento de escolher algumas pessoas da sua equipe, ou você mesmo, e buscar a profissionalização dos mesmos.
Além do curso de Scrum Foundations – essencial para todos que estão começando na Agilidade, você pode dar um passo a mais e se especializar fazendo os treinamentos de Product Owner ou de Scrum Master, por exemplo e replicar todo esse conhecimento internamente, em sua organização. Se você é um líder da sua organização, o PAL-E é uma ótima forma de aprender mais sobre como deixar os times mais ágeis.
5 – “Sei que posso ter benefícios e que se aplica em minha realidade, mas não sei quais, nem sei como…”
Nesta fase, para ter esses resultados de forma mais rápida e assertiva é essencial apostar num bom diagnóstico para ter uma solução focada em sua realidade. Para esses novos conceitos realmente gerarem valor, é preciso incorporá-los de maneira profunda, profissional e customizada às suas necessidades. Não corra o risco de implantar a Agilidade em sua área de forma mecânica! Em um diagnóstico gratuito e de apenas 2 horas, podemos te ajudar a entender qual o melhor processo ágil para o seu time ter mais resultados e mais produtividade.
6 – “Já tentei usar as práticas, mas sinto que ainda faço coisas erradas e por isso não tenho todos os benefícios.”
Se esse é o seu desafio atualmente, é importante ter pessoas chaves para se capacitar e fazer treinamentos de acordo com sua área de atuação e levar esse conhecimento para outras camadas da empresa, como líderes, gerentes e diretores, para assim o impacto desse novo conhecimento ser muito maior e proporcionar mais resultados em diversas áreas.
Mas, se ainda assim é difícil para você enxergar como esses métodos te ajudam a ser mais ágil, a ter mais produtividade e melhores entregas, busque uma consultoria que vai te ajudar a identificar as melhores práticas para a sua realidade e remover amarras do sistema que você possui hoje.
7 – “Já faço muitas práticas ágeis, mas sinto que minha empresa ainda tem amarras…”
É isso! Se você já consegue identificar os impedimentos que atrapalham o desempenho do time e as entregas, mas ainda assim não consegue removê-los, é preciso trabalhar na cultura, nas práticas, no produto e nas pessoas, de forma que todo o mindset seja transformado, seja realmente ágil.
8 – “Tenho profissionais que ainda precisam evoluir em suas áreas de especialização.”
Sem dúvida nenhuma, nessa situação é preciso treinar! É muito comum vermos no mercado, diversos Scrum Masters e/ou Product Owners imaturos, atuando de forma mecânica e que precisam aprender o verdadeiro ágil. Se este é o cenário que você se encontra, a capacitação é a melhor escolha. Confira os treinamentos oficiais da Scrum.org no Brasil e veja qual mais se encaixa em seu papel e dia a dia.
Mas qual é a melhor solução?
Se sua dor não é uma das descritas acima ou se ainda está em dúvida sobre todo esse processo, nos envie uma mensagem, teremos o maior prazer em lhe ajudar. Vale ressaltar que o fator financeiro também é determinante nestas escolhas… E investir um pouco mais – seja em treinamentos ou consultoria – te ajuda a ter os reais benefícios a curto prazo, com muito mais chances de sucesso.
Se já descobriu que precisa de treinamento – cuidado com os cursos que te ensinam apenas o básico. Aprenda direto com quem trabalha com os criadores e aprenda o verdadeiro ágil. Se o seu caso precisa de um apoio de consultoria, podemos bater um papo sobre como te ajudar nesse processo!
De forma macro, você pode investir em treinamentos individuais, treinamentos in company, ter um diagnóstico rápido para entender mais, ter um diagnóstico mais aprofundado para saber como vai ser aplicado no seu caso, ou já ter o apoio da consultoria nessa jornada. Essas são as ferramentas que você pode usar para te apoiar na sua jornada ágil.
Montar essa quebra cabeça é complexo e difícil… Mas as coisas certas, nos lugares certos, fazem você ganhar mais o jogo e atingir uma maturidade ágil elevada e um novo mindset.
Uma das técnicas que aprendemos com a Scrum.org e aplicamos em todos processos de consultoria que fazemos é a “Why Agile?”. Essa prática é o ponto inicial dos nossos trabalhos dentro de uma organização e você pode aplicar também em seu dia a dia para ter mais sucesso na transformação ágil.
Mas por quê a resposta do “Why Agile?” é tão importante? Porque se você não definir claramente o motivo pelo qual está buscando Agilidade para sua empresa; se você não estabelecer quais são os benefícios esperados dessa iniciativa, a grande chance é que este trabalho será feito apenas pelo método e não pelos resultados.
Por isso, quando nós começamos um processo de transformação ágil dentro de uma organização, fazemos uma série de dinâmicas e isso envolve várias etapas, reunindo vários stakeholders para entender o “por que ágil?”.
Num primeiro momento, não existe um consenso, nem muita clareza do motivo, e essas é uma das dinâmicas que nos ajudam à ir construindo isso, consolidando e aterrizando…
Cinco motivos comuns de quem busca a Agilidade
Entre as diversas respostas que ouvimos quando aplicamos essa dinâmica do “Why Agile?”, neste texto, quero te apresentar as cinco mais comuns e que podem te ajudar a ter mais sucesso na transformação ágil. Confira:
“Porque o mercado está fazendo isso, outras empresas também e eu preciso fazer.”
O “porque está na moda” é uma das respostas que mais ouvimos ao perguntar o motivo pelo qual se está querendo implementar Agilidade em uma organização. Talvez não seja essa a resposta que mais gostamos de ouvir, mas, sem julgamento, é um motivo bem comum.
“Porque eu quero ser mais ágil.”
Ok, mas o que é ser mais ágil para você? Essa é uma outra resposta comum, mas na qual muitas pessoas não tem uma definição clara do que é “ser mais ágil”. Para entender melhor esse cenário, fazemos um processo de coaching para entender o real motivo por trás dessa resposta.
Ser mais ágil é entregar mais valor? É entregar mais tarefas em menos tempo? É ter mais produtividade? Com esses feedbacks, é possível definir melhor o que é Agilidade para aquela organização e para aquele grupo de lideranças. A maior parte das pessoas querem ser mais ágeis para serem mais produtivas e entregar mais valor.
“Porque eu quero ter melhores entregas.”
É comum ouvirmos que os times trabalham demais, fazem várias horas extras, possuem uma rotina super desgastante e alguns acabam até se desligando da empresa. Isso traz um impacto imenso nas entregas, que poderiam ser melhores e com menos sofrimento. Por isso, querem implementar a Agilidade para ter uma rotina mais fluida e entregas com mais qualidade.
“Com a agilidade eu vou conseguir governar melhor os times e projetos.”
Em muitas empresas, o motivo principal pelo qual se está buscando a Agilidade é para ter mais transparência, mais visibilidade, remover os impedimentos e conseguir ajudar a destravar o potencial das pessoas, e fazer com que as coisas fluam melhor.
“Quero mitigar os riscos da minha área.”
Por fim, essa também é uma resposta bem comum… Muitos líderes querem ser mais ágeis para ter controle dos riscos. Da mesma forma, querem ter entregas mais curtas, precisam de uma definição de objetivo do produto mais clara e de uma boa interação entre os stakeholders.
Esses são os principais motivos que vemos em nosso dia a dia pelos quais empresas buscam transformação ágil. Em resumo, quando você define claramente o que é o ponto B, ou seja, aquele lugar onde se deseja chegar e o você espera de resultados, é muito mais fácil traçar o caminho para chegar lá.
“Se você não tem clareza para onde quer ir, qualquer caminho serve.”
Espero que essa técnica consiga te ajudar a começar seu processo de transformação ágil. Se você quer um pouco mais de detalhes sobre essa dinâmica, como fazemos e quanto tempo leva, ou sobre alguma outra relacionada, mande uma mensagem aqui para nós!
Ter essa resposta é muito importante para te ajudar não apenas para ter um propósito claro ao implementar a agilidade em sua organização, mas a chegar num outro nível de produtividade e obter ao máximo os benefícios desse processo, de uma forma muito mais simplificada.
Agora, se você quer aplicar essa técnica em sua área para saber realmente o seu objetivo com o ágil – e com isso encurtar o caminho para a transformação, fornecemos consultoria especializada que te ajudará a fazer a transformação ágil com sucesso, obtendo mais valor com menos dor.
Entenda agora como funciona a aplicação de metodologias ágeis na prática para ter um time mais eficiente e ágil
Muito se fala sobre os benefícios do uso de metodologias ágeis, não apenas na área de tecnologia, mas em diversas outras como Marketing, RH, Vendas, Financeira, etc… Entretanto, uma das dúvidas mais frequentes relacionada à esse assunto é “como um processo ágil organizado funciona de verdade na prática?”. Também surgem perguntas como: “Ok, eu quero ser mais ágil, mas como isso pode funcionar pra mim?”
Antes de responder essa pergunta, vale ressaltar que, se você não possui um processo de trabalho bem estruturado e bem implantado, provavelmente seu time deve estar com desperdícios ou sendo muito improdutivo no dia a dia. E isso acontece por diversos motivos:
Falta de objetivo claro e propósito
Falta de clareza sobre papéis e responsabilidades
Incertezas perante à organização
Muito retrabalho e desperdícios
Ou seja, não adianta ter um processo de trabalho organizado, armazenado num documento dentro de uma rede, e não implantado, que as pessoas não vivam em uma base diária.
Benefícios de um time ágil
Além disso, se você tem um processo bem definido e ele não for tradicional, se ele tiver conceitos ágeis incorporados, e for praticado por cada pessoa, no dia a dia do time, os benefícios são imensos.
Ao implementar os conceitos e metodologias ágeis em um time, ele passa a:
Ter chances de produzir muito mais
Ser mais assertivo nas tarefas
Entrar em ciclos de melhoria contínua
Evitar o desperdício e o retrabalho
Ter mais coordenação e dar mais visibilidade para a liderança
Melhorar a comunicação entre todos os envolvidos
Ser mais eficaz e eficiente como um todo
Como implementar essas mudanças na prática
Tudo parece lindo na teoria, mas e na prática? Para deixar seu time mais ágil e com um processo melhor estruturado, primeiramente, é necessário entender que cada time e empresa vai ter uma solução diferente. Ou seja, não existe certo ou errado, mas sim um método organizado para atender às SUAS necessidades e te ajudar a atingir os SEUS objetivos.
Esse é o nosso modelo de implementação de um processo ágil para uma área de marketing, neste caso. Não necessariamente é o que vai funcionar para você, mas já pode servir como base e te auxiliar a descobrir o seu formato ideal.
Foto de um modelo usado em uma área de Marketing
Para te ajudar nesse processo, selecionamos os principais pontos de uma implementação de um processo ágil:
Definir os objetivos de forma clara
Não adianta querer usar novos conceitos de trabalho dentro de um time, se ele não tem uma visão bem clara de qual o propósito das iniciativas. As técnicas de OKR são ideais para definir os objetivos e resultados-chaves para atingir as metas e ter clareza do que está acontecendo no dia a dia de trabalho.
“Se você não sabe para onde ir, provavelmente seu time estará sempre perdendo.”
Estruturando a lista de tarefas
Quando definimos a visão do projeto ou produto, começamos uma estruturação do backlog, ou seja, criamos uma lista ordenada de tarefas a serem executadas para atingir determinado objetivo. Usamos diversas dinâmicas e técnicas para selecionar esses itens (Design Sprint, Lean Inception, etc) e assim criamos o Product Backlog.
Em seguida, é muito importante fazer a correta priorização e ordenação desse backlog, começando os trabalhos pelas tarefas mais importantes, ou pelas que possuem mais dependência, identificando e removendo os impedimentos, etc.
Começando as Sprints
Depois de refinar os itens e definir o Sprint Backlog e começamos a trabalhar nas Sprints – que são ciclos constantes com períodos pré-definidos para desenvolver as entregas. Neste exemplo da campanha de marketing, como o time era muito volátil, fizemos Sprints de uma semana, pois além do cenário ainda incerto, tudo era adaptação e as pessoas estavam sendo treinadas e trabalhando neste novo formato, ao mesmo tempo.
Nesse primeiro ciclo, o time deve trabalhar focado no Sprint Goal (objetivo daquele período) e, ao final de cada Sprint, chamamos uma série de stakeholders para falar das entregas, dos resultados, ter o momento dos feedbacks e ajustar qualquer item para o próximo ciclo de trabalho.
Vale ressaltar aqui que a transparência e a gestão visual são essenciais nesse novo formato de trabalho. Usamos diversas técnicas e conceitos de Scrum, Kanban, Gestão 3.0, entre outras.
Entre num processo de melhoria contínua
Ao final desse novo ciclo de trabalho, pare e pense: se você pudéssemos voltar no passado e fazer tudo de novo, faríamos tudo igual? Ou teríamos feito algo diferente? Nessa retrospectiva, é possível identificar e selecionar um ponto de melhoria, e ter um plano de ação para trabalhar nele, junto com os outros itens do backlog, na Sprint seguinte… Iniciando assim um processo de melhoria contínua.
Treine as pessoas
Uma das fases mais importantes de uma implementação de metodologias ágeis é a de aculturamento. Esse é o momento no qual as pessoas passam por uma série de treinamentos, com objetivo de não apenas aprender novos conceitos, mas de realmente mudar o paradigma e atingir os objetivos. Aplicamos diversos treinamentos oficiais (com certificação) para elevar o nível de conhecimento e de experiência prática das pessoas.
Tenha métricas e dados
De nada adianta esse novo formato de trabalho, se não é possível mensurar! Tenha dados e métricas, tanto métricas de resultado (outcome), como de tarefas (output). Elas servem para entender o quanto essa iniciativa está sendo positiva ou precisa de ajustes. São esses indicadores que ajudam a guiar o time para ser melhor a cada Sprint!
Lembrando que, se você não tiver as pessoas corretas para te ajudar, toda essa iniciativa para ter um processo ágil, mais organizado e estruturado, pode fracassar. Se você ainda tem alguma dúvida sobre essa transformação, fale com um de nossos consultores e solicite um diagnóstico para saber se as metodologias ágeis vão funcionar para o seu time.
Quer que seu time trabalhe de forma mais ágil e estruturada?
Entenda como os métodos ágeis podem ajudar diversas áreas e times a ter mais produtividade e organização
Dia após dia, diversos profissionais de áreas como Marketing, times de RH, times de projetos diversos, vem até nós, perguntando: será que os métodos ágeis podem realmente me ajudar a ser mais eficiente, ser mais ágil?
Em 90% dos casos, a resposta é SIM.
Quando conversamos um pouco mais com essas pessoas, citamos algumas situações comuns em times que precisam ser mais ágeis. Alguns desses problemas são:
Muitas interferências externas
Coisas que impedem de você entregar suas tarefas, e que muitas vezes precisaria de uma ajuda da liderança
Mudanças de prioridade – às vezes se perde sem saber qual a próxima prioridade
Pouca visibilidade do que está acontecendo na organização
Pouca visibilidade dos pares – às vezes alguns ficam bem sobrecarregados, e outros nem tantos
Muitas incertezas com relação a qual o real objetivo do projeto, como saber se o que estou fazendo está realmente gerando valor
Problemas de produtividade e entrega
Processos às vezes burocráticos
E, algumas vezes, até perguntamos para a liderança, além das características da lista acima, se eles possuem algum desses problemas a mais:
Baixa visibilidade e transparências dos times;
Dificuldade de organização entre times;
Dificuldade em ter datas e prazos;
Estrutura complexa para liderar;
Problemas para as tomadas de decisão;
Basicamente, se algum desses pontos acima estão presentes no dia a dia do seu time, seja qual for sua área, nossa resposta será: “SIM, os métodos ágeis podem te ajudar no aumento de controle e produtividade“.
Muitas vezes, as pessoas gastam demasiado tempo em coisas que não geram o real valor, nem para suas entregas, nem para a organização como um todo. Com isso, gera-se uma perda muito grande de produtividade!
É como se uma área ou um determinado time fossem uma máquina, que não está sendo eficiente e está causando desperdícios diversos…
Como usar métodos Ágeis para ser mais eficiente em qualquer área?
Ser ágil não é apenas passar por um processo para ser mais eficiente e ter mais resultados. É passar por uma mudança de paradigma, de mindset, usando não apenas os métodos ágeis, mas diversas ferramentas e técnicas que fazem deste processo uma verdadeira Transformação Ágil.
Essencialmente, usamos os conceitos de Scrum, Kanban, Gestão 3.0 e OKRs para definir papeis e responsabilidades, eventos e detalhes dos novos processos de trabalho deste time.
Os princípios e características de um time realmente ágil são:
Pessoas que possuem transparência das informações, com muita gestão visual, escalando problemas rapidamente;
Times com objetivos claros e engajados, trabalhando em formato de SQUADs;
Visão de produto customer centric, mapeados em um backlog único;
Possuem métricas importantes visíveis;
Conseguem resolver problemas complexos;
Fazem entregas em ciclos curtos (são iterativos e incremental);
Promovem a melhoria contínua;
Identificam e removem impedimentos de forma rápida.
Como aplicamos na prática
Para te ajudar a visualizar melhor esse processo de mudanças, seguem alguns exemplos de Transformação Ágil em diferentes áreas:
Área Jurídica
Um time de um projeto formado por especialistas da área Financeira, Logística, Contadores e Advogados, tinha o desafio de mudar a estrutura de produção de bens de consumo, com a meta de ter ganhos fiscais chegar na casa de milhões por ano.
Passaram vários meses e esse problema não era resolvido. Com uma mini Lean Inception, criaram o backlog, montaram a Squad e, com gestão visual e indicadores, começaram a rodar os Sprints. Em pouco tempo, os problemas e impedimentos foram aparecendo e sendo escalados para a diretoria. Pouco a pouco, as situações foram sendo resolvidas, focando no objetivo daquela indiciativa e os benefícios começaram a ser atingidos.
Área de Marketing
Alguns times de uma área de marketing queriam ter mais controle sobre as demandas e processos. Com alguns conceitos de agilidade aplicados – e também de ágil escalado – criou-se um processo de governança, além de ajudar nas entregas dos times na operação. Rapidamente, os times entraram num fluxo de melhoria continua, até chegarem no processo ideal para realmente serem mais eficientes e ágeis como um todo.
Área de Recursos Humanos
Um departamento de RH precisava deixar suas entregas mais ágeis, porém com mais valor para a organização. Para isso, foi mapeada a jornada dos colaboradores – desde quando eles entravam na empresa; quando eles tinham dúvidas; quando eles usam o processo mês a mês e quando eles se desligam da empresa.
Para cada parte desta jornada do usuário – no caso, o colaborador, foi montada uma Squad, com um backlog, usando Kanban, trabalhando com Sprints e OKRs. Semana a semana, a jornada do colaborador foi sendo melhorada, visando o atingimento dos objetivos da área.
Treinamentos para toda a empresa
Nesse caso, os conceitos já citados acima precisam ser aplicados para toda empresa, mas não em plenitude. Isso significa que, muitas vezes, uma organização não vai ter Squads, Sprints, etc, em toda organização, mas muitas dessas práticas e a mudança de paradigma, são os principais pontos que ajudarão na produtividade como um todo.
Para isso, treinamentos como o Ágil Além da TI, é feito para toda a empresa. Cada funcionário vai identificar o que pode ou não ser aplicado – técnicas de visualização do fluxo, mapeamento de impedimentos, reunião diária, sprints, entre outros temas. Vale ressaltar aqui que, capacitando seu time, ele se torna mais produtivo!
Esperamos que você realmente consiga deixar seu time, sua área ou sua empresa mais ágil e mais eficiente com essas dicas.
Nós visitamos diversas áreas e empresas ao longo do nosso processo de consultoria, seja do setor de desenvolvimento de produtos, de programação, recursos humanos, financeiro, vendas, área de negócios, entre outras, e uma dúvida muito comum é:
Será que o formato de SQUADs realmente funciona para organizar times?
Se funciona, será que a forma como estamos fazendo realmente é eficaz? É possível melhorar algo?
Basicamente, as SQUADs são uma estrutura organizacional de pessoas de diferentes habilidades, que possuem um objetivo muito claro: ter mais entrega de valor. Diferente do modelo Tradicional, SQUADS são times multidisciplinares, com menos silos, menos hierarquia, mais autonomia, focada em seus princípios e objetivos, que trabalham para resolver um problema ou desafio dentro de uma organização.
O Spotify criou esse modelo para resolver um desafio que eles tinham na época e, como se popularizou, muitas pessoas começaram a copiar esse formato de organização de pessoas. E assim virou uma manada, ganhou uma proporção gigante, muitos passaram a se organizar em SQUADS, mas sem ter o mínimo de noção de Agilidade, de desenvolvimento de Produtos, acreditando que ter SQUADs já as tornavam empresas ágeis.
Como não existe um órgão que determina e regulamenta essa questão, neste texto, vamos abordar esse tema com base em nossa experiência sobre esse assunto.
Os pilares para bons SQUADs
Mas, de fato, qual o propósito por trás delas? Como citamos acima, as SQUADs são focadas em maximizar a entrega de valor, para isso, são ancoradas por quatro pilares:
– Equipe multidisciplinar
Elas são compostas por pessoas de diferentes habilidades que, juntas, possuem a missão de resolver problemas em uma determinada área da empresa ou desafios no desenvolvimento de Produtos.
– Autonomia
Dentro de uma SQUAD, as pessoas possuem autonomia para dizer como elas resolvem determinado problema. É muito comum ver times nos quais os integrantes apenas executam diversas ações que o chefe determina. Se ainda existe um comando externo com muito controle, você está ferindo esse princípio da autonomia dentro de uma SQUAD.
A ideia é juntar pessoas de diferentes habilidades em um time, tornando-o mais produtivo e criativo possível, dando autonomia para essas pessoas resolverem um problema.
– Objetivo claro
Nada disso funciona se os objetivos não forem claros! Isso mesmo. É preciso ter o propósito dessa iniciativa bem explícito: “qual problema é preciso resolver?”.
– Restrições
Esses limites devem ser criados para que as pessoas possam fazer o que elas quiserem, desde que não infrinjam alguma dessas restrições. Algumas restrições comuns são: determinar um tempo para criar e desenvolver aquele produto; ou quantidade de dinheiro; ou até uma restrição que não fira os princípios da organização.
O conceito de SQUAD vem de esquadrão, pelotão – assim como em uma war room – você monta um esquadrão, no qual “missão dada é missão cumprida”. Ou seja, uma SQUAD no primeiro dia de trabalho é praticamente um “quarto de guerra”: você junta pessoas de diferentes habilidades, com um propósito muito claro, dá algumas restrições e elas trabalham para resolver esse problema.
Mas dá pra escalar esse formato para toda organização?
Sim! O modelo Spotify sugere diversas formas de como resolver um problema muito complexo, com várias SQUADS, através de outras estruturas como tribos, capítulos e guildas… Mas isso rende um outro artigo! Se você quer saber mais sobre como essa parte de escala do modelo Spotify funciona, deixe sua sugestão aqui nos comentários que podemos falar sim sobre isso!
Além de todas as técnicas de escala, o modelo de SQUADs do Spotify também têm uma série de princípios como:
Aversão ao desperdício – no qual buscam continuamente pontos de melhorias para evitar a perda de tempo ou dinheiro;
100% de previsibilidade é igual à zero por cento de inovação – ou seja, se você quer fazer algo realmente inovador, não tem como ser totalmente previsível… É preciso permitir que as pessoas falhem, ou que a falha seja mais bem vista, desde que aconteça para em busca de resolver aquele determinado problema;
Entre outros princípios…
Se quiserem saber mais dos princípios, deixe sua sugestão aqui nos comentários que podemos falar também sobre isso!
Não tente se encaixar em um modelo!
A grande mensagem que quero deixar para finalizar esse texto é a partir de um erro que vi em uma empresa e que cabe trazer aqui para exemplificar algo que você não deve fazer: apenas mudar o nome de “time” para “squad” e não incorporar de verdade os princípios que o modelo possui.
Será que você também não está tentando encaixar sua área ou empresa numa caixa, num formato já pronto?
Não copie o Spotify! Entenda os princípios, os propósitos e aprenda com ele para criar o SEU MODELO, aquele que mais combina com sua realidade. O próprio Spotify não usaria este modelo hoje, pois eles aprenderam com esse formato, usaram várias técnicas como Scrum, Kanban e foram o adaptando para usar da forma que mais cabe atualmente, sempre focando no objetivo de desenvolver bons produtos, com eficiência e eficácia.
Quer alcançar esses resultados, assim como o Spotify, ser mais digital e entregar mais valor à sua organização, mas não sabe por onde começar, nós te ajudamos!
Muitas empresas querem fazer a transformação ágil para que consigam organizar melhor seus times, com o intuito de entregar mais valor e garantir mais vantagem competitiva para a organização. Entretanto, ao longo desse movimento de mudanças, ao passarmos por diversas empresas com nosso processo de consultoria ou montagem de squads, identificamos alguns comportamentos bem comuns.
E resolvemos agrupar esses principais erros durante uma transformação ágil, que estão atrapalhando as empresas a atingirem os resultados e extrair ao máximo os benefícios desse processo. Confira:
Não ter entregas curtas
Tanto no processo de transformação (executamos o processo de Transformação Ágil, de forma Ágil / incremental – clique aqui e saiba mais), quanto no dia a dia dos próprios times que atuam no desenvolvimento do Produto, é essencial ter entregar curtas para ser realmente ágil. São essas entregas, feitas com o fatiamento e a priorização correta, que promovem o mecanismo de inspecionar e adaptar – um dos principais pilares da agilidade.
Pensar somente em processo e esquecer da Engenharia
Outro erro típico que vemos dentro de empresas que estão passando por uma transformação ágil é dar muito foco para o processo e deixar de lado a engenharia de software. Para extrair ao máximo os benefícios dessa jornada de mudanças, é necessário dedicar atenção à qualidade de sua engenharia.
Um dos itens do Manifesto Ágil é justamente ter uma boa arquitetura de software e um design adequado para habilitar as equipes a terem mais entregas mais curtas e que consigam fazer os conceitos de Agilidade ser bem usados dentro da rotina dos times.
Fazer o mecânico e achar que está bom
Outra falha que acontece bastante é achar que os conceitos e pilares da Transformação Ágil ou Digital são apenas mais processos e não dar a correta profundidade que eles possuem. Não dá para ter uma mentalidade tradicional (waterfall), usando apenas algumas técnicas ou processos mecânicos dos frameworks ágeis e atingir os resultados estimados. É preciso ter uma mudança verdadeira de mindset!
Falando ainda sobre profundidade, se você ainda não conseguiu fazer essa transformação em uma célula pequena dentro de sua empresa, não comece a escalar essa iniciativa para toda a organização. Esse processo de transformações, seja ele ágil ou digital, é fundamentado por uma mudança cultural, de virada de chave do pensamento das pessoas… E essa mudança pede que sejam feitas as corretas capacitações, a quebra de amarras que existem no dia a dia dos times – que fazem com que eles não tenham a performance necessária, entre outras características, que levam tempo para serem modificadas. Portanto, é importante saber a hora certa de começar a escalar!
Não medir e aprender durante a transformação
O quinto erro que mais identificamos nas empresas durante a transformação ágil é não medir e não aprender ao longo deste processo. As entregas estão sendo curtas, a engenharia de software está tendo a correta atenção, você está colocando em prática os princípios ágeis da forma certa, está escalando no momento correto, mas, você tem indicadores de tudo isso?
É preciso ser data driven e usar os dados para medir o que está acontecendo. Isso vai te ajudar a saber se você está realmente entregando mais valor para a organização com essas iniciativas. Será que a produtividade dos times está maior? Será que a quantidade de impedimentos está diminuindo? Será que o lead time está diminuindo? Será que os usuários e clientes estão satisfeitos com o produto? Esses são alguns questionamentos que precisam de respostas, dados e análises para te ajudar a medir e aprender com esse processo de transformação.
Pouco foco no produto e no cliente
Quando falamos em transformação ágil, temos três grandes pilares: processos e/ou gestão, engenharia e produto/cliente. Quando você não dá o devido foco no produto e no cliente, você não possui, por exemplo, técnicas de priorização e não sabe o que é realmente valor e o que é sucesso para um projeto. Você pode trabalhar com qualquer método, mas se não dar a devida atenção para o produto e seu usuário, provavelmente, você está gerando muito desperdício no desenvolvimento deste negócio.
O sétimo erro que mais vemos em processos de transformação ágil praticamente consolida todas as falhas anteriores, que é achar que o Agile é um fim e não um meio. Isso é muito comum! Durante nossas consultorias, ouvimos muito as pessoas dizerem que querem ser mais ágeis, querem implantar o modelo Spotify, etc… Mas o que as organizações devem desejar não são esses formatos e sim:
Ter mais resultados
Fazer mais com menos
Aumentar a eficiência e a eficácia
Vantagem competitiva
Fazer com que a área de tecnologia seja protagonista dentro da organização
Entregar mais valor para o negócio
E, para atingir os objetivos acima, a Agilidade entra como um meio! Se para isso, seja preciso usar outros princípios e conceitos diferentes dos Ágeis, tudo bem. O importante nessa iniciativa de transformação é alcançar os objetivos, esse é o fim.
Se você identificou alguns desses erros em seu dia a dia e quer corrigi-los, fale conosco. Podemos fazer esse diagnóstico em sua empresa e ajudá-la a ter mais resultados!
A maneira como desenvolvemos produtos está mudando constantemente. Atualmente empresas em todo mundo estão adotando o desenvolvimento ágil de produtos, utilizando alguns de seus frameworks (Scrum, Kanban, Lean…).
Essa nova maneira de trabalho afeta todos os cargos tradicionais, incluindo Analistas de Testes, ou QA (Quality Assurance).
Neste artigo, vamos falar de uma maneira básica sobre as diferenças entre QAs tradicionais e QAs Ágeis, além de um breve conceito sobre agilidade e o framework Scrum.
Contexto tradicional x Contexto ágil
Em um contexto tradicional, os passos do projeto são planejados com antecedência, antes do seu início. O escopo é definido e não pode ser alterado após iniciado o desenvolvimento. Qualquer mudança requer uma aprovação e um novo contrato entre as partes. A data de entrega também é definida.
Para passar de um estágio para o próximo, é necessário inspeção e aprovação. Esse contexto também é chamado de cascata (waterfall), e geralmente segue o modelo da figura abaixo:
No modelo ágil, o software é entregue em pequenos pedaços, geralmente já funcionais, em um prazo que varia de uma semana a um mês, no caso do framework Scrum. Com estes pequenos incrementos funcionais, é possível se adaptar rapidamente a mudanças. Ser ágil não é ser rápido, mas ser adaptativo!
QA tradicional
Com base a figura acima, vemos que os testes só acontecem no quarto estágio do projeto. Nesta etapa, o software está praticamente pronto.
Geralmente, no contexto tradicional, QAs não têm contato direto com os desenvolvedores. Nesta situação, QAs praticamente caçam bugs, às vezes sendo a quantidade de bugs encontrados, uma medida de desempenho.
Nestas circunstâncias, somente QAs são responsáveis pela qualidade do produto. São eles que garantem que os requisitos foram atendidos corretamente. Qualquer erro no software, ou não conformidade com os requisitos, a responsabilidade é exclusiva da pessoa QA.
O Manifesto dos Testes
O Manifesto Ágil foi criado por um grupo de pessoas que queriam mudar a maneira de como softwares eram desenvolvidos. Alguns anos depois, seguindo os passos do Manifesto Ágil, foi criado o Manifesto dos Testes:
Testar por todas as etapas MAIS QUE testar no final;
Prevenir bugs MAIS QUE encontrar bugs;
Testar o entendimento MAIS QUE checar funcionalidades;
Construir o melhor sistema MAIS QUE quebrar o sistema;
Time responsável pela qualidade MAIS QUE responsabilidade exclusiva de QAs.
QA Ágil
Pegando como referência o Manifestos dos Testes, vamos aqui descrever um pouco de como deve ser o comportamento de QAs Ágeis. Assim como no Manifesto Ágil, valoriza-se mais o item à esquerda que o item à direita – não é uma substituição, você vai continuar fazendo o que está à direita, entretanto, vai priorizar a esquerda (não confundir com política ok!?). Sendo assim, o QA Ágil deve:
Testar por todas as etapas [mais que] testar no final
Os testes devem começar já na reunião de planejamento. A partir dos critérios de aceite definidos, já é possível pensar nos casos/cenários de testes que serão feitos.
Se o time já tem mentalidade voltada a testes e realizam TDD, BDD ou outra técnica, é hora de combinar a divisão dos testes (aplicação da pirâmide ou outra estratégia); definir o que vale a pena ser automatizado; como será a integração contínua, etc.
Também é recomendado que QAs façam code review e pair programming. Muitos bugs e inconsistências podem ser pegos durante o desenvolvimento somente observando o código, o que leva ao próximo tópico…
Prevenir bugs [mais que] encontrar bugs
Com os testes sendo feitos durante o desenvolvimento, a chance de um bug ir para produção é muito menor. Nessa fase a correção do bug pode ser imediata, pois o time de desenvolvimento está trabalhando na funcionalidade.
Dependendo do conhecimento, no momento que o bug é descoberto, a própria pessoa QA pode corrigi-lo.
Testar o entendimento [mais que] checar funcionalidades
A qualidade vai além de verificar se o software funciona como foi descrito. Isso pode ser feito por um robô.
Qualidade também engloba o entendimento da necessidade do usuário e garantir que essa necessidade é realmente o que o usuário precisa. Para isso o usuário também deve participar junto com o time no desenvolvimento, dentro do possível.
Construir o melhor sistema [mais que] quebrar o sistema
Como parte de um time, apontar defeitos e encontrar meios de quebrar o sistema vai contra o objetivo de entregar o melhor software possível. Temos que ter em mente que um software sem defeitos, nem sempre significa um software de qualidade.
O melhor sistema é aquele que resolve as dores de seus usuários. Trabalhe para isso.
Time responsável pela qualidade [mais que] responsabilidade exclusiva de QAs
Colocar a responsabilidade da qualidade em apenas uma pessoa ou área é isentar outras pessoas envolvidas no processo de qualquer problema que será identificado.
Todos que fazem parte, direta ou indiretamente, do desenvolvimento de uma solução devem ser responsáveis por entregar o melhor possível dentro do seu papel.
QAs podem não ser desenvolvedores no sentido de serem a pessoa que codifica a aplicação, mas desenvolvem testes e fazem parte do time de desenvolvimento. Todos que contribuem com o desenvolvimento do produto, incluindo designers/UX, são desenvolvedores e devem se responsabilizar pela qualidade do que vai ser entregue.
Trabalho em conjunto
Como o time é responsável pela qualidade, QAs devem estar presentes em todas as etapas do desenvolvimento, ajudando o time a entregar o melhor produto. A figura abaixo mostra como, em cada etapa da Sprint, QAs podem contribuir com suas próprias responsabilidades e ajudando membros do time.
E também, como parte do time:
ajudam a descobrir o produto certo;
colaboram para especificar;
pensam em exemplos;
refinam as especificações criadas pelo time;
automatizam as especificações;
ajudam a manter a Integração Contínua;
ajudam a manter a Documentação Viva atualizada e acessível.
QAs tradicionais x QAs Ágeis
Resumindo em tópicos as diferenças entre QAs tradicionais e QAs Ágeis são:
Além disso, QAs Ágeis:
estão sempre aprendendo novas habilidades e tecnologias, se adaptando a mudanças;
praticam comunicação clara e efetiva, colaborando com pessoas técnicas e não técnicas;
entendem do negócio, defendem o produto e colaboram com o cliente;
disseminam a cultura de qualidade e cuidam da saúde do time;
promovem e obtém feedbacks, tendo coragem de expor o que errado e elogiando o que está certo;
se mantém simples e auto-organizado, não dependendo de instruções para realizar suas atividades;
gostam do que fazem 🙂
E você, está no contexto tradicional ou ágil? Se no tradicional, gostaria de ir para o ágil? Se no ágil, faz o foi descrito no texto ou já está além? Deixe um comentário aqui!
Considerada uma das 15 profissões emergentes de 2020 no Brasil – segundo um estudo publicado pelo LinkedIn, o Agilista, ou Agile Coach, ou Scrum Master, ou Agile Master, ou Agile Expert, entre outros nomes dados ao papel do especialista em Agilidade, é um dos trabalhos que mais cresce nos últimos tempos… Mas, você sabe como é a jornada do Agilista, seu desenvolvimento e/ou crescimento desta carreira? Ou qual o ciclo de vida desse papel dentro de um time?
Foi pensando nisso que, nós, Ricardo Avigro e Fabricio Pequeno, resolvemos escrever esse artigo! A ideia da Jornada do Agilista não surgiu para ser uma jornada definitiva, ela foi idealizada a partir do momento no qual foi perceptível um comportamento recorrente em times ágeis.
Não significa também que, seguindo essa jornada, você vai conseguir sucesso absoluto. Esse caminho defende que o Agilista tem um ciclo de vida a cumprir dentro de um time e expõe alguns marcos importantes, no qual devemos ficar atentos antes de cobrar maturidade e auto-organização das pessoas.
Pense que, por alguma vez, conversando com agilistas, você se deparou com dúvidas sobre “como é o nível de sucesso desta função?”. O papel de Agilista sempre deixou muito vago como você pode fazer as coisas e o quanto você pode fazê-las…. Não estamos aqui para limitar sua criatividade, nem o trabalho, muito menos o histórico de cada um, porém é muito importante que a gente tenha um rumo para seguir. E, com isso, nasceu a essa jornada, uma entre tantas outras que pode ser um bom caminho a ser tomado.
… Agora vamos ao que interessa, a Jornada do Agilista
Muita coisa acontecendo, correria, entregas parciais, atividades entrando no meio da sprint, desenvolve nessa sprint e na outra testa, “daily, para que isso?”, “retro só sai problemas direcionado a pessoas e não tem nada de positivo”, mas, no geral o time está bem, faz entregas e é auto-organizável para realizar suas atividades.
Identificou alguma coincidência com algo citado? Bom, nós já passamos por algumas situações assim, e aí pensamos: “O que fazer? Por onde começo? Como agir?”. Pensando nisso, mapeamos o que chamamos de “Jornada do Agilista”, com base em nossas experiências que deram certo.
Etapa 1 – ENTENDIMENTO
Cheguei em um time, e agora? Entendemos que é preciso fazer uma leitura do ambiente. Ok! Você já leu isso em todos os lugares, por isso, vamos lá… Como fazer essa leitura ou como chamamos, “Entendimento”, que é dividido em quatro etapas:
1 – Entenda quem é o seu time, quem são as pessoas, converse com cada um e ouça seus desafios, seu momento e suas dificuldades, sem julgamentos! Entenda o perfil técnico também, isso é muito importante. Não precisa entrar no detalhe de código, mas é bom saber minimamente;
2 – Analise o fluxo de trabalho atual. Alguns times acham que tem um fluxo de trabalho quando na verdade é um go horse disfarçado e, na loucura do dia a dia, não conseguem ver o quanto geram de retrabalho para eles mesmo. Examine também as restrições, pois muitas empresas têm processos originados do modelo tradicional e, algumas vezes, precisamos conviver com isso por um certo tempo.
3 – Entenda o backlog do produto e sua priorização. Sim, o Agilista pode ajudar o Product Owner com o backlog, questionar as priorizações e ajudar a gerar mais valor nas entregas, e isso influencia diretamente no próximo ponto.
4 – Saiba o propósito do time. Um time sem propósito vira um time tarefeiro, uma fábrica de software e isso desmotiva as pessoas.
Não existe um tempo ou uma ordem para toda essa análise, colocamos assim pois foram os pontos que achávamos mais importante e que davam base para a ação seguinte.
Etapa 2 – AÇÕES
Depois que você tiver todo esse entendimento, chega o momento mais desafiador e pode ser contraditório com algumas literaturas, mas, é o momento de “AGIR”!
Identifique os problemas, monte uma proposta e apresente para a hierarquia da empresa – é muito importante estar sempre alinhado com seus superiores.
Apresente essa proposta para o time e busque aliados para implantação deste plano. Embora muitos falem o contrário e na agilidade pregamos que as mudanças fazem parte, as pessoas tendem a resistir à elas, por isso, quanto mais aliados você tiver, melhor para a implantação da proposta.
Deixe essa proposta visível para todos, compartilhe a jornada de desenvolvimento, acordos de trabalho e o que mais achar necessário.
Um dos pontos mais difíceis e cruciais desta etapa é identificar os sabotadores. Nem todos estão preparados para a mudança, seja por qual motivo for – e, sim, sabotadores existem e temos que lidar com eles. Como? Elimine-os!
Nem sempre um sabotador será uma pessoa, às vezes pode ser um processo não muito inteligente que gere desperdício, mas no geral são pessoas, e podem ser pessoas do time, de outras equipes que temos dependência ou até mesmo um gestor desconfiado e centralizador.
Essa é a parte mais complicada, pois não lemos isso (pelo menos nunca li diretamente). Mas, na prática, o sabotador se tornou um impedimento na melhora do fluxo de trabalho, implementação da proposta e/ou dia a dia do time. E falando em impedimento, nós, Agilistas, removemos como ninguém!
Para cada tipo de sabotador, temos um tipo ação a ser tomada:
Uma Pessoa do Time: Já li que o time deve ou não permitir uma determinada pessoa ali e, nós como Agilistas, só atuamos quando o time sinaliza. Porém, algumas vezes o time não tem maturidade para isso ou ainda não percebeu que determinada pessoa é um sabotador. Por isso, você Agilista, sim, você mesmo, deve colocar seu casaco de “general” e determinar que o sabotador seja retirado do time. (a forma de fazer isso dependerá da autonomia que terá dentro da organização, porém deve reportar o caso ao gestor direto da pessoa para que a ação seja tomada. Lembrando que deve sempre ter exemplos das situações que o levaram a tomar essa decisão e após feedbacks com esse “sabotador”.)
Gestor centralizador: O ideal é entender e minimizar o medo ou insegurança que ele tenha sobre o trabalho, seja falta de visibilidade, achar que o time faz muita reunião e “coda” pouco, achar que a falta de um cronograma prejudica a visão, enfim o ideal é entender e remover esse “sabotador”, pois mesmo de forma inconsciente ou indireta essas atitudes atrapalham o andamento do fluxo e consequentemente as entregas.
O que queremos dizer aqui é que, independente do que ou quem esteja atrapalhando, o andamento do fluxo e proposta estabelecida, deve ser removido.
Outro ponto importante é sempre estimular o time para ações que garantam o fluxo da jornada de desenvolvimento, uma vez estabelecido, ele deve ser cumprido. Considere sempre, os refinamentos e tenha as dependências mapeadas. Elas serão extremamente importantes para o engajamento do time em relação a Qualidade e Entrega – são coisas que não podem ser negociadas e uma não caminha sem a outra.
Nesse ponto que entraremos a seguir – que também é polêmico, pois muitos dizem que a área de Produto não faz parte do papel do Agilista, mas, na prática, como trabalhamos junto com a pessoa que energiza o papel de Product Owner, é muito importante orientar e ajudar. E como podemos fazer isso?
Primeiro, é preciso garantir que o backlog esteja claro, disponível e entendido pelo time, e depois para toda a empresa.
Em seguida, devemos também deixar transparente para todos as entregas do time.
Etapa 3 – DISSEMINAÇÕES
Tendo a visibilidade do backlog e das entregas do time, começamos a entender e questionar se essas entregas estão alinhadas com o propósito do produto. E, para que isso seja possível, precisamos entender e conhecer nosso cliente, olhar pela ótica de UX e UI, para saber como é sua jornada e sua experiência usando este produto.
Neste momento, é muito importante que você e a pessoa que atua como PO fiquem próximas de que faz o papel de Designer e do especialista da Área de Produtos. Aliás, essa parceria é essencial em todas as etapas e, levar todo esse entendimento para o time para que participem das decisões estratégicas, traz um senso de “dono do produto”, e você verá que isso fará toda a diferença.
Por fim, pensando sempre em visibilidade, criamos um painel no qual é possível mostrar todas as entregas do produto, voltadas para as experiências do usuário, independente de times.
Literatura x Realidade
Algumas literaturas trazem modelos do que devemos seguir, eventos com sequências nas quais, independente de serem eficazes ou não, são importantes de se fazer. Não achamos que isto está errado, a questão é que poucas vezes vimos uma orientação realmente voltada ao Agilista nisso tudo….
Subentende-se que o Agilista deverá saber como se comportar e que a evolução do time irá acontecer perfeitamente como descrito a partir das situações propostas. O entendimento dos ciclos em muitas vezes é aplicado para produtos e para a maturidade do time, porém não é aplicado para a evolução do Agilista sobre a ótica de progresso do time como um todo.
Nossa proposta é de conscientizar a todos que existe um ciclo de vida para a atuação do Agilista dentro de um time e que, esse ciclo, a partir de sua completude, não indica que uma deverá ter uma promoção e sim um critério de sucesso, visando o direcionamento de carreira. Assim, podemos buscar um outro time no qual nossa atuação terá resultados mais expressivos – visando a maturidade como um todo em uma empresa.
Essas foram algumas ações que adotamos e nos fizeram alcançar sucesso nos projetos que atuamos. Claro que nem sempre acertamos e aqui contamos apenas o que funcionou…
Deixe nos comentários se já passou por algo parecido e o quanto essa jornada se aplica a sua realidade. Valeu, até a próxima!
