Scrum beyond the enemy lines

Enfoque histórico

Nos últimos anos, o paradígma Ágil vem sendo adotado cada vez mais em grandes corporações pelo mundo inteiro. Seja qual for o motivo que está levando essas empresas ao uso de Agile, de maneira geral é possível arriscar a leitura que a grande maioria delas, buscam algum ganho de eficiência de processso, para que ao final, seja possível algum resultado tangível na esfera financeira.

Mal ou bem, esse movimento de amplificação das experiências ágeis, tem sido bastante facilitado pelo Scrum. E  como o Scrum, de alguma maneira, parece ser palatável para executivos e gerentes, é possível afirmar que ele seja um grande catalisador inicial da filosofia Ágil no contexto corporativo.

 

Desafios corporativos

O universo corporativo por muitas vezes é duro (e até cruel), o que torna o processo da adoção sistêmica de Scrum  (de Agile em geral)  extremamente difícil e na maioria das vezes, deveras longo.

As dificuldades encontradas em ambientes organizacionalmente complexos são várias, mas comumente é possível identificar algumas características principais:

  • Necessidade de alinhamento do Scrum com as questões de governança corporativa em TI (SOX, Itil, COBIT, Órgãos regulatórios).
  • Falta de uma clareza compartilhada do motivo (dor ou prazer) que levou a adoção de Scrum (ou da filosofia Ágil em geral).
  • A falta de clareza deste motivo, faz com que o senso de urgência seja diferente entre as áreas envolvidas num projeto Scrum.
  • E finalmente, “doa a quem doer”, existem os jogos políticos dentro das empresas,  então é comum um projeto Scrum sofrer boicotes pela simples guerra pelo poder, pela visibilidade ou pelo budget financeiro da companhia.

 

Pensamento sistêmico

Infelizmente não há uma fórmula mágica para essas questões, mas se fosse possível  resumir numa única ideia o principal aprendizado nesse tipo de ambiente, ele seria:  Desenvolva sua capacidade de compreender sistemicamente uma organização, pois como diria o filósofo Nascimento: O sistema é f#%&!

Com isso, é necessária uma ampla compreensão de algumas características relacionadas ao sistemas:

  • Sistemas possuem uma complexidade de detalhes – Isso significa que um sistema pode ser composto por várias e diferentes partes.
  • Todo sistema é dinamicamente complexo – Isso significa que o sistema pode ganhar propriedades emergentes de acordo com as movimentações das partes.
  • De maneira geral, sistemas buscam o equilíbrio – Por isso um o sistema  resiste a  mudanças como forma de assegurar sua própria sobrevivência.
  • E a melhor maneira de mudar um sistema, é compreender a relação de causas e efeitos entre suas partes.

Essas pequenas lições acima, impactam fortemente as questões políticas e técnicas referentes ao movimento de  adoção do Scrum. Vale lembrar que o Scrum é um framework, condição que faz dele, algo incompleto por natureza. E já que o Scrum é incompleto,  a compreensão sistemica acerca da organização, é uma abordagem vital para construir as expansões necessárias sobre o framework.

Um exemplo disso, é o entendimento de como que o Scrum pode evoluir seus artefatos, regras, papéis e cerimônias, para criar uma integração com outros processos da companhia, como por exemplo: Gestão de Mudanças, Gestão de Demandas,  Auditoria, etc.

Na prática, o Scrum direta ou indiretamente, tanto pode influenciar esses processos, quanto também ser influenciado por eles. Por isso que mais uma vez,  a compreensão sistêmica será crucial para criar uma relação de equilíbrio entre essas partes.

Uma breve dica para gerar essa relação de equilíbrio é, dialogar com as outras áreas da empresa, sobre as seguintes dimensões de integração com o Scrum:

  • Quem fará a integração?
  • Qual o impacto da integração, para a Agilidade dentro do Scrum?
  • Qual o impacto do jeito Ágil, nessas integrações?
  • Em que momento do ciclo Scrum, essas integrações serão realizadas?

 

Conclusões

É válido destacar  o aspecto político envolvendo a adoção do Scrum, pois essa visão sistêmica colabora também na compreensão das inter-relações de causa e efeito envolvendo os “jogos políticos” da empresa. Na maioria das vezes, esse aspecto político, se torna o fator mais importante, seja para facilitar ou para impedir o movimento de adoção do Scrum.

Por muitas vezes abstraímos esse assunto e atribuímos os problemas para a questão cultural da empresa, mas o que é a cultura senão um sistema de valores, crenças e comportamentos? Por essa razão, mais uma vez se torna importante compreender sistemicamente a organização, para que se possa fazer uma mudança cultural na empresa, pois na realidade, não se muda um sistema inteiro, sem antes passar por suas partes. Dessa forma, a capacidade de entender sistemicamente uma organização, é a melhor maneira de descobrir quais partes, se tratadas primeiro, terão uma maior chance de causar uma mudança mais efetiva em todo o sistema.

 

Sobre o autor:

Manoel Pimentel Medeiros (www.ica-ti.com.br) – Coach com mais de 15 anos de experiência na área de TI, onde atuou com Coaching e Trainning para executivos e times em ambientes organizacionais de Consultorias, Bancos e Telecom. É Diretor Executivo do ICA-TI (Instituto de Coaching Aplicado a TI) e fundador da Revista Visão Ágil, já escreveu sobre Agile e Coaching para portais e revistas do Brasil e exterior. Também palestrou em eventos nacionais e internacionais sobre agilidade. Possui as certificações PPC, CAC, CEC da SBC/BCI, Worth Ethic Corporation, CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.

5 thoughts on “Scrum beyond the enemy lines

  1. Fala Mané,

    Gostei do artigo e atualmente em meu trabalho de implantação Agile tenho me beneficiado muito de Systems Thinking, até mesmo pela minha aproximação com Kanban.

    O que tenho experimentado é que Scrum seria exatamente um contraponto com Systems Thinking. O Scrum muda a organização para transparecer os problemas, por isso em implantações difíceis minha primeira opção sempre será Kanban ou Scrumban. Opto por ser menos invasivo, e consequentemente menos arriscado. Systems Thinking tem me deixado muito mais conservador que o normal.

    Você deve saber que mesmo uma mudança mínima no sistema pode levá-lo a um comportamento inesperado e altamente indesejado, e esse é o risco que vejo na adoção do Scrum logo de cara. Concordo que há casos e casos e meu trabalho tem influência grande do Scrum, mas uma das filosofias que sigo atualmente é jamais dizer numa review que a equipe falhou.

    Acho legal que tenha mais pessoas na comunidade querendo aplicar Systems Thinking a TI. Acho que Systems Thinking deveria ser a base para qualquer tipo de transição, porém, infelizmente a comunidade ágil em geral não se beneficiou desse conteúdo e se preocupou mais em pregar suas próprias verdades. Os estudos do Deming também deveriam ser nossa base para mudanças.

    Abraços e parabéns…

  2. Caro Manoel,

    Parabéns pelo artigo. Bastante realista e objetivo, principalmente na análise dos aspectos não técnicos da implantação dos conceitos ágeis.

    É exatamente esse o aspecto que encontro maior dificuldade nos relacionamentos com nossos clientes/prospects. A Dextra trabalha com desenvolvimento ágil há pelo menos quatro anos, sendo uma das primeiras empresas no Brasil a oferecer serviços de software sob demanda na metodologia. Quando começamos, lá atrás, o mercado ainda não comprava o “modismo” do Scrum e tivemos que, além de mostrar resultados, fazer uma forte evangelização. Hoje o cenário é outro. O mercado compra Scrum e o Kanban está sendo aceito com uma barreira incrivelmente menor que o Scrum há 4 anos.

    Porém – sempre há um porém – a resistência política e não técnica ainda é bem grande. Recentemente fizemos um grande projeto para um banco nacional de destaque usando desenvolvimento ágil. Após algumas iniciativas fracassadas de terceirização no banco com outras empresas, nosso projeto foi extremamente bem sucedido. Ao ponto do Gerente de Desenvolvimento falar claramente que se o projeto não fosse com Scrum teria fracassado, do Superintendente de Desenvolvimento falar que ficaria satisfeito com ‘somente’ 1 mês de atraso (adiantamos em 1 semana!), e o Diretor de TI nos ter chamado para entender “que metodologia foi essa que usamos”.

    Fantástico, não? Agora rompemos todas as barreiras do RUP incrustrado e vamos entrar firme com o desenvolvimento ágil no banco? Não… Apesar de todos os resultados evidentemente positivos e surpreendentes (para eles), a alternativa executiva foi reforçar ainda mais a metodologia RUPiana, com mais UML, mais fase de arquitetura e requisitos, e o Scrum continua sendo algo experimental e “arriscado”.

    Um dos pontos mais curiosos é o porquê do arriscado, na análise deles: escopo aberto. “É arriscado tanto para o banco, que não sabe o que vai receber, quanto para a área de TI, que deixa o cliente interno escolher demais o que vai receber”.

    Sim, é isso mesmo. Basicamente é “medo da perda de controle”. Em última instância, preferem controlar um pacote de requisitos do cliente interno que tem boas chances de não atender a necessidade de negócios e um contrato com um fornecedor que vai entregar produtos inadequados, do que “correr o risco” de ter um projeto em desenvolvimento ágil que vai ser bem sucedido.

    Como diria um colega, eles ainda precisam fracassar um pouco mais em projetos tradicionais para se abrir a novas formas de encarar a complexidade dos projetos, expectativa dos clientes internos e geração de valor.

    Um abraço,
    Marcos Alves

  3. Olá Manoel,

    Muito bom o artigo. Conteúdo rico com objetividade, um texto leve… Gostoso de ler. Apesar de estar cada vez mais conhecido, o Método Ágil é um assunto que sai dos padrões de costume da maioria das pessoas/empresas. Esses têm dificuldade na hora da prática, pela falta de estudos, de suporte, de testes, entre outros.
    Parabéns para toda a equipe que se dedica por um espaço tão importante para o desenvolvimento de boas idéias relacionadas aos métodos ágeis.

    Já faz algum tempo que a Equipe GPE acompanha o Blog Visão Ágil e, de tanto usar Desenvolvimento Ágil, criamos uma ferramenta web de Scrum brasileira!
    Demos o nome de Scrumhalf (www.scrumhalf.com.br) e gostaríamos muito de contar com a sua opinião – existe um plano gratuito que dá para testar a vontade.
    Qualquer dúvida ou problema é só falar!
    Ok?

    Grande Abraço,
    Equipe GPE.

  4. Gostei do artigo e das perguntas que ele evoca.

    No entanto, o grande lance do Ágil é só documentar o que é necessário. Dizendo que podemos juntar a métodos como CMMI, COBIT, ITIL, ou mesmo aquele RUPzinho que a empresa adotou, só dá munição para gerentes e diretores tentarem juntar água e óleo. É a mesma coisa de apresentar 3 designs para um cliente. Ele vai tentar juntar o que há de melhor nos 3 e produzir um minotauro!

    Embora o SCRUM não diga como fazer, é importante, antes de tudo, ter em mente o Manifesto Ágil: http://manifestoagil.com.br/.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s