Agilidade na prática: evite tantas reuniões

Continuando a série de problemas práticos encontrados na maneira de
pensar quando adotamos metodologias ágeis, um comentário sempre feito no curso é a situação que afeta muito a produtividade de Product Owners e Scrum Masters (ou líderes/papéis similares em qualquer metodologia): a falta de produtividade dos dois devido a quantidade de projetos que lidam.

Para praticantes de Scrum, por exemplo, 13% do tempo de um PO e SM é
consumido em reuniões por cada projeto que ele participa.

Isso não é nada frente ao tempo investido por dois desenvolvedores em
pair programming (80~100%). Mas o objetivo do desenvolvedor é
alcançado durante esse período de comunicação. Para um PO, SM ou
líder, é durante esses 13% que colherá informações para trabalhar em
cima no resto do tempo.

A consequência é grave: PO e/ou SM e/ou líderes distantes,
impedimentos que duram meses, falta de tempo para novas idéias etc.

Para deixar claro, vamos aos prejuízos alarmantes:

Se você, como SM, líder ou PO, toca cinco projetos
simultâneamente, você tem 2 horas e 45 minutos para se dedicar a
cada um desses produtos por semana
. Nesse tempo terá que ter
idéias novas, resolver problemas, responder emails, fazer reuniões
fora do ciclo tradicional. É tempo suficiente?

A conclusão é que é impossível se dedicar com alta qualidade tocando 5
projetos simultaneamente. 4 projetos? Você agora tem 4 horas
e 45 minutos por semana
para pensar sobre seu produto, ter novas
idéias, conversar com seus clientes, ler seus emails, fazer reuniões
fora do ciclo etc.

3 projetos? Nesse caso você tem 8 horas, um dia por semana
para pensar sobre seu produto
ou resolver os problemas de sua
equipe.

Está é uma medida simples que mostra quanto tempo estamos investindo
em reuniões e faltando POs e SMs e quanto tempo está sendo gasto
pensando em seu projeto e resolvendo os problemas de verdade. Para
fins de completude – e possível conversa dentro de sua empresa para
evitar cair nessa situação – o gráfico a seguir ilustra o número de
horas livres por projeto por por semana em função do número de
projetos:

Horas livres para cada projeto que você está se ocupando

Horas livres para cada projeto que você está se ocupando

Utilizei a regra de que, se sua iteração é mais longa ou
mais curta que 3 semanas, utiliza-se um número de horas proporcionais
ao seguinte: 15 minutos de daily meeting, 3 horas de review, 3 horas
de planning e 2 horas de retrospectiva. Utilizando regras não
proporcionais o cenário fica bem pior.

Para ter um ótimo desempenho, aceite o segundo, evite o terceiro e
diga não ao quarto projeto.

Tags: ,

17 Comentários

  1. Rodolpho Arruda 27/04/2010 at 17:08 #

    Qual é a fonte para os “13%”? Quero usar o número… mas para isso preciso da fonte.

    -RA

  2. sergio taborda 27/04/2010 at 18:04 #

    Este post é completamente errado a niveis tão profundos que doi até dizer.
    Se um SM tem 5 projetos , em uma semana ele tem 1 dia para dedicar a cada projeto em média, e não 2 horas e 45 minutos.
    O SM e o PO dedicam tempo ao projeto mesmo fora das cerimóias scrum , da mesma forma que o desenvolvedor dedica.

    Se o SM ou o PO estão tendo problemas de tempo, a solução é arranjar mais PO e SM, e/ou aumentar o foco para que cada reunião seja mais curta e mais produtiva.

    A solução não é fazer menos reuniões. Isso é simplesmente anti-scrum (sem reunião não ha abertura, ha falha de compromisso e falta de respeito ao quebrar regras).

    Por exemplo, a reunião de preparação de sprint deve durar no máximo 4h. Isso não significa que tenha que durar 4h. Se resolver em 30m está otimo. Além de que, se o SM ou o PO tem problemas com a sua alocação, isso deve ser dicutido na reunião de retropetiva.

    Ha muitas formas de fazer scrum, mas fazer menos reuniões com certeza não é uma delas.

    É um salto muito longo entre o vosso problema é excesso de projetos e/ou falta de SM e PO e dizer que a solução para isso, dentro do scrum, é fazer menos reuniões. No momento que fizer isso, está fazendo scrum-but
    “We do scrum, but we do less ceremonies than we shoudl”

  3. Guilherme Silveira 27/04/2010 at 18:25 #

    Tudo bem Rodolpho?

    A conta dos 13% aparece da seguinte maneira: para 2 semanas de sprint, use 2 horas de retrospectiva, 3 de planning, 3 de review, e 15 minutos diários de daily. Isso representa 10.5 horas semanais, dividido por 80 são 13%.

    Para extrapolar para mais dias basta trabalhar com proporções adequadas e no fim dividir o tempo livre pelo número de projetos que você tem ao mesmo tempo, resultando o número de horas livre por projeto.

    Posso te passar a planilha simples de exemplo se quiser.

    Abraço!

  4. Guilherme Silveira 27/04/2010 at 18:59 #

    @sergio

    Concordo com você quanto a conclusão: o objetivo não é manter o mesmo
    número de projetos e diminuir o número de reuniões – não só concordo
    como também não sugeri o contrário, sua lógica está um sofisma. No
    texto eu claramente sugiro não pegar tantos projetos e,
    consequentemente, ter mais tempo para trabalhar, com menos reuniões.
    Não sei se você leu o artigo inteiro.

    Em um sprint de 2 semanas, temos 5 * (retrospectiva + review +
    planning + 10 * daily) = 5 * (8h + 2h30min) = 52 horas e 30 minutos.
    Sobrando 27 horas e 30 minutos em 2 semanas para todos os projetos.
    Divida isso por 2 semanas e por 5 projetos, você terá
    (27*60+30)/(2*5)=165 minutos.

    Isto é, o scrum master terá 2 horas e 45 minutos por semana para
    resolver problemas de um projeto, 2 horas e 45 minutos por semana para
    resolver problemas de outro projeto etc.

    As reuniões podem demorar menos sim, correndo o risco de reforçar as
    características negativas que você comentou.

    Creio que você deve ter usado outra base de contas que não a que eu
    citei no texto. Tentei citar o que acontece no mundo real e não na
    proposição ideal. Para quem está sofrendo com a falta de tempo por
    causa dos números que mostrei, a solução é a que nós concordamos.

    Na sugestão ideal (scrum guide), seriam 4 horas por semana para
    resolver os problemas de um projeto ao manter 5 em paralelo.
    Para qualquer SM, nesse mundo ideal (melhor que o real), resolver
    todos os problemas do dia de uma equipe em 45 minutos é um grandioso
    desafio, para não dizer impossível.

    Abraço

  5. sergio taborda 28/04/2010 at 00:18 #

    Vejamos a falha nas suas contas.
    Para um sprint de 2 semanas : a retrospectiva acontece fora do sprint. logo, não conta, o mesmo para os planejamentos. logo as suas “2 horas de retrospectiva, 3 de planning, 3 de review” acontecem na semana anterior e posterior ao sprint.
    Então, temos que contar que no dia 1 do sprint, essas coisas já aconteceram, ou que acontecerão no dia após o sprint acabar ( o dia 11 , num sprint de 10 dias)
    Veja que toda a equipa, desenvolvedores, inclusive, estão nessas reuniões. Pela mesma conta que vc fez, cada desenvolvedor, teria apenas 2 h 45 m para desenvolver, o que não faz sentido algum.

    Então temos 10 dias de sprint com 15 minutos diários. O que deixa 45 minutos
    por hora diariamente para pensar nos assuntos e fazer o seu trabalho. Portanto, no dia, ele tem 7h 45 minutos livres por dia, que em 10 dias são 77h 30 m que são 97% do tempo do sprint.

    Agora vamos pensar que o cara tem 5 projetos. Então ele terá 5 reuniões, logo terá 5 * 15 minutos = 75m = 1h 15m por dia para reuniões. o que deixa, 6h45 por dia, o que deixa, 67h 30 m por sprint. o que equivale a 84% do tempo. Nada mal.

    A sua conclusão é irrelevante se o titulo é “Evite tantas reuniões” o problema ai é o “tantas” dando a impressão que são mais que as devidas, quando são exatamente o minimo das que devem acontecer.

    Vc partiu de calculos errados, o que demonstra que não o que escreveu não é baseado em fatos , depois vc desmerece o scrum dizendo que as reuniões são “tantas” , mesmo chegando na conclusão certa, isso não lhe dá nenhum crédito. É como acerta na massa da Terra usando o tarot. lá porque acerta, não significa que o raciocinio é válido.

    Eu espero que as pessoas tenham a lucidez de esquecer este post. Mas infelizmente os desavisados que lerem este titulo em algum feeder por ai, vão ficar acreditanto mentiras e citar isso como mais uma desculpa para continuar fazendo scrum-but.

    Nota: Para ser totalmente correto os calculos devem incluir 12 dias. 10 de sprint , 1 para demo e planjemanto e 1 para retrospectiva. Mas mais dias podem passar entre sprints. Porque esses dois dias a mais se anulam matemáticamente o resultado é o mesmo que expus. mas vale lembrar que entre um sprint e outro pode passar um numero indeterminado de dias. Isto não é uma linha de montagem.

  6. Guilherme Silveira 28/04/2010 at 13:12 #

    @sergio

    Desculpe mas suas contas se baseiam em Scrum But.

    “One Sprint starts immediately after the other.”… “Sprint contain and consist of the Spring Planning meeting, the development work, the Sprint Review and the Sprint Retrospective”

    Scrum but sem você saber, você é a prova de que no mundo real, as pessoas adaptam o Scrum sem perceber.

    Cuidado com seus rants. Peço que você tenha mais compreensão com o but que outras empresas que vemos no mercado adotam, se não outros também poderiam fazer online rants sobre sua proposta de scrum but.

    Evitando distorcer o que eu disse através dos seu but: “em *qualquer* metodologia não aceite tantos projetos”… como está escrito no post

    Abraço

  7. puc1s 28/04/2010 at 14:56 #

    Sério, não entendo como vocês ainda dão trela pra algum comentário desse taborda, o maior troller da historia do guj.Eu apagaria sumariamente esses comentários que tem um linguajar mais que ofensivo. “não alimentem os trolls”

  8. sergio taborda 28/04/2010 at 22:27 #

    Se vc citar a fonte de onde tirou essas afirmações seria mais interessante porque eu nunca vi ninguem em scrum dizer que um sprint vem imediatamente depois do outro … isso é o que teoricamente deve acontecer, mas não é o que acontece na prática. Na prática vc pode precisar de dias entres os sprints por várias razões. Algumas de ordem burucrática como o PO não ter priorizado as estorias ainda. E isso pode acontece não apenas quando ele é preguiçoso, mas também quando ele precisa realmente comunicar com outras pessoas para decidir.
    Outras de ordem tecnica. Porque o scrum não é uma metodologia de eng de software ele carece de oportunidades para que existam reuniões mais tecnicas entre a equipa. Os chamados “lab days” são uma prática comum em empresas com a Google e servem exactamente para divulga o conhecimento entre os membros da equipe e entre as equipes. Servem também para ajudar aquele API ou classe da infra que deu problemas ou que vai ser precisa num dos próximos sprints.

    Leia mais aqui
    http://scrummasterblog.com/2009/03/what-do-you-do-when-your-product-owner-cant-give-you-priorities-before-next-sprint-planning/

    Uma coisa é vc ler sobre scrum, outra coisa é vc praticar scrum.

    “At the end of each sprint a sprint review meeting is held” (http://www.mountaingoatsoftware.com/scrum/sprint-review-meeting), “At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective” (http://en.wikipedia.org/wiki/Scrum_%28development%29 ), “In Scrum, every iteration begins with the sprint planning meeting” (http://scrummethodology.com/scrum-meetings/)

    O ciclo de sprint começa com uma reunião e acaba com uma reunião, mas o sprint em si mesmo não contém essas reuniões. Quando se faz um orçamento de pontos e se mede a velocidade os dias em que essas reuniões são feitas não contam. Então, embora sejam as cerimónias de abertura e termino o periodo do sprint para efeitos de calculo não as contabiliza. Além de que, mesmo contabilizando elas são imediatamente descontadas, como expliquei antes.

  9. Sergio k 29/04/2010 at 08:59 #

    Concordo com o Guilherme, alguem esta querendo se aparecer! O conceito aqui é agregar informações, passando orientação e direcionamento que são fundamentais para uma boa experiência. O rapaz esta sendo leviano…. ignore = true!

  10. Guilherme Silveira 29/04/2010 at 11:33 #

    Claro. A origem do que mencionei é o scrum guide do Ken Schwaber e do Jeff Sutherland, criadores do Scrum. Aqui vai o link com o texto de onde extraí, recomendo a leitura:

    http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit

    De resto, estamos alinhados: na prática, o que acontece é diferente do guia e cada diferença implica em gráficos distintos, como eu mencionei no próprio post.

    Abraço

  11. sergio taborda 29/04/2010 at 19:03 #

    É por essas e por outras que Schwaber é cada vez menos uma referencia em scrum. Afinal a sua saida da Scrum Alliance significa algo. http://sergiotaborda.javabuilding.com/2010/02/scrum-reloaded/

    Ele escreve essas regras restritas que ele mesmo não cumpre e chama ao fato de não cumprir “adaptabilidade”. Ora… convenhamos que é muito mais simples não instituir a regra para começo de conversa. Que os sprints se sigam sequenciamente é um dado adquirido embutido no conceito de ciclo (repetição) e o tempo entre eles está embutido no valor de foco. Quando mais tempo passar entre eles , pior. Mas isso não significa que ha uma lei que diz que são imediatamente sequencias… até porque na prática isso é simplesmente impossivel.

  12. Antonio Kantek 04/05/2010 at 21:30 #

    Para mim, esse foi um dos posts mais bacana que eu jah li nesse blog.

  13. Ronan 07/05/2010 at 09:25 #

    valeu guilherme, muito bom o post! nos ajuda a ver o SCRUM mais na vida real!

  14. Paulo Silveira 06/07/2010 at 17:19 #

    Guilherme, lendo o Rework lembrei desse post, no capítulo “Meetings are poisoning.”

  15. Leo Balter 06/01/2011 at 11:32 #

    Admiro bastante o trabalho da Caelum, mas concordo com a opinião do Sergio Taborda, é o que vejo acontecer na prática do scrum.

    Quanto a externos, entendam que uma discussão de ideias diferentes não são trollagem, o cara apontou uma opinião com base em algo. Mesmo se estivesse errado, ele tería contribuído muito mais.

Deixe uma resposta