Profissionais TI - Pra quem respira informação

As práticas ágeis não são novidade já há algum tempo. Diversas empresas, como Spotify, Google, Facebook, Amazon e outras grandes nos seus diversos segmentos já usam o Scrum e outras práticas ágeis como um Framework inovador, voltado para as necessidades do negócio. O que também não é novidade é que, antes de usar essas práticas e ferramentas, várias organizações, principalmente as que não possuem TI como seu “business core”, já usavam uma gama de várias outras práticas, ferramentas e metodologias bem antes do Scrum e Agile surgirem nessas empresas. Por isso, a resistência para uma possível transformação ágil é evidente, principalmente em áreas de uso intenso das predecessoras.

Apesar disso, os resultados obtidos com o uso constante da agilidade nas empresas demonstra que é possível usar estes mindsets para garantir entregas eficazes, com melhores benefícios e alto ROI. Neste caso, podemos falar que o Scrum e Agile são infalíveis, isto é, são a “bala de prata”, que resolvem todos os problemas de qualquer projeto ou empresa? Obviamente que não! E é preciso ter cuidado com esta e outras linhas de raciocínio, para que a sua transformação ágil não afunde no cemitério dos projetos. 

1 – SCRUM É SOLUÇÃO PARA TODOS OS SEUS PROBLEMAS

Durante minhas experiências com Scrum, já vi muitos argumentos que tornaram a prática o bicho papão dos gerentes de projetos, e outros que fazem do Framework a salvação eterna. Obviamente, as duas suposições podem estar erradas, dependendo da forma como você a enxerga. Mas, se tratando do Scrum como a solução uníssona e esplêndida, é simplesmente uma ilusão em sua maior plenitude. É um Framework que pode trazer resultados melhores? Com certeza. Todavia, é preciso evoluir em outros pontos, como:

• Gestão de mudanças da organização;
• Motivação das pessoas na atuação diária;
• Propiciar um ambiente mais sustentável e saudável para todos;
• Alinhamento dos times operacionais e gerenciais com o objetivo estratégico.

Há diversos fatores que influenciam na aceitação do Scrum, mas há diversas outras técnicas, práticas e ferramentas que, mesmo não fazendo parte do Scrum, podem ajudar tanto quanto o modelo. O foco precisa ser no Mindset, eliminando desperdícios, diminuindo gargalos processuais e do negócio.

2 – PMBOK É INIMIGO DO AGILE

Há uma “buzz word” ou mito nesse extenso universo da agilidade, mencionado ou ensinado em alguns círculos, que as práticas de gestão de projetos orientadas pelo PMBOK são incompatíveis com práticas ágeis. É importante lembrar que, em projetos que usam Scrum, XP, Crystal, Kanban:

• Há um escopo: toda Sprint tem seu escopo, guiado pela meta da Sprint ou do ciclo de construção. Temos sempre um escopo que deve estar alinhado com uma meta mensurável. Desenvolvimento sem escopo, é um desenvolvimento sem alinhamento.
• Há um prazo: toda organização possui um deadline, uma data a ser atendida. Em alguns momentos, essa data não é tão clara, principalmente se você lida diretamente com mercados imprevisíveis e com concorrentes incisivos. Mas sempre há um prazo. Que eu saiba, a data final da Sprint e / ou da Release é um prazo.
• Há um custo: todos no mundo de projetos entendem o significado de ROI. Ou, ao menos, deveriam. O Retorno sobre Investimento é uma visão clara de quanto gastamos e quanto ganhamos por conta deste investimento. Só sabemos isso se estivermos medindo nosso custo. 

“Mas Felipe, se em um projeto ágil existe tudo isso, qual a diferença?”

Existem várias formas de controlar todos estes aspectos. Escopo, prazo, planos, cronograma, tudo isso existe, porém, existem formas mais enxutas e direcionadas para gerencia-los. O centro de tudo não é o plano em si, mas o problema que seu projeto vai resolver. É o OBJETIVO. De que adianta entregar tudo isso se o objetivo não foi alcançado?

Além disso, o foco do Agile não é dizer que é uma visão boa e outras práticas são ruins. A questão é que, em determinados contextos, Agile é extremamente útil e produtivo. Não quer dizer que Waterfall ou PMBOK ou PRINCE2 deixarão de existir. Estamos mudando a forma como resolvemos problemas complexos, e não discutindo religião.

3 – ADAPTAÇÃO E DETURPAÇÃO

Também chamo de “a falácia dos modelos híbridos“, é muito importante para quem atua com práticas ágeis / enxutas que saibam diferenciar adaptações de deturpações nos processos. Por ser um Framework, práticas como Scrum podem ser adaptadas a vários contextos, principalmente se queremos atingir melhores resultados ou associar / vincular com outras práticas, como XP ou Kanban. É viável e recomendado. Mas e quando a empresa não topa qualquer mudança?

Por diversas vezes, vemos empresas usando ágil como uma desculpa para mudanças, consultorias, atrasos e outras “muletas”. Um grande exemplo é usar Sprints para quebrar o projeto em pequenas fases.

“Mas Felipe… Isso não é usar Scrum? Tem até Scrum Master!”

Não. Mesmo tendo um projeto em pequenos ciclos, o ponto aqui é que são ciclos curtos de VALOR. Ou seja, a cada Sprint, o time precisa entregar um resultado, completo, “Done”, para uma parte interessada. Se simplesmente quebrarmos um projeto em fases, não estamos fazendo diferente do Waterfall. 

Outro grande exemplo para o uso inadequado destas práticas é usar o tal do Big Design Up Front. Apesar de válido em tipos de projetos que se encaixam em Waterfall, quando estamos em um ambiente complexo, com altos níveis de incerteza, especificar tudo com antecedência é desperdício de tempo e dinheiro. Isto se dá por alguns motivos:

• É impossível prever todos os problemas que ocorrerão no caminho de uma só vez;
• Coisas especificadas com muita antecedência tendem a mudar com o tempo;
• O tempo gasto para especificar coisas que podem mudar de direção pode ser gasto já construindo o MVP da solução;

Por fim, pela última vez: MVP não é uma entrega que você não conseguiu fazer por completo e fica tirando peças pra atender um prazo. MVP é um conceito onde o PO, alinhado com os stakeholders do projeto e time(s), concebem um produto minimamente viável para conseguir colher feedback. É uma validação de uma hipótese, não um carango mal construído.

4 – USUÁRIO NÃO SABE O QUE QUER

Este é um tema bastante difundido e, ao mesmo tempo, confuso. É quase impossível afirmar que os usuários não sabem o que  querem e, ao mesmo tempo, dizer que todos os projetos que já foram entregues ficaram aquém das expectativas. Um cliente ou usuário sabe muito bem o que quer: eles querem seus problemas resolvidos. Querem o resultado que esperam há anos. 

“Mas Felipe, por que então as coisas ruins acontecem, clientes reclamam, ficam insatisfeitos?”

Não há uma resposta muito simples, mas talvez eu possa listar algumas:

• O seu foco está apenas nas métricas e contratos ou no objetivo do projeto?
• Você envolve os seus clientes e stakeholders durante a construção e colhe feedbacks constantes?
• Suas priorizações estão orientadas a resultados ou a projetos? Isto é, você foca no valor percebido?
• Seus clientes participam da concepção e construção dos requisitos e necessidades?

Seus clientes podem não entender de desenvolvimento de software, engenharia ou construção. E nem são obrigados a entender. Cabe a nós a tarefa de gerenciar suas expectativas, com transparência e processos sustentáveis. Entenda a necessidade do cliente – o tal do problema complexo – quebre essa necessidade em problemas menores, e resolva-os, envolvendo o cliente desde a concepção até a entrega. Ao mesmo tempo, gerencie suas expectativas conforme a capacidade do time e restrições do projeto.

5 – TIME NÃO TEM QUE DECIDIR, TEM QUE FAZER

Já ouviu daquele gerente, coordenador – Scrum Master?? – diretor, supervisor – desenvolvedor?? – que o (a) desenvolvedor(a) são “apertadores de parafuso”? Pois é, eu já. E assim como em diversas empresas, não é uma percepção tão errada. 

Durante todo o desenvolvimento de um produto, neste caso, um software, podem existir diversos stakeholders, como investidores, usuários, gerentes de projetos, clientes, etc., mas dentre todos esses papeis, talvez o desenvolvedor seja o MAIS envolvido nesse fluxo. 

“Nossa Felipe, mas por que? Ele só tem que desenvolver, não?”

Não. Quem trabalha no Front, nas trincheiras do desenvolvimento, precisa entender o fluxo, os motivos pelos quais estão ali, o objetivo do produto sendo construído. O senso de propósito de um time deve vir de uma alta transparência e envolvimento, não através da imposição de uma necessidade. Trazendo os times mais perto das decisões sobre o produto, as pessoas começam a se motivar mais, interagir mais e apoiar a construção de algo além de um software: um propósito. É o velho sentimento de “eu resolvi este problema para o meu cliente”. 

Um exemplo interessante é sobre exércitos em alguns países do mundo. Milhares de soldados se voluntariam a servir sua pátria. Não há um pedido, uma obrigação ou imposição. Eles saem do conforto de seus lares, em direção a um caminho desconhecido, em meio à fumaça, dor e desconforto. Mas vão com orgulho. Por que será?

6 – SCRUM NÃO TEM POR QUE OLHAR PRA NÚMEROS

Este é um dos meus favoritos. A velha farsa que traz a pior percepção que as pessoas podem ter: de que Scrum e práticas ágeis não possuem métricas. 

Mesmo com você, caro leitor, se surpreendendo, é simples obter números com estes modelos. Um exemplo que sempre uso em treinamentos é o Pay back. É um indicador bastante utilizado para medir quanto tempo um determinado investimento passará a trazer lucro para  empresa. Por exemplo:

Se eu investir R$ 100 mil em um determinado empreendimento e, depois de finalizado, o retorno financeiro, por mês é de R$ 20 mil, depois de quantos meses eu passarei a ter lucro? R$ 20 mil x 5 = R$ 100 mil. Ou seja, o Pay Back é de 5 meses. 

Agora, me diga: ao usar Scrum obtenho mais retornos em menor tempo, com proporções diferentes? Se sim, isso não é uma métrica?

Outro exemplo: caso eu precise aumentar a quantidade de acessos no meu site e, por consequência, aumentar as minhas vendas, eu preciso tomar ações que trarão esse resultado. Com isso, estabeleço iniciativas que podem trazer este retorno, como:

• Aumentar a relevância do meu site no google;
• Melhorar experiência mobile nas paginas de produtos;
• Diminuir o tempo do usuário no fluxo de compra no site;

São ações que, se aplicadas em pequenas entregas de valor, consigo acompanhar continuamente os resultados no meu site, medindo vendas e visualizações do site. Tais indicadores também são números.

E aí… Como anda sua gestão ágil? Deixe seu comentário abaixo. Grande abraço!