A importância do foco no Scrum

  • 0

A importância do foco no Scrum

Olá,

(Se você preferir, pode fazer o download deste artigo em MP3 e escutar no seu celular, tablet ou computador.)

Tudo bem? Uma dúvida muito comum para quem ainda não trabalhou com Scrum é: será que o time Scrum precisa mesmo ficar focado em apenas um projeto? Não dá para fazer pelo menos dois simultaneamente? Algo como “de manhã, um projeto A; de tarde, um projeto B”?

A resposta simples e pragmática é: dá, claro que dá sim, mas não funciona nada bem. Não é recomendável.

Focar em vários projetos dá a falsa impressão de que estamos usando melhor o tempo, porque afinal estamos atendendo várias demandas simultaneamente.

Mas, se analisarmos bem, na prática, num dado momento, estamos sempre trabalhando em um projeto só. Repare que no exemplo “de manhã, projeto A; de tarde, projeto B”, na verdade estamos dizendo que em cada período trabalhamos apenas num projeto. Não há mágica, pois nós não conseguimos trabalhar, de fato, em mais de uma coisa ao mesmo tempo.

Se fizermos uma análise simples de encadeamento das entregas, também chegamos à conclusão de que não há benefícios.

Vamos fazer algumas simulações com números, apenas para ilustrar: vamos supor que o projeto A demorasse 4 meses se trabalhássemos 100% de nosso tempo nele.

O projeto A leva 4 meses para ficar pronto com 100% de foco nele

O projeto A leva 4 meses para ficar pronto com 100% de foco nele

Para simplificar, vamos supor que o projeto B também levasse os mesmos 4 meses com foco integral.

O projeto B também leva 4 meses para ficar pronto com 100% de foco

O projeto B também leva 4 meses para ficar pronto com 100% de foco

Se focássemos primeiro no projeto A, e se tudo desse certo, ao final do 4o. mês, ele estaria pronto. Começaríamos o projeto B e, novamente tudo dando certo, ao final do 8o. mês, ele estaria concluído.

Foco em 1 projeto de cada vez, como prega o Scrum

Foco em 1 projeto de cada vez, como prega o Scrum

Já num cenário de focarmos 50% de nosso tempo para cada projeto, significa que duplicaremos o prazo de entrega: cada um deles levará 8 meses.

Trabalho em projetos paralelos (como não prega o Scrum)

Trabalho em projetos paralelos (como não prega o Scrum)

Nada muda para o projeto B, pois ele será concluído igualmente no 8o mês, junto com o projeto A. Na prática, porém, perdemos a oportunidade de lançar o projeto A com 4 meses de antecedência!

Percebe como não há ganho nenhum?

Isto se considerarmos que tudo correu bem em ambos os projetos, o que dificilmente acontece. A única coisa garantida neste cenário de trabalho em paralelismo é a de que deixaremos de entregar um dos projetos que poderia ter sido finalizado primeiro.

Além disso, perdemos um dos grandes benefícios do Scrum. Se focarmos em apenas um dos projetos de cada vez, graças às entregas incrementais do Scrum, sempre priorizadas por valor, pode acontecer do cliente ficar satisfeito antes mesmo do prazo inicialmente previsto.

Assim, é possível que os 4 meses originais sejam encurtados, porque, por exemplo, o cliente já ficou satisfeito com as entregas feitas até o 3o. mês.

Outro aspecto que quase sempre é ignorado é que trabalhar em modo multitarefa é desgastante e diminui, sim, a nossa performance, embora muita gente não queira reconhecer isto.

Jeff Sutherland, co-criador do método Scrum, em seu livro “Scrum – a arte de fazer o dobro de trabalho na metade do tempo“, sugere um exercício que “É simples, mas mostra o profundo impacto do foco e do fluxo. Mostra como multitarefas são árduas para o nosso cérebro, e como isso reduz o seu ritmo, mesmo que você acredite que está aumentando. Demonstra como essas atividades desperdiçam tempo e energia.

Capa do livro de Jeff Sutherland sobre Scrum

Capa do livro de Jeff Sutherland sobre Scrum

O exercício é o seguinte: escrever os números cardinais de 1 a 10, os números romanos de I a X e as letras de A a J, da seguinte forma:

Você deve fazer o exercício de duas formas: na primeira, escreva linha por linha, isto é, escreva a primeira linha:

1   I   A

Depois, escreva a segunda linha:

1   I   A
2   II   B

E assim por diante, até a décima linha. Cronometre quanto tempo você levou.

Agora, escreva coluna por coluna, isto é, escreva a primeira coluna:

1
2
3

10

Depois, a segunda coluna:

1   I
2   II
3   III

10   X

E, finalmente, a terceira coluna, a das letras. Novamente, marque quanto tempo levou.

Experimente fazer o exercício, de verdade! Eu fui 40% mais rápido quando escrevi coluna por coluna. É realmente incrível!

Sutherland relata no livro: “Simplesmente por fazer uma (coluna) de cada vez, em vez de ficar trocando um contexto pelo outro, eu cortei pela metade o tempo que levei para realizar a tarefa.

O autor prossegue mencionando o estudo de Gerald Weinberg, que quantifica a perda de produtividade em função de trocas de contexto de projetos.

Perda de produtividade por trabalhar em projetos simultâneos (por Gerald Weiberng)

Perda de produtividade por trabalhar em projetos simultâneos (por Gerald Weiberng)

A coluna “perda” significa puro desperdício!

O Fabrício foi desenvolvedor de software por muitos anos (e, para falar a verdade, ainda gosta de “meter a mão na massa”) e tem um depoimento sobre este assunto:

“Realmente, quando focamos em um projeto só no Scrum, a produtividade do time aumenta a cada ciclo. A gente vai adquirindo conhecimento sobre as regras daquele produto e vai ficando cada vez mais rápidos.

Quem já desenvolveu software moderno sabe que muitas vezes mexemos pela primeira vez com algumas APIs, componentes, classes, frameworks, durante um projeto. Cada projeto é um aprendizado novo. Ficar focado em apenas um projeto torna esse aprendizado muito mais rápido e produtivo.

Aliás, sobre essa questão do ‘aprendizado’, sempre me lembro de um treinamento em Engenharia Ágil de Software que fizemos com o Klaus Wuestefeld na Infoglobo.

Klaus Wuestefeld

Klaus Wuestefeld

Qualquer livro de engenharia de software traz uma definição sobre ‘o que é software’ parecida com esta da Wikipédia: ‘(…) é composto por uma sequência de instruções, que é interpretada e executada por um processador ou por uma máquina virtual. Em um programa correto e funcional, essa sequência segue padrões específicos que resultam em um comportamento desejado‘.

Já o Klaus, no curso, deu uma definição completamente diferente, poética até. Algo como ‘software é a expressão do aprendizado da equipe sobre os problemas a serem resolvidos‘.

O que é software (adaptado de Klaus Wustefeld)

O que é software (adaptado de Klaus Wustefeld)

Sem querer entrar no mérito de qual é certa ou errada, o fato é que a definição do Klaus fez muito mais sentido para mim quando pensei nos projetos em que já trabalhei.

Por isso, acho que quando focamos 100% em um projeto de cada vez, conseguimos aprender a ‘resolver seus problemas’ mais rapidamente e de forma mais produtiva.”

Uma última informação: o autor Cal Newport lançou no início de 2016 o livro que ele classificou como “o livro que o Facebook não quer que você leia”, no qual trata sobre concentração e foco: “Deep Work: Rules for Focused Success in a Distracted World“.

Capa do livro Deep Work

Capa do livro Deep Work

Alguns dos feitos de Newport: publicou cerca de 50 artigos acadêmicos, com mais de 2500 citações, escreveu 5 livros com mais de 200 mil cópias vendidas e criou um blog que teve 300 mil páginas visualizadas em Dezembro/2015.

Tudo isto sem trabalhar até tarde da noite e raramente trabalhando nos finais de semana. Apenas usando o foco. 🙂

Abraços,

Cláudio Barizon
Diretor de Negócios Digitais
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 4
Agenda com tarefas do dia

Como fazer o seu dia render?

Olá,

Tudo bem? Desde que me tornei um (feliz) empreendedor adepto do home office, em Setembro/2015, comecei a procurar um método para organizar bem meu dia-a-dia.

Já tinha experimentado por um tempo o método GTD (Getting Things Done), de David Allen, quando fui coordenador de TI na Infoglobo. Li seu livro Produtividade Pessoal e, na época, me agradou.

Livro Produtividade Pessoal, de David Allen

Livro Produtividade Pessoal, de David Allen

Só que desta vez eu procurava algo um pouco diferente, para eu produzir de forma mais eficaz, mas também me fizesse sentir mais dono do meu tempo, já que eu realmente tinha mais autonomia sobre ele.

Eu já conhecia o autor Cal Newport, professor de ciências da computação na Universidade de Georgetown. Pesquisando sobre o assunto, encontrei em um de seus artigos a sua metodologia de planejamento diário.

O título do artigo logo me chamou a atenção: “The Importance of Planning Every Minute of Your Work Day” (numa tradução livre, “A importância de planejar cada minuto de seu dia de trabalho“).

Ora, de imediato, discordei! Afinal, onde já se viu querer planejar cada minuto do seu dia?! Lógico que não vai funcionar!

Porém, como já conhecia o autor, e tinha me identificado com ele, resolvi ler o artigo para conhecer o método. Basicamente, ele consiste em, diariamente, planejar as suas atividades, criando e bloqueando fatias de tempo específicas para cada atividade. Durante essas fatias de tempo, concentração e foco total na tarefa definida.

Gostei muito e coloquei em prática! Veja uma agenda diária minha (as partes hachuradas mencionavam nomes que preferi não expor):

Agenda com tarefas do dia 30/11/2015

Agenda com tarefas do dia 30/11/2015

Três preocupações comuns para quem acaba de conhecer o método (eu realmente tive as duas primeiras):

1) Vale a pena mesmo investir tempo nesse planejamento? Segundo o autor, uma semana de 40 horas de trabalho bem distribuído segundo esse método equivale a uma semana de 60 horas de trabalho adhoc. Não sei quantificar, mas minha percepção é de que funciona, mesmo. Quando chego na fatia de tempo de trabalho, simplesmente a executo e não me preocupo com as outras coisas. Ou melhor, digo “não” para as outras coisas. Email fechado, redes sociais fechadas, etc. Dependendo do nível de concentração que preciso, WhatsApp no silencioso também.

2) E aquelas atividades, não planejadas, que eu sei que vão aparecer (geralmente, no meu email)? Neste caso, o autor também recomenda uma solução simples: crie uma fatia de tempo para elas. Por exemplo, 1 ou 2 horas para checar o email e encaminhar as demandas. Ele, inclusive, sugere uma estratégia para a incerteza natural dessas fatias de tempo: “process client requests; if I have downtime during this block, work on project X”.

3) Será que funciona para trabalhos de natureza criativa? Segundo o autor, sim, porque garante uma dedicação consistente de foco e esforço às atividades criativas. Além disso, a tranquilidade por saber que sua agenda está organizada permite você se aprofundar nesses seus “blocos criativos” e gerar mais valor. Eu acrescentaria que você pode também escolher o seu melhor momento do dia para trabalhar nessas atividades. Por exemplo, eu gosto de escrever mais pela manhã e tenho feito assim. E, de fato, saber que eu tenho um bloco de tempo definido para isso, mas também para as minhas outras atividades, no meu caso, me dá muita tranquilidade e prazer para escrever.

Refletindo sobre o método de Cal Newport, vejo algumas práticas parecidas com o método Scrum: bloquear tempo, foco em uma coisa de cada vez, representar visualmente o trabalho, uma divisão clara entre planejar X executar e a flexibilidade para mudanças.

Aliás, falando em falando em planejar X executar, num outro artigo o autor fala sobre planejar o dia seguinte ao final do dia anterior. Isto eu fiz umas poucas vezes e gostei também, mas confesso que ainda não consegui incorporar como hábito.

Sua metodologia na verdade é bem mais abrangente e aborda também o planejamento semanal e a longo prazo. Se você achar interessante, podemos abordar num texto futuro. Espero que tenha gostado. Veja aqui o artigo original do autor sobre o planejamento diário e deixe seus comentários. 🙂

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


Receba nosso Boletim

Grátis, diretamente em seu email, artigos sobre métodos de startups aplicados a soluções empresariais.