RE: [scrumdevelopment] Retrospective instructions?
Designing and leading a retrospective is no more difficult than executing the project itself, which should give you an idea regarding complexity. But, as the facilitator (which I assume you are) you may have more control over the complexity in the retrospective. That said, a retrospective is an initially designed event that changes based on the needs of the group and the objectives of a given retrospective. To be a master practitioner, you need a huge toolbox and the ability to think on your feet and work skillfully with group dynamics.
Derby and Larsen’s book will make clear to you that there is a set of exercises, activities and techniques that you can pull out of the box to get yourself started. They by no means cover the waterfront on this, and “full-time” retrospective practitioners are always coming up with new techniques. The time line is one of those, as is the mad, sad, glad technique.
Norm Kerth is the “father of retrospectives,” and his book /Project Retrospectives: A Handbook for Team Reviews/ is the basic text for practitioners. Through reading that book, you’ll discover that a good retrospective both gathers data for the organization so it can do better next time and “clears” the project from the team so they can get on with the next thing. One very important thing that Kerth talks about is preparing for the retrospective by walking around and assuring that all participants will be showing up willing to participate; you also need to have an understanding of why they won’t if they will not. This “walking around” process will help you decide whether and how to use the mad, sad, glad device. It may or may not be the best way to get the information you need and help the group process their experience of the project.
Retrospectives have a beginning, middle, and end, which is why the timeline is useful. I think the Prime Directive (http://www.retrospectives.com/pages/retroPrimeDirective.html) is critical to retrospective success. I distribute it to team members and have them put it on their wall as we near the end of the project so I can start training this principle into the group. It can also help stabilize a team late cycle on a difficult project.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Cory Foy
Sent: Monday, September 01, 2008 8:31 PM
Subject: Re: [scrumdevelopment] Retrospective instructions?
Alan Dayley wrote:
> I waiting for the "Agile Retrospectives" book to arrive so itmay be
> the resource I'm looking for. In the mean time, I'm finding little onYou should have purchased the PDF version directly from the Pragmatic
> the web to help define retrospective techniques.
Programmers site. Not too late. ;)
> For example, many blog posts and photos mention doing a "timeline"
> retrospective or using "mad, sad, glad" or some other thinghere
> structures. But few, if any, provide a definition of HOW to do "mad,
> sad, glad" or any of the other methods. Is usually "We used and
> are the results...," which is fine for the blog writer's purpose butI
> want to learn the details of the "" part.In my write-up, I tried to give a brief synopsis of each thing I did:
http://www.cornetde sign.com/ 2008/07/agile- retrospectives. html
> One of my weaknesses is a tendency to seek complex solutions. MaybeThere's the book you've already got. Bill Wake posted a good overview of
> retrospective methods are so simple that I'm looking for more
> complexity where there is none. Is there a resource of outlines of
> how to do these different retrospective methods?
some patterns here: http://xp123. com/xplor/ xp0509/index. shtml
There's also the Retrospectives web site: http://www.retrospe ctives.com/
That should get you started. I believe there is a mailing list somewhere
as well. And if worse comes to worse, I'd be happy to answer questions
about what we're doing.
- --- In email@example.com, Ron Jeffries
> Yes. I have some dear friends who used SAMOLO and loved it. I wasIt seems to me this has less to do with clever mnemonics or
> not as impressed as they were. For reasons such as you're referring
> to, and others, it seemed to me that important things just couldn't
> be brought up.
retrospective techniques (which are certainly useful tools) and more
to do with the fact that retrospection is not equivalent to
introspection either individually or collectively. A tendency towards
superficial examination of past history without a requisite amount of
serious introspection cannot have a significant impact on future
development. As with all things Scrum related, teams will get out of a
retrospective whatever they put in. The trick for the ScrumMaster or
coach is to inspire them to be more introspective individually and as
a group. I don't think there is a mnemonic or prescriptive technique
that provides that.