Scrum - Más interpreções, segundo Ken Schwaber

Ken Schwaber deu uma palestra sobre más interpretações do Scrum, que apesar de básica para quem já conhece scrum é muito boa para alinhar conceitos. Aliás, a maneira como ele fala o mesmo que você já leu é muito boa. Ele consegue repetir o conceito sem passar por chato. Ele fala um conceito e conta um caso de como deu certo ou deu errado, assim como ele faz nos livros dele.
Para iniciar, scrum não é uma metodologia. É um framework, ou como alguns dizem aqui, arcabouço para gerenciar desenvolvimento de produto. Ele define os encontros, papéis e atitudes esperadas dentro do desenvolvimento do produto. O que você tiver que colocar ou melhorar vai ser a partir desse framework. Por isso, se você quiser boas práticas de XP, normas da qualidade ou mesmo integração com o ITIL você pode fazer a partir dele. O que entendo disso é que técnicas e regras podem ser inseridas, desde que não descaracterizem a priorizaçõa do backlog. Aliás, acho que o scrum cresceu bastante no mundo de desenvolvimento não só pela definição de um bom framework, mas pela capacidade de inserir técnicas de desenvolvimento ágil tornando a atividade de gerar e testar código mais fácil a cada mudança necessária. Se fosse só pelo livro preto de scrum, o framework ficaria muito teórico e pouco prático para a dinâmica das empresas hoje. A outra coisa que o torna um grande framework é que ele muito simples de aprender. Você não precisa ler muita coisa e decorar muitas normas. Você precisa ler um ou dois livros, fazer um bom curso de scrum master ou product owner e está dentro. A facilidade de aprendê-lo não poder ser confundida com a dificuldade de implementá-lo. Sim é difícil de implementá-lo. Para falar o óbvio, essa dificuldade tende a ser proporcional ao tamanho da organização que ser quer inseri-lo mais a quantidade de anos e experiência com processos antigos.
Outra coisa que Ken Schwaber lembrou é que o Scrum foi criado a partir da percepção que desenvolver software para produtos é um processo empírico. Ou seja, há tanta incerteza no QUÊ se quer e também em COMO atingir esse objetivo que é melhor fazer um pouco de cada vez, mostrar, ver o que tem que ser ajustado, e iniciar o ciclo de uma maneira melhor.
Enfim, achei importante Ken Schwaber relembrar dos conceitos que ele mesmo usou e pensou para criar scrum, pois mostra para o pessoal que não viveu com outros métodos ou frameworks onde já se passou até chegar ao Scrum, e como podemos evitar erros no futuro. 

Times agile formado por centenas de pessoas

O apresentador, Bas Vodde, escreveu livro com Craig Larman sobre scaling times de desenvolvimento agile. Parece ser boa leitura para se fazer, quando o livro for lançado (http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961/ref=sr_1_4?ie=UTF8&s=books&qid=1225363486&sr=1-4). Ele já escreveu outro e até apresentou a capa, mas nem está listado ainda na amazon. Lembrando que o companheiro de escrita dele, Craig Larman, escreveu Applying UML and Patterns, que na época do RUP foi um dos livros mais interessantes para se ler. Mesmo tendo RUP no livro, ele já procurava criar uma cultura de desenvolvimento iterativo com entregas em time box, e diagramas informalmente desenhados. Por isso, acho que seria bom algum dia Craig Larman reescrever o livro de Applying UML and Patterns tirando as menções aos artefatos do RUP e pensar mais nos design patterns GRASP, que ele explica muito bem, e como transitar da análise para o design, transformando histórias de usuário em esboços de classes. Mas voltando ao Bas Vodde, ele trabalhou na Nokia em Helsinqui por 3 anos, se não me engano. Ele liderou a transição da Nokia para processo ágil. Porém ele já não trabalha mais lá. Atualmente é um consultor independente em Cingapura. Ele parece ser uma pessoa que lê muito sobre desenvolvimento, mostrou fotos da casa dele cheia de livros. Pessoas que o conhecem mais intimamente disseram-me que ele lidera times de desenvolvimento durante o trabalho, e ainda contribui com projeto opensource. Além disso, ele tem um blog (http://www.odd-e.com/blog/). Bom, seja para concordar com ele, ou discordar dele, é bom escutar uma apresentação de uma pessoa assim, pois você sabe que está em contato com alguém que conhece muito bem o assunto.
Imagine-se trabalhando em um desenvolvimento de produto com cerca de 500 pessoas em usado processo ágil. A situação seria a seguinte:
1) o product owner tem de priorizar o backlog ainda pela importância para o negócio;
2) há diversos times de aproximadamente 7 pessoas. Provavelmente cerca de 70 times;
4) existem várias disciplinas ou áreas de conhecimento para desenvolver o produto. Com certeza, muito mais do que um time poderia ter;
3) é claro que seria interessante manter todos homogeneamente ocupados;    

A proposta dele é muito simples. Aliás, ele demorou mais para descrever o ambiente do que para explicar a proposta. Ele acha que o product owner e os designers deveriam pensar no produto sem vícios associados à formação do time (lei de Conway descrita no post abaixo). Uma vez feito isso, uma equipe de arquitetos formada por gente especializada em cada área de conhecimento necessária para desenvolver o produto dividiria os desenvolvedores do produto em grupos pequenos, mas procurando deixar os times com várias áreas de conhecimento diferentes. Então a cada iteração, o product owner priorizaria os itens a serem desenvolvidos, e o mesmo grupo de arquitetos distribuiria para os times de maneira equilibrada possibilitando a ocupação de todos. Na realidade a proposta é bem parecida com o scrum de scrums, descrito no livro do Ken Schwaber. O que ele adiciona é a ênfase em manter o desenvolvimento do produto sem vícios de formação de times. Ou seja, pensar em partes interdependentes do produto, e para cada uma dessas partes ter uma equipe de especialistas que distribui trabalho de maneira equilibrada para as pessoas. Embora, ele não tenha conseguido colocá-la em prática ainda, parece-me bem promissora.

Lei de Conway

Durante uma apresentação, Bas Vodde enunciou a Lei de Conway para argumentar o que ele estava prestes a apresentar: 

"..organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"

Se você for parar para pensar, vai dizer: Oh! Really! Qual é a grande novidade? Pois é, mesmo sendo óbvio para os dias de hoje para quem participa do desenvolvimento de sistemas, ela faz refletir e pensar até que ponto os problemas de comunicação entre times, ou mesmo a formação de diferentes grupos funcionais não deforma ou vicia o design idealmente pensado de um produto. Ou mesmo quantos problemas de usabilidade poderiam ser evitados em alguns produtos se alguém de dentro do projeto observasse isso, e decidisse reestruturar o time para melhorar a comunicação. Além disso, isso me fez pensar como o desenvolvimento de um produto inovador, às vezes contando com estruturas organizacionais já montadas para um produto antigo não influenciam e eventualmente viciam o produto inovador.

Ela tem uma prova empírica escrita em um artigo de harvard:  http://www.hbs.edu/research/pdf/08-039.pdf

Gerente de projetos e o scrum master

Enquanto eu esperava o início de uma apresentação, participei de um fórum sobre comparações entre pmi e scrum. É claro que o assunto estava sempre muito associado aos papéis de gerente de projetos e scrum master.
Um dos pontos importantes dessa discussão foi o de proteção do time. O gerente de projetos tende a proteger as pessoas no sentido de iteração com as outras pessoas. Afinal de contas, ele precisa saber o que está acontecendo e ver necessidades de mudanças, e conseqüentes impactos. Com o scrum, o time flui e interage melhor com as pessoas. A discussão tem de ser focada em cumprir as atividades relacionadas às histórias do sprint. O scrum master, nesse caso, só atua para garantir que o time não esteja sendo interrompido e se desviando dos objetivos combinados.

Implementação de método ágil na Salesforce.com

Transição de waterfall para agile

SalesForce tem uma plataforma para montagem de aplicações de CRM. Interessante e curioso. Vou olhar com mais detalhe para entender como eles funcionam.
- 500 pessoas em P&D
- tinham 4 major deliveries por ano usando processo na linha do waterfall
- enfrentavam problemas de produtividade, após crescerem o time depois do boom em 2000. Com a expansão, eles perderam velocidade que tinham originalmente.

Eles tinham:
- gargalo de pessoas – por exemplo, um chefe de arquitetura, um chefe de QA
- falta de previsibilidade
- falta de responsabilidade do time, pois as pessoas não estavam integradas em torno de um objetivo. Falta de saber datas de quado alocar as pessoas, e com isso os clientes estavam ficando infelizes e os desenvolvedores desmotivados.

Então eles criaram um método chamado ADM (adaptative development method). Para implementar, tiveram que radicalizar:
- 3 meses para transitar mais 18 meses de ajustes
- um conselho que foi dado a eles, pelo Ken Schwaber, resolva os bugs da versão corrente. É algo que eu tenho visto nos times transitando para o scrum no UOL, e que faz sentido. Acaba acontecendo que os bugs vão para o backlog e ficam sabidos por todos, inclusive o product owner
- o valor de uma funcionalidade só se realiza quando você entrega para o cliente.

Uma coisa legal que eles têm é um lugar no site que o cliente pode colocar sugestões e os outros podem votar qual a importância daquilo. É como se fosse uma priorização de backlog web 2.0. @:-))) Acho que város produtos poderiam se beneficiar dessa idéia, principalmente os que lidam com empresas. Os usuários com perfil corporativo ou de pequenos negócios geralmente já sabem definir melhor o que querem e focam em valor para o negócio.

o método que eles criaram se chama ADM – é uma mistura de XP + Scrum
- self organizing teams
- product owner
- scrum master
- testar antes de desenvolver
No momento de implementar é importante ter cooperação multifuncional
Quando a transição foi feita o envolvimento foi geral
Eles compraram livros e pediram ao pessoal para ler
Contrataram treinamento de scrum master e de product owners
Fizeram um wiki com agrupamento de todos os artigos e boas definições que eles queriam que o time compartilhasse. Muitas dúvidas estavam surgindo, tais como, a definição de bom, papel das pessoas. O detalhe é que o wiki referenciava documentos e links de outros sites importantes para eles. Mesmo sendo encontrados por busca na internet, eles acharam melhor descrever o que eles consideravam informação oficial.

Chief product owner só resolve disputas e conflitos. Ou seja, ele espera que os product owners evoluam os produtos sozinhos e de acordo com as metas passadas. Por isso, acho que as empresas tem de procurar pensar em metas que tragam união e cooperação entre os times e product owners.

Eles têm 50 times de scrum trabalhando em paralelo
Ele disse que as vendas vão bem, mas admitiu que não foi só o método ágil. O momento do mercado também foi o principal causador de prosperidada da companhia. Mesmo assim, isso prova que o método agil deles não afetou negativamente o bom momento do mercado deles.

Erros cometidos
- product owners têm de treinar antes. Tiveram muito foco em scrum master.
- demoraram para contratar consultoria.
- não ter envolvido os executivos com objetivos concretos de mudança

Critérios de qualidade
99% do código tem de passar automatizados

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.