Teams adopting agile, and even frequently teams who consider themselves agile, often hit a stumbling block. Here’s how the thinking goes… agile is about improvement. Agile projects do retrospective to improve. Therefore, retrospectives = improvement and improvements (only) happen in retrospectives.
Unfortunately many teams suffer without realising improvements go beyond retrospectives. Everyday there is an opportunity to improve, an opportunity to learn. It sometimes takes a while to see them. It often takes much longer to unwind the restraints of organisational “process” on people’s desires to experiment and fail fast, and learn from those mistakes.
Don’t get me wrong. Retrospectives also have their place. Sometimes teams don’t have an environment safe enough and retrospectives are one way of helping establish some safety. It takes commitment from leaders to create this environment of safety, and something I encourage greatly when I work with teams.
Do you recognise your team falling in this pattern? Break out of them, and remind them that improvements don’t have to wait for a meeting to be attempted.
Great post Pat. I think one of the times that retros go wrong, are when people wait until the retro to make a point. If this is an issue the team hasn’t ever discussed, it becomes a winge fest!
I find this to be less of a problem with retros and more a problem with the culture of the team, where issues aren’t big and visible and feedback isn’t shared regularly. I completely agree that leaders have a great responsibility in ensuring that there are open channels of communication – retro or not!
I’ve seen my previous team evolve from ‘holding back improvement suggestions until the retrospective’ to ‘raising them the minute they appear in their mind’. My feeling says this change in mindset comes with hands-on experience. Most experienced agile developers I know, are already in this mindset, and practice continuous improvement constantly.