In my little experience and in all the books that I have read (have read most on Retrospectives), I always see retrospective as a one-time event. There are many types of these though - a sprint/iteration retro, or a release retro, program retro - you name it. Yet, though various in scope, they seem similar in structure - recounting experience for the duration that the retro covers. One uses various means to prepare the team, poll them for their thoughts, represent them in a visible information radiator and facilitate discussion. This is truly a great exercise that I have come to admire, that forms a wonderful feedback loop for the team.
Now, I have been trying to do this a little different recently - applying Systems thinking. How about, in the usual retro that you do, after collecting the various positive and negatives, you don't see them as individual issues but a chain of cause and effect. For every positive or negative, there is, if you seek into the audience another cause attributed - and soon you'd see an entire cycle emerge (Last build was slow - (why, because) - the CI pipeline has become large - (why, because) - the QA had suddely added a lot of tests - (why, because) - we hadn't added enough functional tests earlier - (why, because) etc etc.. you see then the entire retro starts to make sense.
What do you think?
RSS Feed