• Primeira aula do curso – As demais podem ser encontradas nos vídeos relacionados
• Outros Cursos de Berkeley – Canal da universidade no YouTube com outras diversas aulas
• Vídeos e WebCasts no site oficial da Faculdade – O primeiro link contém os vídeos disponibilizados no YouTube. No entanto, a faculdade também disponibiliza em seu site os mesmos vídeos além de outros da disciplina de ciências da computação.

Depois da reunião oficialmente terminada fomos almoçar e como acabamos entrando no assunto de gestão de projetos comentei um pouquinho a respeito de gestão democrática e prometi deixar alguns links disponíveis:

• Palestra do Akita que foi uma das minhas maiores motivações sobre esse assunto
• Palestra do Ricardo Semler no MIT – Essa é a palestra que o Akita cita como referência
• Lvros de Autoria do Ricardo Semler no Amazon e no Submarino
• Manager Without Managers – Paper da Harvard Business Review também de Autoria do Ricardo Semler sobre o assunto
• Palestra do Akita @ RailsSummit 2009 – Essa é pra quem quiser viajar mais e conhecer as entradas que levam ao assunto de maneira mais profunda

Sabe porque Scrum não funciona? Porque se chama Scrum. Esse hoje é o maior problema do Scrum. Há dois anos atrás pouquíssimo se falava nisto que hoje virou hype. Nessa época as pessoas só falavam que usam Scrum depois de estudar bastante, trocar experiências e exercitar bastante. Ai sim alguém tinha coragem de dizer “Eu uso Scrum” e ainda assim com um pouco de receio, pois sabiam que tinha mais coisas além de apagar toda documentação do projeto e e quebrar as cadeiras pra fazer as reuniões em pé. As pessoas (a maioria) que diziam isso sabiam o que estavam dizendo. Scrum tinha credibilidade.

Nessa época, essas pessoas que conheciam agiram como evangelizadores do Scrum e finalmente ele atingiu as massas. No entanto, hoje o que mais se ouve são times/pessoas que não tem a menor idéia das noções e fundamentos por trás do Scrum ou qualquer outro processo/metodologia/framework ágil dizendo que são praticantes de Scrum. Até gente que nunca participou de um projeto usando Scrum hoje vende Scrum.

Isso é propaganda ruim. E propaganda ruim se multiplica muito mais rápido do que a boa. O pior da propaganda ruim é que cria-se ainda mais preconceito em cima de algo que já encontra resistência naturalmente. Isso tira todas as chances de sucesso de uma implementação de Scrum. Estou cansado de ver em todos os lugares pessoas frustradas dizendo que tentaram implantar Scrum em suas empresas e não conseguiram. Mas é claro que não! O filme do Scrum já está queimado. Você vai falhar antes mesmo de tentar.

Já faz um tempo que eu parei de vender a idéia de usar Scrum. Desde então eu digo que eu procuro executar práticas ágeis. Soa mais leve, mais simples. O pré-conceito diminui dessa forma e a resistência também. Do que importa se meu facilitador chama Gerente de Projetos ou Scrum Master? As pessoas se preocupam mais com nomes do que com resultados e esse é o problema. Agilidade é o que há, mas funciona melhor sem rótulos.

Pergunto isso, pois aqui no Brasil ainda não temos nenhum grande case (que eu conheça pelo menos) de empresas prestadora de serviços (as famosas consultorias) que tenham investido nesse modelo durante tempo o suficiente (aka bastante tempo) e tenham conseguido se consolidar mantendo dentro de toda a cadeia de consultores e projetos as mesmas práticas e cultura envolvidas na utilização de métodos ágeis.

O motivo para isso não ter acontecido, na minha opinião, é que agilidade é um hype recente e por conta disso as consultorias ainda não chegaram no momento de replicar esse conhecimento para muita gente e muito rápido. Esse conhecimento ainda está na cabeça de poucos e os projetos que estão sendo executados utilizando agilidade são coordenados por estes poucos.

Mesmo em empresas “de verdade” (costumo chamar assim empresas “não consultorias” onde TI é importante, mas não é o core business) ainda não tenho certeza se isso é possível. Sei que o pessoal da Globo.com obteve muito sucesso em disseminar as práticas em mais de dez equipes, mas isso aconteceu com bastante trabalho, muito coaching e depois de algum tempo. Não do dia para a noite. Não tinha como ser diferente. Nesse cenário (vou me dar a liberdade de falar uma possível bobagem) onde a equipe tem um tamanho fixo ou perto disso e a demanda é mais ou menos conhecida acredito que escalar agilidade e disseminar as práticas seja mais fácil. Mas e em um cenário onde essas informações não são conhecidas, como fazer?

Como vocês sabem, trabalho em uma consultoria de software e estamos procurando aplicar práticas ágeis no maior número de projetos que pudermos (e onde agilidade for a melhor estratégia). No entanto, estamos indo com responsabilidade, pois senão de ágil só vamos levar o nome e nada da cultura. Por conta disso, esse movimento ainda não está em seu ápice de maturidade e poucos projetos (em relação ao todo que a empresa executa) estão utilizando dessas práticas. Contudo, a demanda por essas práticas está aumentando de uma maneira gigantesca e em algum momento a cultura e as práticas vão se perder se nada for feito a respeito.

Em resumo, temos um cenário onde a demanda não é conhecida nem de perto, as pessoas que farão parte dos novos projetos também não são conhecidas (pelo menos a maioria) e o tamanho das equipes e requisitos não são sabidos. Ai volto para pergunta inicial: como escalar e ainda assim obter consistência com agilidade em um curto espaço de tempo? Tenho certeza que não existe resposta mágica para essa pergunta.

É por isso que estou iniciando uma pesquisa não focada em agilidade e nem em aspectos técnicos, mas sim em um assunto que eu pouco vi comentado nas minhas leituras: capacitação de equipes ágeis. Ok, ok, ok…vocês vão me dizer que tá cheio de gente por ai que ministra cursos de capacitação de equipes em Scrum, XP, etc. Só que quando falo de capacitação, não estou falando em dar um treinamento de dezesseis horas para uma equipe e deixar a bola rolar. Isso, apesar de fundamental, está longe de ser suficiente.

Para inciar o estudo, estou me apoiando na experiência adquirida pela Toyota com a utilização do método de Instrução de trabalho e que está disponível em diversas literaturas onde cada um dos operários da linha de produção é um instrutor em potencial. É desse tipo de capacitação que estou falando. Executar um processo detalhado e peculiar (como são as metodologias ágeis) com a mesma precisão e qualidade em todas as pontas. Independente de gestão, equipe e localidade. Compartilhar os mesmos principíos desde o estagiário até o último nível da gestão. Para atingir esse objetivo é necessário aplicar um esforço brutal em treinamento e capacitação para que, na eventualidade, seja possível formar uma nova equipe treinada e preparada rapidamente.

Portanto, se alguém tiver experiência ou conhecimento de referências sobre esse assunto peço encarecidamente que compartilhe comigo (e com todos os leitores do blog), pois tenho certeza que esse é um assunto que em breve vai dar bastante dor de cabeça para muita gente. A idéia não é ficar esperando sentado até que as práticas e o nome se deteriorem pelo mau uso, mas fazer algo a respeito.

Conforme eu for avançando vou compartilhar minhas descobertas e experiências com vocês. Me desejem boa sorte.

Agile Project Management with Scrum

Assim como o livro do Eric Evans está para modelagem e DDD este livro do Ken Schwaber está para agilidade. É com certeza um “must read”.

Comprei na Livraria Cultura por R$71,00 e tem pouco mais de 150 páginas . O livro é importado então demora um bucadinho pra chegar. No meu caso foram aproximadamente 4 semanas.

O livro não é uma bíblia explicando como utilizar Scrum e nem um guia de implantação da metodologia (até porque os processos e regras são bem simples e existe um outro livro do mesmo autor com esse intuito), mas sim uma parte da experiência que o Ken acumulou a respeito de Scrum desde sua criação e gerenciamento e desenvolvimento de projetos de software.

Apesar de não ser a bíblia, até quem não conhece pode comprar o livro e tirar muito proveito dele, pois o primeiro capítulo e os apêndices são dedicados a descrição do processo e as regras que a metodologia diz que você deve seguir.

O restante dos capítulos é dedicado a histórias curtas (de 2 ou 3 páginas cada) narradas pelo autor e tem como objetivo dar uma mão para aqueles que já implantaram Scrum, mas engasgam no meio do caminho e/ou tem algumas dúvidas a respeito do que pode e não pode.

Como exemplo do conhecimento que o livro oferece, posso citar uma história onde o cliente/patrocinador de um determinado projeto não queria saber de processos e metodologias, mas ainda sim queria poder acompanhar o andamento de seus proejtos. Como tudo o que o cidadão conhecia para acompanhamento de projetos era Gantt Chart, Ken e o Scrum Master do projeto tiveram que bolar outra forma, sem fugir das premissas do Scrum, de reportar o andamento do projeto com sucesso ao gestor ranzinza.

Histórias referentes a todos os papéis do Scrum e suas dificuldades particulares aparecem no livro. Outro ponto interessante que vale a pena citar é que diversas formas de customização e adaptação da metodologia são apresentadas no livro e esse tipo de informação é muito valiosa.

De fácil leitura e entendimento, é um livro obrigatório para os agilistas adeptos de Scrum, escrito por um dos criadores da metodologia e praticante até hoje, que vai ajudar MUITO aqueles que já aplicam Scrum e dar uma prévia dos benefícios oferecidos pelas práticas ágeis aos entusiastas e “scrum-master-wannabe’s” de plantão.