Um pequeno review

O evento foi muito bacana, teva ótima organização, boas palestras, tudo muito legal mesmo. Parabéns ao Danilo Sato, ao Hugo Corbucci, à Mariana Bravo e aos demais organizadores.

Palestras

As palestras foram boas, mas em geral não trouxeram nada de muito novo. Mesmo o keynote do Martin Fowler, que tocou no assunto de deploy contínuo, não trouxe nada de muito novo. O Guilherme Silveira, da Caelum, havia blogado em março e feito uma apresentação em maio sobre esse tema no evento Maré de Agilidade, em BH.

Gostei bastante do tutorial do Paulo Caroli, da ThoughtWorks, sobre Agile Card Wall; da palestra do Franscico Trindade, também da ThoughtWorks, sobre Coaching de Guerrilha; achei interessante a palestra do Manoel Pimentel, da Visão Ágil, sobre Coaching para Liderança de Equipes Ágeis, mas fiquei um pouco entediado com suas dinâmicas; e infelizmente, não pude ver o workshop do Rodrigo Yoshima, da Aspercom, e do Phillip Calçado, da ThoughtWorks, sobre Modelagem Ágil, porque eles baleiraram a sala!

O keynote do Klaus Wuestefeld foi bem divertido – feito no Notepad! – e, como sempre, subversivo!

Networking

Mas apesar das boas palestras, a parte mais interessante mesmo, na minha opinião, foram os papos informais nos intervalos das palestras, almoço e final do dia. Papos informais são uma excelente maneira de trocar experiências, ter insights e conhecer pessoas talentosas. Rolou de tudo: liderança de times ágeis, auto-gerenciamento, débito técnico, desafio de lidar com sistemas legados, gerenciamento de iterações, Kanban, métricas, e por aí vai. Muito proveitoso.

Dicas de reviews

Sugiro fortemente que você leia os reviews feitos pelo Rafael Rosa, um dos meus colegas de Locaweb que também estiveram por lá.

Outra dica de leitura é o review que o Alan, também da Locaweb, fez do curso de CSPO que ele fez na prévia da conferência.

Segue abaixo o resumo das minhas submissões e, se você quiser, além de poder deixar comentários aqui, também pode fazer isso no próprio site de submissões do evento.

Espero te ver lá!

Como vi Scrum ser completamente rechaçado em uma grande empresa

Ouvimos por aí muitos relatos de sucesso de implementação de métodos ágeis em empresas grandes. Nós mesmos temos alguns. Mas onde estão os relatos de derrotas?

Nesta palestra vou contar uma história real em que vi Scrum ser completamente rechaçado em uma grande empresa que trabalhei.

Essa não é uma palestra sobre apontar culpados, mas sobre identificar falhas que comprometeram completamente a adoção de métodos ágeis nesta empresa.

Princípios de Agile Coaching

O que faz um coach ágil? Quais são suas ferramentas? Em que se baseia seu trabalho?

Essa palestra é sobre alguns princípios do coach ágil e como ser eficaz nessa missão. Vou abordar temas como:

- educação
- facilitação
- feedback
- percepção
- apoio

Além de falar sobre as atitudes esperadas de um coach:

- liderança por exemplos
- equilibrio emocional
- respeito ao ritmo do time
- linguagem que vence barreiras
- deixar o time aprender com seus erros

Contextualizando

Há pouco tempo assumi uma posição na Locaweb como gerente da equipe de desenvolvimento responsável pelos sistemas centrais da empresa. É uma equipe relativamente grande, dividida em três times de multi-talentosos desenvolvedores, um para cada domínio de negócio que lidamos: Provisionamento, Cobrança e Atendimento; além de dois sysadmins que dão suporte a estes times em tempo integral.

Os times atualmente estão organizados como times de Scrum tipicos, com os tais multi-talentosos desenvolvedores, um Scrum Master e um Product Owner – que no nosso caso, é um gerente de produtos que trabalhar fortemente conosco, extremamente comprometido com os interesses de negócio da empresa.

Desde então, comecei a buscar me interar um pouco mais sobre assuntos de gerenciamento e liderança ao melhor espírito ágil, com a preocupação de não me tornar aquele tipo de gerente que simplesmente “delarga” e vive alienado; ou pior ainda, aquele que comanda e controla o tempo todo, e que no final das contas, mais caroça e atrapalha do que ajuda.

Novo release: Gerente 2.0

Bem, além de conversar com vários amigos – muito mais experiêntes do que eu nesse papel –, também naveguei bastante pela Web e acabei chegando num artigo muito interessante de Pete Deemer, da Scrum Training Institute, que tem me ajudado bastante. Se você também tem interesse no assunto, acho que vale a pena ler.

Pete sugere no artigo, de maneira bem coerente, 14 atividades de um gerente de desenvolvimento. Vamos dar uma olhada no resumão delas:

1- Ajuda a remover impedimentos que o time não tem condições de resolver por si só

Enquanto o Scrum Master remove impedimentos hora-a-hora, dia-a-dia, coisas referentes ao projeto, o gerente precisará focar seus esforços em resolver impedimentos mais sistemátivos, mais corporativo, digamos assim.

Estes impedimentos, frequentemente, são os mais desagradáveis; e que requerem alguma influência, alguma autoridade, para lidar com eles de maneira efetiva.

2- Dá ao time conselhos e sugestões sobre dificuldades técnicas que aparecem

Gerentes deveriam estar disponíveis para dar conselhos e assitência técnica ao time sempre que solicitado.

Nota minha: é que claro que, volta e meia, o gerente vai precisar ir a reuniões estratégicas, corporativas – ou seja lá como chamemos em nossa empresa –, e não poderá atender às solicitações do time de imediato. É preciso tratar isso de maneira bem madura com o time, colocando na mesa as limitações impostas por suas outras atividades e buscando uma maneira de mitigar isso, para que nem o time fique na mão quando precisar, nem o gerente seja crucificado quando não estiver à pronta disposição.

3- Regularmente conversa com os membros do time, um por um, para dar coaching e mentoring

Gerentes deveriam gastar tempo com os membros do time, individualmente, com certa frequência (que cada um deve achar a melhor para si), para dar coaching e mentoring. Veja: não é para pedir status report; é para ensinar, ajudar, guiar, etc, menos cobrar.

Alguns gerentes gostam de fazer isso pareando e escrevendo código junto.

4- Dá sugestões sobre como fazer features melhores

Estas sugestões são endereçadas diretamente ao Product Owner, geralmente, durante a Sprint Review.

Nota minha: o ideal é que isso aconteça sempre, mantendo o máximo de proximidade possível com o Product Owner. No meu caso, por exemplo, sento de frente para o gerente de produtos de sistemas centrais e bato-papo com ele o tempo todo. Ou seja, se tenho algo a sugerir, não preciso esperar a cerimonia de revisão.

5- Mantem-se pari passu do desenvolvimento de ferramentas, tecnologias e técnicas que o time está usando

Esta é uma atividade muito importante e frequentente negligenciada pelos gerentes. Gerentes não podem ficar congelados no tempo. Mesmo porque, a atividade 2 é sobre estar apto a dar conselhos técnicos ao time.

Nota minha: não tem coisa mais irritante do que um gerente que não entende nada do trabalho que você está fazendo, dando palpites furados, e ainda querendo que você explique para ele algo que ele não tem um mínimo de base técnica e conceitual para entender.

6- Planeja treinamento e outros skills de desenvolvimento para os membros do time

Gerentes deveriam pensar cuidadosamente sobre onde o time poderia usar seu skill; e também, cláro, que capacidades o time precisará ter quando for desenvolver determinados itens do Product Backlog.

7- Mantem-se atualizado sobre as novidades e evoluções da indústria

Novamente, uma atividade importante, mas frequentemente neglienciada. Sem ela, a atividade 2 fica fortemente comprometida.

8- Antecipa ferramentas, skills e futuras necessidades

Outra atividade importante, que tem tudo a ver com a atividade 6, e que é frequentemente negligenciada. Converse com seu time a respeito, peça sugestões.

9- Planeja e gerencia orçamento e caixa

Outra vez, algo muito importante, mas muito negligenciado por diversos gerentes.

Nota minha: qual foi a última vez que você colocou no seu orçamento um din-din para cursos, eventos, livros, e outras coisas que melhoram o skill do seu time? Ou você é do tipo que não se preocupa com isso e que, pior ainda, até acha ruim que seu time vá a eventos, faça cursos ou leia livros no horário de trabalho?

10- Dá sugestões de que features o time deveria construir

Vale o mesmo comentário do item 4, não vale? Acho que sim, tem tudo a ver.

11- Faz avalição de performance e dá feedback aos membros do time

Isso é algo necessário em muitas empresas, apesar de bastante subjetivo. Mas o ponto aqui é que gerentes deveriam basear suas avaliações em suas próprias observações, bem como no feedback de outros membros de time.

12- Faz planejamento e desenvolvimento de carreira com os membros do time

Oportunidade de carreira é uma das mais significantes formas de compensar pessoas por seu trabalho. Além de din-din, é lógico!

13- Recruta, entrevista e contrata novos membros para o time

Uma das melhores (mas às vezes, aterrorizantes!) ações de gerenciamento é tomar decisões de contratação. Isso porque boas contratações dão lucro desde o primeiro dia, enquanto que más contratações são uma “taxa” invisivel na habilidade do time entregar valor de negócio.

14- Remove membros que não são capazes de fazer um bom trabalho no time

Se mesmo depois de extenso coaching um membro do time não é capaz de contribuir, de trabalhar harmoniosamente com os outros membros do time, ou de fazer seu trabalho na qualidade esperada, ele precisa ser removido do time, ou mesmo da empresa, rapidamente. Tipicamente, gerentes precisam guiar esse processo de maneira coordenada com o RH da empresa.

Nota minha: não deixe a moral do seu time e o dinheiro da sua empresa ir para o ralo. Cuidado! Há uma linha muito tênue entre “vou dar mais uma chance” e a omissão. Não tenha medo de fazer uma demissão, mesmo que tenha sido você que fez a má contratação. Contratações são quase que como loterias! Na verdade, quem fez a má contratação é o que menos importa; o que realmente importa é a performance e moral do time, que no final das contas, se traduz em mais dinheiro para a empresa.

Conclusão

O papel do gerente de desenvolvimento 2.0, como diz esse artigo de Pete Deemer, traz um mix de habilidades de liderança técnica e de gerenciamento de pessoas – pelo amor de Deus, não chame as pessoas de recursos!

A mim faz todo sentido; e está bem alinhado com as atribuições que recebi, quando contratado pela Locaweb. Aliás, acho que vale citar que, uma das coisas que Pete diz no artigo é que esse “novo” papel do gerente de desenvolviemnto precisa ter uma bênção formal do diretor de direitor TI, ou alguém com poderes equivalentes.

Mas e você, o que acha? Deixe um comentário…

Resolvi postar aqui também, porque achei bem interessante para quem quer ter uma visão introdutória sobre o assunto.

Divirtam-se!

James Shore declarou que agile está em declínio. Ele cita como por exemplo os vários times fazendo ‘sprints’ e stand-up meetings, sem adotar nenhuma das práticas técnicas necessárias para produzir software de alta qualidade no longo prazo. Em sua estimativa, este fato tem levado milhares de times Scrum praticar métodos Ágeis tão pobremente que eles quase certamente fracassarão, e provavelmente levarão o movimento ágil com eles.

Esse é um bom ponto de partida para que novos times ágeis façam uma reflexão sobre o quão ágeis realmente são.

Aqui na CVC Turismo estamos praticando desenvolvimento ágil há pelo menos um ano e meio, e uma das coisas que aprendemos durante esse período foi que, manter o espírito ágil realmente vivo em nós, é mais importante do que seguir “regras de caixinha”. Afinal de contas:

Indivíduos e interações são mais importantes que processos e ferramentas!

Então, muito embora Scrum seja a nossa base, não é e nem jamais será o nosso limite. Além de Scrum, há também outras práticas ágeis que estão presentes em nosso dia a dia, tais como:

- Integração Contínua (mesmo antes de adotarmos Scrum);
- Code review;
- Refactoring;
- Código coletivo;
- E testes, testes e mais testes!

Ainda temos muito que aprender, crescer e amadurecer – mas acreditamos que estamos no caminho certo.

E você, o que tem a dizer sobre seu ambiente de trabalho? O quão ágil ele realmente é?

Todos já fomos somos vítimas desse mal. Mas todos temos também a solução ao nosso alcance…

Reciclagem!!!

Todo processo e todo conhecimento precisa de reciclagem periódica. Só assim conseguimos nos manter atentos aos detalhes.

Tudo bem, mas o que isso tem a ver com o Scrum Master?

O Scrum Master deve ser o guardião dos valores e das práticas do Scrum na equipe. É dele a responsabilidade de disseminar esses valores e práticas e promover a sua reciclagem de tempos em tempos, tanto para o Time quando para o Product Owner. Isso mantém o Scrum não apenas vivo, mas evoluído na equipe.

Com isso, a toda equipe [e os projetos] só tem a ganhar. Porque nem o Time, nem o Product Owner, nem o próprio Scrum Master, se esquecerão de coisas que parecem apenas meros detalhes – mas que fazem a diferença quando observadas [e/ou aplicadas] adequadamente.

Por isso, Scrum Master, fica a você a perguntas: O que você tem feito para promover a reciclagem da sua equipe?

Afinal, ser Scrum Master é ser facilitador…

Notoriamente, todos os itens de um Sprint Backlog são relevantes. Porém, nem sempre todos estes são vitais para o dado momento do projeto – neste caso, é possível viver mais um timebox sem eles. Ter esta percepção te ajuda a descobrir o quando uma Sprint foi bem sucedida.

Scrum é viciado em ROI. Sendo assim, o sucesso da Sprint está intimamente ligado ao ROI do cliente. Se o que o time conseguiu produzir e entregar com total qualidade ao final da Sprint é exatamente o que o cliente precisava para começar (ou continuar) a ter lucro com seu negócio, ótimo, a Sprint foi bem sucedida!

Agora, se ao final da Sprint o cliente não tem nada de relevante e que trague algum valor ao seu negócio, a Sprint foi um fracasso. Talvez, não um fracasso total; mas ainda assim, um fracasso.

Quer sucesso na sua Sprint? Dê lucro ao seu cliente… É o que ele mais gosta…

Até a próxima!

O evento foi ótimo. Organização, coffe break, brunch, palestras, logística. Tudo esta “nos conformes”.

(Os lanches estavam muuuuito bons, como em todos os treinamentos da Caelum. rsrsrs)

Sobre as palestras, um mais que rápido review:

1- Abertura, Paulo Silveira

Fui muito legal saber dos números da Caelum. Tudo que o Paulo Silveira falou, certamente, foi muito inspirador para todos que estão pensando em começar um negócio, ou mesmo já começaram.

2- Os 7 hábitos dos arquitetos altamente eficazes, Guilherme Silveira

A visão da Caelum para um arquiteto é bem na linha daquilo que eu também acredito, então, foi uma boa palestra para eu ganhar mais embasamento em minhas idéias, sabendo que mais gente (e neste casa, uma pessoa reconhecidamente capaz) pensa como eu penso. Não estou totalmente errado… Uff! =)

Basicamente, a palestra dele colocou o arquiteto no lugar onde ele realmente deve estar: Junto com os desenvolvemores, ajudando no desenvolvimento técnico/profissional deles. É papel do arquiteto estar sempre antenado quanto a tudo quanto é tecnologia que exista por ai. Mas é também papel do arquiteto capacitar (com workshops, coach, pair programming, enfim…) seus desenvolvedores nas tecnologias adotadas num dado projeto que estejam participando.

De que adianta um arquiteto conhecer de mais de uma dada tecnologia, se seu time não conhece, não tem fluência? Adianta se ele capacitar o time. Senão, adianta absolutamente nada. (Porque não adianta um arquiteto decidir por uma dada tecnologia se o time não conhecer essa tecnologia.)

Também é importante que todo arquiteto tenha plena certeza de que NÃO EXISTE A BALA DE PRATA. Entendeu? Não? Vou repetir: NÃO EXISTE A BALA DE PRATA!

Vou falar mais sobre os 7 Hábitos e o papel do arquiteto num próximo post.

3- JAP 2.0, Emmanuel Bernard

Esse cara é o líder da implementação Hibernate da JPA, e também um dos participantes da especificação 2.0 da JPA. Isto além de ser líder do projeto Hibernate Search – que também rendeu palestra.

A palestra dele foi bem legal, deu para ver que eles estão trabalhando numas coisas interessantes para a JPA 2.0. Vamos esperar que tudo dê certo… =)

Uma das principais idéias da JPA 2.0 é expandir a API de forma a padronizar coisas que JÁ EXISTEM no Hibernate, para que também outras implementações tenham compatibilidade entre si; e cada vez menos teremos que usar recursos específicos do Hibernate.

Que venham esses novos recursos, porque depender de TopLink… é… deixa pra lá…

4- Domain-Driven Desig, Sérgio Lopes

Cara, essa palestra foi muito divertida. Muuuuito engraçada mesmo. Parabéns ao Sérgio pela criatividade!

Em termos de conteúdo, ele não pode se aprofundar muito, por conta do curto tempo para sua palestra. Como já estou trabalhando com DDD [num grande projeto] há pelo menos 10 meses, tinha anseio de ouvir coisas um pouco mais avançadas. Mas tudo que ele passou, de maneira simples e didática, creio que toda a galera conseguiu entender.

Paulôôô, da próxima vez, dá mais tempo pro menino!

5- Hibernate Search, Emmanuel Bernard

Essa me surpreendeu, porque eu não fazia muita idéia do poder dessa API. Caraca! O negócio é muito bom mesmo.

A idéia do Hibernate Search é literalmente GOOGLEAR suas pesquisas ao seu modelo de domínio. O que é isso? É você fazer aquelas pesquisas que o Google faz (por exatidão, por proximidade, por relevância, etc, etc, etc) no modelo de domínio (sim, objetos!) da sua aplicação. Seria uma full textual search em cima de objetos persistentes.

Com certeza vou estudar dar um estudada nessa API.

Ah! Acho que vale dizer que Hibernate Search usa recursos do Apache Lucene.

6- JRuby, Fábio Kung

Esta era a palestra que eu estava mais interessado em ver. Por quê? Motivos óbvios, adoro Ruby. JRuby então, vixi! =)

O Fábio falou principalmente sobre a experiência de estar desenvolvendo o GUJ on Rails, que é a versão 3.0 do GUJ (a maior comunidade Java da América Latina) totalmente desenvolvida com JRuby on Rails. Chapante!

E o benchmark? Esse foi de matar… O GUJ 2.0 (Pure Java) atende 20 requisições por segundo; o GUJ 3.0 (JRuby on Rails) atende 140 requisições por segundo.

Hammm… Alguém ai disse que Ruby é lento? É… A história se repete…

Tinha expectativa de ver uns códigos, o processo de deploy, etc. Mas de qualquer forma, valeu bastante a palestra. (Se eu já estava doido para colocar alguma coisa Rails no ar, agora estou completamente maluko!)

Bom, depois dessa palestra tive que ir embora, pois tinha um outro compromisso inadiável.

Agora, fora as palestras que foram muito legais, o evento também serviu pro famoso network, ou troca de idéia, ou o que você queira chamar.

Conheci pessoas novas, como o Tony, que trabalha num time Scrum na Abril; o Guilherme Chapiewski, que é ScrumMaster/Tech Lead na Globo.com. E também reencontrei uns caras que não via há um tempo, como o Fábio Akita.

Enfim, valeu de mais o evento!

Mais uma vez, Caelum: Parabéns!

Fui…

Esse ano, entre outras “atrações”, o evento traz [dos EUA] Emmanuel Bernard, líder da implementação JPA do Hibernate e membro do time de especificação da JPA 2.0. Sem dúvida alguma, uma palestra imperdível.

Além desse figura, outras também muito tarimbadas da comunidade brasileira: Paulo e Guilherme Silveira, Alexandre Magno, Fábio Kung, entre outros.

Com certeza, eu vou!

A gente se vê por lá…