Lideranças e formadores de opinião ditam o ritmo

Fato: Para falar de auto-organização e colaboração, é preciso falar sobre lideranças e formadores de opinião, que tanto podem gerar a aceleração de bons resultados, quanto gerar restrições que atrasarão o aprendizado e melhoria. Não há uma fórmula mágica, cada equipe e organização encontra seu caminho, quase sempre dá certo, mas as vezes é preciso tentar mudar alguns mindsets.

Se a Curva de Tuckman prevê uma fase de storming, etapa de aprendizados para aproveitar (ou não) o melhor do conjunto, pelas suas partes, de forma cooperativa. Algumas condições podem ser um acelerador ou um freio, entre eles temos as lideranças e os formadores de opinião, gerando o risco de proxys, pessoas que acabam tornando-se pontos únicos de falha ou sucesso.

#1. Liderança

O papel da liderança é importante, fundamental, são elas que legitimam cada participante estar naquela equipe, de acordo com seu CHA, senhoridade e potencial, não esquecendo de conceitos de meritocracia e equidade. Acredito muito no que disseram Nonaka e Takeuchi nos fundamentos do SCRUM (1984): Equipes auto-organizadas não são equipes descontroladas!

Nem é preciso ler muito sobre management 3.0 para entender a abordagem do Jurgen Apelo. Enquanto as equipes geram valor para os seus clientes, alguém precisa ter uma visão estratégica da sua área, TI e organização, trabalhando para que o ecossistema formado por diferentes equipes ágeis organizem-se de forma construtiva e equilibrada, para os clientes, organização e profissionais.

Para que um time possa focar em geração de valor, alguém tem que montar o time, oferecer as condições, estabelecer CHA e expertise adequados, apoiar, ajudar em questões fora da alçada do Scrum Master, etc. Não necessário ser um chefe, via de regra é, mas pode ser o modelo hierárquico (99%) ou holocrático (Zappos), na Zappos é aquele papel que serve de ponto de contato e representação entre áreas e níveis organizacionais.

#2. Formador(es) de opinião

Todas as equipes possuem pelo menos um formador de opinião, para o bem ou para o mal, no bom sentido. A existência da auto-organização pressupõe uma boa dose de liberdade de expressão e argumentação, o que exige o esforço de todos na tentativa de entender não só os seus argumentos, mas também o dos outros.

Já vi formadores de opinião os mais variados, alguns fazem com que a curva de aprendizado seja acelerada, como catalisador, proporcionando que cada debate seja assertivo, focado em resultado e melhoria. As vezes o formador de opinião exerce uma espécie de hierarquia informal, quer por gênio (relativo ao seu grande saber) ou “gênio” (relativo a psicologia, uma pessoa geniosa, difícil).

Conheço variados times que deram certo, atingindo a fase de norming e performing da Curva de Tuckman, alguns com a correnteza a favor e outros contra. Não chega a ser mérito ou demérito, trata-se de pessoas, elas crescem, o sucesso diz respeito a melhoria contínua de todos. Crescer e melhorar não tem uma receita, a grandeza é fazer acontecer, entrar e sair do storming juntos.

O Scrum Master é um formador de opinião treinado para tal, é um (novo) papel que exige disposição, muito conhecimento e experiência. Muitas empresas evitam assumir este papel, improvisam, tentam usar parte de um gestor, analista ou desenvolvedor. Muitas empresas já possuem Agile Coachs e Scrum Masters, responsáveis por alguns times ou por uma área, assim como em algum momento no passado perceberam a necessidade de analistas de negócios, GP’s e arquitetos de soluções.

#3. Domínio e proxy

Em meio a um projeto, não tem metodologia que se sustente com gargalos não trabalhados, quer no domínio de negócio, metodológico, engenharia de SW ou infraestrutura. Havendo, é preciso trabalhar para melhorar continuamente, não podemos desconsiderar ou alimentar gargalos, proxys ou pontos únicos de falha, sob pena de mascarar riscos e ter resultados baseados em sorte e azar.

O primeiro proxy a ser quebrado, o PO (product owner) NÃO É o cliente, que devem ser envolvidos permanentemente, ele é tão somente o representante. Não quer dizer que os clientes estarão sempre a disposição, mas é preciso ter a participação deles desde a visão, release plan, discovery, homologação, feedback e decisões. NÃO existe PO com poderes supremos, é responsabilidade dele legitimar cada passo e decisões, conforme necessário, durante todo o projeto.

O segundo proxy a ser trabalhado é o Scrum Master, ele não é e não pode assumir o papel de chefe e secretário de luxo do time. Seu papel é de facilitador. Ele não pode ser caminho crítico, não pode puxar para si a atualização de artefatos, a organização das dailys, de status reports, etc. A dependência cega de um time ao seu Scrum Master é a melhor métrica da qualidade dele como facilitador, isto acontece se ele for centralizador e comando-controle.

O terceiro proxy é a dependência histórica por um super-herói, desenvolvedor que se transforma em único solucionador de problemas. O papel da equipe a cada sprint é executar boas práticas de disseminação e compartilhamento deste conhecimento, é trabalhar para mitigar e eliminar esta dependência … Nesta vibe entra muuuuuuito forte as práticas do XP e gestão do conhecimento.

O quarto proxy é o ponto de contato com equipes de infraestrutura, quer contemos ou não com boas práticas de DevOps. É importante envolver a infra nos momentos cíclicos estratégicos do projeto, mas ele não pode se transformar no ponto único de contato com a infra. Já vi equipes que acabam terceirizando, quer apenas usando tickets ou centralizando demandas com um só profissional. Não recomendo nem um nem outro, tem que participar de forma inteligente.

Conclusão

Em treinamento de Scrum Masters, a base de tudo são princípios, teorias e conceitos da psicologia, sociologia e ciências sociais – Tuckman, Yerkes-Dodson, Cynefin, dissonância cognitiva, diferentes modelos de gestão do conhecimento, teoria das restrições, Job Strain Model, Teoria da Agência e Institucional, … não só SCRUM, Kanban, XP, Design Thinking, Lean StartUp.

Digo isto sem desmerecer um milímetro a disciplina de engenharia de software, como disse um gerente ao final de uma palestra SCRUM 360: “Curti tudo isso, mas saber Java continua sendo importante, né?” Sim, saber programar continua sendo requisito para um projeto de software, mas só saber Java não gera valor, gera código, os estudos do Standish group mostram isso a duas décadas! 🙂

espiral do conhecimento - sobre os ombros de gigantes

Trabalhamos em sistemas sócio-técnicos, só engenharia ou método com seus timeboxes, artefatos, quadros e reuniões não solucionam nada. A solução está no equilíbrio entre ambiente, pessoas, método e engenharia, é valor para o cliente, fornecedor, empresas e pessoas, com equidade e sustentabilidade.

Agile é trabalho duro, até mesmo porque não existe um método mágico, as pessoas ainda são a solução e nada mais singular e complexo que a psique humana. Quanto antes cair esta ficha, antes você entra na linha  \o/

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s