Depois de 03 turmas no Brasil, já temos agora mais de 50 pessoas que participaram do nosso treinamento Management 3.0, que é licenciado por Jurgen Appelo – autor do livro com mesmo título.
O feedback destas turmas foi bastante positivo, seguindo o nosso novo modelo de avaliação de treinamentos, temos um NPS (Net Promoter Score) de 9.2, o que nos rendeu inclusive o seguinte tuíte do autor:

Mas, o que discutimos nestas turmas? Como padrão, no início de cada um destes treinamentos, avalíamos as principais questões de cada aluno que possam ser atendidas por uma das visões do Management 3.0 e trabalhamos nelas em cada parte do treinamento. Dentro deste contexto, os pontos abaixo foram os mais trabalhados nestas turmas:

• Como trabalhar na resistência que as pessoas têm a um processo de mudança?
• Como posso manter as equipes fiéis à proposta de mudança?
• Como identificar o que motiva cada pessoa de um time?
• Como desenvolver a maturidade da equipe para melhorar a auto-organização e colaboração?
• Como motivar o time a auto-organizar de verdade?
• Como influenciar outros departamentos da empresa a adotarem/aceitarem métodos ágeis?
• Como melhorar o entendimento do cliente por valor?
• Como favorecer a troca de conhecimento?
• Como liderar em ambiente fortemente competitivo e com projetos de alta complexidade?
• Como adaptar novas pessoas no ritmo de um time ágil?
• Como posso manter a empresa como um todo alinhada e respeitar as limitações de negócio?
• Como manter alguma ordem em um ambiente sem previsibilidade?
• Como ajudar o comercial a entender o novo mindset de Agile?
• Qual é a melhor forma para dar feedback para times e indivíduos?
• Como criar disciplina nos métodos ágeis para projetos grandes com equipes remotas?
• Como lidar com um Product Owner ausente?
• Como unir times que trabalham com tecnologias e metas diferentes?
• Como favorecer a comunicação entre times?
• O que fazer para a auto-organização não desmotivar especialistas (arquitetos, testers, etc.)?
• Como avaliar o progresso do investimento em conhecimento para o time?
• Como melhorar meus conhecimentos de liderança?
• Como posso remover o medo que as pessoas tem em “prestar contas” (accountability)?
• Como trazer o cliente para dentro do processo de mudança?
• Como envolver stakeholders funcionais em meus projetos?
• Como fazer com que o time não perca a motivação em projetos com prazo definido?
• Como trabalhar com metas setoriais (PMS) em um ambiente ágil?
• Como dar empoderação para times remotos?
• Como empoderar sem se desligar do que tem que ser feito?
• Como gestor, ao empoderar times não estarei “cavando minha própria cova”?
• Quais as melhores estratégias para liderar uma transformação de Agile na minha empresa?

Por mais que possa não haver uma resposta exata para algumas destas questões, todas elas –  e outras – foram bastante discutidas, reunindo experiências e confrontando possibilidades. O resultado tem sido bastante interessante e praticamente todos os alunos têm saído de sala de aula com um “plano de ação” para aplicar de imediato vários conceitos do Management 3.0.

E você, em quais dos seus problemas você acredita – ou gostaria – que o Management 3.0 possa lhe ajudar?

Um dos aspectos mais importantes em uma equipe ágil é, sem dúvida, a confiança. Para James Shore, autor do livro The Art of Agile [1], equipes altamente produtivas são compostas de pessoas que cofiam umas nas outras.

Em seu livro Management 3.0 [2], Jurgen Appelo, explica que a confiança sempre se dá em duas direções: eu posso escolher confiar em você, e você pode escolher confiar em mim, mas ambos não necessariamente coexistem. Nessa linha de raciocínio, podemos identificar quatro grupos básicos de relações de confiança em uma ambiente de desenvolvimento de software: Confiar no time, ganhar a confiança dos membros do time, ajudar os membros do time a confiar uns nos outros, e confiar em si mesmo.

Shore ressalta a importância de a organização confiar no time, mas lembra que a confiança, não surge em toque de mágica, você precisa conquistá-la.

Para Appelo a formula secreta para conquistar a confiança das pessoas é muito simples: “Cumpra aquilo que Promete”. As pessoas confiam em você quando sabem que podem contar com você. Quando sabem que podem acreditar no que você diz.

A falta de confiança sempre vem acompanhada de diversos outros sintomas prejudiciais a saúde da organização tais como a centralização das tomadas de decisão, a falta de delegação, a micro-gestão, e a falta de motivação das pessoas.

Em seu livro Coaching Agile Teams [3], Lyssa Adkins, afirma que “confiar, não significa dar férias ao seu cérebro”, mesmo confiando você pode estar atento ao que ocorre no time e ao redor do time. Confiar não é o mesmo que negligenciar, assim como delegar, não é o mesmo que abandonar suas responsabilidades, existem diferentes níveis de delegação que devem ser aplicados de acordo com a competência e preparo das pessoas.

No artigo Accountability in Software Development [4], Kent Beck, criador do método XP, argumenta que a confiança tem uma relação direta com a responsabilidade e a coragem que cada um de nós deve ter em nos esforçamos para sermos sempre o melhor que pudermos ser em tudo aquilo que fazemos.

Como anda a confiança na sua organização? Os membros dos times confiam uns nos outros? A gestão confia nos times e vice-versa? Seus clientes confiam na sua organização? Quais os efeitos indesejáveis que a falta de confiança está trazendo a sua organização?

Referências

1. James Shore – The Art of Agile
2. Jurgen Appelo – Management 3.0
3. Lyssa Adkins - Coaching Agile Teams
4. Kent Beck - Accountability in Software Development

Não são poucas as empresas e times de desenvolvimento que vem questionando o papel do ScrumMaster. Precisamos realmente de um ScrumMaster? O que faz um ScrumMaster se o time já sabe auto-organizar? E se não há impedimentos, o que ele deve fazer? E se não uso mais Scrum, o que farei com o ScrumMaster? Neste post pretendo discutir esses e outros pontos para tentar desmistificar o trabalho do ScrumMaster.

Por que preciso de um ScrumMaster?

Se você revisitar o paper que “oficialmente” deu origem ao Scrum (Scrum Development Process, Ken Schwaber, 1995) e procurar por alguma referência ao papel de ScrumMaster não encontrará absolutamente nada! Isso porque quando da “criação” do Scrum este papel simplesmente não existia. Mas então por que ele foi criado? Essencialmente, porque Scrum é difícil de ser colocado em prática, a resisência é muito grande, e foi percebido que se não houvesse alguém realmente comprometido e dedicado a fazer isso acontencer, a mudança não aconteceria.

Quais as principais dificuldades para colocar Scrum na prática?

Segundo a edição mais recente da pesquisa “State of Agile Survey”, organizada pela Version One, 58% das empresas que disseram usar Agile mencionaram Scrum como o método que utiliza, e mais 17% citaram que usam Scrum e Extreme Programming (XP). Nesta mesma pesquisa, quando perguntados sobre as principais barreiras para fazer Agile funcionar, responderam:

• [ 51% ] Habilidade para mudar a cultura organizacional
• [ 40% ] Resistência geral a mudança
• [ 40% ] Disponibilidades das pessoas com as habilidades necessárias
• [ 34% ] Suporte da Gestão
• [ 31% ] Complexidade ou tamanho do projeto
• [ 29% ] Colaboração do Cliente
• [ 21% ] Confiança na habilidade para escalar Agile
• [ 19% ] Tempo percebido para transição
• [ 13% ] Restrições de orçamento
• [ 12% ] Nenhum
• [ 06% ] Outros

Bom, se sua empresa está decidida a aplicar Scrum a ponto de ter alguém com um papel chamado “ScrumMaster”, os impedimentos acima são os principais a serem combatidos por este profissional. Mas aí eu pergunto: quantos ScrumMasters você conhece que estão se envolvendo nos impedimentos organizacionais? quantos estão influenciando a Gestão para conseguir mais apoio? Quantos estão trabalhando com as pessoas para reduzir a resistência a mudanças, trazendo o cliente para dentro do projeto, ajudando áreas resistentes a entender e se aproximar de Agile…quantos?

Infelizmente eu tenho visto pouquíssimos, o que portanto me faz acreditar que grande parte dos questionamentos em volta deste papel seja pelo fato de poucos ScrumMasters estarem conseguindo fazer bem o seu trabalho. Portanto, a culpa é do ScrumMaster, certo? Não necessariamente. Grande parte do problema tem sido o fato  das empresas não empoderarem este papel de forma adequada. Não estão dando a ele a autonomia necessária para se envolver em questões organizacionais que estão impactando aquele projeto.

O que tem faltado aos ScrumMasters?

Segundo Thiago Santos, que atua em papel equivalente ao de ScrumMaster na R7.com, “Faltam mais habilidades humanas, relacionadas a técnicas de facilitação, coaching e motivação de pessoas.”. Além disso, pelos pontos citados no “State of Agile” podemos perceber claramente que falta aos ScrumMasters investir no estudo de gestão e liderança, e ainda no conhecimento organizacional. Se grande parte dos reais impedimentos estão fora do ambiente de projeto e muitas vezes até fora de TI, um ScrumMaster que não conseguir influenciar outras áreas da organização se tornará fraco.

Mas se a empresa (ou departamento/área) não deu o nível de empoderação necessária ao ScrumMaster, é dever dele influenciá-la para conseguir isto. “Os primeiros meses foram terríveis, para praticamente todos os impedimentos que apareciam eu tinha que dar a resposta ‘Não tenho como resolver, vou ter que escalar.’. Passei então a investigar porque era tão difícil para a Gestão me dar autonomia, e comecei a ver que não era chatisse ou necessidade de mostrar poder. Trabalhei então nos pontos que descobri tentando mostrar ao PMO como poderiam ter a mesma ‘segurança’ ao me dar um certo nível de autonomia em alguns pontos.”. diz Charles Bennini, brasileiro que trabalha como ScrumMaster no Coutts Bank em Londres.

ScrumMasters precisam ainda entender que em sistemas complexos a gestão é diferente do que estamos acostumados a ler nas cartilhas de “boa gestão”. Em sistemas complexos o conceito de auto-organização é natural, e portanto a gestão tem que ser focada no sistema e não no trabalho que as pessoas fazem ou deixam de fazer. Recentemente fiz o seguinte comentário no blog da Lambda3 em uma discussão relacionada à figura do gerente:

Basicamente minha mensagem é: novos gerentes devem esquecer a idéia de gerenciar pessoas…e devem aprender a gerenciar sistemas, “apenas” isso. Uma mudança difícil, mas com impactos radicais. Restrições são necessárias em sistemas complexos – se não estes se tornam caóticos – e é aí onde entra a figura dos “novos” gerentes.

[...]

No meu ponto, o gerente A gerencia X que é o sistema onde B, C, D, E trabalham o sistema onde as pessoas trabalham, e não o trabalho das pessoas.  Mas para garantir que este sistema não caia na falácia da linearidade…e nem no caos; ele precisa trabalhar com as restrições do ambiente, e para isso precisa trabalhar – dentre outras coisas – com os fatores humanos (ufa…rs).

É um trabalho full-time?

É comum os livros de Scrum afirmarem que um ScrumMaster deve ser um trabalho em tempo integral. Mas isso, na minha opinião, só faz sentido se ele possuir (ou estiver em busca de) empoderação suficiente para atuar em problemas que envolvam a estrutura da empresa, ou seja, quando ele realmente assumir a figura de um agente de mudança, que na verdade é o que esperamos dele. Mas caso isso não aconteça acho difícil conseguir uma justificativa para mantê-lo em tempo integral, aí o natural vai ser atribuir a ele novas responsabilidades e, comumente, dar a ele um outro título. “Apesar de ser um trabalho em tempo integral, como o título ScrumMaster não representava bem o papel, este passou a ser chamado de ‘Consultor de Projetos’.” diz Thiago Santos da R7.com.

Além disso há ainda a situação de empresas (ou times) pequenas, que possuem uma natural auto-organização e pouca interrupção da cultura organizacional. É bastante comum nestes casos haver o compartilhamento do papel de ScrumMaster com outras funções ou papéis.

O que um ScrumMaster deve estudar

É quase um consenso que o que mais tem faltado aos ScrumMasters tem sido habilidades de gestão e liderança, “ScrumMasters precisam de habilidades menos técnicas e mais interpessoais” afirma Milene Fiorio, Especialista em Agile na Petrobras, que cita que na sua área ScrumMasters são responsáveis por auxiliar os desenvolvedores e resolver os impedimentos, e comumente fazem parte do próprio time de desenvolvimento.

“Logo após servir e dar coaching aos times [de desenvolvimento], os [Certified] ScrumMasters devem considerar servir e dar coaching aos gerentes e líderes da organização” escreveu Jurgen Appelo, autor do livro Management 3.0, no post “What Comes After Certified Scrum Master?”.

Para finalizar, minha recomendação de estudo para ScrumMasters está concetrada em 03 pontos:

• Complexidade Organizacional: Teoria da Complexidade, CAS – Complex Adaptive Systems, System Thinking, o impacto da complexidade nas organizações, organizational design, …
• Gestão e liderança em Sistemas Complexos: Management 3.0 (Leia Você sabe o que é Gestão 3.0?), Beyond Budgeting, Radical Leadership,  …
• Relacionamento de Agile com: Governança de TI, Operações, Área de Negócios, e outras áreas e processos da organização.

Uma resposta simples para esta pergunta seria “Sim, Management 3.0 é o título de um livro escrito por Jurgen Appelo, um holandês que não gosta de futebol. Tal livro tem sido elogiado na comunidade internacional de Agile e de Management por pessoas como: Jim Highsmith, Scott Duncan, Lisa Crispin, Israel Gat, Ed Yourdon, Robert (Bob) Martin, Diana Larsen, Esther Derby, e outros”. Mas isso seria realmente uma definição simplista.

Para entender o que é a Gestão 3.0 precisaremos antes avaliar o que o autor considera como as duas primeiras “versões” da gestão.

Gestão 1.0: Focada em hierarquias, esta versão da gestão ficou mundialmente conhecida através do modelo comando-e-controle. Poder na mão de poucos em uma estrutura de decisões top-down. Aqui foi criado aquele conhecido jargão “manda quem pode, obedece quem tem juízo”. Podemos dizer, sem possibilidade de erro, que ainda é o modelo de gestão mais utilizado “na prática”.

Gestão 2.0: Focada em técnicas, esta versão procura “corrigir” alguns dos “problemas” da primeira versão de gestão…mas mantendo a mesma estrutura top-down, o que – não surpreendentemente – resolve muito pouco. Poderíamos dizer que é uma Gestão 1.0 “turbinada” por Balanced Scorecards, Six Sigma, TQM e outros add-ons.

Eu ainda me arriscaria a inserir nessa lista uma Gestão 1.love. Nesse modelo estariam inseridos todos aqueles livros que pedem para lideres abrirem seu coração, dar as mãos aos colegas, mentalizarem palavras positivas pois assim tudo de bom acontecerá. Esses livros também dizem que você agora (?) é um líder, e não mais um gerente.

A Gestão 3.0, ou Gestão Ágil.

Focada na complexidade, esta gestão encara as organizações como redes, e não como hierarquias; e nessas redes as pessoas e seus relacionamentos devem estar no foco da gestão, mais do que os departamentos e seus lucros.

Para conseguir isso, o modelo da Gestão 3.0 sugere que  a gestão trabalhe com seis visões. Não à toa, essas visões são representadas por um modelo um pouco diferente dos conhecidos círculos, flexas e retângulos de desenhos organizacionais; algo bem mais próximo do que muitas das organizações se parecem: monstros.

Energizar pessoas: pessoas são a parte mais importante de uma empresa, certo? Gerentes devem portanto fazer o que for possível para mantê-las ativas, criativas e motivadas.

Empoderar times: times devem auto-organizar, mas para isso precisam empoderação, autorização e confiança da gestão.

Alinhar restrições: auto-organização pode não funcionar, para diminuir esta possibilidade dê às pessoas um propósito claro e metas compartilhadas.

Desenvolver competências: times não conseguirão atingir as metas caso alguns de seus membros não forem suficientemente capazes. Gerentes devem contribuir para o desenvolvimento de competências.

Crescer a estrutura: muitos times trabalham dentro de um contexto organizacional complexo, portanto é importante considerar estruturas que promovam a comunicação.

Melhorar tudo: pessoas, times, e organizações precisamos melhorar continuamente para evitar falhas sempre que possível.

Portanto, sendo auto-organizados, times de desenvolvimento de software precisam de uma gestão que os auxilie, e não de uma que os obstrua. Gerentes organizacionais precisam absorver as competências necessárias para fazer este trabalho.

Sei que isso pode parecer ousado para muitos, mas se Stephen Hawking estiver certo com a citação de que o século 21 é o “século da complexidade”, todos nós precisaremos adquirir novas habilidades para trabalhar de forma adequada aos sistemas complexos, e a gestão não será exceção.

ScrumMasters e a Gestão 3.0

ScrumMasters devem ser verdadeiros agentes de mudança, ajudando a organização a alcançar melhores resultados através do Scrum. É o que deveriam estar fazendo.

Em grande parte ScrumMasters se limitam a cuidar de impedimentos, post-its e reuniões por se sentirem impotentes ao tentar permear as camadas de gestão organizacional. Eles sabem que grande parte das melhorias que precisam acontecer dependem da gestão que, em sua maioria, funciona com uma mentalidade 1.0, com uma visão hierárquica e focada no comando-e-controle.

A pesquisa anual The State of Agile (VersionOne) citou em seu último relatório que os principais obstáculos para uma boa adoção de Agile nas empresas são: cultura organizacional, resistência a mudança, desenvolvimento de competências e apoio da gestão. ScrumMasters devem ajudar a gestão organizacional a entender o que é ser ágil e os benefícios em volta disso. Eles devem ajudá-los a se mover para a Gestão 3.0 assim como ajudaram times a auto-organizar.

Mais sobre Gestão 3.0

Publicarei frequentemente sobre a Gestão 3.0 aqui no blog da AdaptWorks. Por ora, seguem alguns links interessantes sobre o assunto:

• Jurgen Appelo’s blog
• Management 3.0 website
• What is Agile Management?
• Joca Torres (Locaweb) sobre o treinamento Management 3.0
• André Faria (Bluesoft) sobre o treinamento Management 3.0