Metodologias Ágeis: 8 coisas que eu posso estar fazendo errado.

Sharing is caring!

Recentemente li um artigo que alertava sobre um lado sombrio das metodologias ágeis, e enquanto pensava sobre a importância desse tipo de questionamento, mais uma vez fiquei incomodado com a frequência que vejo alguns insucessos acontecendo em nosso meio.

A verdade é que existem inúmeras empresas (principalmente do interior) que já tentaram aplicar essas metodologias em seu ambiente de trabalho mas não conseguiram resultados satisfatórios. Eu mesmo conheço várias que desistiram do Agile e voltaram para o modelo cascata ou inventaram sua “própria forma” de trabalhar se baseando em algumas técnicas e práticas que existem por aí.

Esse post foi feito para essas pessoas, que encontraram ou encontram dificuldades em fazer as metodologias ágeis funcionarem e alcançarem o tão sonhado “dobro do trabalho na metade do tempo”. Eu me simpatizo com vocês porque no início da minha carreira, cheio de vontade de fazer as coisas acontecerem mas sem recursos e pouco apoio, sendo obrigado a fazer “SCRUM clandestino” eu tive muita dificuldade de encontrar pela internet algum tipo de material honesto, sem sensacionalismo nem publicidade, que apresentasse os fundamentos corretos que eu só fui descobrir quando comecei a investir dinheiro para aprender sobre o assunto.

Eu não pretendo falar sobre o que é Agile nem fazer propagandas para te convencer a usar, espero que se você esteja lendo isso é porquê você já trabalhou ou trabalha em ambientes ágeis e tem dificuldades em conseguir resultados incríveis com essas metodologias.

O meu objetivo é desmistificar alguns conceitos e balançar essa sua cabecinha para te fazer enxergar as coisas de um outro ponto de vista, e esse mind-blowing será fantástico pra você.

Por isso pegue uma xícara de café, ajuste a cadeira em uma posição confortável e aproveite o conteúdo 😉

1 – SCRUM não é metodologia

Poise amigos, essa é a primeira decepção do dia: O SCRUM é um Framework e não uma metodologia, e esse é um assunto difícil de compreender, principalmente quando se está aprendendo sozinho, mas  é importantíssimo entender a diferença entre os dois.

Como um Framework, o SCRUM se posiciona como uma estrutura (tradução de framework) para servir de pilar na construção da metodologia da sua empresa. Ele é apenas uma base, um conjunto de eventos, papéis, artefatos e fluxos para que o seu time possa usar como mapa para moldar a direção que a evolução da equipe precisa seguir.

De grosso modo, quando trabalhamos com uma metodologia nós esperamos que ela nos diga tudo o que precisamos fazer, como devemos trabalhar, como devemos agir em determinadas situações e etc, e o SCRUM definitivamente não faz isso.

Se não acredita em mim, dá um olhada no SCRUM Guide que é o documento oficial de especificação do SCRUM. Você vai perceber que ele não diz nada sobre User Histories, nem sobre Planning Poker, nem sobre TDD nem Integração contínua nem nada disso.  Se trata de um documento de 20 páginas totalmente preocupado com a estrutura do trabalho e apenas isso.

Você pode estar se perguntando então de onde vem a ideia de que para usar SCRUM eu preciso obrigatoriamente usar essas técnicas que listei, e do meu ponto de vista é mais uma coisa subentendida por explicações incompletas que vemos por aí, e tudo começa com o famoso livro “A arte de fazer o dobro do trabalho na metade do tempo” escrito por Jeff Sutherland (um dos criados do SCRUM), pois para que as pessoas possam compreender as vantagens de se utilizar o SCRUM ele vê a necessidade de dar exemplos reais onde empresas usam o SCRUM como estrutura de trabalho, mas adicionam em cima (como se fossem peças de lego) essas técnicas para criarem enfim suas próprias metodologias, e é disso que o SCRUM se trata.

Imagine o SCRUM como a base de um jogo de lego:

E aí você começa a planejar uma forma de rodar isso na sua empresa, e como você trabalha em uma empresa que desenvolve softwares, você precisa escolher uma forma de registrar os itens do seu Product Backlog (perceba que o SCRUM diz que você precisa de um Product Backlog, mas não diz como você deve fazer).

Conversando com sua equipe vocês tomam a decisão de usar “Casos de Uso” para registrar os itens do P.B.

O QUE????? Casos de uso???

Sim! Casos de uso! Cada empresa trabalha sob um contexto diferente, dependendo do produto, da equipe e da empresa, pode sim existir muitas vantagens em usar casos de uso em vez de histórias de usuário. E assim o seu time pluga então essa técnica na estrutura, e vai plugando várias outras técnicas até definirem a metodologia inicial:

Feito isso, vocês podem começar a trabalhar, rodar SPRINTS até chegarem em um dos momentos mais mágicos do SCRUM: A reunião de Retrospectiva!

O SCRUM é moldado para a melhoria contínua e constante aprendizado. Se durante uma SPRINT o time percebeu que algo não está certo, o time PRECISA mudar e melhorar o processo, removendo algumas peças e adicionando outras. Nesse ritmo sua equipe sempre estará se adaptando a atual realidade da empresa e evoluindo com grandes resultados!

2 – Você não precisa do Planning Poker, nem de User Histories, nem de integração contínua

Só pra deixar claro uma das fontes da associação desse conjunto de técnicas com o conceito de Agile, vamos lembrar que o SCRUM não é a única ferramenta no universo ágil, existe também o Extreme Programming (XP) e essa sim é uma metodologia (TAN DÃ!)

É no XP que encontramos a integração contínua, a programação em par, o desenvolvimento guiado a testes e várias outras práticas para lidar com todos os contextos de uma empresa de desenvolvimento de softwares.

Só que muitas vezes eu vejo as pessoas se esquecendo que o XP tem práticas primárias (práticas de aplicação imediata) e práticas corolárias, que são difíceis ou perigosas de serem implementadas antes de se adotar as práticas primárias.

Então se você usa o XP como um guia de práticas e põe isso pra rodar na estrutura do SCRUM, focada em melhoria contínua e constante adaptação, para evoluir o que da certo e remover o que dá errado, aí sim você tem uma receita pro sucesso 😉

Mas o XP é o melhor pra todos os caso?

Não!

Como em qualquer parte da vida, tudo que é extremo pode fazer mal, por isso é importantíssimo enxergar esses caras como ferramentas e usar do bom senso para escolher as que melhor se adequam ao seu ambiente, e necessariamente construir uma rotina de constante aprendizado para garantir que o time esteja trabalhando da forma mais adequada à situação, mas nunca se esquecer dos valores e princípios do Manifesto Ágil.

Em ambientes complexos, você não deve se preocupar com “Melhores práticas” mas sim com “Práticas emergentes” que são as melhores práticas para aquele determinado contexto e momento, e ter a tranquilidade de aceitar que tudo isso vai mudar algum dia, e quando mudar você irá se adaptar ao novo cenário.

3 – Você não deve usar o SCRUM em todos os projetos, mas isso não te impede de ser Ágil

Para explicar esse ponto eu vou recorrer a um outro framework para tomada de decisões chamado Cynefin. Ele é baseado na teoria da complexidade e ajuda líderes a tomarem decisões através da classificação do entendimento que se tem sobre o contexto em que o negócio se encontra:

Segundo o Cynefin, e de grosso modo falando, nós podemos classificar o nosso ambiente em 4 domínios: Complexo, Complicado, Caótico e Simples.

A verdade é que dentro do universo de TI nós encontramos todos estes contextos, veja alguns exemplos:

Complicado:

  • Softwares criados para engenharia, que exigem cálculos gigantescos mas previsíveis, o que o engenheiro diz que precisa ser desenvolvido é exatamente o que precisa ser desenvolvido e nada pode ser mudado, como sistemas de controle de bordo de aviões por exemplo.

Caótico

  • Help desk e suporte, onde aparecem incidentes o tempo todo, não existe previsibilidade nenhuma sobre o que pode acontecer.

Complexo

  • A grande maioria dos softwares que desenvolvemos são feitos em ambientes complexos, pois existem muitas variáveis envolvidas e o requisito do cliente pode mudar com frequência alta, mas o objetivo é relativamente claro e existe um produto em si que precisa ser entregue ou pelo menos alguma necessidade específica que precisa ser atendida, só não se tem certeza de como isso será feito.

Simples

  • O mais raro no universo de TI. São demandas muito pequenas, 100% previsíveis, de solução conhecida e fáceis de serem desenvolvidas. Eu sinceramente só consigo citar alguns trabalhos de faculdade como exemplos aqui.

Usando o Cynefin, nós podemos identificar em qual contexto o nosso negócio se encontra e escolher as melhores ferramentas para se trabalhar, e é aqui que percebemos que o SCRUM não serve para todos os casos.

O SCRUM é uma ferramenta criada especificamente para ambientes COMPLEXOS, e não existe suporte caso queiramos aplica-lo em outros tipos de ambientes.

Apesar disso, o SCRUM é apenas uma parte do universo Agile, universo cujo o qual tem os seguintes fundamentos:

  • Indivíduos e interações mais que processos e ferramentas
  • Software em funcionamento mais que documentação abrangente
  • Colaboração com o cliente mais que negociação de contratos
  • Responder a mudanças mais que seguir um plano

A partir disso, podemos encontrar soluções para todos os tipos de ambientes desde que consigamos pensar de forma Ágil. E é daqui que sai a tão famosa frase: “Agile é uma questão de cultura e mentalidade, não de ferramentas“.

4 – Agile pode não gostar de gestores, mas é apaixonado com a Gestão

Se você é o tipo de pessoa que paga o salário de um desenvolvedor e insiste em dizer pra ele como ele precisa configurar o banco de dados, como ele precisa cuidar da segurança do sistema, como ele precisa desenvolver a solução, sinto muito por isso mas você tem um grande problema em mãos.

Mas não pense que o problema é com o desenvolvedor, muito pelo contrário, o problema é que o seu processo de desenvolvimento centraliza a responsabilidade do projeto e coloca uma pessoa que muito provavelmente tem o menor conhecimento técnico do time para tomar decisões que afetam diretamente nos resultados obtidos. Em outras palavras, você deveria pagar pelo desenvolvedor que te dissesse como resolver os problemas e não que precisasse que alguém dissesse isso pra ele.

Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

Tudo isso é sobre a distribuição da responsabilidade entre o time. Não é sobre colocar um gerente no comando, mas sim sobre distribuir a responsabilidade de gerência entre todos, e garantir a extração do melhor de cada um.

Se dentro do seu contexto existe a necessidade de um gerente por um ótimo motivo, tudo bem, vá em frente, mas não deixe que esse gerente assuma uma postura controladora e tome decisões isoladamente, principalmente as decisões técnicas.

O controle do trabalho que precisa ser feito é uma responsabilidade do time de desenvolvimento, e quando você consegue aplicar isso de verdade, o time se sentirá desafiado, sentirá parte da responsabilidade e consequentemente se motivará para entregar resultados cada vez melhores.

A auto organização só vem pela necessidade ou interesse, e distribuir a responsabilidade é uma ótima forma de provocar a necessidade de que o time se organize sozinho.

5 – O produto é mais importante que o projeto

Vamos fazer uma rápida reflexão: O Projeto de construção do Titanic foi um projeto de sucesso?

E o Titanic como um navio (desconsideramos os filmes e repercussão) foi um produto de sucesso?

Da ótica do construtor do navio seria correto falar que o naufrágio foi culpa do usuário ou de algum imprevisto?

E da ótica dos passageiros seria correto falar que o naufrágio foi culpa do desenvolvedor que não pensou em uma funcionalidade para detectar imprevistos e impedir o acidente?

Pois essa polêmica nos persegue no dia a dia de desenvolvimento e eu só queria falar que não existe nada mais inútil do que gastar tempo e esforço fazendo algo que não deveria ser feito.

É inútil que o projeto tenha sido desenvolvido dentro do prazo, dentro do custo estipulado, seguido a risca todo o escopo se depois de entregue o produto não seja usado ou esteja errado.

6 – O valor é mais importante que o escopo

Seguindo a linha de raciocínio do tópico anterior, vamos entender a diferença entre Valor e Escopo:

O Seu José precisa viajar do Brasil até Portugal, e para isso ele precisa de um meio de transporte que o possibilite realizar essa viagem, mas o Seu José não entende absolutamente nada sobre transportes, ele não sabe que tipo de transporte irá o ajudar. Então o Seu José contratou uma equipe de desenvolvimento e pediu que eles desenvolvessem um Fusca pro Seu José!

Juntos eles passam dias definindo a cor do fusca, quantas marchas, o aro das rodas, entre uma séria de funcionalidades e o gerente de projetos sai da reunião todo feliz porque ele vai garantir que o o desejo do Seu José fique pronto dentro do prazo e com um custo bem razoável.

Chega então o dia da entrega, o Seu José recebe aquele fusca lindo, entra e dirige em direção ao mar. Dentro d’água o Seu José percebe que o fusca não é capaz de leva-lo a Portugal, ele sai furioso de dentro do fusca e chama a equipe de desenvolvimento de incompetente e vai atras de outra pessoa que possa resolver seu problema.

7 – O “Porquê” é mais importante que o “O quê”

Quando a sua equipe sente mais orgulho da tecnologia que está usando do que do produto que está desenvolvendo, vocês tem um grande problema.

Assim como no exemplo do fusca do Seu José, o foco no “quê” fazer não garante a satisfação do cliente e pode guiar o time a construir ferramentas inúteis que não servem para o cliente e por consequência não sustenta a empresa.

8 – Sempre existe mais de uma forma de se fazer a mesma coisa

Na vida real, o levantamento de requisitos e a compreensão do porquê é uma responsabilidade do analista de negócios ou do product owner, mas a responsabilidade deles deveria terminar aí.

A partir do momento em que pensamos “como” resolver determinado problema, a responsabilidade deveria cair para as pessoas que tem a melhor competência pra isso.

Vamos voltar a história do Seu José.

Após sua fracassada tentativa de cruzar o oceano com um Fusca, o Seu José foi até outra empresa buscando alguém capaz de desenvolver pra ele um fusca capaz de atravessar o oceano.

Quando o analista de requisitos ouviu a história do Seu José, ele não se conformou com o pedido de um fusca, em vez disso ele buscou conversar mais com o Seu José até descobrir que ele precisava chegar até Portugal.

Com essa necessidade em mãos, o Analista de negócios chegou pro time de desenvolvimento e apresentou a demanda, o time então começou a apresentar possibilidades:

  • Nós podemos construir um Avião pro Seu José, isso custará alguns milhões de dólares, demorará alguns anos e ele ainda vai precisar de tirar uma habilitação de piloto
  • Nós também podemos construir um Navio pra ele, isso vai ficar mais barato e vai ficar pronto em menos tempo
  • Ou nós podemos ainda comprar uma passagem aérea pra ele, vai ficar mais barato, é rápido e sem transtorno
  • Outro membro do time se perguntou se o Seu José realmente precisava ir até Portugal, se não dava pra ele resolver o problema dele pela internet

Com esse estudo em mãos, o Analista de negócios se reuniu novamente com o Seu José e apresentou essas opções pra ele, e juntos eles decidiram que um fusca realmente não fazia sentido, e de todas as opções, a mais interessante pro contexto deles era apenas comprar uma passagem.

A partir do momento que a equipe de desenvolvimento se posiciona como um parceiro técnico e não apenas como um prestador de serviços, não existe o que não possa ser feito, existe a escolha de uma solução para o problema que melhor se encaixa no orçamento e no prazo estipulado.

Não existe trabalho impossível, existe trabalho inviável por limitações de custo/benefício, por isso o foco nunca deve ser no trabalho em si, mas no benefício desejado.

 

 

 

Sharing is caring!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *