Princípios

Empirismo mais que metodologias

No mundo do (desenvolvimento de software), realizamos, aceitamos e abraçamos que tudo o que fazemos vem com aprendizagem, já que não sabemos muito de antemão. 

Portanto, a única coisa que podemos prever com segurança é que algo imprevisto acontecerá. 

A maneira de agregar valor, ir na direção certa e reduzir o risco neste mundo é focar no empirismo, ou seja, basear as decisões em fatos, experiências e evidências. 

Não importa a metodologia ágil usada, se as observações da realidade não estiverem ocorrendo, a gente não vai superar.

Vou sempre reconhecer que o cliente tem necessidades ágeis e não ágeis e trabalharei de acordo com sua necessidade superando a adoção de frameworks e ‘puxando’ o que for necessário para seu desenvolvimento e não ‘empurrando’ práticas que não são necessárias.

Desenvolver pessoas mais que certificá-las

Como em outras disciplinas, pessoas motivadas com uma mentalidade “certa” e compatível são a chave para criar sucesso no mundo ágil. 

No entanto, muitas empresas acreditam que seus funcionários compreenderão magicamente os métodos ágeis obtendo uma certificação. 

Embora muitas certificações sejam ótimas, o nosso foco deve ser em desenvolver pessoas ampliando seus horizontes profissionais, ajudá-los a compreender o valor agregado da centralização no cliente e equipes capacitadas, desenvolver sua capacidade de conectar estruturas teóricas aos desafios de negócios. 

As certificações podem ser um meio para isso, mas definitivamente não são o fim.

Mudança de cultura mais que programas de transformação

As palavras ‘transformação’ e ‘programa’ implicam algo temporário com um início e um fim. No espírito de melhoria contínua, o estado final é dinâmico, e não absoluto, onde a ‘agilidade’ foi alcançada. 

Portanto, o pontapé inicial de tal mudança de cultura deve fazer parte de qualquer transformação ágil. Certifique-se de não criar muitos KPIs ou OKRs para mostrar que está “fazendo o ágil”, como o número de equipes estabelecidas, pessoas certificadas ou eventos realizados mas sim em medidas de comportamento mais “agilizadas”, como os membros da equipe desafiando o Product Owner, já que as equipes têm competências para trazer PBIs do backlog para o ‘pronto’ etc. 

Somente quando o comportamento muda, a mudança de cultura é devidamente iniciada.

Foco no produto mais que frameworks de escalonamento

Com o surgimento de vários frameworks de escalonamento para permitir agilidade entre equipes relacionadas e até mesmo em toda a empresa, a ideia de desescalar antes de dimensionar é tipicamente uma ambição útil.

Aqui, desescalar pode significar definir claramente os produtos na organização e estabelecer equipes multifuncionais centradas no produto que podem fazer qualquer trabalho necessário para aquele produto.  

Portanto, em vez de ter um portfólio de trabalho que abrange produtos e equipes, mapear equipes para produtos poderia reduzir a sobrecarga, estreitar o foco de cada equipe e melhorar o engajamento, propriedade e valor agregado.