I originally titled this “Components of a Great Sprint Retrospective” – but behaviors is the better word. You can have all the processes and systems you want but at the end of the day, it’s the behaviors that the team excuses that make a team’s Sprint Retrospective successful.
Whether it’s code, test cases, or requirements. Trust what you have built, and how you have built it, and share it with others. There is nothing to hide from having done an incredible job that you have poured everything into.
Back to figuring out the hard problems. Back to banging your head against the wall. Back to having setbacks. Back to things breaking over and over again. Back to betas that blow up. Back to Build Mode.
We get frustrated when we undertake activities when we cannot see the value they derive. Inevitably this is the response of our team as well. Everyone wants to be doing things of value. The goal then is to make sure you can draw the line between those that do generate value (focus on those) and those that don’t (eliminate those too) and ensure you are doing the same for your team.
Someone can tell me that putting my hand on fire is going to hurt. I don’t need to experience it for myself – whether I know you or not – I’ve seen what it can do to a piece of wood and can draw the conclusion myself, irrespective of how well I know you. However, when the scenarios are less than known, how much we trust the source doling out the knowledge adjusts how much…