I noticed it first with retrospectives. Esther Derby and I worked to share our insights about this powerful tool in the Agile Retrospectives book. We created a simple, flexible framework that could be dressed with activities most relevant to that team on that day. Many people have told us how much the book means to them and their teams, the benefits from holding retrospectives, and the support they felt.
Other parts of the community have sung a different refrain. “We tried retrospectives and they didn’t work for us.”
Setting aside time for a shared informal learning and improvement opportunity didn’t work for them? A easy-to-use framework that focused the conversation on the nitty-gritty of their most recent work experience didn’t work for them? Discussing and planning for ways to improve work lives, product quality, team interactions didn’t work for them? Really?
But this isn’t about people who are too inept to use retrospective well. These people have a point, but it’s not the point they think. Because we also hear, “We tried TDD and it didn’t work for us.” “We tried pairing and it didn’t work for us.” “We tried backlog grooming and it didn’t work for us.” “We tried Scrum…Kanban…Lean…(N-methods) and it didn’t work for us.” And this is true with many other Agile practices.
Clearly this isn’t an issue with retrospectives, it’s an issue with how new Agile teams embrace, absorb and master the core elements of Agility. It’s about Fluency.
Jim and I invested several years of our lives getting a whitepaper (and, more recently, an eBook) planned and launched because we see that the Agile community has reached a point of frustration that shows a critical need for a fresh perspective, a fresh approach, and a fresh way to see its own learning.