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.

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.

Jeito Google e Jeito Apple de desenvolver produtos

Esta semana comprei a revista Fast Company de março, fazia um bom tempo que não a lia e o tema da capa era super interessante “The World’s 50 most innovative companies“, claro que na capa esta o case do Google. Ao ler a matéria “The Faces and Voices of Google“, achei uma frase dita pela Marissa Mayer que achei muito foda e tem muito a ver com o que eu penso.

“There are two different types of programmers. Some like to code for months or even years, and hope they will have built the perfect product. That’s castle building. Apple is great at it. Others prefer to have something working at the end of the day, something to refine and improve the next day. That’s what we do. The hardest part about indoctrinating people into our culture is when engineers show me a prototype and I’m like, ‘Great, let’s go!’ They’ll say, ‘Oh, no, it’s not ready.’ I tell them, ‘The Googly thing is to launch it early on Google Labs and then to iterate, learning what the market wants–and making it great.’

Some companies think of design as an art. We think of design as a science. It doesn’t matter who is the favorite or how much you like this aesthetic versus that aesthetic. It all comes down to data.”

Eu definitivamente penso em desenvolvimento de produtos com esta filosofia, (apesar de recentemente começar a gostar muito dos produtos Apple:-) acredito muito na premissa que li em uma entrevista do J Allard (head de games da Microsoft e responsável pelo projeto do Xbox) “if it’s a possibility that you may fail, then fail fast and learn“. Desenvolver produtos rapidamente e colocar estes na rua para que possamos pegar o feedback dos usuários o quanto antes e se for necessário fazer ajustes e incrementar mais features ou retirar features que não atendem as demandas dos usuários, é neste metodo mais “Googly” que eu acredito, desenvolvimento continuo e iterativo, com melhoria contínua e constante.

Ficar sentado em cima de um problema pensando anos como resolvê-lo da forma perfeita definitivamente não faz o meu tipo.

Para finalizar mais uma frase Googleneska da matéria, agora de um dos diretores de engenharia David Glazer, responsável pelo desenvolvimento do OpenSocial:

“…When in doubt, do something. If you have two paths and you’re not sure which is right, take the fastest path. What’s true in physics about objects in motion is true when you’re creating a product. It’s easier to keep moving and change course than when you’re sitting and thinking and thinking.”