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?


Leave a Reply

    View my profile on LinkedIn


    The author of this blog goes by many names in different places. But, the one that seems to have  stuck for now is... RamRam


    August 2013
    November 2012
    April 2012
    December 2011
    September 2011
    December 2010


    Business Analysis
    Cognitive Science
    Product Management
    Social Justice
    Software Consulting
    Systems Thinking