Apesar de eu ter sido convidado para apresentar o case da Globo.com mais uma vez, quando vi o tema do evento, resolvi falar de algo que me preocupa muito ultimamente: A adoção do SCRUM pelo mainstream sem muita preocupação com os princípios e valores que estão por traz das práticas muito simples de serem explicadas e compreendidas.

O SCRUM pode ser facilmente explicado para um leigo no assunto com menos de 2 minutos e 2 ou 3 diagramas. Porém implementar o SCRUM e ter o time no que Jeff Sutherland chama de “Estado de Hiperprodutividade” é uma tarefa muito complexa.

Numa escala de complexidade que vai do simplório, passando pelo complexo, para chegar ao simples, eu classifico o SCRUM como um framework “simples”.
Além de toda a teoria da produção puxada, teoria das restrições, lean, PDCA, teoria dos sistemas adaptativos complexos e do paper de Nonaka e Takeuchi, por trás dessa simplicidade do modelo, o SCRUM engloba 38 patterns organizacionais de 60 que foram constatados pela equipe de Pesquisas da Bell Labs nos EUA, durante a ultima década do ultimo século, em projetos de dúzias de empresas ao redor do mundo que tiveram sucesso fora do comum.

Quer saber mais? assista ao vídeo da minha apresentação e veja os slides abaixo.

Aqui vc encontra um pouco da história de como esses patterns foram estudados através de 120 retrospectivas e aqui vc pode ver os 38 patterns, sem os quais provavelmente, o SCRUM não tem chance de funcionar.

Agradecimento especial para a Teresa Maciel, pelo convite e pela organização do evento e a Ana Rouiller e companhia pela receptividade e hospitalidade de sempre.

A cobertura em fotos do evento está aqui no site do Manoel Pimentel

e mais outras no flickr do Luciano Felix, que também apresentou uma excelente palestra em conjunto com o Gustavo Coutinho

Os slides da minha apresentação estão no slide share onde é possível baixar a versão original com as notas que usei para apresentar.

Outras apresentações podem ser encontradas aqui, e nos blogs abaixo:

No final do evento fui convidado para uma rodada de perguntas livres e respostas ao lado do Boris Gloger, Alexandre Magno, Michel Goldenberg e Jim Cundiff que fugiu para colocar a camisa do Brasil. Tivemos a chance de discutir sobre vários assuntos interessantes como times distribuídos, Agilidade no ambiente acadêmico, e What-Went-Wrong / What-Went-Well desde o início do Scrum.

se você esteve no evento, deixe suas impressões nos comentários.

No fim do dia Boris Gloger fez uma apresentação que tem tudo a ver com o tema da minha apresentação: Going LARGE by Staying small

Apresentaram também no mesmo dia:

Agradecimento especial para a Ana Paula Cavalcanti e Teresa Maciel pelo convite e pela excelente organização do evento.

Como sempre, feedback sobre a apresentação é muito bem vindo.

O evento reuniu grandes nomes do movimento ágil no Brasil para discutir estudos de caso, patterns de adoção das práticas ágeis, presente e futuro do desenvolvimento ágil. Entre os palestrantes estavam: Phillip Calçado, Antonio Carlos Silveira, Guilherme Chapiewski, Danilo Sato, David Anderson e muitos outros.

A pedido de algumas pessoas que viram minha ultima apresentação em Recife sobre a adoção de Scrum na Globo.com, eu repeti a dose, atualizando todos sobre como estamos evoluindo, quais os desafios que estamos enfrentando e quais são os planos para o futuro.

Os slides atualizados estão no slideshare:

ATUALIZADO:
o pessoal da Caelum publicou hoje(04/12/08) o vídeo a palestra:

Como sempre, pra quem assistiu a apresentação o feedback é muito bem vindo, fiquem a vontade para deixar seus comentários.

A Mostra PUC-Rio acontece entre os dias 19 e 22 de agosto, com o tema “Os desafios da Inclusão do Conhecimento numa Economia Globalizada”.

os slides da minha apresentacão estão aqui:

O programa tem um ano de duração, durante o qual eu acompanharei o Boris, ajudando nos seus treinamentos com uma participação cada vez maior, até estar apto a realizar todo o treinamento.

O primeiro passo foi dado nesse fim de semana quando fui à São Paulo, para ajudar o Boris num treinamento CSM aberto. A idéia era chegar na sexta-feira pela tarde para poder fazer a programação do sábado com o Boris no fim do dia, mas devido ao tempo ruim no Rio de Janeiro, o Galeão ficou um bom tempo fechado e acabei chegando em São Paulo muito tarde. Por conta disso tive que fazer a minha parte de improviso.

Durante o treinamento, Boris me pediu para explicar a dinâmica do Wall-Board e no final, quando ele falou sobre como escalar Scrum, tive a chance de mostrar como estamos tratando esse asunto na globo.com com 17 times atualmente.

Foi muito gratificante ver como o Scrum está se difundindo rapidamente no Brasil além de poder trocar ideias com o pessoal da Abril Digital, Instituto Nokia de Tecnologia, Weg e Motorola. Sorte a todos!

• Post do Boris sobre o treinamento
  
• FeedBack do Marcio Marinho
• Fotos do evento por Marcio Marinho

PS: ao pessoal que assistiu o treinamento, gostaria muito de ter um feedback sobre minha apresentação e como posso fazer para melhorar. Fiquem a vontade para escrever nos comentários.

O Objetivo do evento era discutir até onde Scrum e CMMi eram compatíveis ou antagônicos, e para isso tivemos presenças dos dois lados da moeda.

Boris Gloger concluiu o evento com sua exposição “Scrum = CMMi?! A provocation to see the truth”, seguido de um debate/Q&A com o Renato da ISD Brasil.

Em sua apresentação, Boris que além de Certified Scrum trainer também já foi Certificado em CMMi, diz que no nível conceitual Scrum e CMMi são iguais, porém suas implementações no nível tático são totalmente diferentes. Boris recomenda CMMi para corporações grandes e estáveis, onde faz sentido a definição de processos formais que quase não mudam com o passar do tempo. O último slide da sua apresentação resume bem isso. Outro ponto interessante foi a observação de que as novas organizações tendem a ser pequenas, distribuidas e guiadas por mulheres, fato que teve bastante apelo para uma platéia de 68 mulheres e 99 homens.

- Pra quem está procurando uma ferramenta para ajudar a organizar a vida do Scrum Master fica aqui a dica de uma ferramenta promissora, o Fire Scrum produzido pelo pessoal do C.E.S.A.R e liberado sob a licença GPL. Apesar de eu achar que nada substitui o quadro branco com os post-its colados nele, quando se tem muitos times num mesmo projeto, ou times com membros distribuídos fisicamente, uma ferramenta como essa passa a ser fundamental.

- Os slides da minha apresentação estão disponíveis aqui:

pra quem assistiu minha apresentação, dúvidas e comentários são muito bem vindos! Principalmente comentários que me ajudem a melhorar para as próximas.

- Por fim, mas não menos importante, queria agradecer a todo o pessoal de Recife pela simpatia e gentileza com que me receberam, em especial um muito obrigado para a Teresa Maciel do SPIN-Recife, que organizou esse ótimo evento, a Isabela pela recepção, a Cidinha, Eduardo, Marco e todo o pessoal do C.E.S.A.R pelo tour e apresentações.

<post_resposta>

Na minha opinião, uma das grandes sacadas do Scrum está justamente no fato dos papéis estarem muito bem definidos.

Durante anos a empresa para a qual eu trabalho, transformou nossos melhores técnicos em coordenadores, pois esse era o único jeito de diferencia-los do resto da equipe pelo excelente trabalho que eles faziam como desenvolvedores/arquitetos/resolvedores de problemas. E é ai que começam os problemas, pois o nosso excelente desenvolvedor senior, foi promovido a aprendiz de gestor junior e tem um longo caminho a trilhar. Mas pra complicar um pouco mais, ele não pode dedicar 100% do seu tempo as suas novas atribuições e ao seu aprendizado, porque alem de coordenador ele também é líder técnico, mete a mão na massa, faz café e chuleia, ou seja, começa a sofrer da sindrome do sofá-cama e não consegue fazer mais nada direito.

Felizmente, a menos de 2 anos atrás, nós criamos o cargo de “especialista” e agora as pessoas podem optar por seguir a carreira técnica e se dedicar aquilo que elas realmente gostam de fazer. Mas isso não resolveu o problema dos nossos amigos coordenadores que ficaram perdidos no espaço-tempo vestindo o chapéu de gestor até o meio dia e o de líder técnico depois do almoço. Isso só foi endereçado a cerca de 10 meses quando começamos a implantar o SCRUM.

Hoje temos coordenadores e até gerentes vestindo integralmente o chapel de time, analistas atuando como Scrum Masters, e todos -podendo- se dedicar 100% ao que mais gostam de fazer.

</post_resposta>

Essa polêmica toda acerca do Scrum Master técnico já foi muito bem endereçada pelo GC em seu blog. No entanto isso me fez lembrar de um tema que venho pensando há algum tempo e que deu origem ao título desse post.

Pode, ou deve, o responsável pelo retorno de investimento do projeto ser uma pessoa com excelentes conhecimentos técnicos?

Entre os papéis que o Product Owner deve exercer estão coisas como:

• Definir as features do produto;
• Release management;
• responsabilidade pelo (ROI);
• priorizar as features que tenham o maior valor de negócio;
• aceitar ou rejeitar o trabalho feito pelo time;

Certo, olhando para isso não me parece que o P.O. precise de qualquer conhecimento técnico. Mas espere um pouco, observe como as grandes empresas que apostam no Lean Thinking constroem os seus produtos.

Vamos começar pelo criador da filosofia, a Toyota. No livro “The Machine that Changed the World”, James P. Womack explica que o elemento chave no processo de desenvolvimento de novos carros é o Shusa, uma espécie de super homem, o engenheiro chefe com excelência técnica, que mistura poderes de gestão a uma visão de mercado excepcional, para ser responsável pelo sucesso do produto. Ele tem responsabilidade e autoridade total sobre o projeto, é ele quem decide quais são as features que o carro terá e também qual será o seu custo no mercado.

O fato do shusa ser multidisciplinar, facilita a decisão rápida na hora de colocar na balança o custo de se implementar determinado requisito funcional versus o seu valor de negócio.

A Toyota é reconhecida por valorizar os seus funcionários como sendo o seu maior patrimonio, pois são as pessoas que desenham processos e produtos. E é com essa premissa que o shusa é “construído” dentro da Toyota, em geral ele é um engenheiro senior com mais de 10 anos de experiência, que então começa a ser moldado nas áreas de gestão, negócios, marketing e etc, para depois de cerca de mais 10 anos finalmente virar um shusa.

Na 3M, nosso líder é chamado de Champion e tem funções muito semelhandtes ao shusa. Todo desenvolvimento de um novo produto é liderado por uma figura dessas e um time extremamente motivado. É o Champion quem concebe o produto(sempre visando resolver um problema do cliente), escreve a sua especificação inicial, monta o time, motiva, remove impedimentos, e lídera até o delivery. O Champion é um líder técnico que consegue enxergar um problema do cliente e endereçar o mesmo com uma solução inovadora.

Como é de se imaginar, na Toyota e na 3M, a posição do shusa e do champion são altamente desejadas. Esse é o lugar onde todo mundo dentro da empresa gostaria de estar, e isso motiva novas pessoas a perseguirem esse caminho gerando uma escola natural de líderes.

Seja Shusa ou Champion, o fato é que produtos brilhantes são concebidos por pessoas brilhantes.

No início do Scrum o P.O. era visto como uma pessoa que trabalhava com uma distância grande do time, ja que a pressão que ele exercia era prejudicial ao time. Atualmente a grande missão do Scrum Master é transformar o P.O. num aliado do time.

Juntando todas essas peças, formulo minha teoria de que, se alguém além do time deve ter conhecimentos técnicos, esse alguém é o P.O.. Ele sim deve ser um grande líder, com experiência técnica em alguma área funcional, que direciona o time pela competência, motiva e entusiasma. É a pessoa na qual o time se espelha e briga pra fazer da idéia dele uma realidade.

www.seeqpod.com

[]‘s

já faz um tempo que não posto aqui porque estou realmente sem tempo até para responder os comentários(perdão).

Mas essa dica é muito boa e como acabei de descobrir quero compartilhar com vcs.

Alguns posts atrás eu comentei como fazer para conectar o seu iPhone ao Linux usando o sshfs/fuse. Hoje lendo no TUAW vi que implementaram o AFP para o iPhone e fiquei pensando qual seria a melhor forma de fazer algo parecido no Linux. Ai lembrei que o servico de SFTP do iPhone jailbreaked é publicado via Bonjour!!!

Então é muito simples fazer o mesmo no Linux com Gnome sem precisar instalar nenhum software adicional no iPhone, veja:

vá até o menu do gnome e clique em PLACES->NETWORK, e automagicamente seu iPhone irá aparecer na lista!!

ai basta um duplo clique, colocar login e senha (root/alpine no 1.1.1 ou root/dottie no 1.02, se vc não alterou ainda)

e pronto, agora vc pode acessar seu iPhone para leitura e escrita facilmente.

com isso vc pode facilmente instalar novas aplicacões, jogando o diretório.app no /Applications, copiar suas fotos direto do /var/root/Media/DCIM/100APPLE ou ainda fazer backup das suas informacões que estão no /var/root/Library.

Quem foi que disse que Linux não é user friendly?  dessa vez deixou o Mac Bem pra trás hehe 

[]‘s