O que é ser Ágil? Minha empresa é Ágil? Eu sou Ágil?

Mais uma vez: Manifesto Ágil

Em um passado não muito distante, o que mais víamos em palestras de Agilistas, e profissionais que trabalhavam com desenvolvimento de software ágil eram citações dos axiomas do manifesto ágil:

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

 

Depois, começou alguns poucos a ressaltar a importância da primeira frase:

Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo.

Essa frase pra mim diz muita coisa e é tão ou mais importante do que os axiomas. Primeiro é que ninguém sabe A melhor maneira de desenvolver software. Nós sabemos que existem maneiras ruins e algumas maneiras que são boas e estas nem sempre se adaptam em qualquer contexto. Outro ponto que eu julgo ser muito relevante é o fato de que você não é Ágil se você não ajuda outras pessoas a desenvolver software. Os famigerados “Agile Coaches” que não desenvolvem software, ou nunca entregaram software trabalhando em equipes de desenvolvimento de software ágil, ou não contribuem com entregas de software e melhoria própria e dos outros colegas, deveriam entender que não são ágeis. Terceiro é a necessidade de experiências prévias, nem sempre a gente consegue ajudar os outros a fazer algo que a gente nunca fez.

Depois de muitas discussões sobre:

O que é ser Ágil? Minha empresa é Ágil? Eu sou Ágil?

E a minha resposta passou a ser: “você segue os princípios do manifesto ágil?” (Chaves já dizia que só os idiotas respondem perguntas com outras perguntas) e a conclusão é de que depois de 9 anos trabalhando com desenvolvimento de software ágil (e não ágil) eu ainda não sou ágil. Por sorte, já tive excelentes experiências, em startups, grandes empresas e estas me ensinaram um pouco sobre o que é ser membro de um time de alta performance, o que é ter uma qualidade adequada para um produto de software, o que é ter apoio e suporte da gestão, entre outros aprendizados..

Abaixo os 12 princípios e alguns dos questionamentos que podem te ajudar nesta reflexão:

Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.

Você conhece o seu cliente? Entende do dia-a-dia do cliente? Sabe quais são os principais riscos, dificuldades e oportunidades do seu cliente?

Como é a sua entrega para este cliente? Você tem entregas frequentes de valor com um grau de confiança adequado quanto as mudanças e funcionalidades que estão sendo integradas ao produto e/ou serviço?

Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.

Vamos imaginar um projeto hipotético com uma estimativa de duração de 6 meses e um escopo de alto nível definido. Se você entrega este escopo, você se adaptou? Você validou e avaliou se este escopo é o correto? Fez experimentos? Testes A/B? Colocou MVPs em produção ao longo desses 6 meses?

Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.

Qual é o seu grau de automação quando falamos de entrega de software? Testes, build, deploy são feitos da mesma forma independente de ambiente para não gerar comportamentos diferentes?

Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.

Se o seu Product Owner ou referência de domínio de negócio tem contato esporádico com a sua equipe de desenvolvimento, você não está seguindo este princípio.

Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.

O primeiro passo é, você conhece os seus colegas de trabalho? Se você não conhece, é muito difícil de conhecer as suas respectivas motivações.

Segundo, o ambiente de trabalho favorece a colaboração e o tipo de trabalho que aquela equipe desempenha? Open offices é uma desgraça para muitas equipes de desenvolvimento de software devido ao alto grau de interrupções.

Terceiro e mais importante: a organização, a gestão e os líderes confiam nos profissionais da organização? Acreditam que eles possuem as ferramentas e conhecimentos necessários para desempenhar este trabalho? Caso contrário, a tendência é um caminho de micro gerenciamento e desconfiança.

O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.

Qual a proporção de emails versus conversas face a face na sua organização? Os profissionais precisam de reuniões formais para conversar? Só conversam 15 minutos por dia, durante a reunião diária?

Software funcionando é a medida primária de progresso.

Como os membros da equipe recebem feedback do software com relação ao progresso do desenvolvimento? Radiadores de integração continua mostrando os resultados das últimas builds? Problemas de código? Suites de testes automatizados funcionais e não funcionais?

Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.

As pessoas da sua empresa ficam doentes com frequência? Quantas vezes é necessário fazer hora extra ou trabalhar finais de semana?

Contínua atenção à excelência técnica e bom design aumenta a agilidade.

O time tem oportunidades para identificar e pagar dívidas técnicas? O foco é apenas entregar ou entregar com qualidade adequada? As soluções são gambiarras ou código que pode ser facilmente mantido e atualizado?

Simplicidade–a arte de maximizar a quantidade de trabalho não realizado–é essencial.

“Menos é mais”

As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.

Existem silos de arquitetura para definir e auditar soluções das suas equipes de desenvolvimento?

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu
comportamento de acordo.

As retrospectivas geram ações relevantes para melhoria e mudança dos processos, técnicas, ferramentas, atitudes e comportamentos da equipe?

E você? Já fez estas reflexões? O que utiliza?

Publicidade