Como criar Retrospectivas de Sprint que funcionam?

O Scrum é um framework ágil de gerenciamento de projetos que envolvem produtos complexos, geralmente usado em equipes de software, embora existam diversas adaptações para outros tipos de times. Costuma-se dizer que o Scrum é simples de entender, mas difícil de aplicar e embora esse paradoxo soe confuso, é exatamente isso. Em partes isso se deve à total necessidade de se aplicar seus três pilares: transparência, inspeção e adaptação, e em partes devido à sua simplicidade de definir poucas reuniões e poucos artefatos, muitas vezes lhe deixando sem ideias de como facilitar (enquanto Scrum Master) reuniões como a Retrospectiva da Sprint (Sprint Retrospective).

Neste post quero dar uma boa ideia nesse sentido, de como conduzir uma Retrospectiva de Sprint que realmente funcione segundo os pilares do Scrum.

Depois de ler e se quiser saber mais sobre o meu trabalho com Scrum, dê uma olhada no livro que escrevi.

Sprint Retrospective

O que é?

A Retrospectiva da Sprint, segundo o próprio Scrum Guide, é:

A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint.

Ou seja, de todas time-boxes do Scrum, certamente a Sprint Retrospective é a mais alinhada com os pilares da Inspeção e Adaptação, pois esse é o seu cerne. Já vi muitas equipes não realizarem as retrospectivas e portanto não evoluírem seus processos de gerenciamento e desenvolvimento de software. As pessoas tendem a ignorar que o maior motivo de termos tantos softwares inúteis ou mal acabados é por falta de comunicação, seja com o cliente, com o chefe ou entre os desenvolvedores. E a retrospectiva é justamente uma oportunidade formal da equipe se comunicar e se aprimorar enquanto time ágil.

Principalmente os programadores, profissionais das ciências exatas, não gostam da ideia de “perder tempo” falando sobre os problemas do time ou pensando em processos, quando poderiam estar programando, que é o que gostam de fazer. Esse pensamento imaturo persistiu na minha mente durante alguns anos no início da minha carreira até que eu percebi que o software pelo software não adianta de nada. Que o que fazia (programar) era apenas um meio, e não o fim. Se meu software não solucionasse o problema do cliente, ele era apenas um monte de lixo, por mais tempo e esforço que eu tivesse colocado em seu desenvolvimento.

Parar e refletir sobre os objetivos e sobre os processos necessários para chegar lá é vital para a eficiência (e muitas vezes para eficácia também) do time.

sprint_retrospective1

Como facilitar esta reunião?

Como todas reuniões, o Scrum Master deve ser o facilitador desta reunião de até 3h para Sprints de um mês. Ele deve convocar o time, explicar o motivo da reunião e apenas auxiliar o andamento da mesma e o respeito ao tempo limite. Somente o time de desenvolvimento (segundo a ótica do Scrum, todos que não são PO ou Scrum Master são desenvolvedores) que realmente “participa” da reunião. A dinâmica abaixo é um exemplo de como ela pode ser conduzida, uma vez que o Scrum Guide apenas dá linhas gerais, sem um exemplo prático.

Escolha uma sala da empresa com quadro branco com canetas marcadoras (também chamados de “caneta para quadro branco” ou “pincéis atômicos”) ou na ausência desse recurso, um mural que possa ser riscado já serve. Vamos precisar também de post-its (se tiver 3 cores diferentes, melhor) e canetas esferográficas comuns. Na ausência de post-its, recorte pequenos cartões do tamanho de um cartão de visita que já resolve. Um bom número é 3 cartões/post-its por pessoa do time de desenvolvimento.

Divida o quadro/mural em três colunas: BOM, MELHORAR e AÇÕES.

Na coluna BOM devemos colocar cartões com aquilo que foi executado e que deu certo, que a equipe deveria manter na próxima sprint como uma boa prática.

Na coluna MELHORAR devemos colocar cartões com aquilo que foi executado de maneira ruim e que pode melhorar na próxima sprint.

Para cada coisa que precisa melhorar, deve existir um registro na coluna AÇÕES com uma ação concreta e factível para o mesmo. Tem que ser algo que possa de fato ser colocado em prática, preferencialmente que alguém da equipe se comprometa pessoalmente de que não irá acontecer na próxima sprint.

As regras de preenchimento são: apenas um fala por vez, e somente aquele que estiver portando um token, que geralmente é um marcador de quadro branco ou caneta, previamente escolhida. Quando a pessoa fala (o que não deve demorar mais de 1 minuto por pessoa) o que deseja, ela escreve em um cartão/post-it de forma resumida e gruda no quadro/mural na na coluna que tem a ver com sua contribuição. A próxima pede o token para poder começar a falar até que todos tenham falado ao menos uma vez.

Ao término da retrospectiva o Scrum Master coleta os dados e garante a cobrança dos indivíduos sobre as considerações para que não retornem a aparecer na próxima Sprint (principalmente as coisas que podem melhorar). É comum guardar os cartões para cobrança posterior ou ao menos uma foto do quadro completo, que permita zoom depois para ler os cartões.

retro

Ações Concretas

Talvez o ponto mais crítico da retrospectiva seja as ações definidas para melhorar o processo. Como Scrum Master, é seu dever garantir que os itens que “devem melhorar” não retornem na próxima retrospectiva, caso contrário o pilar da “adaptação” do Scrum não estará sendo aplicado e o processo, que deveria ser vivo, ficará estagnado. Via de regra, para cada item que está na coluna “MELHORAR” deve ter um item na coluna “AÇÕES” para resolver o problema. E aqui que mora o problema: as ações devem ser concretas.

O que diferencia uma ação concreta de uma abstrata?

Imagine que algo que deve melhorar é a comunicação com o PO, que representa o cliente da equipe. Que algumas features tiveram de ter retrabalho porque não atenderam às necessidades do cliente, sendo que trazer essas necessidades pro time é responsabilidade do PO que não esteve presente. Isso certamente deve melhorar para que a qualidade das entregas igualmente melhore. Assim, para esse item que deve melhorar devemos ter uma ação concreta para que não ocorra novamente. Certamente alguém irá sugerir “conversar mais com o PO”, mas note como isso é vago, em contraponto, uma ação concreta seria “marcar uma reunião semanal com o PO para alinhar a execução das features” e mais do que isso “definir que todas segundas-feiras às 11h teremos uma reunião de 30 minutos com o PO para mostrar como estão sendo desenvolvidas as features que estão em DOING no Kanban“. Percebe a diferença?

É difícil chegar nesse nível de ação concreta, mas é o que devemos buscar. Cabe ao Scrum Master tensionar a reunião para que as ações tenham esse nível de qualidade para que de fato elas sejam postas em práticas e o processo seja melhorado. Perguntas como: “Como? Quando? Quem?” devem ser instigadas até que a ação seja refinada neste nível de detalhe.

No entanto, um alerta: jamais defina ações, que por mais precisas que sejam e por mais boa intenção que tenham, sejam inexequíveis, isto é, não tenham como ser executadas. Quando uma ação é definida, o time inteiro está se comprometendo com ela e caso a ação seja impossível de ser realizada, haverá frustração quando os mesmos problemas voltarem a acontecer. Então defina ações que resolvam o problema e que sejam concretas, precisas, mas jamais inexequíveis.

Usando o mesmo exemplo anterior, do PO ausente, de nada adianta definir que as reuniões ocorrerão todas as segundas às 11h se o PO não pode nesse horário. Nesse caso, uma ação concreta mais facilmente executável seria “conversar hoje, logo após esta reunião, com o PO para definir um dia e horário semanal que ele possa estar presente na equipe para discutirmos o andamento das tarefas”. Mas note que ainda é uma ação precisa: hoje falaremos com ele, hoje marcaremos um dia e hora semanal na agenda dele para conversar com a gente.

E aí, mais confiante de aplicar Scrum na sua empresa?

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Treinamento Scrum em um post

Conheço e aplico métodos ágeis há pelo menos 6 anos, principalmente o framework empírico Scrum. Durante o final da minha faculdade a empresa onde trabalhava, RedeHost, necessitava urgente de uma reorganização dos seus processos de desenvolvimento de software e queriam que eu me tornasse um de seus líderes de desenvolvimento. Obviamente agarrei a oportunidade, que foi muito importante para minha carreira, e isso me rendeu uma ida à São Paulo participar da segunda turma de um treinamento latino-americano oficial da Scrum.org para desenvolvedores Scrum. O treinamento de uma semana foi incrível e me capacitou para tirar duas certificações na área de gerenciamento de projetos com métodos ágeis e passei a atuar como facilitador do framework Scrum na empresa, em treinamos e em consultorias (como esta).

No post de hoje resumo o famoso Scrum Guide, o livro de apenas 19 páginas que detalha tudo o que você precisa saber sobre o Scrum antes de passar a aplicá-lo em seu time de produto. No fim do post você encontra os slides do treinamento que aplico, disponíveis no Slideshare. Caso queira saber mais sobre o meu trabalho com Scrum, dê uma olhada em meu livro.

rugby-scrum

O que é Scrum?

A definição formal, cunhada pelos criadores Ken Schwaber e Jeff Sutherland, diz que:

Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.

Entenda um framework como uma caixa de ferramentas. Scrum não é algo pronto que resolve todos seus problemas, mas sim um conjunto de processos que norteiam o desenvolvimento de produtos complexos.

Apesar de leve e simples de entender, Scrum é extremamente difícil de dominar, uma vez que envolve rigidez em sua aplicação. Implementações de Scrum que não seguem as regras previstas em seu manual são o que chamamos de Scrum flácido, e tendem a não alcançar o potencial máximo da metodologia.

Mas por que confiar e seguir cegamente este framework? Scrum é um processo empírico, baseado pura e simplesmente nas experiências passadas de seus criadores que desde o início da década de 90 aplicam Scrum em projetos de software com sucesso, já sendo uma das metodologias ágeis mais usadas no mundo. E uma vez que você se torna adepto do Scrum, o empirismo passa a fazer com que você respeite o processo cada vez mais e adicione novos processos e artefatos complementares baseados nas SUAS experiências com o mesmo.

Os Pilares

O Scrum se baseia em três pilares de sustentação, suas ideologias:

Transparência: aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados.

Inspeção: os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção a detectar variações. Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas.

Adaptação: se um ou mais aspectos de um processo desviou para fora dos limites aceitáveis ou produto não será inaceitável, o processo ou o material sendo produzido deve ser ajustado.

Sobre estes pilares o framework Scrum divide-se em papéis, eventos e artefatos.

Papéis

Os papéis dentro do time Scrum são:

Product Owner

É o responsável pelo ROI (retorne sobre o investimento) do projeto, é responsável por gerenciar e priorizar o Product Backlog (veja mais abaixo) e para que o Scrum funcione e ele consiga trabalhar, toda a organização deve respeitar as suas decisões. No mundo mais tradicional da gestão de projetos, o P.O. seria o Gerente de Produto (Product Manager).

O P.O. é membro do time scrum e deve estar presente e disponível para solucionar dúvidas do time em relação ao produto e ao backlog. Se esse papel for assumido por alguém da empresa do cliente, esta pessoa idealmente dever ter um canal de comunicação ininterrupto com o time de desenvolvimento, para que ele possa avançar sem atrasos.

Desenvolvedores

São os responsáveis por desenvolver o produto. O time de desenvolvedores (que não precisa e não deve ser composto apenas por desenvolvedores) é auto-gerenciável, multifuncional e compartilham a responsabilidade pelo sucesso ou fracasso do projeto.

O time de desenvolvimento é quem decide o quanto consegue entregar a cada iteração, para que haja comprometimento com a entrega.

Scrum Master

É o responsável por aplicar e garantir a adoção do Scrum dentro da equipe e até mesmo dentro da organização onde estão inseridos. Cabe ao Scrum Master, que é um líder-servidor, liderar o time para que os objetivos do Product Owner sejam alcançados e para que o time de desenvolvimento consiga avançar sem impedimentos, removendo-os quando necessário.

Todos os eventos Scrum são facilitados pelo Scrum Master da equipe, que idealmente não deve ter outra função paralela no time Scrum.

Eventos

O Scrum chama seus eventos de time-boxes, uma vez que são eventos de duração fechada. Um evento pode ser encerrado em tempo menor do que o previsto, mas nunca maior, e o Scrum Master deve garantir isso enquanto facilitador dos eventos. Permitir a extrapolação cria um sentimento inconsciente de impunidade e faz com a equipe não respeite os objetivos e o planejamento da Sprint. Por sua vez, falhas constantes em entregar os objetivos de uma Sprint forçarão o time de desenvolvimento em serem mais eficientes no planejamento, focarem mais nos objetivos e se comprometerem de maneira mais coerente com as entregas.

Sprint

As sprints são time-boxes de 1 mês ou menos e são o coração do Scrum. Durante o período da Sprint um incremento utilizável do produto é criado. Mas nem só de desenvolvimento vive a Sprint, fazendo parte da mesma também o planejamento, as reuniões diárias, a revisão e a retrospectiva.

Sprint Planning

Time-boxe de 8h para uma sprint de um mês, ou menos tempo de acordo com o tamanho da Sprint. Nesta reunião é onde o Product Owner é ouvido em relação às prioridades e os objetivos desta Sprint. É nela também onde o time irá deliberar sobre o que conseguem fazer nesta sprint em relação às necessidades do P.O., formalizando o Sprint Backlog, ou lista de coisas que serão feitas no próximo mês.

É comum o uso de artefatos externos ao Scrum nesta fase, como o Planning Poker, usado para estimar o custo de tarefas a serem realizadas. O ideal é que independente da técnica usada para estimar (pontos de função, por exemplo), que cada tarefa não ocupe um membro do time por mais de um dia. Se isso acontecer, veja como pode quebrar a tarefa grande em tarefas menores.

planningpoker

Outro artefato muito popular também é o kanban (especialmente usando Trello), um board onde temos colunas com cards, onde em cada card temos uma tarefa a ser realizada, previamente estimada. Cada coluna representa um estágio do ciclo de desenvolvimento de uma tarefa, tais como: TODO (para fazer), DOING (fazendo), Testing (testando) e DONE (pronto).

kanban-board-e60650d1-1

Daily Scrum

Time-boxe de 15 min que deve acontecer diariamente, sempre no mesmo local e horário para gerar consistência e evitar perda de tempo, facilitada pelo Scrum Master. Nesta reunião, que deve ser muito dinâmica e que popularmente é feita em pé (para evitar prolongamentos e distrações), cada membro do time deve responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem algo me impedindo.

A reunião diária é o método mais eficaz de alinhamento dos membros do time que tive a oportunidade de experimentar. Ela permite a descoberta rápida de problemas e desvios de curso e suas respectivas correções, por isso deve ser respeitada.

burndown-chart-formula

Artefatos passíveis de serem usados nessas reuniões incluem um Burndown Chart, que nada mais é do que um gráfico de features a serem desenvolvidas (eixo y, vertical) versus tempo da Sprint (eixo x, horizontal). O gráfico começa no alto do eixo y (ou seja, faltam todas features) e no ponto 0 do eixo x (ou seja, ainda tem todo o tempo da sprint sobrando) e deve ser atualizado diariamente com o progresso do time. Um Burndown Chart sempre visível garante o dia inteiro, todos os dias, que todos sabem o quanto falta para terminarem a sprint, e caso estejam longe do seu objetivo, de resolverem os problemas. A ideia aqui não é analisar o Burndown Chart na reunião diária, que é curta e deve se manter assim, mas apenas acompanhar rapidamente, também de maneira diária, o progresso do time.

Esse evento é um dos que representam o pilar de inspeção do Scrum.

Sprint Review

Time-box de 4h para sprints de 1 mês onde o incremento do produto, que está pronto pra uso, é apresentado ao Product Owner para apreciação. Também é na review (que deve ser facilitada pelo Scrum Master) que o Product Owner apresentará os números, gráficos e tudo o mais que for importante à equipe saber sobre o produto. Novas prioridades, movimentos do mercado, etc, tudo focado em manter os objetivos coerentes ao longo das sprints.

Essa é o evento que melhor representa o pilar de inspeção do Scrum.

Sprint Retrospective

Time-box e 3h para sprints de 1 mês onde o time de desenvolvedores e o Scrum Master (que atua apenas como facilitador) falam sobre os resultados obtidos na Sprint que passou e as lições tiradas a partir daí, para melhorar o processo, fortemente arraigado ao pilar de adaptação. Trato em mais detalhes desta importante reunião neste post.

Artefatos

O Scrum determina alguns poucos artefatos:

Product Backlog

Lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. Gerenciado única e exclusivamente pelo Product Owner, que o faz a todo momento, o product backlog deve ser mantido longe do time de desenvolvimento, para evitar dispersão.

Muitas empresas tem usado a ferramenta Trello para seus products backlogs. Já usei muito, mas atualmente uso só o Visual Studio Online.

project-management-trello

Sprint Backlog

Uma versão reduzida de backlog apenas com os itens que devem ser desenvolvidos nesta Sprint, retirados do backlog original. Também pode ser organizada em formato de kanban no Trello, mas em um board separado do Product Backlog.

Cabe ao time de desenvolvimento montar o Sprint Backlog com base nas prioridades do Product Owner e é sua responsabilidade dar cabo de todos itens até o fim da sprint, servindo o Scrum Master como um facilitador para que nada interrompa o ciclo de desenvolvimento.

Conclusões

É isso. O Scrum Guide tem apenas 19 páginas e esse post umas 2000 palavras. O Scrum é pequeno, mas difícil de ser posto em prática porque exige muita disciplina. Nos treinamentos que ministro aplico sempre um exercício prático aos alunos para enriquecer a experiência e vivenciar na prática, mesmo que por poucas horas, como funciona o ciclo de desenvolvimento de um produto usando Scrum. Não encontrei uma boa maneira de colocar o exercício aqui, mas se puder filmar da próxima vez que aplicar o treinamento, vou incluir o vídeo aqui.

Boa sorte aplicando o Scrum em sua empresa!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Consultoria Scrum e Treinamento Android

Este post é apenas pra compartilhar algumas novidades com relação aos mais diversos trabalhos que desenvolvi no RS. Depois de pouco mais de 2 meses inteiramente dedicados ao meu projeto de startup, Busca Acelerada, eis que volto a aparecer na “casa dos outros” para disseminar um pouco de duas coisas que gosto bastante: Scrum e Android.

Consultoria Scrum na Opideia

Consultoria Scrum na Opideia

Sabe como é, networking nunca fez mal a ninguém, e não é por acaso que graças a uma amizade de mais de 5 anos com Daniel Castro, diretor da agência digital Opideia, tive a oportunidade de realizar um trabalho junto com a equipe de desenvolvedores da agência. O intuito da consultoria era identificar problemas e aperfeiçoar os processos de desenvolvimento de produtos complexos na empresa, dando maior visibilidade e precisão aos projetos, reduzindo o desperdício e aumentando a agilidade da equipe como um todo. O trabalho da consultoria se deu em duas etapas, sendo a primeira mais teórica, abrangendo o framework ágil Scrum, do qual tenho duas certificações desde 2010, além de um pouco de Lean Startup, que venho estudando tem algum tempo. Nesta primeira etapa, passei um pouco dos meus dois anos de experiência com métodos ágeis e mais de 6 anos como desenvolvedor/analista freelancer, em um treinamento que incluiu muitas práticas como técnicas de análise de requisitos, estimativas de tempo e produtividade, artefatos de gerenciamento ágil de projetos e muitas, mas muitas dicas que não se ensina em livros.

Na segunda etapa, que ainda está acontecendo, participo como membro honorário da equipe durante um projeto real, conduzindo as reuniões e acompanhando o projeto para que o investimento da empresa seja maximizado e alcance o resultado esperado. A ideia é que nas próximas etapas deste mesmo projeto, o time já consiga se coordenar sozinho, de uma maneira mais ágil e com alta rastreabilidade, dando mais segurança aos desenvolvedores e aos clientes. Com isto a Opideia, que se encontra em um crescimento vertiginoso neste ano de 2012, espera aumentar ainda mais a qualidade dos projetos entregues consolidando sua marca no mercado nacional. Sucesso pra galera que posa pra foto!

Neste livro, ensino tudo o que você precisa saber sobre Scrum.

Curso de Android no CAFW/UFSM

Curso de Android no 3º EATI do CAFW/UFSM

E para começar novembro com o pé-direito, eu e meu colega de viagens, Cristiano Diedrich, tivemos a honra de sermos convidados a participar do 3º Encontro Anual de TI, no Colégio Agrícola de Frederico Westphalen (CAFW), que para quem não sabe, é um dos campi da Universidade Federal de Santa Maria (UFSM). A faculdade, que de colégio tem só o nome, promove um já tradicional evento de TI na cidade, organizado pelos professores do curso Tecnólogo de Sistemas para a Internet, que atrai estudantes e profissionais do país inteiro, totalizando mais de 300 inscritos no evento. No evento tinham convidados de peso como os profissionais da Globo.com e do Terra, além de nós dois representando a RedeHost.

O Cristiano ministrou uma palestra sobre Segurança de Servidores Web, e como bom pinguim que é, puxou brasa pro assado do Linux. Pelo que fiquei sabendo (estava dando um curso em paralelo) os profissionais de infraestrutura da cidade marcaram presença na palestra, que abrevia de maneira excelente os anos de experiência do Cristiano como Analista de Infraestrutura Open-Source. De minha parte, contribuí um curso básico de Android, totalmente reformulado desde suas primeiras edições nos campi da Ulbra e mais focado em integração com a web. Os alunos tiveram a oportunidade de criar aplicações de teste que utilizavam diversos recursos da plataforma, como widgets, listas, banco de dados, APIs HTTP e JSON, entre outros. Segue abaixo os slides do curso de Android e os fontes da app criada no final do mesmo, que é uma app que consome minha API beta do Busca Acelerada para consulta de veículos. Espero que tenha sido útil para quem queria quebrar o gelo com a plataforma Android ou ao menos encontrar um carango novo ;P

Agradecimentos especiais para a profa. Letícia e o prof. Rômulo, pelo convite e excelente acolhida na cidade, que fica no extremo norte do estado. Também agradeço aos mais de 40 alunos que prestigiaram o curso e contem conosco para o ano que vem!

Link da app “pronta”:BuscaAcelerada.zip (109,14 kb)

Link dos slides do curso:slides-curso-cafw.zip (1,32 mb)

Fotos do evento podem ser vistas no Flickr.

Curso Básico de Android no CAFW/UFSM

Quer aprender tudo sobre desenvolvimento de apps com Android e se diferenciar no mercado de trabalho? Conheça o meu livro sobre o assunto: Criando apps para empresas com Android!