Sysvale - O Scrum em uma startup

O Scrummaster rotativo

Este artigo foi escrito para aqueles que já conhecem alguma coisa de Scrum. Por isso, não vou ficar explicando, aqui, muitas coisas. Basta dizer, aqui, que o Scrummaster é o "padre" do Scrum: é quem garante que os papéis sejam cumpridos, os ritos sejam seguidos e os artefatos sejam preenchidos. Quando o Scrum foi criado por Jeff Sutherland e Ken Schwaber e passou a ser adotado por outros agilistas como Mike Cohn e Bob Martin, nunca se havia pensado no Scrummaster como uma função fixa: a função do Scrummaster deveria ser rotativa entre os membros da equipe. Bob Martin, o Uncle Bob, fala muito bem disso em sua palestra "The Land That Scrum Forgotten" (A Terra que o Scrum Esqueceu).

Infelizmente, pessoas e empresas acostumadas com processos mais antigos de desenvolvimento, onde havia a figura do "gerente de projeto", mapearam o papel do Scrummaster (e a sua certificação) como se fosse uma figura equivalente. Não é. Não há um gerente de projeto no Scrum e as funções desse gerente são simplesmente divididas dentro da equipe, que se auto gerencia.

Na Sysvale não havia vícios ou muitas referências de trabalhos anteriores e, dessa forma, a equipe autogerenciável com seu Scrummaster rotativo funcionou bem desde o princípio. Na medida em que novos membros são agregados à equipe, eles observam como rodam algumas Sprints e, após uma ou duas, já recebem a função de Scrummaster, sendo auxiliados pelos demais (e pelo coach) no cumprimento desse papel de líder servidor e destruidor de obstáculos.

A Sprint Blindada

É repetitivo dizer Sprint Blindada, já que toda a Sprint é, a rigor, blindada. Na prática, porém, é preciso reconhecer que é impossível a blindagem de todas as horas de trabalho em um dia para que, dentro delas, sejam realizadas apenas as tarefas combinadas na Sprint Planning Meeting. Logo que comecei meu trabalho de coaching na Sysvale, tive uma dificuldade enorme em estabelecer o heartbeat, a batida, o ritmo de nosso Scrum. Havia muitas interrupções, o tempo todo, começando por atividades burocráticas que dependiam de respostas externas (contador, órgão de registro da empresa, agência de financiamento, bancos) e tinham a ver com o próprio processo de criação da empresa. Em nossas primeiras Sprints foi necessário assumir um compromisso de apenas duas horas diárias, que às vezes aconteciam na parte da manhã e outras na parte da tarde, onde todos se comprometiam a estar juntos, trabalhando nas tarefas trazidas para o Sprint Backlog.

O ritmo inicial, porém, ainda que frágil, ficou estabelecido e a própria equipe reconheceu a importância e necessidade de intensificá-lo, uma vez que já havia a percepção de que a produtividade é, de fato, impulsionada pela constância do ritmo. Mas ainda havia um volume grande de interrupções externas.

Afinal, todos concordaram em blindar a parte da manhã e que um dos colaboradores mais experientes da empresa atuaria como o "buffer" das interrupções, resolvendo-as sempre que possível ou segurando-as para passá-las à equipe apenas na parte da tarde, após a Sprint Blindada.

Agora, então, a explicação do porque da manutenção do nome "Sprint Blindada". Acabou por acontecer que o ritmo conseguido com a Sprint matinal contaminou o trabalho na parte da tarde, onde as tarefas que estão no Sprint Backlog continuam a ser feitas, mas com a concordância de que elas podem ser interrompidas caso o "buffer" precise de ajuda. Também, como prática do XP, trabalhamos em um bug assim que ele é detectado mas, na medida do possível, esse trabalho também é trazido para a parte da tarde.

Dessa forma, nosso "buffer", o Eugênio Marques, junto com o Caio Ladislau, desenvolvedor, batizaram como "Over Sprint" esse trabalho que acontece na parte da tarde que, não é uma Sprint real, por não ser blindada, mas é contaminado pelo ritmo estabelecido na parte da manhã. O "Over Sprint" veio de uma brincadeira deles comigo, que insisto na prática do "No Overtime" (sem horas extras).

Claro, ainda não é o ideal. Esse ritmo estabelecido pelo Scrum ainda vai aumentar o seu poder de contaminação e será possível, com o tempo, blindar mais horas para a Sprint oficial. Tenho que reconhecer, porém, que o nível de interrupções e mesmo de provocações que a Sysvale recebe do mercado fazem desse arranjo Sprint/Over Sprint algo bem interessante.

Pair Programming

A maioria dos desenvolvedores com os quais tive contato preferem, inicialmente, trabalhar sozinhos. E desses, quase todos relutam em dividir seu computador e espaço de trabalho com outra pessoa. Eu insisto na programação em par e agora na Sysvale, mais uma vez, pude ouvir dos próprios desenvolvedores que seu trabalho melhorou graças a esta prática. Para começar, a produtividade aumenta porque diminuem os erros, aumenta a qualidade do código e a "polinização cruzada" de ideias e conhecimentos amplia a criatividade.

Recentemente, adicionamos ao time que já contava, além de mim, com os já mencionados Eugênio e Caio e o ainda não mencionado engenheiro Denisson, o Geidson, licenciado em computação e uma das pessoas mais versadas em design responsivo que já conheci. Rapidamente o Caio e o Denisson absorveram, dentro da programação em pares, muito do conhecimento do Geidson sobre o Bootstrap e, por outro lado, o Geidson está ficando cada vez mais cobra no Laravel, o framework para o desenvolvimento em PHP que adotamos na Sysvale.

Claro, há mais coisas a serem ditas mas, por hoje, encerro o artigo. Com o tempo, vou contando mais histórias interessantes de mais essa adoção do Scrum. Agradeço ao pessoal da Sysvale pela confiança em seu coach! E, meninos, NO OVERTIME!