Why Retrospectives should not be pushed to the next sprint
Hi guys, first of all I want to apologize for not contributing any new posts lately. I moved to another city, changed my job, and this took all my energy. :)
During this past week I had some interesting discussions with a few of my colleagues about retrospectives and when to conduct them. Therefore, I want to explain why, in my opinion, retrospectives should be the last thing to do in a sprint and not dragged into the next sprint.
In my opinion, retrospectives are the most important part of agile software development. This is the time when teams analyse their ways of working and suggest new methods to improve their current processes.
I believe everyone agrees that this is a mandatory artefact and cannot be avoided. However, not everyone agrees that retrospectives should be conducted within the sprint— thus I would like to explain why I think it´s important to do these within the sprint.
First of all, I see retrospectives as the closing part of a sprint; when the team does a retrospective, the sprint is over, and everything related to it is gone. This allows the team to start a new fresh sprint without any pending issues from the previous sprint.
Secondly, during retrospectives teams come up with several action points and topics to be tackled during the next sprint. If we allow a retrospective to be dragged on for two or three days inside of the next sprint, how can we take all of the items that will pop up within the retrospective and put them into the planning process for that sprint? This is why I think it´s extremely important to confine retrospectives within sprints.
I just wanted to share this observation with you; I hope it was useful.
In case you are interested in Agile Retrospectives I am at the moment preparing a 10 DAYS FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.
[hcshort id=”14″]
More from our blog
See all posts
Hi Luis,
I will sent you a message via Twitter, although I almost only used it for reading blogs, etc. :-)
We could do a Skype session if you like. Let me know what suits you best.
Regards,
Michael
Hi Luis,
the Prespective was discussed with my team and they feel we already are doing this while dealing with our weekly backlog meeting, during our retrospectives, as we also include the planning meeting for the next iteration in there, and ad hoc when we encounter impediments.
How do you see the Prespective?
Regards,
Michael
Send me a msg in twitter :) Lets get a skype call ;)
Hi all,
Within my project we also do a retro at the end of each iteration.
We combine the retro with a demo of the iteration’s shippable product, if present, and a planning session for the next iteration.
As a team we make sure our backlog is managed weekly, or more often if necessary, so we can prepare for the planning part of the meeting. This is really helpful and leads to a very constructive and efficient meeting with the whole team being very happy.
If, in the middle of an iteration, we encounter problems or improvements we write them down and discuss them directly or decide to discuss them during the retro meeting if not that urgent. During the retro we chose a few improvements to work on in the next iteration so we improve continuously.
The prespective seems very interesting to me. I feel we already could deal with this during our weekly backlog prioritising meetings. We have a good feeling of the most important stories which probably will be included in the next iteration and could already discuss what Niels points out in his reply. Will take this to the team tomorrow. Thanks for that!
Regards,
Michael
Thanks Michael, let me know how did it go :)
Oh my goodness! an amazing article dude. Thank you However I am experiencing issue with ur rss . Don’t know why Unable to subscribe to it. Is there anyone getting identical rss problem? Anyone who knows kindly respond. Thnkx
From: http://www.malotaux.nl/ :
Retrospectives are important to learn what could have been done better. Prespectives, however, are even more important, to imagine what we are going to do that may lead to learning in the Retrospective, because then we can decide to do it better before we’ve done it, rather than afterwards finding out that we should have done it better. With a Retrospective, we already wasted time on something we should have done better. With a Prespective, we can avoid wasting that time.
Thanks for your nice comment. I fully agree.
Luis
If retrospective is dragged to the next sprint, team will be focused in new tasks and will lost the the items to be improved. Retrospective is the key for a mature process.
For me, I agree that retrospectives need to be at the end of the sprint in which they relate. It gives everyone an opportunity to put their baggage out there and then leave it behind. Once an iteration starts then people automatically switch their thinking to the next thing, the next piece of work and it becomes harder to look backwards. Also having the retro at the end of a sprint is a good time for the team to unwind, especially if it was a difficult iteration. The importance of this time should not be underestimated.
BTW. Lucian, if you get together in the middle of an iteration to discuss a problem, it is just a meeting not a retro.
Nice points.
I like to finish the Sprint with a demonstration and after that the retrospective. So I prefer to put this meetings inside of own Sprint because sometimes I try to take the opportunity on schedule of stakeholders and managers and invite they to participate of retrospective meeting. Like listeners and without participative (or imperative) opinions. Listeners.
This kind of meeting depend of maturity skill level of your team and I know that the most common practice probably is the participation only of PO and SM.
Other explanation is about the storage time that brain can retain information and how much important information will be lost. New informations are coming and the oldest going.
Without good facts there are no good actions.
If you cold not do it at the end of Sprint do it in the beginning of next one. But do it. :)
And what people think about to push the retrospective to next Sprint or something like this?
Regards
The most important about retrospectives is that they ensure that the process is constantly and regularly improved.
Having the retrospective at the end of sprint allows us learning a lesson from what has just been concluded on the sprint review and improve the collaboration.
Reblogged this on Sutoprise Avenue, A SutoCom Source.
First, in order to judge correctly, what do you mean by “should be conducted within the sprint”, and what are the options others present ?
It is important to consider when the sprint ends, because there are various views and this influences the time-scope of the retrospective.Some believe that the sprint contains also the demo/review meeting, and sometimes the retrospective is scheduled before this meeting, that could go very bad, and the learnings are deferred for the next time a retrospective takes place.
Beside this, I share your view that each sprint should have a retrospective attached to it :) so that people think about what was good, what was wrong, and how things could be changed for better. But I also add that this should not be an iron rule. Retrospectives need to take place whenever learning is happening, whenever changes are needed.
I personally have encountered situations where we had a retrospective mid-sprint, because of an important event, and the retrospective was about how we did builds. We all agreed that this is so important that it can not and it does not worth waiting until the end of the iteration. At that moment it was a good approach.