< Insights

Três modelos de Metodologia Agile para começar com o pé direito

  • Metodologias

Sabemos que na teoria tudo funciona muito bem. Mas para implantar Metodologia Agile dentro de uma empresa é necessário um primeiro passo e talvez, o mais difícil: mudar a mentalidade e cultura.

Sabemos que isso não vai acontecer em uma segunda-feira cheia de bugs para resolver e projetos para começar.

Pensando nisso, elaboramos este artigo com conteúdo compartilhado pelo Agile Coach da Objective, Alexandre Nodari, com três modelos prateleira para você implantar Metodologia Agile o quanto antes.

O conteúdo foi apresentado no Agile Trends, onde o Alexandre abriu a sua palestra citando que “não existe uma verdade absoluta, tudo depende de contexto”.

Portanto, a dica logo de cara foi: analise a estratégia e o contexto em que você está inserido antes de acreditar fielmente no conjunto de práticas e modelos de Agile que vamos apresentar.

Antes de continuar, reforçamos que este artigo é destinado para os seguintes cenários:

  • quem não usa ágil só leu ou recém adotou, mas ainda está muito incipiente;
  • quem já adota ágil e percebeu o time se mexer mas ainda não consegue converter isso em ganhos de métricas efetivas para seus clientes.

Se identificou? So, let’s go…

Começando do zero a implantar Metodologia Agile

Você ainda não conhece o produto ou projeto que vai iniciar? A grande sacada aqui é não começar indo na direção errada. Explicamos: Quando abordamos eficiência e eficácia, muito utilizado nas práticas ágeis, uma afirmação bastante citada diz “é mais importante dar um passo devagar na direção certa do que sair correndo na direção errada”.

E seguindo nesse sentido, o Agile Coach conta da sua experiência: “a primeira coisa que se percebe são muitos times começando em determinados projetos ou buscando desenvolver um produto sem entender e fazer uma avaliação de qual o escopo ou projeto deste produto”.

Aqui a dica foi entender um pouco sobre Design Thinking. Na palestra, a sugestão do Alexandre é sempre que começar algo novo ou desenvolver uma versão nova de produto em produção, avaliem o escopo usando um conjunto de práticas do Design Thinking.

Com a apresentação de três práticas, ficou bem claro e apresentamos a seguir:

1- Imersão

Entender o que estão fazendo. Aqui podemos destacar a primeira fase de design sprint, que acontece no primeiro dia, “compreender”.

No Lean Inception, do Paulo Caroli, existem as fases de visão de produto e o  

“é/não é, faz/não faz”.

Podemos afirmar que o design sprint acontece em aproximadamente uma semana e o inception em até menos de uma semana, ou seja não, é um desperdício de tempo é um investimento para entender o produto.

Confira nosso eBook completo sobre Lean Inception aqui

2 –  Inspiração

Agora que já foi entendido o que é o problema e analisamos os usuários, como resolver o problema detectado?

No Lean Inception, este momento aparece como fase de identificação de personas e mapeamento de usuários de jornada. Na Google Design Sprint são o segundo e terceiro dia: Divergir e Convergir.

3 – Implementação

No Lean Inception é mencionado a definição (o desenho) do MVP.

O MVP que, apesar de não ser uma prática exclusivamente do Lean Inception, está mencionado como uma possível saída para esses dois ou três dias.

Já no Google Design Sprint, os últimos dois dias são para prototipar e validar.

No Extreme Programming é feito o uso das Spike Solutions, que são pequenos protótipos de códigos que podem ser descartados só para validar algum desafio técnico ou alguma expectativa de negócio que você tenha.

Experiência Objective na aplicação de Metodologia Agile 

Falando um pouco da experiência da Objective em projetos na linha do Design Thinking.

Optamos por essas ações já que para a aplicação é necessário um investimento pequeno, utilizando aproximadamente 40 horas do time, com práticas bem conhecidas.

Além disso, quando a empresa adota essa prática com a Objective, tem como ganho o seu protótipo ou ao menos o escopo bem definido e relativamente fatiado para começar uma primeira sprint, caso trabalhem na linha Scrum.

Execução da Metodologia Agile –  Já existe um escopo inicial

Com um escopo claro e um time preparado para trabalhar nesse projeto? É possível que essa equipe trabalhe exclusivamente para esse projeto em específico? Se sim, recomendamos para esse segundo modelo uma linha de pensamento de entregas interativos e implementáveis.

Mas algumas pessoas perguntam: Como fazer isso? A primeira prática sugerida na palestra é o fatiamento de escopo. 

Neste momento entra uma das maiores chances de um time adotar uma metodologia ágil e não conseguir – dentro das sprints ou outras iterações propostas pelo projeto – realizar as entregas dentro do prazo. É exatamente quando as equipes desmotivam e preferem reverter a adoção da Metodologia Agile

Se o Product Owner, sendo apoiado pelos líderes técnicos do projeto e pelos analistas de testes, tivessem feito um bom fatiamento deste escopo, reduzindo a granularidade do projeto, isso ajudaria muito a tornar a equipe mais ágil.

Atenção: agilidade é: obter feedback! E o melhor tipo de feedback que podemos ter é entregar software para o cliente e receber dele as respostas e indicações do que acertamos e do que erramos para corrigir.

Outra prática também indicada é formar um ciclo de feedback do processo. Em que os colaboradores já começam a olhar em como podemos melhorar. Na verdade, mais do que isso, entender como o processo e como essas mudanças e práticas estão servindo.

Todas as metodologias ágeis indicam que em determinado momento é necessário parar e pensar como o seu projeto e o seu processo está.

Normalmente, no dia a dia a gente se vê sugado por um redemoinho de tarefas e raramente paramos para pensar se estamos fazendo a coisa certa.

Sempre buscamos ser mais rápidos e resolver mais problemas. Mas não conseguimos parar para pensar em uma melhoria de eficácia ao invés de eficiência. Melhorar o nosso processo ao invés de fazer simplesmente mais do nosso produto.

Quando falamos do Scrum essa cerimônia se chama retrospectiva. Já no Kanban uma boa forma de obter isso é com o quadro que oferece a gestão visual, além de buscar kaizens em cima das métricas tirada a partir do quadro de permite a gestão visual.

Vale destacar a facilidade que se costuma observar nas equipes que fazem retrospectivas em reclamar do que está ou deu errado. Mas, investem muito pouco tempo, esforço ou até recursos financeiros para efetivamente atacar os problemas levantados.

Apenas visualizamos uma prática que funciona nesse sentido: tempo de qualidade nas atividades. É bom lembrar que não é a simplicidade do Scrum, das práticas, das cerimônias, ou dos papéis que são importantes na adoção de uma Metodologia Agile, e sim a não preparação  da mentalidade do time antes de fazer.

Aplicação da Metodologia Agile – quando não tem um escopo bem definido

Apenas para reforçar, este cenário é considerado em qualquer situação que o time seja interrompido constantemente por bugs, problemas de operação, entre outros, e não conseguem se concentrar no escopo dentro da mudança.

Nesse caso, é recomendado uma linha de pensamento orientada ao fluxo. São time que estão buscando continuidade, querem entregar novas qualidades, correções de bugs e resolver problemas de operação.

A primeira prática para esses time é: visualizar o fluxo de trabalho e entender realmente o que é feito e qual o resultado de cada etapa do trabalho. A ideia é deixar claro para todo o seu time quais são as etapas de trabalho, os tipos de tarefa que executam.

Para ações que deem resultado, é necessário a participação do time por completo. No caso do Kanban, é fundamental o papel do Service Delivery Manager.

Outra ação é limitar o trabalho em progresso (WIP) e, muitas vezes nesses times, a reclamação mais comum é “estamos sobrecarregados”. Para isso, vale analisar: “se você tem três tarefas que levam um mês, fazê-las em paralelo significa uma demora de três meses para entregar os projetos. Mas se você tocar os projetos de forma linear, com limite de trabalho, você consegue entregar uma atividade por mês e assim eliminar as pendências.”

A experiência que temos na Objective, apresentada pelos nossos Agilistas, é que limitar um trabalho por progresso muda drasticamente uma equipe. Vale a pena tentar!

Um detalhe importante: deixe bem claro para as pessoas que se envolverem no projeto e para o próprio time quando cada uma daquelas cartelas está pronta para ser começada, quando ela pode passar de cada uma das colunas e quando ela está pronta para ser entregue.

Essa dica ajudará muito os times a não passar atividades de cartelas e precisar colocá-las aos antigos postos. Também foi mostrada como ação a prática de medir e gerenciar o fluxo.

Existem três métricas simples que normalmente adotamos na aplicação de Metodologia Agile para nossos clientes. São elas:

  • Eficiência de fluxo: só de olhar para o mapeamento de cadeia de valor já é possível fazer um cálculo de 15 a 20 min da eficiência do fluxo, apenas somando os esforços de cada uma das etapas e dividindo pela soma dos prazos;
  • Lead time: o tempo de comprometimento com a atividade;
  • Vazão: a atividade sendo entregue no tempo exato que a equipe previu e colocou como meta no quadro.

Depois desses modelos e frameworks de Metodologias Agile citadas nesse artigo, com qual você começar na próxima segunda-feira? Se precisar de ajudar de nossos especialistas, ou quiser conversar mais com eles, clique aqui e marque um café!

Sugira um artigo

    Para enviar o formulário é necessário o aceite das políticas.

    Insights do nosso time

    Obtenha insights do nosso time de especialistas sobre metodologias de desenvolvimento de software, linguagens, tecnologia e muito mais para apoiar o seu time na operação e estratégia de negócio.