What took you so long?

Está rolando uma discussão na scrum-brasil sobre complexidade e horas, provocada por este que lhes fala. Ela surgiu, na verdade, de dois casos:

1. Meu diretor pediu que tenhamos relatórios via Web para qualquer um ver. Daí veio o assunto de ferramentas. Porém, ele queria utilizar o Team Foundation, que será o substituto do Sourcesafe na empresa. Qualquer um dos templates utiliza horas. E eu, em minhas outras experiências em Scrum, utilizei horas internamente, para ter um acompanhamento incial, de transição, de como a equipe está andando, e sentir também a resistencia de alguns. Queira ou não, há pessoas que se você deixar livres (principalmente juniores e traines) que acabam fazendo corpo mole com uma boa malandragem.
2. Alguns amigos meus trabalham em consultorias. E tem uma diretriz de seguir Scrum. Como podem chegar o cliente de colocar na resposta de uma RFP que o projeto demorará “679″, um valor abstrato, mas com o aviso que será 100 pontos a cada duas semanas?

Isso sempre me deu as seguintes conclusões:

1. Em transição, não se pode fazer uma ruptura imediata. Mas não se pode, como algumas empresas tentam, de deixar o Scrum com complexidade e tarefas adicionais com horas. Isso faz com que não se tenha uma métrica geral da equipe.
2. A alta cupula quer gráficos. Em um primeiro momento, onde, apesar de um coaching e mentoring, não se tem uma maturidade de todos em fazer user stories, quebrá-las mais, e criar tarefas atomicas, um BurnDown de estórias por tempo será lento, crescerá a complexidade, enfim, não dará a eles a segurança necessária para se manterem na agilidade. As horas podem, inicialmente, até haver uma certa maturidade, ajudar nisto.
3. Empresas de consultoria precisam ou de mudar seu modelo ou haver um controle/definição de tempo no mínimo internamente. Acho que neste ponto às vezes nós, seguidores de agil, somos cegos quanto aos problemas deles. Terceirizar, as vezes, não é para baixar custos, mas necessidade para empresas de baixo orçamento. Eles precisam de algumas certezas, ou de serem convencidos da maleabilidade quanto ao RoI que terão ao utilizarem uma terceirização agil.
4. O apois a agilidade é complexo. Os stakerollers (como os chamos, rs) querem mais resultados. COmo no livro de Ken Schwaber fala, não interessa se é Scrum, Agile ou não, eles querem resultados. Não querem saber de periodo de adaptação. E, as vezes, para provar os problemas, temos que usar de horas, de impedimentos com horas (simbolos como bolas de dias impactantes as vezes não são claros, mostre em horas, ou em atraso, ou em aumento da complexidade), de novvas estorias derivadas das existentes, de aumento de complexidade bem claramente do por que, e por ai vai.

Esse é um tema que sei que provavelmente ainda teremos que amadurecer muito no agil, mas acho que estes pontos podem ajudar a muitos que passam por isso e não tem referencias (por isso o subject do que procurava no Google:)