Inspect and Adapt IterationTrabalhar em ciclo e fazer retrospectiva é algo tão natural que fazemos isso todo ano. É ou não é?

A chegada do fim do ano é um momento tão almejado por todos, que aguardamos ansiosamente a virada do ano como uma oportunidade para deixar o ano velho pra trás, deixar o que passou realmente passar, abandonar as frustações, as dúvidas, queixas, falhas… tudo, tudo para trás e ganhar um ano novinho em folha com mais dias, mais meses, mais novas oportunidades para podermos fazer algo diferente.

Inclusive comemoramos o findar de um ano e o chegar de um novo! Fazemos festas! Brindamos de alegria e alívio! E assim procedemos todos os anos, pois no íntimo o que fazemos no final desse ciclo de 12 meses é avaliar o resultado das promessas, metas e desejos que nos fizemos no início do ano. É avaliar se cumprimos com nossas promessas, se alcançamos nossos objetivos e se realizamos nossos desejos. O saldo foi positivo ou negativo? Onde falhamos e onde acertamos?

No fundo o que estamos fazendo é uma retrospectiva do ano. Uma retrospectiva que nos leva a traçar um novo plano de ação, com melhorias a serem implementadas, novas promessas, novas metas, novos desejos e para isso é preciso recomeçar. Fechar um ciclo e começar um novo.

Mas… O que vem primeiro? Trabalho Iterativo ou Retrospectiva?

É porque trabalhamos de forma iterativa que fazemos retrospectivas ou é porque fazemos retrospectivas que precisamos trabalhar de forma iterativa?

"Retrospectivas permitem o aprendizado de todo o time, agindo como catalizador de mudanças e gerador de novas ações/atitudes" [1].

Para fazer retrospectivas precisamos trabalhar de forma iterativa?

Para gerar novas ações e atitudes é preciso que venha algo depois para colocá-las em prática, certo?

E conforme apresentei no post anterior (Retrospectiva Ágil) uma retrospectiva pode acontecer ao final de um projeto, onde o levantamento das lições aprendidas poderá ser utilizado em um outro projeto.

Logo, não é porque um time deseja fazer retrospectivas que é preciso trabalhar de forma iterativa. Um projeto que use de metodologias outras que não sejam metodologias ágeis pode (e deve) ter ao final do projeto uma reunião de retrospectiva para formalizar as lições aprendidas e gerar ações novas para um próximo projeto.

O importante é o desejo do time de querer fazer a retrospectiva para favorecer a aprendizagem contínua.

Se trabalhamos de forma iterativa temos que fazer retrospectiva?

Trabalhar de forma iterativa significa termos vários ciclos curtos (em geral de 2 a 4 semanas) dentro de algo maior, um projeto, por exemplo.

Um dos ganhos em se trabalhar de forma iterativa é a possibilidade de ao final de cada ciclo o time poder fazer uma retrospectiva tratando das lições aprendidas no ciclo finalizado, gerando ações para o ciclo seguinte.

Nesse caso, o conceito de aprendizagem contínua é maximizado! Pois certamente alguns poderão dizer: "Se eu trabalho sem ser de forma iterativa eu também estou aprendendo!". Sem sombra de dúvida, aprendemos sempre de uma forma ou de outra. Porém, com diversas retrospectivas no final de cada ciclo ao longo de um projeto, é possível conhecer aos poucos mais sobre o projeto, seus requisitos, do cliente, das pessoas que integram o time, do processo e poder adaptar logo.

Isso é Aprendizagem Contínua Ágil! : )

Aprendizagem Contínua Ágil

Mas a pergunta acima ainda não foi respondida… : )

Trabalhar de forma iterativa atrai retrospectivas, porém o time tem que querer fazer.

O time tem que entender os benefícios de uma retrospectiva para melhor aproveitá-la, tem que querer aprender, querer mudar, querer melhorar continuamente. Na agilidade não há espaço para a famosa frase "time que tá ganhando a gente não mexe". Mexe sim, esse é o desejo. Se está bom o que podemos fazer para ficar ainda melhor?!

E não é somente a questão de querer mudar por mudar, mas dada a complexidade das relações entre as pessoas que integram o projeto, a imprevisibilidade do que vai acontecer logo adiante no projeto, que tudo vai mudando a todo momento e isso requer adaptação para continuarmos sendo produtivos e ágeis para reagir a essas mudanças (está nos princípios do Manifesto ágil: "responder a mudanças ao invés de seguir um plano").

Inclusive, dada toda essa complexidade, as próprias retrospectivas vão mudando a medida que o projeto e o time vão evoluindo.

Na sequência a esse post abordarei mais as etapas que compõem a estrutura básica de uma reunião de retrospectiva apresentando técnicas e práticas que podem ser usadas em cada uma dessas etapas.

Enquanto isso, não deixe de ler o post anterior da série: Retrospectiva Ágil.

E aproveitando, se tiver dúvidas, não deixe de postá-las como comentário. As responderei em cada post dessa série.

 


Referências:

[1] – Agile Retrospectives. Making Good Teams Great, Esther Derby & Diana Larsen, The Pragmatic Programmers

[2] – Retrospectiva Ágil –  Blog ScrumHalf, Ester Lima

Referências:

[1] – Agile Retrospectives. Making Good Teams Great, Esther Derby & Diana Larsen, The Pragmatic Programmers

 

– See more at: http://blog.myscrumhalf.com/2013/12/retrospectiva-agil/#more-8615