I often hear the same complaint about Agile Retrospectives: They are not held at the right level in the organization! Or, at least, that is the conclusion that people draw from one fact: Many issues brought up in the Retrospective need resolution at a much higher level in the organization. There is no one in the room who can address or resolve them. Continue reading
Yesterday, I wrote about the methodological challenges of correlation based research on software artefacts. The article which is the base for this post also has a fundamental methodological flaw. McHugh, Conboy and Lang have perfomed a post hoc study of trust in agile software development teams where they asked the participants to compare “now” with “before”…
Their conclusion is that the agile software development practices studied (iteration planning, daily standups and iteration retrospectives) does increase trust among team members. One of the interesting findings is that team members see little value in the iteration retrospectives.
They felt that
it was routine with few issues raised. In the event that an issue is raised, there may be
some discussion, yet few action points are made or followed up from the retrospective.
The retrospective as implemented limited communication, knowledge sharing, and the
provision of feedback, which are important for building trust. There was also some
concern expressed over the participants of the retrospective. In one case the Product
Owner was regularly absent from the retrospective, which impacted their relationship
with the team and little trust was reported between them and the team.
I have personally found that conducting a good agile retrospective is very hard. After participating in, leading and coaching retrospectives for years in several projects I have come up with a model that works, takes less than an hour to perform and leads to prioritized actionable results. I thought I had already blogged about it but since I have not, be sure to remind me about that in the future…