? O enorme desafio de escalar o Scrum na corporação. Publicado em 29 de dezembro de 2016? José Finocchio Jr
?Vai ser difícil você escalar o Scrum na corporação.
Por corporação entenda-se uma grande empresa como por exemplo a Ambev, o Banco Itaú, a Telefônica ou a Vale. Por escalar leia-se implantar essa metodologia para todos os projetos, não apenas Tecnologia da Informação ou meramente desenvolvimento de *software*. E para entender por que afirmo que é difícil, primeiro você precisa conhecer aquilo que batizei de regra magna.
Regra magna do Scrum: UM MEMBRO DA EQUIPE TEM QUE SE DEDICAR A UM ÚNICO PROJETO DURANTE O *SPRINT*.
Faço a ressalva que essa regra magna não está oficialmente no Scrum, ela é minha opinião sobre a razão do Scrum funcionar bem e acelerar projetos. Na prática essa regra pode ser quebrada e nesse caso o Scrum passa a ter as mesmas doenças de sincronismos que as abordagens tradicionais possuem no ambiente multi-projetos, atrasos em cadeia, alto estoque, prazos alongados e por fim o caos total.
A seguir, reproduzo as perguntas que um personagem fictício a cargo desse desafio numa grande organização me faz.
*Qual a chance de aceitarem essa regra magna na minha diretoria?*
Zero. Parece que você não conhece seus chefes?
*Mas, e se eu explicar isso bem para os executivos e tentar convencê-los?*
Você vai contar que as pessoas mais disputadas por todas as inciativas somente poderão participar de um projeto por vez, não poderão trabalhar no suporte e na operação e não poderão participar de reuniões sobre outros projetos durante toda a duração do *Sprint*?
E que isso valerá para todas as pessoas que participam de projetos na sua organização.
Eles não aceitarão isso.
*E se eu partir para um **framework** escalado do Scrum como SAFe, Nexus, Less ou DaD* ?
Todos eles usam a regra magna do Scrum e é essa regra que faz o Scrum ser mais rápido que outras abordagens. Você pode por em prática mais de 20 processos do Scrum, mas se você remove a regra Magna é como se retirasse a turbina do avião.
*Mas eu pensei que o Scrum era mais rápido porque é contra documentação e não faz planejamento*?
Seus conceitos estão errados. O Scrum tem planejamento e ele não é contra documentação. O Scrum é rápido porque traz foco e autonomia para equipe.
*Mas se o Scrum funciona em outras organizações grandes, por que eu teria alguma dificuldade de implantar na minha organização que é uma corporação?*
Porque essas organizações grandes, que você mira, realizam desenvolvimento de um produto orientado por* feature*, e ainda que seja um time grande ele é dedicado a esse produto.
Na sua organização, o desenvolvimento de *software* representa apenas uma fração do que é feito, são projetos de SAP, CRM, *e-commerce*, *Business Intelligence*, infraestrutura de TI, sistemas legados, isso para ficar só no departamento de TI, pois uma metodologia de gerenciamento de projetos decente tem que valer para todas as áreas da empresa como logística, operações, vendas, *marketing*, jurídico, finanças etc. Já pensou impor a regra magna a esses departamentos?
*E se eu implantar a charmosa metodologia SQUAD da Spotify?*
Não funcionará. Ela usa a regra magna também.
*E se tivessemos substitutos para os colaboradores críticos que não puderem ser alocados ao sprint?*
Isso melhora o problema e seria o ideal de qualquer organização ter múltiplas pessoas habilitadas para entregar um pacote de trabalho. No prática ter substitutos é mais exceção do que regra. Lembre-se, estamos falando de levar para a grande maioria dos projetos da corporação.
*E se eu fizer um piloto com um time terceiro de desenvolvimento de * *software** e depois escalar para os funcionários da minha organização?*
Vai funcionar maravilhosamente bem e você vai chamar a atenção de todos. Mas isso é uma estratégia para enganar as pessoas por um tempo. Quando você tentar escalar para os projetos que usam funcionários da corporação, será um desastre porque vai bater de frente com a regra magna e muito provavelmente você será demitido. Talvez seja demitido antes, caso seu chefe leia esse artigo.
*O Scrum é centrado em pessoas; e se contratarmos um **agile Coach** para mudar os paradigmas e o **mindset** das pessoas?*
É verdade que o Scrum é uma filosofia centrada nas pessoas e que tem um novo *mindset*. Mas mesmo se você mudar o *mindset* das pessoas, não vai mudar o ambiente em que sua corporação opera; é uma empresa com uma grande quantidade de projetos, as pessoas se dividem entre operação e projetos, os funcionários tem que participar de muitas iniciativas ao mesmo tempo. Mesmo que o *Agile Coach* seja um fofo e consiga transformar todas as pessoas para tornarem-se seres iluminados e mais elevados, ele não vai mudar o ambiente complexo no qual sua empresa está inserida. Vai ser bom para o *Agile Coach* que vai ganhar uma boa grana, mas no final do dia você vai estar com o mesmo problema na mão: a regra magna que não encaixa.
*Mas e se eu contratar uma empresa de **gestão de mudanças** que transformará o **mindset** dos chefes para dedicar cada pessoa em um projeto por **sprint**?*
Sério? E quem você está pensando em contratar ? O Coelhinho da Páscoa, a Dona Cegonha ou o Papai Noel?
Que tal mudar de emprego para uma *start-up* que desenvolve produto *feature driven*? Parece mais realista para você, eu te ajudo a elaborar o currículo, juro.
*Além da regra magna, existe outro problema ao escalar o Scrum?*
Existe sim. São problemas difíceis, mas ainda assim mais fáceis de serem contornados que a adaptação para a regra magna.
O primeiro deles é que o conselho e a diretoria da corporação estão acostumados com o paradigma: Escopo fechado + Prazo Fixo + Custo fixo. No fundo acaba sendo mais um “me engana que eu gosto”, mas o fato é que essa regra é a dominante entre os executivos. Isso se deve ao processo de orçamentação corporativo que é rígido. O Scrum costuma trazer grandes resultados de custo e prazo, talvez aí esteja a chave para convencer os executivos sobre essa nova abordagem. O Scrum não trabalha com escopo aberto, mas também não é escopo fechado. Eu diria que é escopo delimitado adaptativo, uma maneira inteligente de trabalhar, mas desafiadora na hora de convencer executivos. Outro problema é que quando se usa o Scrum para projetos que não são *feature driven*, com redes com interdependências muito complexas, WBS’s com muitos elementos integrativos, as ferramentas do Scrum ficam mais difíceis de serem trabalhadas.
*Você me falou o que não funciona, esparramou um monte de terror, mas não disse o que funciona. O que eu faço agora?*
O objetivo desse artigo foi claramente dizer o que não funciona na escalação do Scrum na corporação. Isso não quer dizer que não existam alternativas de gerenciamento ágil de projetos que possam ser implantadas numa corporação. Pode ser que existam alternativas que não sejam as mencionadas aqui e que ainda tragam um ambiente de agilidade sem comprometer os pilares da metodologia ágil. Sempre que te apresentarem algo, seja crítico, desafie, pense e depois, se for o caso, confie e abrace a causa.
*Você tem alguma alternativa específica para me sugerir?*
Nos últimos 3 anos, desenvolvi uma metodologia ágil para corporações bastante aderente aos princípios *Lean*, chamada TakT pm. Ela consegue acelerar projetos mesmo num ambiente de múltiplos projetos simultâneos, criando um fluxo contínuo de trabalho puxado. Essa abordagem funciona mesmo que não sejam projetos de desenvolvimento de *software* *feature driven*; pode ser qualquer tipo de projeto em qualquer indústria. Não consigo dizer que o TakT pm é a única abordagem que funciona, mas posso afirmar que testei em corporações grandes e deu bom resultado.
Fonte: www.linkedin.com/pulse/o-enorme-desafio-de- escalar-scrum-na-corpora%C3%A7%C3%A3o-jos%C3%A9-finocchio- jr?trk=hp-feed-article-title-like ?