Concrete Logo
Hamburger button

Como vender a metodologia ágil ao cliente

  • Blog
  • 18 de Dezembro de 2017
Share

Você acabou de entrar em uma empresa, sendo contratado como scrum master.  O cliente que você vai atender já tem o mindset ágil e, portanto, está aberto à aplicação do framework Scrum em suas atividades diárias, pois seu passado de waterfall já foi o suficiente para ele entender que precisa, com urgência, combater o desperdício. Sendo assim, uma das mais importantes atribuições do scrum master, que é a de ser agente de mudança, garantindo que o Scrum seja implementado, vai ser uma tarefa tranquila, certo?

Oh, well… não é bem assim!

Principalmente quando se entra em um projeto em que não se rodou a primeira sprint, que é um ciclo de trabalho realizado pelo time de Scrum, é bastante comum que o cliente, por mais aberto que ele seja, tenha inseguranças sobre o framework por uma razão óbvia: trata-se de uma mudança. E não é qualquer mudança, não: o cliente estava acostumado a ter um projeto com fases bem definidas estabelecidas logo no início, a ter mapeado seus custos e riscos… de repente se depara com um novo modelo, em que não se sabe a data de entrega do projeto logo de cara.

No qual o foco é o planejamento não a médio ou a longo prazo, mas a curto, no máximo quatro semanas, e no qual os riscos e custos vão sendo descobertos ao longo das iterações de trabalho. Que atire a primeira pedra quem nunca se sentiu ansioso ou teve algum receio frente a uma situação que nunca vivenciou. Como scrum master, nosso papel é também o de garantir que o cliente esteja confortável com a metodologia ágil e que reconheça valor nela.

Com base em minha experiência na área, ao invés de focar em explicar a teoria em si, é melhor apresentar a ele as vantagens que o framework Scrum pode trazer e focar no que você está tentando atingir com a metodologia ágil. Ou quando você está inseguro você prefere ficar ouvindo blá blá blá em vez de saber o que você vai ganhar com a mudança que está por vir?

Então vamos às dicas que o agilista holandês Christiaan Verwijs nos trouxe com maestria:

  • Foque na mudança: o desenvolvimento ágil diz que a mudança de escopo faz parte do desenvolvimento de software. As mudanças no escopo podem ocorrer por diversas razões, tais como ideias em evolução sobre como um sistema deve funcionar ou como um processo deve ser automatizado, por novas idéias que aparecem durante o processo ou até mesmo a fatores externos (econômicos, políticos, judiciais etc) devido à complexidade ou ao feedback dos usuários. Como scrum masters, devemos garantir que o cliente veja o valor de uma abordagem que permite a mudança. Muitos projetos falham simplesmente porque o projeto entregou o sistema que foi projetado, mas não o sistema que era necessário;
    • Se concentre no desenvolvimento iterativo: a agilidade prega que a melhor maneira de lidar com as complexidades do desenvolvimento de software é trabalhar, em “passos de formiguinha”, em direção a um estado final bastante vago ao invés de tentar mapear todos os detalhes desde o início. Os detalhes vão mudar de qualquer jeito, à medida que novos conhecimentos forem sendo obtidos. Isso evita custosos projetos funcionais e técnicos que são difíceis de entender, abertos a variadas interpretações, e que só vão resultar em negociação de contrato à medida que os debates acalorados sobre uma certa funcionalidade forem surgindo. O cliente precisa ver o benefício em poder começar o mais rápido possível, em vez de ter que ficar esperando aqueles enormes documentos de design;
  • Se atente aos ciclos de feedback frequentes: o desenvolvimento ágil enfatiza que, para que a mudança seja reconhecida, são necessários ciclos de feedback frequentes. No Scrum, fazemos isso através das daily scrum meetings – que têm como objetivo promover a comunicação entre a equipe e checar seu progresso em relação ao objetivo da sprint –, das sprint review meetings – em que o time mostra aos interessados os releases entregues funcionando – e das sprint retrospective meetings – identifica o que funcionou e o que não funcionou bem na sprint anterior. O cliente é sempre bem-vindo, pois dá ao time visibilidade para transformar ideias em mudanças;
  • Foque na entrega de funcionalidades que agreguem valor comercial: o desenvolvimento ágil dá destaque à entrega de funcionalidades com o objetivo de se alcançar o valor comercial no final de cada iteração ou sprint. Em vez de ter que aguardar meses, o cliente pode verificar o progresso periodicamente. Melhor ainda: cada sprint pode, potencialmente, dar origem a funcionalidades que podem ser colocadas em produção ou usadas para convencer a maior gerência ou usuários finais de que o projeto realmente está progredindo;
  • Se concentre em remover a “caixa preta”: o desenvolvimento ágil enfatiza que a melhor forma de se desenvolver software é compartilhar com o cliente o que vai ser feito e, provavelmente, entregue na próxima sprint, respeitando suas necessidades, através de quem tem ônus sobre o valor agregado do projeto, o Product Owner, ou seja, praticando um dos principais pilares da Agilidade: a transparência. Isso facilita a comunicação mais direta, o maior compartilhamento de conhecimento possível e ajuda o cliente a desvendar a “caixa preta” que é o desenvolvimento de software.

Caro scrum master, quando você está usando uma abordagem Ágil para o desenvolvimento de software, você precisa reconhecer que a mudança vai ocorrer, compreendê-la e contribuir para que ela seja identificada e sentida pelo cliente como algo positivo, por lhe trazer benefícios como a possibilidade de nos fornecer feedbacks constantes a cada ciclo de trabalho, tendo a chance de se auto-inspecionar quanto à aderência ao goal a ser atingido na sprint. Sem falar que tais feedbacks vão possibilitar ao time a oportunidade de se adaptar para as próximas iterações, a entregar funcionalidades que o ajudem a atingir o valor comercial desejado, além de permitir uma comunicação frequente entre os membros da equipe.

Por isso, a mudança deve ser sim bem-vinda, traduzida em um esforço conjunto do Product Owner com a equipe de desenvolvimento em cumprir o prometido com o cliente –  tranquilizando e conquistando sua confiança – e do scrum master agindo para facilitar que ela ocorra da maneira mais tranquila e transparente possível.

Quer saber a fonte desse artigo? Clique aqui.

Saiba mais sobre a aquisição da Concrete pela Accenture neste link.