Agile Continuous Learning

Iteration and retrospective is so natural that we do it every year.

The end of the year is an expected moment for all of us. We expect it so eager as an opportunity to leave the old year behind: leave the frustrations, doubts, complaints, failures... everything behind and Start a brand new year with more days, months, more opportunities for us to do something different in ours lives.

The New Year is so expect that we celebrate it! We party and toast of joy and relief! And so we proceed each year because inwardly what we do, at the end of that 12-month cycle, is to evaluate the result of the promises, goals and desires that we did in the beginning of the year. We evaluate if we keep our promises, if we reach our goals and realize our desires. The balance was positive or negative? Where we failed and where we succed?

Actually we are doing is a retrospective of the year. A retrospective that brings us to chart a new plan of action, with improvements to be implemented, new promises, new goals, new desires. And for all these it´s necessary to begin again. Close a cycle and start a new.

But… Which comes first? The Iteration or the Retrospective?

Because we work in cylces we do retrospective? Or because as we do retrospective we need to work in an iteration way?

“Retrospectives enable whole-team learning, act as catalysts for change, and generate action.” [1].

As we do retrospective we need to work in an iteration way?

To generate new actions and attitudes we need a new opportunity to put them into practice, right?

As presented in the previous post (Agile Retrospective) a retrospective can happen at the end of a project, where the lessons learned can be used in another project.

Therefore, it is not because a team wants to do retrospectives that he must work iteratively. A project that uses methodologies other than agile can (and should) do, at the end of the project, a retrospective meeting to formalize the lessons learned and generate new shares for an upcoming project.

The important thing is the desire of the team to do a retrospective to foster continuous learning.

Because we work in cylces we do retrospective?

Working iteratively means having several short cycles (usually 2-4 weeks) into something bigger, a project, for example.

One of the gains in working iteratively is the opportunity the team have to look back, at the end of each cycle, analyse what happen and generate actions for the next cycle.

In this case, the concept of continuous learning is maximized! For surely some might say: “If I don´t work iteratively I’m also learning”. Not a doubt! We always learn one way or another. However, with several retrospectives at the end of each cycle over a project, you can gradually learn more about the project, its requirements, the customer, the people who make up the team, the process… and be able to adapt immediately.

That’s Agile Continuous Learning! 🙂

Agile Continuous Learning!

But the above question is still not answered : )

Iterative work attracts retrospectives, but the team needs to want to do it.

The team must understand the benefits of a retrospective to better take advantage of it, they have to want to learn, want to change, want to continuously improve. And it is not the issue of wanting to change just for change,considering the complexity of the relationships, the unpredictability of what will happen later in the project, that everything is changing all the time that requires from all of us adaptation to continue being productive and agile to react to these changes (Agile Manifesto: “respond to changes over following plan”).

Following this post I will discuss further steps that make up the basic structure of a retrospective meeting. I will presente practical techniques that can be used in each of these steps.

And while, if you have any questions, be sure to post them as a comment in this post. I will answer in each post of this series.

Referencies:

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