-
Notifications
You must be signed in to change notification settings - Fork 4
/
risesprint5-042211.html
240 lines (200 loc) · 11.1 KB
/
risesprint5-042211.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xml:lang="en" xmlns="http://www.w3.org/1999/xhtml" lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="prev" href="http://opl-management.rit.edu/rise/node/571">
<link rel="up" href="http://opl-management.rit.edu/rise/node/506">
<link rel="canonical" href="http://opl-management.rit.edu/rise/node/681">
<link rel="shortcut icon" href="http://opl-management.rit.edu/profiles/openatrium/themes/ginkgo/favicon.ico" type="image/x-icon">
<link type="text/css" rel="stylesheet" media="print" href="risesprint5-042211_files/reset.css">
<link type="text/css" rel="stylesheet" media="print" href="risesprint5-042211_files/base.css">
<link type="text/css" rel="stylesheet" media="print" href="risesprint5-042211_files/print.css">
<link type="text/css" rel="stylesheet" media="print" href="risesprint5-042211_files/print-custom.css">
<link type="text/css" rel="stylesheet" media="all" href="risesprint5-042211_files/reset.css">
<link type="text/css" rel="stylesheet" media="all" href="risesprint5-042211_files/base.css">
<link type="text/css" rel="stylesheet" media="all" href="risesprint5-042211_files/print.css">
<link type="text/css" rel="stylesheet" media="all" href="risesprint5-042211_files/print-custom.css">
<title>Sprint 5 Retrospective (2011-04-22) | OPL Open Atrium</title>
</head><body class="print rubik admin-static page">
<div class="limiter clear-block">
<div id="content" class="clear-block">
<div class="print-header">
<h1 class="site-name">OPL Open Atrium</h1>
</div>
<div id="node-681" class="node node-book clear-block node-page">
<div class="node-submitted clear-block">
<div class="picture">
<a href="http://opl-management.rit.edu/rise/user/14" title="View user profile."><img src="risesprint5-042211_files/picture-14.jpg" alt="John Karahalis's picture" title="View user profile." class="imagecache imagecache-user-s" height="30" width="30"></a></div>
<div class="byline"><a href="http://opl-management.rit.edu/rise/user/14" class="username" title="View user profile.">John Karahalis</a></div><div class="date">7:12pm Fri Apr 22</div> </div>
<h2 class="node-title">
<a href="http://opl-management.rit.edu/rise/node/681">Sprint 5 Retrospective (2011-04-22)</a>
</h2>
<div class="node-content clear-block prose">
<div id="diff-inline-681"><p>Posted below are the meeting notes
from the Sprint 5 Retrospective meeting. These meetings occur at the end
of each sprint with the goal of improving the process. Two question are
asked -- "What went well?" and "What could be improved?".</p>
<p>Everyone: Please let me know if I misrepresented you here.</p>
<h2>Red Bottle</h2>
<ul>
<li>Seppi: It's great to consult with Red Bottle, people who have professional Drupal experience.</li>
<li>Riordan: Yes. In the past we have tried researching stuff, but
having someone who can say "Been there, done that, here's what you need
to do." is very valuable.</li>
</ul>
<h2>Estimation</h2>
<ul>
<li>Riordan: We need people to provide a more realistic estimation of
how much work they can take on. Ariel has over-committed in the past,
and John made the same mistake a week later.</li>
<li>John: [I didn't think to mention this at the meeting, but it is an important point. This is actually <a href="http://www.youtube.com/watch?v=WMgch8BxSWw#t=02m25s">a very common problem</a> among Scrum teams. Teams learn to avoid this mistake only through experience.]</li>
</ul>
<h2>The Planning Meeting</h2>
<h3>Timing</h3>
<ul>
<li>Guy: I think the planning meeting went very well this week.</li>
<li>Me: What about it went well?</li>
<li>Guy: The timing was good. Everything was accomplished quickly (we
even had 10 minutes to spare), but we still covered everything.</li>
</ul>
<h3>Being direct</h3>
<ul>
<li>Me: What do you think caused the timing to work out so well?</li>
<li>Guy: Everyone knew what needed to get done.</li>
<li>Riordan: Everyone realizes that the the deadline is looming.</li>
<li>Riordan: Also, John was very direct. He started the meeting off with
"This is what needs to get done. We can't put off any development to
week 9 -- we will only do testing that week. I won't budge on this."</li>
<li>Guy: Yes. You showed us where we were and what we needed to do.</li>
</ul>
<h3>"State of the state"</h3>
<ul>
<li>Me: At the beginning of the meeting, I gave an overview of all the
remaining tickets. Did this work or not? I noticed that most people
didn't seem interested in this.</li>
<li>Guy: I think it was good, but too fast. Also, you asked people "What
do you want to do?". Instead, I think you should have framed the
question as "What is the highest priority?"</li>
</ul>
<h3>Assigning tasks</h3>
<ul>
<li>Mark: If someone doesn't have any tasks, give some to that person.
We need stuff done. If someone is available, give that person something
to do. I was in this position a few weeks ago -- I wasn't assigned
anything, so I had nothing to do. I could have been working on the theme
during that time.</li>
<li>Me: Guy, should I assign tickets to people who don't have any? Doesn't Scrum advise against this?</li>
<li>Guy: Yes. The success of the team depends on individual members
being committed to success. If you assign tasks to people, they tend to
be less committed to getting that task done.</li>
<li>Me: But I do think Mark is making an important point. Maybe we can
strike a balance. If I notice someone is low on tasks, I can say "Hey
Joe, you don't have a lot of stuff on your plate. What are you
interested in working on?"</li>
<li>Guy: That seems like a good approach.</li>
</ul>
<h3>Food</h3>
<ul>
<li>Riordan: How has food affected the meetings? Has it had a positive or negative effect?</li>
<li>Me: I think pizza got people too excited. It gave them the energy to
say "Well, we can do it this way!!". I really think that exhaustion was
one of the reasons this last meeting was so successful. Everyone was
tired, so cutting out the fluff to get to the core points was much more
easy.</li>
</ul>
<h3>"To be done..."</h3>
<ul>
<li>Me: While we all seem to like the "To be done..." criteria, I think
it is too time consuming to write them out during the meetings. Matt and
Ben mentioned their frustration with this. Filling these out before the
meetings would be very helpful, I think.</li>
<li>Riordan: Yes. Some things will change slightly during the meeting,
but we will have about 80% understanding of what needs to be done before
the meeting.</li>
<li>Me: Agreed. Professor Riordan, can you fill these out before these meetings?</li>
<li>Riordan: I have a tight schedule, but I can get some work in. Since
you're usually in at about 12, maybe you can review / amend them at that
time.</li>
<li>Me: That makes sense. I tend to be more conservative, so maybe this
would be a good job for me. "Don't forget to about this aspect of that
feature!"</li>
</ul>
<h3>Misc</h3>
<ul>
<li>Mark: John often defaults back to "I'll take the ticket" if no one
else is interested. Don't let that happen. Let other people take
responsibility for the work.</li>
<li>Me: Agreed. I'll do that.</li>
</ul>
<h2>Daily Status Updates</h2>
<ul>
<li>Riordan: Participation is low.</li>
<li>Guy: Yes, but it is better than the last time John tried it.</li>
<li>Guy: Dustin asked me "If I don't do anything, should I still write
something up?" I told him that he should -- the point is not to make
people feel guilty about not doing enough work, the point is to get an
understanding of where everyone is.</li>
<li>Me: Funny, Jackie asked me the same question. I had essentially the same answer.</li>
<li>Me: Do you think it is too time-consuming for people to fill these out?</li>
<li>Guy: I think the length is fine.</li>
</ul>
<h2>Burnout</h2>
<ul>
<li>For me, the most major problem this week was burnout and lack of
motivation. I had enough time to improve the contribution form, but I
was just too burned out to do much. I barely had enough energy to think.</li>
<li>Guy: You know why that is, right?</li>
<li>Me: No...</li>
<li>Guy: Scrum advocates having a short break between sprints. Some
companies have, for example, three week sprints. They sprint for three
weeks and have a retrospective meeting at the end. They then spend about
a week working on other projects before starting the next sprint.</li>
<li>Riordan: In the hyper-compressed development we are doing now, the
time to relax is the weekend. We need to make sure everyone uses it
effectively.</li>
<li>Guy: John, have you been working on the weekends?</li>
<li>Me: Not much, but sometimes.</li>
<li>Riordan: You shouldn't. You need to relax.</li>
</ul>
<h2>Ben / Design</h2>
<ul>
<li>Guy: Ben's design mockups were amazing. Seeing tangible stuff like that is great.</li>
<li>Me: Do you think that fits into the "user story"-driven development that you advocate?</li>
<li>Guy: <strong>Yes!</strong> That's essentially what it was. "To post a story, the user goes here", etc.</li>
<li>Me: I totally agree.</li>
</ul>
<h2>"Done"</h2>
<ul>
<li>Riordan: I think the deadlines have been ending soft. We never fully
meet out deadlines, and instead end in a state of
almost-done-but-continuing-next-week.</li>
<li>Me: I've been thinking about this. Last year, I took a much more
strict approach to "done". If we needed to finish, say, user
registration at the end of Sprint 1, I would ensure that everything
regarding registration was completely finished by that point. I would
stay up until 4am to make sure that happened. This worked to a degree,
but it also increased stress dramatically.</li>
<li>Guy: I think the "To be done..." criteria work well here, since
these are minimum requirements for completion. If something doesn't meet
these criteria, the whole task should be marked as incomplete and moved
to the next sprint.</li>
<li>Riordan: If we had more time, I think we would have better time estimates by now and this would be sort of a non-issue.</li>
</ul>
<h2>How sprints end</h2>
<ul>
<li>Guy: What I want to know is how sprints end. I really have no idea,
and I don't think anyone else really knows either. I don't know what
actual deployment process I need to keep in mind and live up to.</li>
<li>Me: That makes sense. I think people will be more likely to live up
to their tasks if they actually picture what will happen at the end.</li>
<li>Guy: Yes. In the future, just say "On Friday, I will take your code and move it here."</li>
</ul></div> </div>
<div class="node-links clear-block"><ul class="links inline"><li class="book_add_child first"><a href="http://opl-management.rit.edu/rise/node/add/book?parent=663">Add child page</a></li>
<li class="print active"><a href="http://opl-management.rit.edu/rise/node/681?print" class="active">Print</a></li>
<li class="print_recurse last active"><a href="http://opl-management.rit.edu/rise/node/681?print&book_recurse" class="active">Print entire section</a></li>
</ul></div>
</div>
</div>
<div id="footer" class="clear-block">© 2009 <a href="http://www.developmentseed.org/">Development Seed</a></div>
</div>
</body></html>