“here's what's in my way” (impediment/obstacle - get dealt with after the meeting since often don't involve all team members)
those are the 3 questions
also a potential 4th question - “on a scale of 1-10, what is my level of confidence that we're going to meet our iteration goal?” 10 total confidence
15 minutes - no more. Could be shorter
Distributed teams with people working from home, team members even stand up
keeps transparency and visibility into what is happening
anybody can show up, but only the team gets to talk
power of public declaration of progress - keeps people focused
story points - effort linked, not time
some teams pick what they call “an ideal programmer day” and give that a 1. “Ideal Day”
some teams say “this is a typical thing that we need to develop”, and give that a 1
just important that the points remain reletive to each other
at end of every iteration, demonstrate running, working software
Ron Jeffries - “the lash of Jeffries” - you have to produce running software, show that it works, demonstrate to the customer in order to get feedback
opportunity for customer to tell you early and often if it's meeting their needs, missing something
time for team to demonstrate “here is what we got to 'done'”
if you can't demo it, it doesn't count as done
may also have additional blackbox testing or testing by users
user testing, regression testing, uat testing was all done during the iteration
another opportunity for team to identify what got in their way from doing what they wanted to do
team lead responsibility to remove the impediments
at end of every iteration
12th Principle is that at regular intervals, the team stops in order to give itself feedback on itself, how it's working together, what kinds of things are coming up over and over again
opportunity to see patterns on how the team is working together
Serves the purpose of: allows you to look at things over time
teams who've worked together for a long time may choose not to do The Retrospective every time, but should never go more than 1 month without one
half a day or less. Minimum 90 minutes - need that time in order to get value out of it. Opportunity for destructive things to be identified.
always have a focus, get everybody ready to do the work
quick check in, “how did this last iteration go for you?”
spend time gathering data. Get everybody's perspective. Everybody comes in thinking they knew what all was going on, but collective picture gives the whole view.
Timeline vs. radar graph
get a shared set of data
seperate the team from the data. Whiteboards and flip charts come in handy. Have people write stuff on sticky notes.
becomes “you and me against the problem written down over there”
make a decision as a group about what's going to be done
get that and go on to….
…“so what does this tell us?”
…“so what are we going to do about this?” Action planning state
experiment we'd like to try?
change up pairing rotation?
things within the team's control or outside the team's control?
if outside, bumping up against organization's culture then need to determine a workaround
example of the Wildcard VP who would continually cause havok, disrupt the team's plan
team couldn't change the guy
team could control how they responded even if they couldn't control the nature
hopefully no more than 1 action item comes out from The Retrospective
needs to be something important enough that you can make a case to the customer that they're going to benefit from the action item
stopped using “which of these is most important” - too absract
now uses “which of these will have the biggest impact?”, which leads then to “which of these do we have the most energy for?”
Now know action plan. Close the retrospective. “How did the retrospective go?” = a restrospective on the retrospective. generally quick