Elderclei Reami's Blog- Around Scrum

ScrumMaster versus Gerente de Projetos (again)

ereami — Thu, 20 May 2010 23:05:38 +0000

Falta de foco e tempo para postar resulta nisso: quase um ano de blog parado

Para dizer que não fiquei parado, publiquei o artigo Agile and management of change no site do novo livro do Jurgen Appelo. O texto fala um pouco sobre a necessidade de “gerenciamento da mudança” nas organizações, então, gostaria de aproveitar o gancho e falar um pouco mais sobre o tema aqui.

Há pouco tempo recebi de um colega um post falando sobre o conflito entre o papel do ScrumMaster e do gerente de projetos nas organizações. Essa discussão da pano pra manga e é totalmente ligada a cultura organizacional e a necessidade de tempo e vontade para mudá-la.

Sobre as opiniões mencionadas no post, tenho minhas próprias:

A opinião do Alexandre Magno é consistente como de hábito. Não a toa, é um ótimo CST e seus cursos são sempre pragmáticos e baseados em casos reais.
O Carlos Santos não sabe do que está falando (gerente de projetos não é responsável direto, nem por gerenciar as pessoas, nem por gerenciar o produto, wtf).
Lisa Grant também não sabe do que está falando (“Scrum Master precisa ser técnico para remover os impedimentos técnicos”? wtf).

O fato é que há restrições de despesas em empresas, então, muitas vezes uma única pessoa exerce múltiplos papeis (não é raro encontrar por aí quem atue como GP, ScrumMaster, arquiteto e programador ao mesmo tempo). O problema essencial disso é que pessoas possuem hábitos arraigados e experiência de vida acumulada, então, desde que não tenham diagnóstico de personalidades múltiplas, seus hábitos pre-existentes (e seus entendimentos sobre “o que funciona”) irão interfirir de alguma maneira no papel que estão desempenhando – é preciso uma disciplina hercúlea e um ambiente favorável para mudar isso.

De outro lado, há confusão de expectativas em relação ao que um ScrumMaster deve realizar e é comum que muitas áreas de uma empresa e mesmo a alta gestão esperem que o ScrumMaster entregue o mesmo tipo de valor entregue por um GP. O mesmo vale muitas vezes para o papel do Product Owner, que confunde-se com o papel do gerente de projetos e do gerente de produtos em muitos lugares. Imagine um local em que tanto ScrumMaster, como POs, são cobrados como GP – muitos eventos de comando e controle dos times vão surgir. Para mudar tudo isso, é necessário um modelo para promover mudança cultural e consistência na sua execução, mas, como é sabido, esse tipo de mudança leva anos para se consolidar e poucos são os relatos de mudança completa e definitiva, ou seja, a mudança é algo para ser cultivado indefinidamente. A Toyota fez isso ao longo de mais de 50 anos e, mesmo assim, sabemos dos incidentes recentes produzidos em parte pelo foco em aumentar os lucros.

Enfim, focar-se apenas no ideal, sem lidar com o dia-a-dia das corporações é receita para o fracasso profissional e frustração pessoal. É preciso entender que mudanças ocorrem numa velocidade muito menor que a ideal e que, apesar disso, é necessário continuar produzindo e gerando os resultados esperados. Há uma maneira melhor? Certamente, há, mas não se chega lá num átimo de tempo.

BlogBlogs.Com.Br

Postura errada mata métodos ágeis

ereami — Fri, 08 May 2009 17:18:14 +0000

Muito bom mesmo, o vídeo “The downfall of agile Hitler” disponível no Youtube em http://www.youtube.com/watch?v=l1wKO3rID9g!

Ajuda a entender o tipo de postura indesejável por parte do time (PS1) e por parte do Scrum Master ou XP Coach ou quem quer que esteja responsável por cultivar práticas de engenharia na empresa.

Por isso, não é possível esquecer os valores e princípios dos métodos ágeis.

PS1: Se o time se comprometeu com algo e não está conseguindo aderir ao comprometimento, ele precisa ter confiança e percebe abertura para dizer que algo está errado, que tal abordagem não funciona, que errou ao se comprometer, etc.

Scrum e XP (still a good marriage)

ereami — Thu, 07 May 2009 14:53:57 +0000

Ken Schwarber ressaltou em artigo no Scrum Alliance (http://www.scrumalliance.org/resource_download/745) que customizar o processo do Scrum pode significar “jogar a poeira para debaixo do tapete”, ou seja, perder a capacidade de descobrir problemas rapidamente e de “inspecionar e adaptar”.

Por outro lado, vejam que ele não diz que XP é uma customização do processo, afinal anos da cultura do waterfall criou programadores sem as habilidades necessárias para criar software de maneira ágil – bem usado, Scrum faz esse problema emergir e adotar XP é um possível remédio para a doença.

Minhas migalhas para essa discussão.

PS: Conheci o Helder Rocha alguns anos atrás e poucos instrutores tem didática e conhecimentos técnicos tão bons. Essa apresentação dele sobre XP (eXtreme Programming) é bastante concisa e muito instrutiva para quem é Scrum Master e, infelizmente, não conhece XP – ajudou-me bastante