Manifesto Ágil 2.0… será?

Olá pessoas,

Antes de mais nada eu gostaria de agradecer o WordPress, por ceder este espaço para que a gente possa, em alto nível, discutir a gestão de projetos (e demais assuntos) no Brasil… (protocolos e blá blá blás cumpridos, vamos ao que interessa)

Na era da “modinha do momento 2 ou 3.0”, o Manifesto Ágil não poderia ficar de fora… justo agora que eu já estava começando a me achar por, após exaustivas reflexões, ter entendido que Indivíduos e Interações deve prevalecer ante a Processos e Ferramentas e que Software Funcionando é melhor que documentação dizendo como ele deveria funcionar… me deparo, nos meus estudos e pesquisas, com uma espécie de Modernização do Ágil. Pois é… lá se foi o meu pedido de aumento de salário por água abaixo, já que terei de estudar um pouco mais para conseguí-lo.

Mas o que é essa tal de modernização do ágil?

Já vi, ouvi e li várias discussões sobre o que é ser ágil… e a definição, porém, que julguei mais razoável é a que diz que, para ser ágil, você precisa estar aderente ao que está escrito no Manifesto (Ágil). Ponto final. Como esta definição guarda coerência com a afirmação de que para ser cristão, você precisa seguir os ensinamentos da Bíblia Sagrada— o que concordo ipsis litteris — não tive como refutá-la. Contudo, pergunto aos meus atônitos botões, para ser ágil preciso estar, necessariamente, 100% aderente ao Manifesto, ou só em praticar algum dos valores, como por exemplo, responder à mudança mais que seguir um plano, já estaria eu (e a organização a qual trabalho) ascendendo à um certo grau de agilidade? Tá bom… até aceito que não seríamos, lá, um time faixa preta do agilismo, mas quem sabe, talvez, não seríamos, um time faixa vermelha?! hum?

agile-manifesto-powerpoint

Entretanto, independente do que você ou eu achamos sobre o que é ser ágil… membros da benfazeja comunidade agilista (ironias à parte), após terem consolidado as transformações que o pensamento ágil vem se propondo a fazer, desde meados dos anos 90… e sensibilizados, modernamente, com os complexos desafios que a criação de produtos inovadores, estão impondo, à indústria de software… começaram a refletir sobre como poderiam reverter, o que eles entenderam como a obsolescência da pedra fundamental de qualquer prática, framework ou metodologia ágil: O Manifesto Ágil, propriamente dito. – Desta evolução/melhoria nasceu o Modern Agile, ou o Ágil Moderno… ou ainda o Manifesto Ágil 2.0, como assim o batizei, carinhosamente, no título do post… 🙂

A partir daqui meu amigo(a), é onde você precisa tomar bastante tenência… se você ainda não engoliu, com casca e tudo, o Manifesto Ágil (1.0), prepare-se então para ter que engolir (também), com casca e tudo, o Manifesto Ágil 2.0 ou o Modern Agile… desta feita, e sem mais papo furado, detalhemo-lo.

Importante: o que você leu até aqui, e o que você lerá daqui em diante, trata-se da minha contribuição com o tema… sinta-se livre para discordar e a vontade para expor sua visão nos comentários. 🙂

Tornar a Segurança um Pré-requisito (mais que) Indivíduos e Interações…

(Individuals & Interactions »»»» Make Safety a Prerequisite)

Nota: O “mais que“, pode colocar na minha conta… se der problemas, diga que foi eu!

Como assim tornar a segurança um pré-requisito? — Confesso que em primeira análise, tive que fazer um exercício mental lascado para entender a mensagem por trás deste valor… de qualquer forma e como um exemplo, repare bem no ponto de vista a seguir: somente quando todos os membros de um time se sentem seguros em modificar quantidade significativa de código, refatorar, integrar continuamente, deployar e falhar (se for o caso) — sem gerar grandes impactos negativos e retaliações — é que pode-se dizer que este time está sendo ágil de verdade. Dito isto, não há como não concordar com este valor, sem que seja aberto um parêntese para algumas das práticas do XP, das quais me empodero para, novamente, indagar os meus sempre prestativos botões: 1) Como um time pode, de forma segura, entregar valor frequentemente, sem que, por exemplo, a propriedade coletiva de código faça parte do senso comum? 2) Como ter propriedade coletiva de código, sem programação em par? 3) Pra que parear, se não se vê valor em refatoração ou TDD? 4) Como deployar continuamente sem fazer uso de tecnologia que auxilie na segurança e na eficiência desta tarefa?

Se estas perguntas também lhe fizerem sentindo… Indivíduos e Interações só existirão de forma plena, quando a segurança na hora de construir um produto, se torna um pré-requisito¹.

(¹) Recomendo insistentes reflexões sobre este valor a fim de refinar e abstrair ainda mais o seu entendimento.

Entregar Valor Continuamente (mais que) Software Funcionando…

(Working Software »»»» Deliver Value Continuously)

Modern Agile é fortemente orientado pelo Lean Software Development (from concept to cash) de Mary e Tom Poppendieck. Neste sentido, construir software funcionando, com código de qualidade e sem bugs… mas que não agrega valor e que ninguém o utiliza, não passa de meras linhas de código. Não passa de inominável desperdício. É mais ou menos como se um engenheiro da indústria automobilística, desperdiçasse tempo e o dinheiro de sua companhia, projetando um cinzeiro para motocicletas… certamente ninguém, em sã consciência, utilizaria um cinzeiro em uma moto. Portanto, software funcionando que não agrega valor é como um cinzeiro em uma moto, não presta para nada. Legal… mas, como saber se o software que estamos construindo agrega valor para o usuário? Simples. Entregando valor continuamente e capturando o feedback. 🙂

Encantar Pessoas (mais que) Colaborar com o Cliente…

(Customer Collaboration »»»» Make People Awesome)

Pois é… colaboração com o cliente, pura e simples, não é mais um raciocínio moderno. Se você tem um cliente e não colabora com ele, recomendo fortemente que você procure um lugar ao sol no permissivo e estável setor público. Lá, e sem generalizar, pessoas, muitas vezes, não passam de mero detalhe. Ademais, o que está em voga hoje é encantar pessoas. Encantar, desde quem paga a conta (clientes) e quem constrói um produto (desenvolvedores), até que utiliza este produto (usuários). Há quem diga por aí que, um requisito ou uma features, só poderia ser considerada como tal, após validação e sabatina feita pelos usuários, ou seja, se elas tiverem, efetivamente, encantado os usuários agregando desta forma, valor real. Diz-se que Mr. Steve Jobs era obcecado por encantar os clientes… foi por conta desta obsessão, sistemática, que pudemos conhecer produtos como o iPhone.

Nota: a tradução proposta no site do Modern Agile é Tornar Pessoas Sensacionais. Tomei a liberdade, porém, de mudar para Encantar Pessoas, por entender que o encantar está mais na moda… 🙂

Experimentar e Aprender Rapidamente (mais que) Responder à Mudança…

(Responding to Change »»»» Experiment & Learn Rapidly)

Claro que responder à mudança é importante… não passa pela cabeça de nenhum apaixonado, que mudanças devem ocorrem apenas pelo desejo de mudar. Todavia, você já se perguntou quais fatores orientam suas mudanças? Imposições dos clientes, dos usuários, da organização… ou além disso, você e seu time tem experimentado novas possibilidades (nem que seja para falhar) e aprendido mais rapidamente? Neste contexto, não devemos pensar em mudanças como mudanças de requisitos ou de escopo apenas… necessitamos de experimentar novos designs, novos patterns, novos padrões de arquitetura, novas tecnologias, novas hipóteses e etc etc… pois é dessa miscelânea toda que sairão produtos realmente encantadores.

Concluindo…

A modernização do ágil não está vindo para anular tudo o que aprendemos até agora com o Manifesto original. Pelo contrário, ela vem para enriquecer o debate e quem sabe melhorar o que já é bom. Ela vem como complemento. Em particular, faço uma leitura bastante positiva deste movimento porque certamente ele ajudará aqueles que, refletindo com a mente aberta, estiverem ansiosos por melhorar os seus processos, por resolver os seus desafios e porque não dizer, por mudar a cultura de sua organização.

Saudações. Ψ

 

6 comentários em “Manifesto Ágil 2.0… será?

  1. Os próprios criadores do Scrum já negaram algumas vezes a intenção de mudar o manifesto.
    O que as pessoas precisam é mudar e melhorar o Mindset. Adotar práticas híbridas e focar no valor da entrega (valor acima de rigidez de processos).

    Muitos se dizem agilistas mas tratam o Ágil de forma tão rigorosa que se torna um processo e esquecem do próprio manifesto e Mindset.

    E precisamos ser rápidos: A moda de Scrum Master em 24/48 horas veio para prejudicar os bons profissionais realmente preocupados com o valor do trabalho.

    Curtir

    • Reafirmo que o objetivo aqui não é modificar o Manifesto, e sim aprimorá-lo, sofisticá-lo… para que assim ele possa nos ajudar, cada vez mais, a resolver os nossos desafios e pq não dizer, contribuir com as reflexões acerca da tal mudança de mindset… com relação a moda do Scrum Master 24/48h confiemos nas forças do mercado, elas saberão o que fazer com esse “fenômeno”.

      Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: