Re: Retrospective instructions? Yes - SIMPLE if done right.
--- In firstname.lastname@example.org, "Alan Dayley" <alandd@...> wrote:
> One of my weaknesses is a tendency to seek complex solutions. Maybe
> retrospective methods are so simple that I'm looking for more
> complexity where there is none.
Alan - I think it really is simple. The simplicity comes from a clear
understanding of how much and how little you are trying to accomplish.
I like to say that we don't call things we understand 'complex'
unless we are trying to intimidate others with our pretension of
knowledge. :-) [sorry if this undermines book sales]
more in context below...
--- In email@example.com, "David H." <dmalloc@...> wrote:
> Reading and learning about retrospectives has probably been the
> most challenging part of my becoming a scrum master back in the
> days and it is still challenging, because it involved soft skills
> which cannot easily be taught.
Interestingly, I found doing effective retrospectives
straight-forward. Perhaps I have some decades of soft skills that I
take for granted. But I don't think that's what's going on. I use a
simple process that I refined while co-teaching a CSM class with
Miskin Berteig a number of years ago. Another piece of the context -
I have successful, focused teams - not contentious ones. That comes
from how I train and coach them. We are just dealing with reality,
openly and honestly, continuing to learn and delivering value.
1. Start with flip-chart pages with adhesive backs (PostIt brand)
placed on the wall.
2. Put the Project Name, Sprint # and dates on the top, draw a line
down the center, put a plus sign at the top of the left column and a
delta sign at the top of the right column. [These are artifacts to be
kept throughout the project in a heap that can be reviewed by the team
members when there's a need. Therefore I put the Sprint
identification below the adhesive area.]
3. To avoid possibly defensive interaction - I ask all team members to
silently take small (3"x3") PostIts and write at least three positive
point about he last Sprint and place them in the left column. I give
them 10-15 minutes and if people are still writing, I'll give them
3. I then read them out loud and ask for clarification if there's
ambiguity. We time-box some discussion - perhaps 15 minutes. The
goal is to appreciate our successes.
4. I then ask people to write at least three points that could use
improvement (deltas) - done in the same fashion as the positives.
5. I group them by theme and read them, asking for clarifications of
ambiguity as with the positives. We have some time-boxed discussion
and prioritize the themes by giving everyone five points to distribute
among them. There's nothing sacred about 5, perhaps 1.5 times the
number of options. The point is to get highest priority ones
6. Starting with the highest scoring themes, we discuss action items
we can take next Sprint to improve this issue. They get written on a
separate piece of flip-chart paper. We choose actions that people
feel comfortably are doable. We stop when the team agrees it's enough
to include in the next Sprint. Examples are:
a) update the task board at least 5 minutes before the stand-up;
b) inform the team (or ScrumMaster) if you need to miss a stand-up
for an emergency or a planned event.
c) change a meeting time that is not working or conflicts with a
d) have the ScrumMaster get impediments escalated and resolved faster.
e) engage in more team collaboration such as with testers or
pair-programming to eliminate silos of code-base knowledge.
These two artifacts (collection of pluses & deltas and retro. action
items) are kept on the information radiator, typically on top of the
previous Sprints versions. We can talk to them as part of the daily
Scrum - like any other tasks being worked on.
I find everyone gets engaged and takes it seriously as long as the
team has the authority to make the changes they propose.
BTW - I do the same for a project retrospective. I just use a full
flip-chart page for each, plus and delta.
more in context below...
--- In firstname.lastname@example.org, Richie Moyle <rsmoyle@...> wrote:
> I tend to start with a simple flip chart with sheets (blue tacked)
on the wall covering "plus delta analysis":
> What went well?
> What didn't go so well?
> What are we going to change (prioritised)?
> I start with either input from individuals (round table) for what
went well, this gets the whole team involved and motivated.
> Secondly you could use the anonymous index cards to kick off what
didn't go well. I like this method as it gives the team a chance to
feedback on each other and more importantly, the Scrum Master.
> Finaly, pick the top 5-10 things that didn't go well and concentrate
on identifying the changes you are going to make for them. If time
allows, tackle the remainder.
> In my experience, the simpler the Retro is, the more success I have
had from teams.
Absolutely - as long as it's focused and purposeful.
> Tip : Try holding it over a lunchtime at a restaurant
> (or dare I say, pub).
I think this may distract from the focus - but I should try it sometime.
> The most important thing is to make the results visable to the team
during subsequent sprints. I tend to put the flip chart sheets up
around their white boards, so they can't ignore the changes they
agreed to make.
Absolutely - radiate it and act on it.
Alan - let me know how this works for you - using a kiss principle.
Lean/Agile Coach, Trainer &
- --- 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.