Author: Agile.Inc

by Agile.Inc Agile.Inc Nenhum comentário

Treinamento ou consultoria? 8 dicas para descobrir a jornada para implementar os métodos ágeis

Saiba qual a melhor solução para o cenário que você se encontra e alcance os reais benefícios de ser ágil

Por Antonio Costa

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.

Treinamento ou consultoria 8 dicas para implementar métodos ágeis em uma empresa

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. 

Clique aqui e tenha seu diagnóstico rápido 

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. 

Conheça os treinamentos de Scrum Master, Agile Leadership Essentials e Scaled Professional Scrum.

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.

Entenda como funciona nossa Consultoria Enterprise

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.

Leia também:

by Agile.Inc Agile.Inc Nenhum comentário

Aumente as chances de sucesso na transformação ágil com essa dica

Aprenda com a dinâmica “Why Agile” a entender os reais motivos pelos quais você quer ser mais ágil e extrair ao máximo os benefícios desse processo 

Por Antonio Costa

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…

Foto conceitual com carros ágeis

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.”

https://www.youtube.com/watch?v=lTVQ6y_wnXI&feature=youtu.be

Replique essa técnica em seu processo

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.


Leia também:

by Agile.Inc Agile.Inc Nenhum comentário

Como as metodologias ágeis podem organizar processos de trabalho

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 de Processo Ágil Organizado usado em uma área de Marketing
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.

Quadro Kanban para gestão visual em um time ágil em uma área de Marketing

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?

Leia também:


by Agile.Inc Agile.Inc Nenhum comentário

Métodos Ágeis: Como ter um time mais eficiente e ágil como um todo

Entenda como os métodos ágeis podem ajudar diversas áreas e times a ter mais produtividade e organização

Métodos Ágeis funcionam para times de Marketing, RH, Vendas, entre outros

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.

 

Leia também: A agilidade funciona para áreas como Marketing, RH, Jurídico ou Operação?

 

 

by Agile.Inc Agile.Inc Nenhum comentário

Será que SQUADs realmente funciona para organizar times?

Entenda como essas equipes multidisciplinares ajudam uma empresa a entregar mais 

Por Antonio Costa
Entenda como o formato de organizar times em SQUADs é benéfico para uma empresa entregar mais, ser mais eficiente e produtiva

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. 

Leia também: As 5 disfunções de um time e como evitá-las para ter pessoas mais engajadas

Resumindo…

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!

Leia mais:

Assista:

https://youtu.be/-GPItbQKp8M
by Agile.Inc Agile.Inc Nenhum comentário

7 maiores erros em um processo de Transformação Ágil

Entenda como essas falhas estão atrapalhando os resultados de sua empresa durante o processo de Transformação Ágil

Por Antonio Costa

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!

Quer realmente mudar o mindset de sua organização e ter times mais engajados e com mais produtividade? Clique aqui e agende uma conversa conosco.

Escalar muito cedo

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.

Leia mais: Você parece Ágil, mas não tem foco no Cliente? Provavelmente está perdendo o jogo!

Achar que o Ágil é um fim e não um meio

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!

by Agile.Inc Agile.Inc Nenhum comentário

Você sabe qual a diferença do QA Tradicional e do QA Ágil?

Entenda como o papel do Analista de Testes ou QA é determinante para a qualidade de produtos digitais

Por Rodrigo Matola
Pessoa digitando num computador

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.

Leia também: O que é de fato a Transformação Digital?

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!

by Agile.Inc Agile.Inc 2 Comentários

A Jornada do Agilista: qual o ciclo de vida desse papel dentro de um time?

Entenda melhor como é o começo, meio e o fim da atuação do especialista em Agilidade dentro de time de desenvolvimento de produtos digitais

Por Fabricio Pequeno e Ricardo Avigro
A Jornada do papel de Agilista e seu ciclo de vida dentro de um time Ágil

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:

Fluxo para explicar a fase de entendimento de times ágeis

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!

 
 
E se você precisa de bons Scrum Masters e Product Owners, nós podemos te ajudar! Clique aqui e agende uma conversa com nossos especialistas que te ajudamos a selecionar os melhores profissionais.
 
 
by Agile.Inc Agile.Inc Nenhum comentário

Você parece Ágil, mas não tem foco no Cliente? Provavelmente está perdendo o jogo!

Entenda como o foco no usuário e em sua jornada deve ser o ponto central do desenvolvimento para um produto digital de sucesso

Por Antonio Costa
Placar do jogo

Muitas empresas que estão no processo de Transformação, seja Digital ou Ágil, estão cometendo um erro muito grave em sua esteira de Desenvolvimento de Produto. Existe um grande foco no Produto e um baixo foco no Cliente. Isso faz com que a organização até tenha entregas mais organizadas e mais rápidas, mas ainda pouco eficazes. 

E sabe por que isso acontece? Às vezes a empresa tem um grande foco em ganhar dinheiro e não percebe que se dar mais atenção para a dor do cliente e atacar essas dores de forma mais organizada, o lucro vem por consequência.

Para isso, é necessário haver uma mudança de pensamento, na qual chamamos por aqui de “Foco em Produtos para Foco em Jornada e Cliente”. Vou explicar melhor no que consiste esse conceito.

Foco em Produto

É quando uma organização olha apenas seu produto, esquecendo seu cliente – o produto vem em primeiro lugar. Pode ser que ela até tenha um time ágil ou práticas ágeis, mas provavelmente o pensamento predominante venha a ser o pensamento tradicional, que faz o time buscar a eficiência operacional. Empresas com foco em eficiência demasiada, ou com grande foco no produto possui algumas características, como:

  • Começar a análise para a criação de produto ou funcionalidade, pelos sistemas internos – o sistema interno vai moldar a solução;
  • Focar em fechar requisitos, ter tudo detalhado;
  • As áreas de Negócio e TI trabalhando ainda separadas, onde não existe grande confiança entre elas;
  • Times de desenvolvimento olhando apenas sua entrega, buscando entregar mais tarefas;
  • Desalinhamento dos canais, pois como o foco é em eficiência, não precisa um canal esperar o outro;
  • Grande foco na produtividade dos times;
  • Mudanças de requisitos não são bem-vindas;
  • Foco em lançar novas funcionalidades, sem medir o que já existe;
  • Entregar o produto é mais importante que a qualidade do que já está feito.

Essa lista pode ser extensa e caberia aqui um novo texto para enumerar mais características e até detalhá-las…. Entretanto, vamos falar do que realmente importa: o modelo correto – Foco na Jornada e no Cliente.

Foco em Jornada e Cliente

Quando um time foca na jornada e no cliente, significa que o usuário final REALMENTE está no centro de todo desenvolvimento de um produto. Entenda um pouco melhor sobre as características desse time:

  • Começa pela necessidade do cliente para definir a solução viável;
  • Têm clara a jornada dos usuários e personas;
  • Áreas de Negócio e TI trabalhando diariamente em conjunto, de forma colaborativa;
  • Times orquestrando as entregas, com foco em valor;
  • Experiências iguais em todos canais (omnichannel);
  • Ciclos curtos para coletas de feedbacks com clientes;
  • Análises baseadas em dados dos clientes;
  • Abertura para mudança de escopo;
  • Foco no cliente e também em suas emoções;
  • Objetivos da empresa com foco em negócios ou cliente, e não metas para entrega de projetos;
  • Grande preocupação com a qualidade do produto (pois se você lançar algo que não funciona direito, nada agregará para o cliente;
  • preocupação em medir as features utilizadas ou não utilizadas e simplificar as funcionalidades – ao invés de lançar mais coisas novas;

Essa lista também não acaba por aqui, mas nela constam os principais pontos que vemos no mercado. A grande mudança, em termos gerais, consiste em se preocupar com a experiência do cliente, na sua jornada ao usar aquele produto digital.

Exercício

Visto os pontos acima, sugiro que você volte nessas listas e faça uma reflexão: “quantos itens acima você consegue identificar em seu time? Eles estão trabalhando com foco no cliente ou mais foco no Produto?

Sugiro também você se colocar no lugar do cliente, mas da seguinte forma, por alguns instantes: 

  1. Lembre-se de algum serviço ou produto que você consumiu recentemente, que proporcionou uma experiência muito desagradável para você… Lembre-se antes de seguir.
  2. O que você sentiu? Raiva, impotência? Pensou ou falou mal desta marca? Qual foi sua atitude?
  3. Agora se pergunte: será que o produto que você está criando, pode estar gerando esses mesmos sentimos em seu usuário? Ele pode estar reclamando da sua marca ou está desapontado com a experiência que teve ao usar esse produto?

Por fim, tenha em mente que o cliente vai consumir seu produto não por que você usa Scrum ou Kanban ou qualquer outro método ágil; não por que você possui tecnologias legadas ou disruptivas; o cliente vai comprar seu produto ou serviço, por que ele gera algum benefício para ele ou resolve uma dor do seu dia a dia.

E se você quiser tirar alguma dúvida ou falar mais sobre esse assunto, deixe seu comentário aqui ou fale conosco!

by Agile.Inc Agile.Inc Nenhum comentário

Não há nada tão inútil do que fazer com grande eficiência, aquilo que não deveria ser feito

Seu time lança diversas funcionalidades, trabalha muito, mas os resultados não aparecem? Entenda agora as principais causas tudo isso

Por Filipe Machado e Thiago Fregni

Em qualquer negócio, seja ele um produto digital ou não, uma das principais preocupações é atender as necessidades dos stakeholders e isso acaba se tornando um dos grandes objetivos a serem cumpridos. Com isso, o time trabalha muito, se empenha em lançar várias funcionalidades, mas vai deixando de lado uma meta muito importante: a maximização de valor e o retorno de investimento daquela iniciativa.

Ou seja, por mais que a Agilidade tenha sido implantada e as entregas estejam acontecendo com mais velocidade, ainda há stakeholders super descontentes. “Não há nada tão inútil do que fazer com grande eficiência, aquilo que não deveria ser feito.” Essa frase do Peter Drucker é uma daquelas que pode resumir de forma simples esse cenário. O time está trabalhando bem, com diversas funcionalidades em produção, mas será que estão fazendo algo realmente útil?

Isso soa comum para você? Pois realmente acontece em muitos negócios que estão iniciando uma transformação digital e por três principais motivos:

  • Maximização de valor e o retorno de investimento

Geralmente, o Product Owner fica muito preocupado em atender os stakeholders e acaba deixando de lado uma das suas principais responsabilidades que é a maximização de retorno do investimento.

  • Senso de propósito

É comum o time (Agilista, PO e Devs) não saber de forma clara qual o objetivo do produto ou não ter visão sob o motivo de estarem trabalhando em determinada demanda. Sabem o que é, como deve ser feito, mas não o por quê – não possuem senso de propósito!

  • Discovery/Ideação/Upstream 

A maximização de valor do produto, ou seja, aquilo que o cliente recebe na ponta, precisa passar por um processo de discovery e refinamento, antes de iniciar o desenvolvimento. E não é sempre que isso acontece!

Mas qual é a causa raiz desse problema?

É possível identificar alguns sinais que ocasionam essas situações descritas acima. Os principais são: 

  • Baixa autonomia do Product Owner, que depende de outras pessoas para tomar decisões e esclarecer detalhes;
  • Product Owner que não tem a competência correta;
  • PO tirador de pedido (PO Proxy/Escriba), que não tem ownership do produto. Anota os pedidos sem entender o porquê da solicitação e quais os resultados esperados;
  • Time se preocupa em encher o capacity. Ou seja, durante reuniões de Planejamento, existe uma preocupação maior em “arrumar” backlog suficiente para deixar todos ocupados, do que gerar realmente valor para o cliente;
  • PO que não sabe quanto custa cada PBI e não tem noção do custo do time, o que o impossibilita de fazer trade-offs baseados no RoI;
  • Times que não possui objetivos claros, impossibilitando-os de fazer escolhas e manter o foco no que mais gera valor;
  • Não possui Discovery (UX). Ou seja, assim que a solicitação chega, vai direto para o time desenvolver. Não existe um processo no qual o cliente é envolvido e hipóteses são tratadas como verdades;
  • Não existe uma visão Customer Centric, focada no consumidor/usuário.

Bom, se você tiver identificado alguns desses pontos acima em seu time de transformação, você está cometendo esse erro. E isso pode ser nítido em um time ágil que ainda está no paradigma tradicional de trabalho.

Resolvendo essas questões 

Quando identificamos esse cenário – que é bem comum, fazemos um trabalho bem intenso de coaching com o Product Owner, com o Scrum Master e com os stakeholders. Para isso, executamos técnicas como:

Criar um time de discovery: a fim de descobrir que funcionalidades devem ser implementadas para atender as necessidades dos usuários;

Técnicas de ordenação de backlog: o backlog deve estar ordenado e tais técnicas nos ajudam a ordená-los de acordo com os objetivos a serem alcançados;

Criar bem claramente um esteira ágil utilizando Flight Levels: esta técnica dá visibilidade de portfólio até chegar na mão do usuário final;

Organizamos os times por Value Stream ligados ao usuários, com objetivos claros, utilizando OKR´s, por exemplo;

Definição de objetivo do produto e deixar o claro qual o valor (aumentar 10% as vendas, aumentar a taxa de conversão em 5%, entre outros) esperado a ser atingido por aquele item, mais valor de itens;

Roadmap: uma visão geral dos próximos passos do produto;

Utilizar dados para tomada de decisão em itens de backlog;

Criação de conceitos de hipóteses: uma ótima forma de trabalho que ajuda a validar as hipóteses é chamada HDD (Hypothesis Driven Development). Este método auxilia na escrita do nosso backlog, orientado à validação de hipóteses.

No geral, tentamos dar o correto propósito para o time como um todo, ligado a valor para o cliente ou negócio… Por que, quando não se sabe onde quer chegar, qualquer caminho serve. E, por isso, o trabalho se torna eficiente, mas não realmente eficaz!

Mais valor entregue, com menor investimento

Solucionando essas falhas durante o processo de desenvolvimento de um produto com um time ágil, é possível ter diversos benefícios, entre eles:

  • Conseguir trabalhar no processo empírico, focando sempre no objetivo desejado;
  • Se torna mais fácil gerenciar a ansiedade dos stakeholders quanto aos resultados;
  • O stakeholder fica mais contente com a entrega, pois ela está ligada ao propósito, com foco em gerar realmente valor com a iniciativa;
  • O clima de confiança do stakeholder com o time melhora;
  • Resumindo, mais valor entregue, com menor investimento e foco na maximização de valor e o retorno de investimento da iniciativa.

Esperamos que você consiga aplicar essas sugestões em seu dia a dia. Qualquer dúvida, estamos à disposição para ajudar… É só entrar em contato conosco!

Top