O post dessa semana é mais uma reflexão em cima de alguns casos vivenciados em que agilidade não funcionou.
Como já é sabido, os métodos, frameworks e ferramentas ágeis são formas muito interessantes de se trabalhar, pois suas essências envolvem, principalmente, aspectos mais interpessoais do que técnicos, sendo muito evidente no mindset ágil. Porém, já dissemos em vários posts em nosso pub que nem tudo é bala de prata.
Tive uma experiência em um projeto que foi um verdadeiro desafio. Um projeto curto (quatro sprints apenas) de um aplicativo com muito potêncial. O início caminhou muito bem! Fizemos um MVP com a participação do cliente e seus stakeholders, levantamos os requisitos, priorizamos e tinhamos o nosso backlog criado de forma colaborativa. Em seguida, foi definido pelo time de desenvolvimento a utilização do scrum, onde o mesmo planejou as principais iterações, identificou alguns riscos e colocou a mão na massa.
Passou a primeira sprint e nada de entrega, fizemos nossa retrospectiva, identificamos diversos problemas, definimos um plano de ação e pronto! Tudo certo para a segunda sprint, começamos, desenvolvemos e, novamente, nada de entregas! E assim foi até o final do projeto, nenhuma entrega no prazo.
No decorrer do desenvolvimento, percebi alguns fatores determinantes para o fracasso desse projeto. Um deles foi que o cliente pedia mudanças constantemente. Mas, como é sabido, isso não é exatamente um problema quando os princípios ágeis estão alinhados, afinal de contas:
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. (Manifesto Ágil)
Entretanto, para cada mudança solicitada, não havia uma negociação do escopo, impedindo o desenvolvimento sustentável para todos os envolvidos. Essa questão fez emergir outro problema: a simplicidade (a arte de maximizar a quantidade de trabalhos não realizados) foi totalmente ignorada! Ou seja, acabou sendo o dobro de esforço no mesmo período.
Já em outro projeto, vi problemas semelhantes. Na época, não entendiamos muito bem a agilidade. Por ser um time novo e com pouca experiência, nossa comunicação “face-a-face” ocorria, em sua maior parte, através de e-mail (apesar de estarmos sentados um do lado do outro). Afinal de contas, precisávamos de respaldos caso alguma coisa desse errada. QUE VERGONHA. Como resultado disso, nossa comunicação era uma droga, baseada em cima de achismos. Ou seja, achar que alguem já havia feito alguma atividade, e no final ela ser bloqueante, impedido-nos de fechar a meta da sprint. Para essa situação, cito novamente um dos princípios do manifesto ágil:
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.
Ora, isso é bem óbvio! Um time que não se comunica de modo eficiente, tende a falhar constantemente. Como construir projetos em torno de indivíduos motivados, se estes não conseguem ter sucesso?
Portanto, fica claro que quando se trata de projetos que envolvam a agilidade, é necessário que todos tenham esse mindset bem definido. Caso algum membro do time, ou até mesmo o cliente, não possuir esse modelo mental bem formatado, não importa a técnica ou método que você vai utilizar, as chances de falhar são altas. Afinal de contas, agilidade é uma cultura e precisa ser trabalhada.
Escrevendo esse post, pude perceber que essas falhas foram de extrema importância, pois me ajudaram a adaptar o meu pensamento para o mundo ágil. É claro que ainda cometemos alguns erros (bem menos que antes, ainda bem!), mas a mensagem que quero deixar é que devemos aprender com eles.
E vocês? Quais os erros que ja foram cometidos? Deixe aí nos comentários! 🙂
Um grande abraço
