Falando em Agile 2008

Esta semana vou fazer uma palestra no Falando em Agile 2008, evento organizado pela Caelum do Paulo Silveira e do Alexandre Magno. Esta é a primeira edição deste evento com foco em agilidade e processos de desenvolvimento de software, um assunto cada vez mais recorrente no nosso dia a dia e tema constante em todos os eventos relacionados a tecnologia que participo e leio a respeito.

Apesar de ser a primeira edição do evento, a Caelum trás na bagagem a experiência de realizar o Falando em Java, evento já bem conhecido dos desenvolvedores e muitos anos de participação na comunidade de desenvolvedores no Brasil.

Como não poderia deixar de ser, a agenda esta excelente. Vou poder reencontrar alguns velhos amigos e trocar idéias com pessoas que estão buscando se aprimorar e conhecer mais sobre processos ágeis de desenvolvimento, entre os palestrantes estão Phillip Calçado, Guilherme Chapiewski, Danilo Bardusco e o David Anderson, um dos criadores do FDD (Feature Driven Development). Aqui esta a agenda completa.

Eu vou falar sobre o Product Owner e seu papel dentro de um time ágil, e discutir alguns pontos que sempre surgem quando se fala sobre a sua atuação: o Product Owner pode ser técnico? O PO é parte do Time ou deve ficar de fora do Time? Como se planejar para entregar um release em uma data específica?

Vejo vcs lá!

Distância ainda é importante

Eu não sou muito a favor do uso de ferramentas eletrônicas no gerenciamento de projetos tocados por equipes ágeis, no entanto, até o momento não tivemos que lidar com grandes distância entre membros de um mesmo time ou entre times na Globo.com. Existem diversas ferramentas digitais que se propõem a ajudar os times que estão distantes, a estruturar melhor a informação, gerar relatórios gerenciais e por ai vai. Algumas destas ferramentas são por exemplo o Mingle da Thoughtworks, o VersionOne, o Jira com Greenhopper entre outros, vc pode ver uma lista mais extensa dessas ferramentas no blog do Wayne Allen.

Ainda acho que tudo se resolve com um bom e velho whiteboard, lembrando um dos princípios do Agile Manifesto “Individuals and interactions over processes and tools“. Se for necessário gerar um report do andamento do projeto (ou do sprint) tire uma foto do whiteboard todos os dias e envie para quem precisa deste report. Não tem nada mais claro para verificar problemas e andamento de um time do que o whiteboard.

Hoje em dia a Globo.com esta recoberta de Whiteboards e os burndown charts podem ser vistos por toda a empresa, o que mostra como as coisas estão mudando por aqui. Mas isso não tira mérito das pessoas que tentam encontrar formas de melhorar o trabalho quando times precisam atuar em um mesmo projeto e estão separados geograficamente.

Nas minhas leituras esporádicas de RSS encontrei um post sobre um projeto interessante do Henrik Kniberg chamado Whiteboard Wiki (http://www.whiteboardwiki.org), que se propõe a recriar online, de uma forma simples e direta, o ambiente de um whiteboard.

De qq forma ainda acho que se vc tiver uma opção de manter o time co-locado, nem pense em outra alternativa, “Take It“. Em linha com isso esta um paper do Gary e Judith Olson chamado Distance Matters, onde eles apresentam um estudo sobre o uso de tecnologia como forma de diminuir os problemas da distância. Abaixo segue a conclusão deste Paper:

Collaborative work at a distance will be difficult to do for a long time, if not forever.There will likely always be certain kinds of advantages to being together. However, as a wide range of collaborative tools emerges, we will find useful ways to use them to accomplish our goals. If at some point in the past we had written a similar article about telegraphy, the telephone, radio, television, or fax machines, we would have had tables that catalog their shortcomings. However, in their own ways, all of them have turned out to have been useful for a variety of purposes, and they worked their ways into social and organizational life in enduring fashion. Indeed, some of the most profound changes in social and organizational behavior in this century can be traced to these tools. The rich repertoire of present and future collaborative technologies will have a similar fate. We will find uses for them, and descriptions of collaborative work in the future will enumerate the emergent social practices that have put these technologies to useful ends. But it is our belief that in these future descriptions distance will continue to matter.

O perigo do mini-waterfall em times ágeis

Hoje estou finalmente tirando o atraso do meu Google Reader e lendo alguns artigos e posts sobre Scrum e Agile development, me deparei com uma excelente iniciativa do Mark Levison chamada Agile/Scrum Smells (baseada em um projeto do Mike Cohn) com o objetivo de catalogar os principais problemas encontrados durante a implantação e dia-a-dia de práticas ágeis, em especial práticas ligadas ao SCRUM.

A lista esta sucinta, mas já constam diversos problemas muito comuns no dia a dia de equipes ágeis. Um dos problemas que me chamaram a atenção e é um problema que temos que evitar a todo custo é a formação do que venho chamando de mini-waterfalls. As pessoas com o tempo, mesmo quando estão dentro de times ágeis, tendem a voltar a fazer as coisas como sempre fizeram, principalmente quando aparecem problemas, Ken Schwaber descreve esta reação no seu livro The Enterprise and Scrum, e a chama de “Muscle Memory”:

Expect muscle memory to exert itself. When a project is going well, everyone is happy with Scrum. However, when stress, a problem, or an unexpected failure occurs, everyone tends to throw away Scrum and revert to their muscle memory. Teams don’t want to self-manage. They want to be told what to do. Managers don’t want to let teams self-manage. They want to command the teams in all matters, down to the minutest detail. Teamwork is dumped for individual heroics. Quality is abandoned. Everyone draws on what they think has worked best in the past. (SCHWABER, The Enterprise and Scrum, Chapter 4).

Bem, detalhamento um pouco mais, entre as caracteristicas de um time ágil temos que ter um número pequeno de profissionais, com todas as habilidades necessárias para que se atinja o goal/visão definida pelo Product Owner e entregando o maior valor de negócio possível no menor tempo possí­vel, aplicando sempre o princí­pio de implementar “The simplest thing that could possible work“.

É neste ponto onde começam os problemas que vão gerar o mini-waterfall, geralmente as pessoas trabalharam toda a sua vida em empresas que empregam o princípio do Big Design Up Front (BDUF), ou seja, primeiro as pessoas querem planejar todas as possí­veis variações do projeto, em todas as telas, todas as mensagens de sistema, todos os fluxos, todas as queries, todo o modelo de dados antes mesmo de começarmos a “meter a mão na massa” no projeto. Isso leva a departamentalização e ao faseamento do desenvolvimento em steps especializados: Levantamento de requisitos, análise, arquitetura da informação, design, provas de conceito, desenvolvimento, testes, produção. Com isso criamos um processo em cascata que incentiva o veneno deste tipo de abordagem: falta de compromisso com o todo, com o Goal e com a Visão, cada um faz a sua parte, e que o próximo na fila no processo dá o seu jeito para entregar para o próximo e assim por diante, as pessoas passam a ser responsáveis pelas suas especialidades e não pelo produto, pela entrega final. É triste ver um time, antes ágil, começando a criar hábitos cascateados e viciados.

O que fazer? Este exemplo usado pelo Mark Levison mostra como seria uma postura ágil:

A successful Scrum team does not need to be comprised entirely of generalists. However, for a team of specialists to be successful each specialist must accept general responsibility for the system as a whole. I may not know how to solve our project’s most intricate Oracle problems but I am going to do whatever I can to help, which may simply include taking on some of our database specialist’s other responsibilities to free her to solve the complex problems.

Enfim, temos que nos policiar contantemente e observar se não estamos voltando aos nossos velhos hábitos, e lembrar que é muito difícil mudar a cultura das pessoas e da organização, e que isso é um trabalho de paciência e perseverança.

Inovação ou erosão

Esta semana estou em Nova York para participar do Streaming Media East Conference e no vôo de Miami para NY, comprei a Business Week desta semana, que tem o Steve Ballmer na capa. A matéria de capa fala sobre o enrolo Microsoft+Google+Yahoo, nada demais ali, mas na página 48 tem uma matéria bem interessante sobre a Westinghouse, uma empresa secular da área de energia que tem como grande especialidade a construção, manutenção e serviços em usinas nucleares.

Obviamente, em uma empresa que projeta reatores e usinas nucleares a inovação e experimentação não eram vistos com bons olhos, na verdade era inibida sempre que possível. Em 2006 a Toshiba (WTF?) comprou a Westinghouse Electric por US$ 5.4bi e começou uma nova fase na empresa, iniciou-se um processo incentivo a inovação em toda a empresa, sem comprometer a integridade dos sistemas e produtos atuais.

Obviamente este é um processo que esta bem longe de terminar, o foco da inovação no contexto da Westinghouse esta bem localizado na criaçao de novos serviços que podem ser prestados para os atuais clientes e tb em novos serviços para clientes que possuem produtos da concorrência. O processo começou escolhendo os melhores gerentes e alocando eles como “Growth Leaders” com a atribuição exclusiva de buscar novas oportunidades e tecnologias, eles tem a liberdade de conversar com todas as áreas da empresa em busca de novas idéias que separadas nao valem muito mas juntas podem formar um serviço novo e diferenciado.

Na verdade o que mais me chamou a atenção na matéria foi a seguinte frase:

If you only do what you know and do it very, very well, changes are that you won’t fail. You’ll just stagnate, and your work will get less and less interesting, and that’s failure by erosion. True failure is a mark of accomplishment in the sense that something new and different was tried.

Isso tem tudo a ver com a nossa industria e nós já sabemos isso de cor, a construção de software passa sempre por falhar, aprender com os erros e melhorar (PDCA), mas nunca tinha lido nada do gênero com uma industria tão peculiar quanto a de energia nuclear. O que reforça mais uma vez que ter a atitude de tentar coisas novas é uma caracteristica cada vez mais importante em qualquer profissional em qualquer ramo de trabalho.

O ScrumMaster e seu papel

O Guilherme Chapiewski escreveu um post esta semana bem polêmico e a discussão esta correndo solta no Blog. O ponto é, até onde vai o papel do ScrumMaster quando este pode ajudar o time resolvendo, quando possível, impedimentos técnicos ou discutindo uma dada solução técnica.

Nas últimas semanas, venho conversando muito com o Guilherme e com a Patricia Fontes (nossa Product Owner nos projetos de vídeos da Globo.com) sobre estas questões de relacionamento entre Time, ScrumMaster e PO, até onde vai o papel de cada um. Nas nossas conversas geralmente temos pontos de vistas diferentes e as vezes opostos, mas o resultado destas conversas tem sido muito enriquecedor, pelo menos para mim. No final de cada conversa sinto que estamos mais unidos e concientes de onde queremos chegar e sempre que discutimos tentamos manter como nossa referência o que é a melhor solução/decisão/atitude para os produtos que estamos construindo.

O Phillip Calçado também fez um post onde coloca o seu ponto de vista sobre ter um SM que também é um líder técnico. Neste post dele gosto muito da frase:

Quem assume que isso é uma verdade absoluta está buscando respostas fáceis ao invés de tentar resolver o problema. Isso não é diferente em nada do cidadão que usa todos os templates, artefatos e papéis do RUP no seu projeto, ou daquele que acredita que um selo como CMMI ou MPS.BR traz qualidade.

E replicando meu comentário no blog do Phillip, para mim não existem verdades absolutas, e sim evolução e aprendizado contínuo, aprendizado quer dizer que erramos e acertamos em ciclos infinitos, e se estivermos no caminho certo, mais acertamos do que erramos, e estes erros que cometemos não deveriam se repetir.