A falta do Business Agility matou a squad
Vim falar sobre uma experiência que eu tive, basicamente nossa Squad acabou. Eu me meto em cada situação!!!
Analisando o histórico:
Quando cheguei como Scrum Master substituindo a pessoa que estava indo executar outra função, o produto estava em evolução a um bom tempo. O público a ser atingindo era interno.
O cenário não era dos melhores, porque o time não estava conseguindo ir lançando aos usuários as features que estavam sendo desenvolvidas de forma incremental. Primeiro porque não tinham um patrocínio forte na área de negócio.
Depois conseguiram tal patrocínio, porém os BOs (business owner) que entraram forte comprando a ideia, também não deixavam lançar e divulgar. Na cabeça deles sempre faltava alguma coisa.
Desta forma o time não tinha retorno sobre qual seria a melhor direção e melhorias que atendessem de fato a um número maior de pessoas. O time permaneceu guiado pelos BOs que eram duas pessoas apenas.
Produto em Risco:
O projeto estava em risco quando eu entrei, porque existia um impedimento que era uma inviabilidade técnica. Eu já entrei com o barco afundando, aff!!!!!
A feature principal era em um formato, quando o desejo dos BO e que fosse em outro formato. E os desenvolvedores já estavam a um bom tempo, antes da minha chegada, tentando materializar essa visão, sem conseguir. Vou te contar porquê disso.
O nosso produto nasceu para ser complementar a um produto de mercado de grande porte, que é utilizado a anos. Como ele é engessado, dificultando a customização de algumas necessidades, fizerma uma discovery para colocar tudo isso na nossa solução.
Nossa solução além de servir de repositório sincronizado com essa grande ferramenta, seria complementar com features difícies de se customizar na outra.
Daí veio um grande problema, queriam que a nossa solução fosse idêntica a solução de mercado no que tange essa tal visão que falei acima. Então, a visão que foi idealizada e desenvolvida pelo time, antes da minha chegada, foi ignorada e rejeitada. Ah o lean, olha o desperdício de tempo e dinheiro!
Scrum Master resolveu impedimento:
Após a PI Planning, já na primeira semana, todos alinhados da inviabilidade técnica, fui falando com um milhão de pessoas, para saber a quem pedir ajuda, e com a graça de Deus, eu consegui.
Impedimento liberado, visão possível de implementar, acabou o risco do fim do produto e da squad, pelo menos por enquanto.
Um outro problema que eu enfrentei bastante, foi com os chamados que eram necessários para determinadas configurações de firewall Eles levam de 1 semana até 1 mes para serem resolvidos. Dependência de uma área externa burocratizada e demorada.
E isso, por diversas vezes atravancavam a subida de produção de algumas features. Imagina se tivéssemos os usuários esperando para usar? Estaríamos atrasando nossa entrega de valor.
Fim do Squad:
Nos ultimos 3 meses do ano, quando fomos liberados para a divulgação e treinamento da nossa solução, a adesão não foi tão relevante quanto era esperada pela gerência.
Lembrando que permanecemos por bastante tempo, se eu nao me engano 12 meses, sem poder ir lançando as features, e com uma visão limitada de 2 BOs. Claro que eles sabiam bastante, mas a visão coletiva pode levar a caminhos diferentes. E por fim, uma BO que patrocinava deixou de fazer parte da empresa.
Com pouca adesão dos usuários, sem patrocinador e em ano de PANDEMIA, não fazia mais sentido a continuação de investimento de uma squad inteira, em algo que teve um baixo retorno. O valor trazido não foi relevante.
A ferramenta iria continuar só sendo sustentada.
Se a empresa fosse Bussines Agity o cenário poderia ter sido outro:
Como a falta do Bussiness Agility atrapalha, não gente? Se todas as áreas da empresa estão integradas falando a mesma língua, no caso da agilidade, tudo flui mais fácil. Vou explicar.
- Se os BOs (área de negócios) tivessem uma visão de ágil, não trataria como um projeto, ou seja, poderíamos lançar as features de forma incremental a uma parcela de público.
- Não ficaríamos limitados a 2 BO, teríamos um universo de usuários para que pudéssemos ter feedback mais variado e com isso poderíamos ser mais assertivos. Entregaríamos um valor mais sólido. Quem sabe até aquela visão desenvolvida pelo time, poderia não ser tão ruim assim para o público?
- Outro ponto, é que teríamos tempo para ir tratando a questão cultural, ir trazendo os usuários para o dia a dia na nossa ferramenta. A ferramenta de uso diário do nosso público era aquela outra robusta de mercado, e não é rápido mudar um costume. Quem conhece sobre gestão de mudança sabe bem disso.
- Nossa ferramenta se estivesse sendo divulgada, mesmo que para uma parcela menor, já teríamos um público, e quando fossemos oficializar o lançamento, não estaríamos partindo do zero, ou melhor, de 2 pessoas.
- Outro problema relevante, era a dependência externa da área que atende os chamados. Eles têm um SLA de uma semana que ficam prorrogando, ah de eterno. Se a área fosse ágil, não atrasaríamos as entregas, como acontecia, por conta deles.
Em conclusão, o desenvolvimento de produto ágil, em uma empresa que não e business agility, muitas vezes, não é suficiente para maximar o retorno de um investimento. A agilidade deve permear por toda organização.
Informações sobre a autora: Jacqueline Viana é Scrum Master e é apaixonada por agilidade.
