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…
- Four people trusting each other for support: Joi on Flickr | CC BY 2.0
Pingback: Can you trust agile software development? - Greger Wikstrand
Pingback: Should you distrust agile? - Greger Wikstrand