**

No mercado de TI, onde excelentes técnicos rapidamente são promovidos e se tornam líderes/gestores não tão excelentes, existe um enorme desafio em construir e estimular a contínua alta performance dos times. Esse desafio é representado de diferentes formas e tem diferentes impactos para os times, para os gestores/líderes e para a organização inteira.

É possível compreender esse desafio através de dois típicos cenários. No primeiro cenário, um novo líder/gestor tem uma grande dificuldade em compreender (e até mesmo aceitar) que o produto de seu trabalho mudou. Antes, resultado de seu trabalho era algo palpável, de natureza técnica e que geralmente resolvia diretamente um problema em algum produto de TI (Tecnologia da Informação) da organização. Agora, o resultado não é uma porção de código ou, alguma solução técnica, mas sim é a excelência (aka: performance) das pessoas.

Costumo metaforizar que antes o produto do trabalho de um excelente técnico, eram bits e bytes, agora, o produto do trabalho de um líder/gestor são as sinapses que ocorrem nos cérebros dos membros do seu time. E isso, na verdade é um desafio enorme.

O outro cenário comum, é buscar por ser a figura do líder-bonzinho-candidato-a-beatificação-que-todo-mundo-adora. Na verdade, esse cenário acaba sendo um caminho gerado pelo universo de literaturas “auto-ajuda like” sobre como ser um bom líder. Nesse cenário, com intuito de liderar pelo carisma e sem gerar atrito ou despertar conflitos com o seu time, o líder/gestor acaba sendo negligente com pontos críticos ao bom funcionamento do time e para a melhoria da performance do mesmo.

No meio dessa confusão toda, o maior prejudicado acaba sendo o próprio time. A intervenção exagerada na maneira como o time atua ou a total negligência, priva o time de ter acesso a ferramentas que ampliem sua consciência sobre o seu funcionamento e o ajude a crescer e produzir enquanto um sistema psicossocial intenso e complexo.

Contribuir de maneira de efetiva para a construção, crescimento e geração de valor de um time, é quase que uma arte. O mercado comumente usa a abordagem de Team Building para obter esses resultados. Fazer Team Building não significa apenas levar o time para fazer atividades ao ar livre (abraçar uma árvore ou alguma gincana lúdica, por exemplo). É preciso conhecer diferentes ciclos de vida de time e como eles podem ser representados e trabalhados dentro da dinâmica singular de cada time.

Através de um amplo e profundo conhecimento sobre a dinâmica dos times, é possível entender por exemplo, que a boa atuação do time muitas vezes é retardada pelo longo tempo que o mesmo leva para reconhecer, expor e resolver seus conflitos internos. Sendo assim, velar conflitos pode ser muito pior do que expor e atacar possíveis conflitos dentro do time. Assim, cabe a um líder/gestor ter meios para promover essa antecipação do reconhecimento e resolução dos conflitos do time. 

Outra dimensão importante, é a maneira como o time compartilha seus objetivos e, principalmente,  como o time computa mutuamente os resultados gerados por todos.   Essa é uma questão vital e que muitas vezes é esquecida pelas organizações. 

Como um time é uma espécie de Sistema Adaptativo Complexo (CAS – Complex Adaptive System),  fazer a “construção” (building) de um time pode não ser uma boa metáfora. Por ser um CAS, o time é um organismo vivo. Logo, “fazer a construção” acaba sendo uma abordagem muito exata para algo que está muito longe de ser exato. Sendo assim, uma abordagem que está ganhando força recentemente, é tratar o time como uma semente que precisa de um ambiente necessário, para que à sua maneira, cresça na direção almejada e produza os frutos desejados pela organização.

Jurgen Appelo, no livro Management 3.0, faz a metáfora de que o gestor deve atuar como um jardineiro (you are a gardener).  Essa ideia nasce do reconhecimento de que, por se tratar se um sistema vivo, não é possível determinar em detalhes e com exatidão como que as pessoas devem ser comportar dentro de um time.

Assim, um bom jardineiro (o gestor) não gerencia as pessoas, mas sim, o sistema(ambiente) necessário para que as mesmas atuem. Isso implica que o gestor deve trabalhar no sistema para que o mesmo estimule e forneça as condições necessárias para o time maximizar suas forças favoráveis e minimizar (ou eliminar) suas forças contrárias.

Por atuar como um jardineiro, o líder/gestor precisa agora de novas ferramentas para nutrir o ambiente. Antes, o gestor construía regras detalhadas sobre como o time deveria trabalhar para garantir determinado comportamento das pessoas, agora o gestor precisa de ferramentas que inspirem o time a trabalhar dentro de algumas restrições para que seja possível chegar em determinado resultado/direção.

É disso que se trata o Team Growing. Essa abordagem é uma compilação de ideias vindas do Team Building, Executive Coaching, Liderança Situacional,  Liderança Servidora, Psicologia Social e do próprio Management 3.0.

Por meio da AdaptWorks treinamentos, Rafael Nascimento e Eu, estamos compilando nossas ferramentas e experiências no treinamento pioneiro de Team Growing. Pretendemos gerar um treinamento verdadeiramente útil e transformador para quem precisa atuar com a construção e com a melhoria de um time. Rafael Nascimento, que além de um grande amigo, é um Team Builder de mão-cheia e tem uma experiência singular como ScrumMaster para empresas como Globo.com e Mongeral Aegon. Já Eu, estou trazendo para o treinamento minhas experiências em Coaching para times do segmento bancário/financeiro, de telecom e de diferentes produtoras de software. E claro que nesse treinamento, haverá muita pitada de ideias de Management 3.0 e da própria filosofia ágil.

Na verdade, muito mais do que apenas captar pessoas para as turmas desse treinamento, por meio desse texto, queremos gerar um massa crítica de pessoas (gestoras ou não), que estejam preocupadas em buscar melhores maneiras de melhorar o trabalho dos times e consequentemente, melhorar o pensamento organizacional como um todo. Portanto, teremos muita satisfação em simplesmente bater um bapo com você (por meio de comentários abaixo, redes sociais etc) sobre os temas inerentes à essa nova abordagem de Team Growing.

**A imagem do topo do texto é uma ilustração do livro Management 3.0 de Jurgen Appelo

Realizado em São Paulo, na última quarta-feira, o Agile Café reuniu os principais pensadores e profissionais que trabalham com métodos ágeis para uma interessante troca de experiências.

 

Criado para fomentar a discussão entre a crescente comunidade ágil brasileira, a primeira edição do Agile Café foi um sucesso de público. Organizada pela empresa brasileira AdaptWorks, especializada em treinamento e capacitação para o uso dos métodos ágeis, em conjunto com a companhia norte-americana Rally Software, que atua globalmente no desenvolvimento de soluções ágeis corporativas, a série de palestras superou as expectativas ainda na fase de credenciamento e acabou sendo dividida em duas etapas, uma pela manhã e outra à tarde, para acomodar todos os interessados em trocar informações sobre a cultura Agile.

As apresentações tiveram início com uma palestra de Andreano Lanusse, Techical Account Manager da Rally Software, que falou sobre a realidade ágil experimentada por sua empresa em todos os níveis e setores, incluindo as áreas de marketing e vendas, por exemplo. Na sequência, Hamilton Fonte, da Abril Mídia, discorreu sobre as dificuldades enfrentadas e soluções encontradas por sua equipe ao desenvolverem o projeto do site da Veja São Paulo utilizando métodos ágeis em uma empresa de visão reconhecidamente tradicional como o Grupo Abril.

Chamando a atenção dos presentes para o aspecto do gerenciamento deste profissional acostumado a participar de decisões e focar a agilidade, o Agile Expert e co-fundador da AdaptWorks, Alexandre Magno, apresentou o conceito de Management 3.0, ou simplesmente Gestão 3.0, onde os profissionais do conhecimento são abordados como tal, substituindo o arcaico modelo de gestão comando-controle.

Antes do painel de discussão, Manoel Pimentel, Coach e Trainer da AdaptWorks, e Luciano Rodrigues, Project Manager, PMP, CSM da Emphasys, mediaram um Lightning Talk sobre suas experiências com a aplicação dos conceitos ágeis.

A programação foi encerrada com os palestrantes reunidos para responder às perguntas dos participantes, que também puderam fazer comentários em relação às suas experiências na utilização do Agile.

“Adaptworks irá fornecer treinamento e coaching para acelerar a adoção de métodos ágeis e uso das ferramentas Rally no Brasil”.

São Paulo, 14 de Janeiro de 2013 – A Adaptworks empresa brasileira especializada em treinamento, coaching, implementação de SCRUM e outras metodologias ágeis, fechou uma parceria com a Rally Software e irá oferecer treinamento e coaching especializado para acelerar a adoção de Agile e Rally pelas empresas.

A Rally Software, fornecedora global de soluções baseadas em nuvem para gestão de desenvolvimento de software Ágil, foi reconhecido como líder em Application Lifecycle Management (ALM) por dois institutos de pesquisa independentes: The Forrester Wave: Application Life-Cycle Management, Q4 2012” em 23 de Outubro de 2012 e Gartner “Magic Quadrant for Application Life Cycle Management” em 5 de Junho de 2012. Mais de 144 mil usuários em 115 países usam a plataforma Rally Agile ALM para alinhar o desenvolvimento de software e os objetivos estratégicos de negócios, facilitar a colaboração, aumentar a transparência e automatizar processos manuais.

 “Através da AdaptWorks oferecemos ao mercado brasileiro um extenso portfólio de serviços, que permitirá aos nossos clientes trazer inovações ao mercado mais rapidamente usando princípios Ágeis e a plataforma Rally Agile ALM”, diz Brendan Walsh, vice-presidente de estratégia internacional. “Nossos clientes em comum e as oportunidades no mercado brasileiro são um reflexo da adoção global e contínua das práticas ágeis.”

“Trata-se de uma parceria onde ambas as empresas só têm a ganhar, somamos em expertise, temos um portfólio de serviços complementar e nosso conhecimento do mercado local, clientes e canais de marketing estão alinhados com o foco e missão da Rally de servir sua base de clientes globais e ajudá-los a transformar a forma com que as empresas gerenciam o ciclo de vida de desenvolvimento de software.”, analisa Alexandre Magno, sócio-fundador e diretor da Adaptworks.

Rally Software e AdaptWorks estão planejando uma série de eventos no Brasil, já iniciando no mês de março com uma série de Webinars sobre métodos ágeis e a plataforma Rally Agile ALM. As inscrições estarão abertas em breve no sitehttp://www.rallydev.com/br. Os interessados em conhecer mais sobre métodos ágeis e a solução Rally Agile ALM podem entrar em contato através do site: www.adaptworks.com.br

Uma reclamação frequente de times de desenvolvimento (Dev Team) em Scrum é que, com o discurso de agilidade, requisitos chegam nas Sprints com baixa qualidade. Não é difícil encontrar Product Owners que mantém no topo do Product Backlog itens com granularidade ruim, pouco (ou nenhum) detalhamento e  - pior – baixo entendimento do próprio Product Owner sobre o que está sendo pedido. Isso, na maioria das vezes, transforma a Sprint Planning Meeting em uma reunião arrastada e com muitas perguntas não respondidas. Consequentemente, times fazem um planejamento de baixa qualidade e são surpreendidos ao longo das Sprints com impactantes descobertas do Product Owner sobre aquele item, o que resulta em mudanças no objetivo e desenvolvimento. Resultado: Time desmotivado. Sprint não consegue atingir meta. Product Owner insatisfeito com o time. Sistema em colapso.

Requisitos Ready se transformam em entregáveis Done

Uma prática que tem ajudado bastante nestes casos é a adição ao Scrum do conceito de “Definition of Ready”. Este conceito age de forma bem parecida com a conhecida “Definition of Done”, mas enquanto “Done” garante qualidade na saída da Sprint, “Ready” garante qualidade na entrada da Sprint.

Enquanto o Dev Team tem o compromisso de entregar ao Product Owner apenas funcionalidades Done, este por sua vez assume o compromisso em manter apenas itens Ready no topo do Product Backlog.

Um exemplo de Definition of Ready

Uma “Definition of Ready” precisa ser capaz de expressar o mesmo significado para todos que a lêem, principalmente Dev Team e Product Owner. Um exemplo:

Um Product Backlog Item está Ready quando:

- Está escrito como uma User Story INVEST;
- Possui um Teste de Aceitação automatizável;
- Possui um Wireframe de baixa fidelidade;

Caso você trabalhe com itens de diferentes tipos no seu Product Backlog, como por exemplo: itens de negócio, itens técnicos, spikes, bugs, etc., você pode optar por ter uma Definition of Ready diferente para cada um deles; afinal de contas pode não fazer sentido gerar um Wireframe para um Spike entitulado “Escolha de solução para Pagamento de Cartão de Crédito”, certo?

Quem tem a responsabilidade de tornar um item Ready?

A responsabilidade é do Product Owner, mesmo que para isso precise envolver outras pessoas. Enquanto o Dev Team trabalha, por exemplo, na Sprint 3, o Product Owner tem que garantir que os itens do topo do Product Backlog estejam Ready para quando da Planning Meeting da Sprint 4. Caso ele precise envolver o Dev Team neste trabalho,  seria interessante “oficializar” reunião(ões) de “Grooming” que já fossem previstas no TimeBox da Sprint.

O uso de “Definition of Ready” não está limitado ao Scrum, e pode ser muito útil também quando trabalhando com Kanban e outros métodos.

Treinamentos da AdaptWorks relacionados ao tema

Certified Scrum Product Owner
Requisitos Ágeis

Durante o mês de setembro a AdaptWorks participou de dois dos mais importantes eventos da comunidade brasileira de projetos. Em São Paulo, o Agile Brazil, maior evento de Agile da América Latina, superou todas as expectativas. E em Porto Alegre, o capítulo RS do PMI fez mais uma vez um belo trabalho ao organizar um evento recheado de boas palestras.

Agile Brazil 2012

A AdaptWorks possui um estreito relacionamento com o Agile Brazil, já que esteve presente em todas as edições (2010 Porto Alegre, 2011 Fortaleza e 2012 São Paulo). Como nas duas primeiras edições, houveram no evento várias palestras dos nossos instrutores associados, com destaque para a palestra “The Green Lake Strategy” do Manoel Pimentel, “Clean Code” com o André Faria e  a sessão mão-na-massa “Learning 3.0″ com Alexandre Magno. Além disso, desta vez a AdaptWorks trouxe como palestrante convidada a americana Johanna Rothman, que falou sobre “Agile Portfolio Management”.

Na Virada Ágil, o treinamento “Managament 3.0″ ministrado por André Faria e Alexandre Magno foi um dos destaques do evento. Turma lotada e excelentes feedbacks.

Um dos pontos altos do evento foi o inovador estande da nossa empresa. Neste ano, ao invés de utilizar o espaço unicamente com esforço de marketing e vendas, a AdaptWorks focou em distribuir conhecimento. Dentro do estande foi criada uma pequena sala com diversas sessões “test-drive” de todos os nossos treinamentos. O estande foi um sucesso e esteve quase todo o tempo lotado, com sessões de destaque com Manoel Pimentel, Fábio Aguiar, Alexandre Magno e André Faria. Destaque também para a nossa camisa “Keep Calm and Be Agile” que chamou atenção de todos no evento e causou disputa de muitos.

Nesta edição a AdaptWorks foi patrocinadora Gold do Agile Brazil, reafirmando seu compromisso com o mais importante evento de Agile no Brasil. Ano que vem com certeza estaremos lá novamente.

Seminário PMI-RS

Estivemos mais uma vez no “Seminário de Gestão de Projetos” organizado anualmente pelo PMI-RS em Porto Alegre. Neste ano, além de estar entre os principais patrocinadores do evento, a AdaptWorks, representada por Alexandre Magno, palestrou sobre a “Gestão de Projetos Complexos” e ministrou o treinamento “Management 3.0″ na abertura do evento. Este ano o evento esteve recheado de palestras sobre Agile, mostrando como o aquele capítulo do PMI está “antenado” com a evolução destes processos no mercado.

Dias atrás, o CIO postou um artigo relatando um caso de sucesso no uso de Agile pelo FBI (http://www.cio.com/article/714333/How_the_FBI_Proves_Agile_Works_for_Government_Agencies).

De acordo com o artigo, o projeto já havia consumido mais de US$ 1bi em mais de uma década de tentativa de desenvolvimento, passando pelas mãos de duas empresas, até que tomaram a decisão de desenvolverem o projeto internamente utilizando Scrum.

Mas o sucesso do projeto não veio simplesmente pela adoção de Scrum—e isto é uma coisa que sempre gostamos de frisar—, mas sim, pela decisão de utilizar o método de gestão mais adequado de acordo com o projeto.

Em cima disso, o GAO (Government Accountability Office) emitiu um relatório com seu parecer, onde chama a atenção alguns pontos:

• O sucesso depende de times excepcionais (mas não necessariamente de excepcionais desenvolvedores)
• Agile funciona mesmo em organizações extremamente burocráticas—ao contrário do que muita gente acredita.
• Lute para ser mais ágil ao invés de tentar usar ágil. Seguir a filosofia de Agile é muito mais importante do que seguir passos determinados (mesmo que sejam fazer Agile).
• Existem pontos bastante desafiadores: desafios quanto a colaboração, staff comprometido, falta de confiança, etc.

Mas o ponto mais importante foi a de que, embora encarassem esses desafios, os stakeholders também se comprometeram com o resultado e demonstraram atitudes bastante flexíveis às práticas ágeis. E isso fez toda a diferença. Afinal, poderiam simplesmente terem sentado em cima da burocracia e tudo teria ido água abaixo.

Enfim, sucesso com Agile é sempre possível, mas contanto que todos incorporem o espírito de Agile, vá à luta e se preparem para uma boa mudança cultural.

Nos dias 10 e 11 de setembro, em São Paulo, a AdaptWorks receberá pela primeira vez no Brasil o treinamento “Manage Your Project Portfolio” com Johanna Rothman. Ela é a maior autoridade mundial quando se fala em Agile Portfolio Management, e é autora do mais importante livro sobre o tema.

Hoje em uma conversa rápida, fiz à Johanna algumas perguntas que podem lhe fazer perceber a importância que este treinamento tem na trajetória de sua empresa – e sua – com Agile. É realmente uma oportunidade única, pois trata de pontos estratégicos para as organizações e muitas vezes negligenciados dentro da comunidade ágil.

Ax: Qual a importância da Gestão de Portfólio para as organizações de TI?

Johanna: Organizações de TI (e organizações de engenharia e R&D) tem sempre muito trabalho a ser feito. A pergunta é sempre a mesma: qual trabalho deve ser feito primeiro? E isto não é uma pergunta fácil de ser respondida. A Gestão de Portfólio de Projetos é o melhor caminho obter esta resposta.

Ax: Quais são as principais diferenças entre as práticas tradicionais de Gestão de Portfólio e uma abordagem Agile/Lean?

Johanna: Abordagens tradicionais precisam de previsão de ROI, de valor, de custo. Você sabe onde eu quero chegar. É esperado que você preveja tudo para poder tomar uma decisão. Mas como sabemos, não somos muito bons em previsões, certo?

Com uma abordagem Agile/Lean, você não precisa prever muito. Você diz, qual é o trabalho mais importante a ser feito agora? Então nós atribuímos aquele trabalho a um time para uma iteração. Ou, se usarmos Kanban, o time trabalha naquela MMF (Minimum Marketable Feature). Quando o time finalizar, eles trabalham então na próxima funcionalidade. Ou, se usarmos Agile, o time nos mostra uma demo, e nós dizemos: “Ok, qual é o próximo trabalho de mais valor para este time trabalhar?”

Ax: Entendi, já que você estará alocando o time em uma MMF ou iteração, e não em um grande projeto inteiro, o risco de “escolher investir no projeto errado” é reduzido. Muito interessante!

Johanna: Isto é baseado em dados. Nós focamos no trabalho mais estratégico, de mais valor. Eu falo um pouco mais sobre isso no post “Visualizing All the Work in Your Project Portfolio”.

Ax: Quem não pode perder este treinamento?

Johanna: Se você é um gestor e está cansado de ver as pessoas perdendo o tempo com multitasking, você deve participar deste treinamento. Se você é um gestor senior, e quer saber como gerenciar um portfólio de projetos, você deve participar deste treinamento. Se você é um indivíduo que participa de projetos em qualquer posição, e pode sair por dois dias do trabalho, você voltará com ótimas idéias para sugerir ao seu gestor. Se você é um gerente de projetos, você aprenderá como tomar as decisões certas.

Ax: O que os participantes podem esperar do treinamento?

Johanna: Após estes dois dias as pessoas dirão: “Eu realmente me diverti. O treinamento foi bastante interativo. Você deveria ter ido! Eu aprendi muito em dois dias”. Portanto, você deve estar lá.

Ax: Na sua passagem pelo Brasil você também fará uma palestra no Agile Brazil, o maior evento da comunidade brasileira de Agile. Pode nos falar um pouco sobre isso?

Johanna: Eu tenho alguns contatos no Brasil através do Linkedin, mas não sei muito além disso. Não vejo a hora de conhecer muitas pessoas da comunidade brasileira e ver se há algo de diferente entre as outras comunidades que já visitei. Aposto que aprenderei muito e conhecerei muitas pessoas interessantes.

Ainda há algumas vagas disponíveis para esta única turma da Johanna Rothman no Brasil, e para evitar que algumas pessoas interessadas fiquem de fora estamos trabalhando com uma condição exclusiva para este treinamento e fazendo o parcelamento em até 12 vezes! Lembrando ainda que cada participante receberá uma cópia do livro “Manage Your Project Portfolio” das mãos da própria autora.

Inscreva-se aqui, ou através do fone (11) 2507-3563.

A Scrum Alliance acaba de anunciar a data para a efetivação do “pass/fail” no Exame de Certificação para Scrum Master (CSM): a partir de 1º de Setembro de 2012 será necessário acertar pelo menos 24 questões de um total de 35.

Recapitulando: após ter feito o treinamento CSM, o candidato terá duas (2) oportunidades para ser aprovado no exame. Caso não seja aprovado na primeira tentativa, o candidato terá uma segunda oportunidade sem custo. A partir da terceira, será cobrada uma taxa de US$25 por tentativa, além de ser altamente recomendado que o candidato assista a um novo treinamento.

Após o teste, caso seja aprovado, o candidato tem a oportunidade de verificar quais questões foram respondidas erradas, com a alternativa correta realçada. Caso não seja aprovado, o candidato também pode verificar as questões erradas, mas sem a alternativa correta realçada.

Desejamos boa sorte a todos os candidatos pleiteantes a se tornarem um Certified Scrum Master.

Na primeira semana de Julho (de 02/07/2012 a 06/07/2012) foi realizado o I° Scrum Camp no ITA (Instituto Tecnológico de Aeronáutica).

O Scrum Camp é uma iniciativa da AdaptWorks, reunindo o conteúdo de diversos cursos em cinco (5) dias de treinamento, mesclando teoria e atividades, permitindo que os participantes tenham uma total imersão em Scrum.

Neste primeiro Scrum Camp no ITA, tivemos a presença de professores e alunos de mestrado, doutorado e pós doutorado da Divisão de Ciência da Computação, além de profissionais da 2RP e EMBRAER, sendo ministrado pelo Manoel Pimentel (@manoelp) e por mim, Edmilson Miyasaki (@emiyasaki).

Além de nossa colaboração e parceria, esta edição do Scrum Camp teve apoio e patrocínio da 2RP Informática e da Fundação Casimiro Montenegro Filho. E claro, a coordenação do Professor Adilson Marques da Cunha, cujos esforços viabilizaram este treinamento.

Não tenho palavras para expressar a enorme satisfação (e acredito que o @manoelp sinta o mesmo) de ter ministrado este treinamento e perceber o interesse e a vontade de entender como utilizar o que foi ministrado, além da possibilidade de propagar os ensinamentos para outras pessoas e mostrar que existem outras abordagens para o desenvolvimento de produtos, sejam de software ou não.

Algumas fotos tiradas durante o treinamento:

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.