I do not like sprints which are longer then 2 weeks and here is why. One of the ideas of time-boxed iterations is to create an environment in which people can get frequent and regular feedback on their work and their way of working. The retro is a tool which reserves time and space for the team e.g., to reflect on their way of working, to reflect on how work is progressing, to understand the big picture in their work (meaning e.g., a longer period of time instead of only daily activities).
Do YOU remember what happened four weeks ago or even three weeks ago? To me, such a time-span feels like ages ago (sometimes like a dream) and I really have hard times to remember details. If this is the case for many, how can you do a meaningful sprint retro covering the entire time span of four weeks? Therefore, I proposed to the team to have an intermediate sprint retro in the middle of the sprint (even though it would be more beneficial for the teams to work in shorter sprints, four weeks seem to be carved in stone).
And so we had. The team created a time-line, listing those positive and negative events which the team members regarded as meaningful. We moved all in front of the time-line chart and the team members shared what they see in the chart, what they think about this “bigger picture” and to some limited extend how they feel about it.
We were able to identify several issues/ facts/ problems/ challenges as well as some ideas for solutions. I found this an important step as the team realized by themselves that (right now) plenty of time and energy is spend on faults and furthermore the team acknowledged that there is room for improvement on what they can do.
And me? I got work for many many weeks to resolve those impediments and I think the team members got a glimpse of what they could do to improve the situation. As the team's “normal” scrum master was also present, the two of us discussed later about the findings and he said, that basically most of those issues are known in the organization (and why is nothing happening in resolving those items???). I still give credit to many people for trying to solve the issues, sometimes, it might not be in a lean and agile “spirit”, which might be the problem why some changes do not stick (this needs certainly deeper digging).
We also reflected a little on our daily scrums and yet again, great ideas came up by the team to improve the information flow in the daily scrum. Lets see how it will go in the future.