SCRUM e Toyota

Isso com certeza não é novidade mas talvez alguns não tenham lido, o Boris Gloger fez um paper há alguns anos fazendo um paralelo entre os 14 princí­pios de sucesso da Toyota, citados no livro The Toyota Way do Jeffrey Liker.

As metodologias ágeis tem tudo a ver com o TPS (Toyota Production System) e sempre que alguém fala de formas ágeis de desenvolvimento acaba citando a Toyota como uma das criadoras destes princípios. Na verdade o link entre estas duas coisas vem do fato de que a Toyota foi uma das grande empresas que começaram a empregar o Lean Thinking na década de 1970, nas palavras de Taichi Ohno um dos criadores do TPS, o foco da Toyota era “the absolute elimination of waste, where waste is anything that prevents the value-added flow of material from raw material to finished goods”.

Esse é o grande foco das metodologias ágeis em relação aos processos em cascata (waterfall), eles são focados no valor adicionado pelo desenvolvimento seguindo os principios constantes no Agile Manifesto.

Enfim, este paper do Boris é uma leitura simples, rápida e fácil e que ajuda a enriquecer um pouco mais nossa cultura sobre SCRUM e suas origens.

Aqui esta o link para o paper: Scrum Delivers or Scrum and the Toyota Way.

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.

Entrevista Mike Cohn: Agile scaling and scope

Lendo o Blog do Alexandre Magno vi este vídeo do Mike Cohn, muito bom altamente recomendavel.

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.

Agile na SD West 2008

Como alguns de vcs sabem estou nos Estados Unidos nesta semana, tivemos algumas reuniões em San Francisco com a ADOBE, onde vimos algumas das novidades que vão acontecer durante 2008 e inicio de 2009 nas plataformas da empresa.

Em seguida, vim para Santa Clara para participar da SD West 2008, um evento com diversos tracks legais e super sintonizados com o momento de transição que estamos passando na Globo.com, particularmente estou assistindo a maioria das apresentações do track chamado People, Process and Methods, onde são discutidas práticas ágeis de gerenciamento do desenvolvimento do Software, como o SCRUM, Crystal Clear e XP entre outros assuntos. Hoje assisti várias palestras e aproveitei para tirar algumas dúvidas com uns dos maiores nomes do mundo Agile, como Mike Cohn, Alistair Cockburn, Paul Hodgetts entre outros.

Na primeira palestra que participei foi a “Agile Transitions“, que na verdade foi um round de discussão de como realizar a mudança para uma metodologia ágil, independente de qual vc estaria interessado. Foi muito bom ver que grande parte das perguntas feitas eu consegui responder corretamente, o que mostra que estamos avançando no quesito de conhecimento sobre práticas ágeis. Uma das perguntas que fiz foi a respeito de qualidade versus número de features, justamente perguntando se na situação onde o time vê a necessidade de melhorar a qualidade do software criando uma estória de refactoring , por exemplo, é correto dropar uma feature e escolher a qualidade?

A resposta foi em linha com o que pensava, todos foram categóricos com o fato de que com qualidade não se discute e que isso é uma decisão do Time juntamente com o PO, mas que o PO precisa entender o que esta em jogo e o que se ganha ao realizarmos um refactoring ou automatizar um teste que na maior parte das vezes é muito sutil, porque só se percebe o Technical Dept quando ele já esta muito alto e coloca o projeto todo em risco, é função do Time mostrar este valor para o PO.

Na segunda palestra Prioritizing Requirements, com Mike Cohn, foram apresentadas técnicas de priorização do Product Backlog, em resumo é possível dividir estas técnicas em dois grupos: Financeiras e as Não-Financeiras. Na parte de técnicas financeiras nenhuma grande novidade, ele falou bem superficialmente sobre NPV, FV, IRR, etc. Mas na parte de técnicas não-financeiras achei interessante o Método de Kano e tb o reforço no método do Beneficio Relativo. Para saber mais sobre este assunto leia o livro do Mike “Agile estimating and planning“.

A terceira palestra foi sobre o Crystal Clear, ministrada pelo Alistair Cockburn (Lê-se Co-burn), onde ele apresentou um overview sobre a metodologia Crystal, que em resumo tem os seguintes propriedades:

• Frequent Delivery
• Reflective Improvement
• Close Communications

Estes principios todos são muito comuns a diversas metodologias ágeis, mas este último tópico (Close Communications) foi muito interessante, onde ele discutiu e mostrou alguns papers como este aqui da Universidade de Michigan chamado Distance Matters, onde é provado que quanto mais proximos estão os membros de um time melhor é o rendimento e a qualidade e por consequencia o retorno sobre o investimento.

A última apresentaçao que fui, ministrada por um consultor da Net Objectives, não teve grandes novidades, mas foi muito interessante para ajudar a verificar como podemos estruturar o conteúdo sobre SCRUM para os nossos treinamentos internos para os Team Members.