What took you so long?

Aproveitando o tema, quero por aqui uma das piores missões que temos: um de nossos projetos depende não de um terceiro, mas de 2. Um que definirá a identidade visual, outro que está montando todo o back-end que utilizaremos, no caso, uma ferramenta de busca (eles são o indexador). Ken Schwaber coloca isso bem em seu livro, quanto a dependencias externas da equipe, mas coloco aqui minha versão. Para o trabalho do back-end, tivemos todo um trabalho, refletido em uma estoria, quanto a nossas entradas para eles começarem seu desenvolvimento. Vale falar que eles são, no Brasil, PMI a risca (ainda vou mostrá-los artigos da própria empresa usando Agile nos USA, rs). Nossa entrega foi um pacote de Excel com nossas regras. Por motivos particulares, não tivemos um review decente, mas apesentamos os nossos arquivos Excel. Eles mostravam que a entrega da empresa terceira seria um sistema que atenderia aquelas regras. Por não depender de nós o funcionamento intrinseco do sistema, tinhamos que validar o que estava nas planilhas, como por exemplo., que VL seria Vila e apto apartamento. São nossas regras, que só poderão ser visuais, deriverables, após o prazo determinado da empresa terceira. Nosso planejamento de Sprints levou em conta isto. Não contamos com nenhum atraso deles. Se em 22 dias nos entregarão, em 2 Sprints (ainda demos alguns dias de margem, pelo planejamento de Sprint quinzenal), o sistema. Se não, será um impedimento crítico. O ScrumMaster e Product owner, durante o Sprint prévio à entrega, tem que estar acompanhando de perto o trabalho da empresa terceira. Isto quebra a lógica de dependencias do Scrum? De certa forma. Se não temos os recursos, o expertise, ou mesmo a ferramenta dentro de casa, ou que possa ser desenvolvida, ou pior, que seja uma definição empirica da alta direção, quanto ao que os terceiros fornecerão, não temos o que fazer. Uma maneira que tratamos foi da inserção da user story de avaliação desta entrega, o que justifica o deliverable, o trabalho da equipe, e a possibilidade de voltar ao backlog e de haver uma nova complexidade nela. Uma sorte nossa foi que o segundo terceiro (ô frase esquisita) poderá trabalhar por entregas ágeis, o que possibilitará que entreguemos algumas estorias com um sistema já integrado ao trabalho destes.

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:)

Uma coisa que é sempre complicado numa introdução de SCRUM é a mudança de gerentes de projetos. Pessoalmente, sempre achei a cosia mais complicada essa relação de gerentes de projetos tradicionais. O que quero dizer com tradicionais? Há uma linha de trabalho histórica apelidada de top-down, top-bottom, etc. Pessoas acostumadas a mandar, obrigar, ignorar as motivações, ameaçar com demissões, etc. Isso sem contar na falta de comunicação verdadeira (papéis não são a maneira mais clara e transparente de comunicação) e, algo não obrigatório mas muito recorrente, a sede de poder. E qual o problema disso? A filosofia Scrum evoca como dogmas como: time auto gerenciado, avaliação do time quanto ao trabalho, o estimando de verdade, não há uma hierarquia na equipe como um todo, e há a obrigatoriedade de uma comunicação clara, com toda a equipe reunida. O time, quando pressionado por um GP tradicional, acaba engolindo o sapo. Até porque muitas vezes esse “sapo” está embasado por algum verdadeiro “top” (diretor, gerente) que quer este resultado agora. Isso acaba não transparecendo a todos. Mas ao haver uma reunião dos Scrummasters, e há algum scrummaster que já tenha se aprofundado mais, ou tenha experiencia, começam a aparecer os problemas: sempre mantendo iniciativas meio escondidas para dar-lhe aparição, a comunicação com pares existe sempre para trazer-lhe uma vantagem, as alianças não são quanto ao conceito de time e sim de posicionamento estratégico, e principalmente você vê que a equipe não pdoe estar satisfeita com uma postura normalmente arrogante que GPs normalmente assumem com a equipe e até pares, quando se posicionaram com visibilidade. Essa é uma das situações onde a empresa, na prática, decide se vai seguir uma linha ágil ou não. Pois, afinal de contas, qualquer gerente de projeto sem ser scrummaster pode fazer isso com a equipe, só muda-se o timebox existente do Sprint, que torna a pressão em volta de resultados maior. Se a empresa quiser seguir uma metogologia agil com ScrumMasters nesta linha, deve saber que está usando uma metodologia própria que: não aumentará a produtividade, não reterá talentos, e nem estará evidenciando seus problemas (a tradicional mitigação, ou seja, esconder debaixo do tapete para a faxineira limpar). Normalmente as empresas não vêem isto, e aceitam este modelo misto. Infelizmente…

Mais uma lista de ferramentas, a quem interessar:

1. Rally
2. Scrumworks
3. XPlanner
4. Mingle
5. VersionOne
6. TargetProcess
7. xProcess
8. Extreme Planner
9. ProjectCards
10. CardMeeting
11. XP Story Studio
12. PlanningPoker
13. Acunote
14. SilverCatalyst
15. PlanB

Logo nos primeiros dias, fui solicitado para um estudo do Microsoft Team Foundation Server para controle da implementação de Scrum. Se o pedido já parecia estranho, mais estranho vou verificar a ferramenta. No momento, existem 4 templates:

• MSF for Agile Software Development v.4.2: Não sei quem foi o louco que resolveu chamar isso de Agile, pois é RUP puro.
• MSF for CMMI Process Improvement v.4.2: Não há uma vantagem neste modelo, além de ser totalmente voltado para qualidade. os controles de Backlog e Task são rpecarios (sem tempo nem complexidade), porém com muitos pontos quanto a bugs e controles de falhas. Imagino que, em uma empresa que encontra-se muitos bugs em produção (nosso caso) poderia ser valioso, porém
• Light Weight Scrum v.2.1: Inclui nos Product Backlog  complexidade e critérios de aceite; um fluxo de impedimento bem processual envolvendo triagem, Backlog Item por complexidade e horas estimadas com sinalização de impedida, controle de release e “defect” (porque não bug?); relatorios de bugs e trabalho faltante.  Seus contras são não haver controle de sprint e poquissimos relatórios.
• Agile Software Development with Scrum v.2.1: O que acabamos escolhendo. Muito completo, mas só peca por não ter: aviso de task impedidas claramente, complexidade e gráficos por complexidade, por consequencia.

A ferramenta, como um todo, é boa, caso já tenha sido feito uma analise dela e várias adaptações. Sempre é necessária a criação de campos e relatórios que atendam a emrpesa, e a ferramenta de criação, dentro do Visual Studio, não facilita muito a vida.

Hora de começar a relatar a implementação de Scrum aqui na atual empresa. Espero que sirva de exemplo para alguns que procuram novos casos, além dos vários citados, de implementação de Scrum numa empresa voltada a outras metodologias (seja PMI, RUP, etc) no cenário brasileiro. Já são várias, e aqui darei enfoque ao que estamos passando, comparando com outros casos conhecidos.