Scrum Organization

Agile Organization
Michael Lundgren
www.citerus.se
http://mikaellundgren.blogspot.com/

Achei a palestra superficial e já um pouco manjada pelo que eu sei de scrum. O palestrante é um consultor de scrum local. Infelizmente os sites dele estão em Sueco.

Seguem alguns tópicos abaixo:

- segundo ele, deveríamos ensinar aos desenvolvedores negociarem e pensarem em dinheiro. Bom acho que ele quis dizer aqui na evolução do produto, pois eu acho complicado e arriscado deixar a mente do desenvolvedor voltada ao pragmatismo financeiro. Acho que ele tem de estar focado em deixar o código certo e se a arquitetura vigente poderá atender o produto no futuro.
- independentemente da quantidade, o seu time está grande, quando todas as pessoeasl perdem a noção do que estão fazendo.
- grassroot movement ao invés do gerenciamento? Ele disse que isso é importante e vai focar nas pessoas. Acho que isso é importante no momento inicial. Depois depende mais da alta gestão saber o que está acontecendo e como mudar ou tirar vantagem da situação.
- ele contou a história de um produto para música que foi lançado com bom hardware, boa idéia, mas com o software que não funcionava
- não teremos mais pessoas copiando requisitos de um lado para outro usando scrum. Não deveríamos ter cercas.
- as pessoas deveriam refletir mais sobre as questões do dia-a-dia de scrum. Estamos fazendo da melhor maneira?
- a gestão deveria aprender com as restrospectivas em como manter o ambiente melhor e as equipes mais motivadas.
- ele também acha que todo o membro do time deveria ser capaz de desenvolver.
- segundo ele, os gestores funcionais se transformam em pessoas que voltam a codificar, após o scrum. Alguns deles são alocados para dar apoio a outros times.
- sobre QA: quanto mais curto o espaço de tempo entre identificar um bug e pedir para alguém corrigir melhor.
- uma coisa que ele não gosta são os pequenos intervalos entre sprints para acomodar tempo  para ajuste de código. Ele sugere peer programming para diminuir esse intervalo. Após codificar, um explica para o outro o que fez.  

Abertura com Jeff Sutherland

Scrum se tornou o processo ágil dominante, segundo pesquisa mostrada por ele. Infelizmente não vi fonte e nem metodologia disso durante a apresentação.

Scrum em software tem mais desempenho se misturado com técnicas de xp. É o caso do UOL, por exemplo. Aliás a consultoria que contratamos, Sprint IT, desde o início veio com uma proposta nesse formalto. Se você seguir somente o livro preto de Scrum, fica difícil de colocar em prática no ambiente de trabalho. Aliás, o Scrum não é uma metodologia, e sim um framework para gerir desenvolvimento de produto, podendo ser complementado por técnicas que vem de fora dele.

Jeff criticou Yahoo! Eles não estão procurando valor para os negócios. Acho que não é legal se aproveitar de um momento infeliz do Yahoo! para fazer valer uma posição em conferência.

Ele falou sobre times que evitam o conflito, e estão sempre convergentes e coniventes com a situação. Isso é ruim, porque não traz inovação, segundo o paper da Harvard Business Review. Só essa vontade de melhorar traz comprometimento e confiança.

Toda implementação ou transição para scrum precisa de um sponsor ou protetor com poder suficiente dentro da organização. É ele que vai proteger os interesses do scrum perante as dificuldades naturais da transição. Foi dessa maneira que seguimos no UOL, tendo um gestor com poder dado pela alta gestão. Realmente não tem jeito, em uma empresa antiga com processos já definidos e alguns nem definidos, mas com certa ineficiência acomodada, é necessário ter um guardião para assegurar que o Scrum não seja contaminado pela situação vigente. As pessoas não fazem por mal, mas tomam posições contrárias a mudança, ou por não conhecerem o que virá, ou por achar que conhecem, e achar que estarão com menos poder ou até mesmo sem emprego. No final, se as equipes e a gestão forem persistentes, as coisas se ajeitam de uma melhor maneira.

Jeff citou John Kotter (http://www.johnkotter.com/bio.html): 70% dos processos que exigem mudança falham. Não tem relação com o scrum somente, mas com estudo sobre processos em geral. A falta de liderança e senso de urgência causam a falha.

Jeff lembrou que os product owners são os visionários. Idéia que me veio na cabeça : Uma coisa que poderia melhorar o desempenho do time dentro da empresas seria o product owner dar um palestra sobre a visão do produto, talvez a cada semestre. Ele teria de dizer qual a visão dele para o produto a cada período. Na rotina do desenvolvimento, às vezes o time perde a noção da importância do produto.

Por fim, Jeff concluiu que equipes muito produtivas tem dificuldade em manter velocidade alta todo tempo. Geralmente esses times tem bons skills em integração contínua e em codificar o teste automatizado antes de desenvolver.

Scrum Gathering 2009 em São Paulo?

O pessoal aqui disse que quer fazer um evento desse em São Paulo no segundo semestre de 2009. Espero que dê certo.

Scrum Gathering 2008

Esse é o primeiro post relacionado ao evento que estou no momento: Scrum Gathering em Estocolmo (http://www.scrumalliance.org/events/6--stockholm-scrum-gathering). Estocolmo? Sim, Estocolmo, capital da Suécia. O pessoal da ScrumAlliance é bem esperto. Eles alternam a realização do evento Scrum Gathering entre Estados Unidos e outra cidade no mundo. E claro escolhem mercados ainda não totalmente explorados pelo scrum e com bom potencial para crescimento.

Na Suécia e países vizinhos há empresas que desenvolvem games, sistemas de telefonia, por exemplo. Com isso cria-se um mercado de consultores de scrum e desenvolvedores free-lancers com pequenas empresas.