Scrum: seu time já deveria estar em outra

Um pouco da experiência de um desenvolvedor


Trabalho com desenvolvimento já há algum tempo. Lembro que quando comecei, passava boa parte do dia em um erra e acerta de implementações. O acerto era peça rara. Mal sabia programar, quem dirá entender alguma coisa sobre metodologia de desenvolvimento.

Desta maneira passei pelo meu primeiro e segundo emprego, abri um negócio e virei freelancer. Trabalhei sozinho, não era introspectivo e tratava tudo com bastante responsabilidade. Não fazia falta alguma aplicar algum tipo de método.


Conheci Scrum há cerca de três anos. Sem ter sido formalmente apresentado ao método, fui aprendendo os conceitos a medida que era surpreendido por uma nova cerimônia. Discovery, planning, daily, review e retrospectiva. As duas últimas, talvez pelo nome começar com “re”, até hoje causam confusão na minha cabeça. Vale dizer que o cliente estava próximo e a equipe era mista. Tinha designer, arquiteto de informação, alguns desenvolvedores, Scrum Master e Product Owner.

Os momentos mais engraçados eram os de Planning Poker. Recebíamos um baralho de cartas na sequência Fibonacci para indicar a complexidade das histórias. Nas primeiras jogadas, a discrepância era grande. A razão era simples: cada história era adequada a aptidão de algum membro do time. E adivinhe, este era o único que tinha argumentos sólidos para justificar a sua jogada.

O time aos poucos aprendeu mais sobre o peso das coisas e a homogeneidade no jogo começou a reinar. Alguns sprints se passaram e algumas releases depois trabalhávamos muito bem juntos. Identificamos os pontos fortes e fracos um dos outros. Foi minha primeira experiência de trabalho em equipe e reformulamos um produto por completo. Apesar de ter ficado por poucos meses, aprendi Scrum.


Quando passei a trabalhar em uma consultoria o cenário era um tanto diferente. Por lá, os times eram menores, sem um Scrum Master e com o papel de Product Owner desempenhado por um desenvolvedor. Quem me conhece sabe que defendo o empowerment da classe. Acredito que tudo o que pode ser feito por um desenvolvedor deve ser feito por ele.

Nossos clientes eram start-ups em diferentes níveis de maturidade. Ensinávamos a eles um pouco de como desenvolvíamos, criávamos um projeto e escrevíamos código desde os primeiros dias. Todos por lá já haviam trabalhado com Scrum, mas não o aplicávamos por completo. Cada time ajustava suas práticas e seguia em frente fazendo entregas, muitas vezes, diárias.

Dispúnhamos também de um par de escritórios, os times mudavam com certa frequência e era comum serem formados por pessoas de diferentes cidades. A comunicação da empresa toda e dos times era apoiada no Slack. Os projetos eram gerenciados no Pivotal Tracker, onde registrávamos as atividades (muito pouco se falava em histórias) com estimativas que podiam variar de um a quatro dias de trabalho.

Em geral, os ciclos eram de uma semana e o Backlog era populado a medida que o cliente passava a melhor conhecer seu produto. Não haviam cerimônias de planning. Sempre que necessário, nos reuníamos e pontuávamos as tarefas. O Pivotal Tracker aferia nossa velocidade e dava um panorama claro de quando uma feature estaria no ar. O cliente participava ativamente do processo, confirmando se as atividades estavam corretas, cadastrando bugs e priorizando o trabalho.

O sucesso de um projeto passa pela gerência de expectativas.

No último projeto em que trabalhei, alguns dias não fazíamos daily e em outros ela durava horas. Ela constumava ser usada para tomar decisões importantes ou desenvolver algo em conjunto. Chamávamos de daily por comodidade, daquilo imposto pelo Scrum, não seguíamos nada. Todos ficavam sentados e falavam o que era relevante da maneira que melhor convinha.

Confesso que até hoje fico assustado lembrando o quanto conseguíamos produzir e com a boa qualidade com que fazíamos. Utilizávamos as tecnologias certas pro nosso mercado e nos cercávamos dos melhores recursos: Code Climate, Travis CI, Testes de Software, Github e Pull Request, Heroku e Slack. Além de tudo, tínhamos uma equipe muito talentosa com sede de conhecimento. Quase nada disto é novidade.


O que penso sobre Scrum

O framework é disruptivo em relação a como desenvolvíamos no passado e pode ser útil para companhias que nunca aplicaram uma metodologia de trabalho. Os conceitos por trás do Scrum são importantes e elaborar um processo é essencial. Criar senso disto e sobretudo fazer que a equipe pratique é fundamental. Todos precisam sentir na pele o quanto é preciso comunicar bem, conhecer sua velocidade de desenvolvimento e consequentemente garantir transparência daquilo que está e será entregue.

Depois que a equipe entender pra que servem as cerimônias e práticas do Scrum, tudo se tornará tedioso e falso. A partir disto, fuja o máximo possível. Pense no framework como os foguetes de lançamento de um ônibus espacial, quando o objetivo for alcançado, não passarão de sucata, um belo peso extra.

Scrum is a self-destructive methodology, it ceases to exist the moment people know what to do, when to do — then the process becomes a burden and annoyance, you may have hit that point.

A grande perda do processo se deve as discretizações do tempo que ele estabelece. Todas as Timeboxes que fazem parte do Scrum são úteis para disciplinar. E, segundo a Lei de Parkinson, por bem ou por mal, as tarefas sempre irão preencher o tempo disponível para se completar. Com a experiência, o tempo entre Plannings e Dailies, que em geral é engessado, servirá apenas para promover procrastinação.

A Daily serve para viabilizar comunicação e ser um momento em que o time possa consumar uma tomada de decisão. A comunicação deve acontecer a todo tempo e de preferência também por meio on-line. Este conceito somente será aprendido quando a Daily não for mais necessária. Um time se comunica adequadamente somente quando tudo aquilo que for dito durante a prática já for do conhecimento de todos. E sobre a tomada de decisão, esta deve ocorrer no momento em que for necessária, e assim como a qualquer comunicado, jamais no dia seguinte.

Talvez por ter trabalhado por bastante tempo remotamente, o que realmente me chateia são os quadros cools com Kanban e Burndown. O que sempre intriga os membros de uma equipe: Quando as tarefas devem ser passadas de Doing para Done? Se for durante a Daily (como prega o framework), todos saberão da mudança, mas se for a todo tempo, o Kanban irá melhor refletir o estado das coisas. Em resumo, este é o tipo de decisão que só o mundo off-line proporciona. Softwares como Pivotal Tracker ou mesmo o Trello resolvem o quadro de maneira muito melhor. Com eles, tudo fica registrado e preparado inclusive para trabalho remoto.

https://twitter.com/rafaelrinaldi/status/526192445835722752

Na mesma linha, as atividades devem ser pontuadas o mais rápido possível. Quanto mais aguçada for a visão do esforço que está por vir, melhor. Plannings a cada quinzena, por exemplo, seja por escolha ou tentativa de economia de tempo, só me parece mais um desperdício. Por questões naturais e culturais já possuímos discretizações de tempo o suficiente: hora, turno, dia, semana e mês. Ao menos use uma delas, organize seu trabalho no início de cada semana. Faça de maneira rápida e informal.


Espero que estes poucos exemplos justifiquem o porquê de abandonar as práticas do Scrum e quanto isto significa não deixar de lado sua filosofia. Questione sua equipe sobre quanto cada membro entende das razões pelas quais são aplicadas as práticas. A partir do momento que existir uma consciência coletiva, não tenha medo de quebrar as regras e fazer com que o talento e experiência do time tomem as rédeas. Principalmente quando tiver uma boa entrega pela frente e o time estiver bem alinhado.

O pior que pode acontecer é um time estar maduro o suficiente para não aplicar uma ou outra prática e ser forçado a fazê-lo por simples formalismo ou medo que isto possa influenciar na produtividade. Saiba também que uma prática não precisa ser abandonada para todo o sempre. Neste chão, não há caminho que não tenha volta. Adequar as práticas aos problemas (ou se livrar delas) e utilizar as tecnologias certas é o segredo para ganhar um time realmente ágil e produtivo.

Aqui não estão todas as respostas, com certeza desconheço grande parte delas. Apenas trago o que definitivamente não irá funcionar e criará problemas em determinadas situações. Não deixa de conferir também o Manifesto for Async Software Development, muita coisa por lá será complementar.

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.