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.”

Cone da Incerteza e SCRUM

Nos últimos meses eu tinha como foco implementar SCRUM na minha equipe, tudo começou com o Phillip Calçado me explicando o conceito de SCRUM, seguido de um curso com o Bloris Gloger que ele e alguns da equipe fizeram, e depois entramos em um caminho sem volta e nos focamos em implementar o SCRUM da melhor forma possível no nosso time. Acho que posso dizer que estamos muito bem neste momento, claro que ainda faltam detalhes mas o time esta andando e esta entregando software de qualidade a cada ciclo de desenvolvimento.

A próxima meta é escalar o SCRUM para toda a empresa, enquanto estava lendo sobre o assunto acabei me desviando e cai em alguns artigos muito interessantes que discutiam um tema que afeta todo e qualquer projeto de desenvolvimento de software: como estimar com precisão o tempo total para se entregar um software em produção?

Acabei caindo na teoria do Cone da Incerteza, que explica o fenômeno onde nós da indístria de software quando iniciamos um novo projeto não fazemos a menor idéia de quando vamos terminá-lo. Quanto mais o tempo passa e mais perto do fim melhor e mais preciso são as nossas estimativas, ou seja, isso culmina na conclusão de que você só tem 100% de certeza de que terminará o projeto apenas um dia antes de efetivamente terminá-lo.

Esta figura é facilmente associada ao desenvolvimento de um software, ou seja, se começa um projeto sem ter a menor idéia do tamanho dele ai vai se detalhando, escreve-se montanhas de papel com requisitos, desenha-se milhões de telas no Photoshop para fechar o design do projeto, ai finalmente depois de alguns meses é que se começa a escrever software efetivamente. Nestes casos existe uma luta constante para afunilar o cone o mais rápido possível. O grande erro das empresas é fazer um “commitment” com um projeto quando ele esta nas suas etapas iniciais, ao fazer isso elas estão aceitando uma margem de erro de 2x ou 4x nas estimativas, e é neste momento que o projeto começa a ruir.

O que é interessante em metodologias ágeis, como o SCRUM por exemplo, é que podemos observar este fenômeno invertido, explicando melhor, se vc perguntar a um desenvolvedor que já esta envolvido em um projeto o que ele consegue entregar nas próximas duas semanas a estimativa com certeza será bem precisa, mas se perguntarmos o que ele consegue entregar daqui a 6 meses, não fará a menor idéia e vai chutar uma estimativa qualquer pois não há como ter certeza do que irá acontecer. A única certeza que podemos ter em qualquer projeto de software é de que as coisas vão mudar, os requisitos, o design, as funcionalidades e o grande trunfo dos métodos ágeis é de entregar software funcionando em ciclos constantes e curtos e com isso se adaptar as constantes mudanças.

Então em um ambiente ágil temos sempre mais certeza sobre as estórias que estão priorizadas para o próximo sprint ou estamos trabalhando neste momento e vamos melhorando nossas estimativas e aumentando a precisão delas conforme o Product Backlog vai sendo entregue, mas sempre com uma visão muito clara do curto prazo e menos clara para o que esta no fim do Product Backlog. Lembrando que as estórias que estão sendo desenvolvidas no Sprint são as de maior ROI para o projeto.

Sendo assim o Cone de Incerteza aplicado a uma equipe que utiliza SCRUM teria este formato:

O papel do Product Owner e priorização do Product Backlog

Na semana passada tivemos alguns treinamentos muito legais na Globo.com, foram três dias de curso com o Boris Gloger da Sprint-it, empresa que esta nos ajudando na adoção do SCRUM. Em dezembro passado tivemos uma série de treinamentos com o intuito de apresentar o SCRUM para as diversas áreas da empresa.

Neste ano continuamos este trabalho de formação dos profissionais da Globo.com, porém este novo round de treinamentos foi focado em um dos principais papéis dentro do SCRUM, o Product Owner (PO) e também na formação de Trainers, que realizarão os treinamentos internos para as equipes que passarão a usar SCRUM este ano.

The Scrum roles
© Copyright Conchango 2006

Apenas relembrando o papel do PO, ele é o responsável pelo Retorno do Investimento (ROI) do projeto, cabe a ele priorizar os itens no Product Backlog (PB) de forma a obter o maior retorno possível, entre as suas responsabilidades estão:

• Criar a visão
• Manter o PB estimado e priorizado
• Priorização do PB, com pelo menos 3 Sprints
• Criar as fronteiras (boundaries) que protegem o Time (Tempo, Orçamento, Visão, Padrões, etc)
• Criar um Release Plan do Produto
• Ser a interface de comunicação com os stakeholders, e outros clientes internos e externos
• Ajudar o ScrumMaster a proteger o Time
• Aceitar ou rejeitar uma funcionalidade no Sprint Review

O PO é quem deve criar a visão, mas esta deve ser compartilhada e refinada com o Time, pois é o time que deve se sentir motivado e desafiado por aquela visão. A visão deve ter algumas características básicas como: ser emocional (criar desejo), deve ser clara e concreta e deve ser difícil de alcançar.

O Product Backlog (PB) é responsabilidade do PO, mas quem deve escrever as user stories é o Time, pois este é que vai executar o Sprint Backlog e se comprometerá em entregar estas user stories, claro que o PO pode ajudar a escrevê-las, mas apenas se o time deixar. Antes deste treinamento eu achava que o PO é quem deveria escrever as user stories. É importante lembrar que o PB é formado por um misto de user stories detalhadas e estimadas e um conjunto de idéias mais amplas e sem muitos detalhes, que serão refinadas e devidamente transformadas em user stories no decorrer do processo. O Time é o responsável por estimar a complexidade das user stories, atribuindo pontos de dificuldade para cada uma delas, que chamamos de Story Points.

É importante ter pelo menos 3 Sprints priorizados e estimados, para que o time não fique “idle” na transição entre um Sprint e outro, recentemente passamos por uma situação assim na entrega de um dos releases do Globo Vídeos, por não ter um PB detalhado e priorizado o time teve de esperar alguns dias para iniciar o Sprint seguinte.

The ScrumFlow

No decorrer de cada Sprint é preciso iniciar os trabalhos de estimativa e planejamento do próximo Sprint, é uma boa prática alocar de 10% a 15% do tempo do Sprint corrente para planejar e detalhar o próximo Sprint. É responsabilidade do PO chamar as reuniões de planejamento e detalhamento dos Sprints (não confunda estas reuniões com o Sprint Planning 1 e 2) e de manter pelo menos 3 Sprints planejados e priorizados, se o PO não realizar estas reuniões o ScrumMaster deve chamar a atenção do PO e em casos extremos assumir esta responsabilidade temporariamente. Cada reunião de planejamento não deve durar mais do que 60 minutos (Timebox) e tem como objetivo manter todos no Time informados sobre possíveis mudanças nas user stories e ajustes de prioridades, além de aumentar a precisão das estimativas feitas anteriormente.

Abaixo segue uma proposta de planejamento para um backlog hipotético que entrega um release a cada 10 dias úteis, aqui vai uma dica do Boris, nunca fazer o Sprint Planning 1 e 2 em uma Segunda-Feira ou depois de um feriado, porque é preciso que todas as partes envolvidas estudem o backlog e se preparem com antecedência para estas reuniões e todos nós sabemos que é muito difícil alguém se planejar durante um final de semana ou feriado. Sendo assim a agenda ficaria assim:

• Segunda-Feira (tarde): Sprint Review e Sprint Retrospective
• Terça-Feira (manhã): Entrega do Release
• Terça-Feira (tarde): Sprint Planning 1 e Sprint Planning 2
• Quarta-Feira: Inicio do Próximo Sprint
• Mais ou menos dois dias depois do inicio do Sprint deve-se marcar uma reunião de planejamento e estimativa do próximo Sprint.
• Mais ou menos dois dias antes do final do Sprint deve-se marcar outra reunião de estimativa do próximo Sprint.

Uma vez escritas e estimadas as user stories o PO deve priorizar o PB, no treinamento aprendemos uma técnica interessante chamada de Relative Benefit. Ela funciona assim: para cada item do Backlog atribui-se um valor para o Beneficio de se ter aquela funcionalidade (variando de 0 a 10) e um valor para Penalidade de não se ter aquela funcionalidade entregue, depois somam-se estes valores e o resultado chamamos de Business Value (BV). Agora dividimos o BV pela Estimativa, que reflete a dificuldade/complexidade para se entregar aquela determinada funcionalidade, por fim o PO reordena o Backlog com base neste resultado, do maior para o menor valor.

Por exemplo, no Backlog acima temos a feature 1 que possui um beneficio baixo (1) , uma penalidade alta(9) e uma complexidade baixa(2), sendo assim o beneficio relativo desta funcionalidade é alto (5) quando comparado relativamente com os outros itens do Backlog. Esta técnica também ajuda a priorizar itens com o mesmo BV, como é o caso da feature 1 e 5, neste caso vemos que a feature 5 possui um Beneficio igual a 5, maior que o beneficio da feature 1. Seguindo este método PB acima ficaria priorizado da seguinte forma:

1. Feature 5
2. Feature 1
3. Feature 3
4. Feature 4
5. Feature 2

Esta é uma técnica muito simples que ajuda a dar uma base concreta para comparação entre as funcionalidades e assim, priorizar corretamente o PB, claro que cada caso é um caso e vão acontecer situações onde um diretor vai pedri prioridade de uma determinada funcionalidade, mas esperamos que esta seja uma exceção e não a regra.

Mas uma das mensagens mais importantes do treinamento foi com relação ao papel do PO de proteger e respeitar o Time, este é uma papel que geralmente o PO não assume e pior, como os PO’s geralmente tiveram uma experiência passada em áreas de marketing ou gerência de produtos , eles tendem a achar que a equipe de tecnologia é devagar e não tem compromisso com o produto e sempre tentam empurrar mais e mais funcionalidades pra cima do time. Isso é natural principalmente nos processos waterfall, mas em um ambiente de utiliza Scrum, esta postura do PO não pode ser aceita. Ele não deve pressionar o time para inserir mais coisas no sprint, o time é que escolhe do PB priorizado o que se compromete a entregar com qualidade até o fim do Sprint. Caso o PO entenda que o time pode entregar mais do que esta entregando, ele deve conversar com o ScrumMaster, pois a produtividade do time é um problema que o ScrumMaster deve resolver. Ao tentar empurrar mais do que o time pode entregar com qualidade, o PO começa a quebrar sua relação de confiança com o time, e o ScrumMaster deve intervir e lembrar o PO de que ele também deve proteger o time.