Antes de começamos a trabalhar com Scrum na Globo.com, era comum nossa equipe trabalhar em três ou quatro projetos ao mesmo tempo. Cada projeto era tocado por um time de mais ou menos uma a três pessoas e assim íamos fazendo as coisas.
Depois, com o Scrum, acabamos criando um time um pouco maior (de aproximadamente 9 pessoas) e, pela força do hábito, várias vezes nos pegamos com vontade de trabalhar em dois ou três projetos ao mesmo tempo. Talvez dê vontade de fazer isso para ter a impressão de que as coisas estão acontecendo, mesmo que lentamente, e que os projetos estão andando… Mas será que isso vale a pena? Vejamos.
Um dos principais objetivos do Scrum é entregar o maior valor de negócio para o cliente no menor tempo possível. Quanto mais dinheiro o cliente puder ganhar e quanto mais rápido, melhor. Sendo assim, o P.O. sempre deve pensar na melhor forma de maximizar o ROI – retorno sobre o investimento.
Falando de forma simplificada, o retorno sobre o investimento é calculado da seguinte forma: se você investe R$ 100,00 em alguma coisa e no final de um período você ganhou R$ 50,00 por conta deste investimento, você teve 50% de ROI. Sendo mais prático, quando você paga alguém para desenvolver um sistema para você, se você gastar R$ 100.000,00 e ganhar R$ 10.000,00 por mês, você está tendo um ROI de 10% por mês. Neste cenário o sistema se pagará em 10 meses, e a partir daí você passa a ter lucro.
Dito isso, vamos pensar numa situação hipotética. Imagine que um time de Scrum está trabalhando em 3 projetos ao mesmo tempo. Constata-se que no fim de 3 meses o time consegue finalizar e colocar em produção todos os 3 projetos:
Para conseguir entregar esses 3 projetos, o time teve que trabalhar paralelamente em todos eles, usando sempre 1/3 do tempo de cada Sprint para cada um dos projetos. Desta forma só depois de 3 meses o cliente poderia começar a faturar com seus novos produtos.
A pergunta é: não seria muito melhor se o time tivesse trabalhado de forma serial, focando todo seu tempo e esforço em apenas um projeto e entregando uma coisa de cada vez?
Trabalhando dessa forma, no fim do primeiro mês o primeiro projeto já poderia entrar em produção, antecipando o faturamento, gerando dinheiro (ROI) para o cliente mais rápido e diminuindo o tempo necessário para recuperar seu investimento. Neste caso, a antecipação da entrega de um dos projetos faz com que o cliente comece a faturar 2 meses antes do que poderia – sem dúvidas o ROI foi maximizado.
Voltando ao ponto inicial, é preciso resistir à tentação de querer trabalhar em vários projetos ao mesmo tempo. O melhor é focar no mais importante deles (ou seja, o que vai gerar mais lucro para a empresa) e trabalhar nele até o fim, passando em seguida para o próximo projeto mais importante e assim por diante.
19 replies on “Times Scrum trabalhando em vários projetos ao mesmo tempo?”
Legal o post, esta observação as vezes passa despercebido em nós e pode ser aplicado perfeitamente nas atividades pessoais.
Trabalhar com vários projetos paralelos também requer maior gerenciamento e isto demanda conseqüentemente também mais tempo, resistir a tentação é, sem dúvidas, muito difícil. Mas, as vezes, esperar um pouco para iniciar um novo é a melhor opção.
Uma duvida,
se os projetos fossem de clientes diferentes, o que seria melhor? Considerando claro trabalhar ao mesmo tempo para dois clientes algo necessário.
Excelente post Guilherme,
Mas no caso de acertos de bugs e melhorias no projeto 1, isso ocorreria paralelamente com o desenvolvimento do projeto 2, por exemplo?
Abraços.
@Diego
Eu particularmente acho melhor não assumir vários projetos ao mesmo tempo. Se for inevitável tocar mais de um projeto, o melhor seria ter mais times, um por projeto. Penso que é melhor encantar apenas um cliente do que atender vários mais ou menos. 🙂
[ ]s, gc
@Rafael
Dependendo do que fosse acho que não teria problema. Na maioria das vezes os bugs são coisas muito simples e que podem ser assumidas sem muitos problemas, porque nos times ágeis normalmente trabalha-se com várias camadas de teste, revisão antes do projeto ir para produção e etc.
Se forem bugs graves pode ser necessário fazer mais um Sprint, porém, neste caso isso seria o menor dos problemas. Se o projeto chegou nesse ponto significa que o time simplesmente não quer saber de qualidade, o que pra mim é inaceitável e muito mais difícil de resolver.
Enfim, acho difícil criar uma regra que atenda a todos os casos. O melhor mesmo é avaliar cada situação.
[ ]s, gc
Gc,
Um raciocínio análogo poderia ser aplicado às histórias de um projeto, certo?
Um time trabalhando em 3 histórias ao mesmo tempo demoraria um tempo maior para ter algum feedback do cliente (ou do P.O) e ainda correria um risco de deixar de entregar valor (por falta de tempo em um sprint) do que aconteceria caso tivessem trabalhado em uma história de cada vez.
Grande abraço!
@Vitor Isso aí 😉
Às vezes certas coisas que são óbvias demais passam despercebidas. Esse seu exemplo é uma delas. É tão óbvio que muitas vezes não nos damos conta disso e trabalhamos em vários projetos simultaneamente.
Vou repassar esse post!
Do ponto de vista técnico, sem dúvida é melhor trabalhar em um projeto só. Do ponto de vista de negócio, já nem sempre podemos dizer isso. Isso vai depender do contexto em que estamos considerando. Já participei de experiências em que foi super válido trabalharmos exclusivamente em um projeto, porém, também já participei de momentos em que mais de um projeto foi fundamental para garantir o sucesso um pouco mais na frente. Algumas vezes o retorno não vem diretamente e isso tem que ser ponderado. Esse tipo de problema existe não só na área de tecnologia, mas em qualquer outra, sendo empírica ou não.
@Rodrigo, pode dar um exemplo, por favor?
O meu post é justamente argumentando (com provas matemáticas) de que trabalhar de forma serial é bom para os negócios, ao contrário do que se imagina. Nem toquei na questão de se é bom ou não tecnicamente.
[ ]s, gc
[…] Times Scrum trabalhando em vários projetos ao mesmo tempo? (Scrum na Globo.com) […]
Guilherme, se os projetos tiverem durações diferentes quando feitos em série, tem-se que saber qual terá o menor prazo para começar por ele.
E estimar prazo não é algo trivial.
Essa sua “prova matemática” só é válida para projetos com a mesma duração e que dêem o mesmo ROI, o que é praticamente impossivel de se encontrar na vida real, ou seja, devemos sempre avaliar o Roi e o prazo de cada projeto (coisas dificeis de se fazer) para decidirmos qual fazer primeiro.
abraços,
–EC
Concordo plenamente.
Aliás, essa é uma discussão interessante que aconteceu na lista da visão ágil. Vale a pena conferir. http://www.visaoagil.com
@Eduardo
A prova matemática funciona para projetos de qualquer duração e ROI. O que não tem é uma receita de bolo. Como vc mesmo falou, é preciso avaliar os ROIs e durações de cada projeto e escolher um para começar – e fazer a sua empresa e o seu cliente começarem a faturar antes 🙂
Ahá! Outro fã do Joel: http://www.joelonsoftware.com/articles/fog0000000022.html
@Juan, excelente link! 😉
Cara, muito legal a forma como você mostrou o problema do ROI. Acho que ainda terei a oportunidade de usá-lo em uma apresentação para a alta gerência 😉
O que minha experiência, ainda é pouca eu confesso, com Scrum me diz é que vai acontecer o seguinte:
1. Por terem de ser feitos ao mesmo tempo, normalmente os projetos tem a mesma prioridade, então as estórias de cada projeto vão ficar intercaladas.
2. Quase sempre o time que está nessa situação é grande, +/- 8 pessoas, então fica dificil todos atuarem ao mesmo tempo na mesma estória.
3. Isso encoraja a formação de grupos no time para atacar isoladamente cada projeto.
4. Como gasta-se tempo para conversar com os usuários sobre cada estória e passar as informações, membros de um “grupo” se sentem menos comprometidos com as sessões de design do outro “grupo”,
afinal não é do “projeto” deles. Mesmo o daily scrum é afetado pois o integrante que está falando está falando sobre “outro projeto”.
Sei que esse é um caso estremo, mas já tive um pouco dessa experiência, e achei bem desgastante e desanimador para o time.
Abraços
[…] Times Scrum trabalhando em vários projetos ao mesmo tempo? http://gc.blog.br/2008/07/29/times-scrum-trabalhando-em-varios-projetos-ao-mesmo-tempo/ […]
Esse post funciona como o “Lampadinha” para o Prof. pardal !!! Esse é um grande dilema, principalmente pra quem vai começar a trabalhar com SCRUM. Existe uma variação desse cenário que quando o ROI não é tão bem definido. Trabalho em uma empresa em que a atividade fim não é TI, porém (por questões que não vem ao caso) ela possuí time de desenvolvimento próprio. Ou seja, existem projetos internos e “todos são urgentes”. Fica mais difícil negociar com o cliente (interno) e por sua vez eleger o projeto mais importante…..