Highly Specific Scrum meeting Question
July 22, 2010 8:22 AM Subscribe
Agile/scrum filter: Alternatives to staring at a backlog Google doc to discuss task updates?
I'm a project manager at a small web agency., We use scrum/Agile to manage projects, and put our task backlog into a Google doc, so it's easy for everyone to access to put in their time estimates at the end of each day.
It's been common practice for the project manager to bring their laptop to a scrum meeting, and bring up the Google doc on the flat screen in the conference room while everyone talks about their updates. I dislike this for several reasons -- it's really cumbersome to haul out my laptop and change my screen resolution for the flat screen, all for a fifteen minute or less standing status update. Also, the point of agile is for team collaboration, and people tend to stare awkwardly at the doc on the screen and mumble updates.
The only problem is, people claim to forget what their tasks were so think they need the spreadsheet or some alternative.
I'm wondering what other people have seen in these meetings, what do you do during scrum meetings to go through the project backlog? I should add that these are short two week sprints with a small team. without a ton of separate tasks assigned to each person. We also are a small company so people are on multiple scrum teams.
Looking for personal experiences/past experience, not links to online Agile tomes -- esp for small web agency work with multidisciplinary groups.
I'm a project manager at a small web agency., We use scrum/Agile to manage projects, and put our task backlog into a Google doc, so it's easy for everyone to access to put in their time estimates at the end of each day.
It's been common practice for the project manager to bring their laptop to a scrum meeting, and bring up the Google doc on the flat screen in the conference room while everyone talks about their updates. I dislike this for several reasons -- it's really cumbersome to haul out my laptop and change my screen resolution for the flat screen, all for a fifteen minute or less standing status update. Also, the point of agile is for team collaboration, and people tend to stare awkwardly at the doc on the screen and mumble updates.
The only problem is, people claim to forget what their tasks were so think they need the spreadsheet or some alternative.
I'm wondering what other people have seen in these meetings, what do you do during scrum meetings to go through the project backlog? I should add that these are short two week sprints with a small team. without a ton of separate tasks assigned to each person. We also are a small company so people are on multiple scrum teams.
Looking for personal experiences/past experience, not links to online Agile tomes -- esp for small web agency work with multidisciplinary groups.
We're having essentially the same problems as you right now (two week sprints, painful spreadsheet list of "stories" discussed in the meetings, etc). We have managed to do proper stand ups for about a month now, without any visual aid. This has mostly worked but it is still a mess of email attachments, a badly organized wiki, etc.
The one thing I've always really liked, development wise, is a bug tracker or similar. One place where you can get a list of items currently assigned to you, where you can track comments and decisions along the way and assign the item to another resource (say, back to a business analyst if the story/item needs clarification or further specification, or to a database resource so the data model can be updated to support the requirements in the item).. By using such a system the individual members have a place to go to get a list of their items right before the stand up. It can be up to them to gather that data or not - some people can remember their tasks off hand, some can't.
There are problems with the bug tracker solution, of course. It doesn't fit completely into the scrum/Agile method perfectly and it takes time to enter all the stories into the system.
This perhaps doesn't answer your question as well as I hoped, but it's good to discuss and think about alternatives. I'm looking forward to any other answers that might pop up here..
posted by mbatch at 8:29 AM on July 22, 2010
The one thing I've always really liked, development wise, is a bug tracker or similar. One place where you can get a list of items currently assigned to you, where you can track comments and decisions along the way and assign the item to another resource (say, back to a business analyst if the story/item needs clarification or further specification, or to a database resource so the data model can be updated to support the requirements in the item).. By using such a system the individual members have a place to go to get a list of their items right before the stand up. It can be up to them to gather that data or not - some people can remember their tasks off hand, some can't.
There are problems with the bug tracker solution, of course. It doesn't fit completely into the scrum/Agile method perfectly and it takes time to enter all the stories into the system.
This perhaps doesn't answer your question as well as I hoped, but it's good to discuss and think about alternatives. I'm looking forward to any other answers that might pop up here..
posted by mbatch at 8:29 AM on July 22, 2010
Response by poster: To clarify -- we need to have the in person standing meetings. We also need to use the Google doc to update backlogs. What I'd like to do is not have to pull up the doc in the meeting and still be able to keep the meeting on track and cover all tasks.
posted by sweetkid at 8:33 AM on July 22, 2010
posted by sweetkid at 8:33 AM on July 22, 2010
At my job we use the exellent free pivotal tracker to manage the backlog. It tracks issues, code velocity, issue assignment, etc.
During stand ups we just talk about the current sprint's items in the order they appear on screen and give updates on progress. It's obviously just as centralized as a spreadsheet or google doc, but I think that having good software to track the project's tasks forces developers to keep things up to date as they proceed and helps project managers prioritize features/bugs/chores etc.
posted by tjenks at 8:42 AM on July 22, 2010
During stand ups we just talk about the current sprint's items in the order they appear on screen and give updates on progress. It's obviously just as centralized as a spreadsheet or google doc, but I think that having good software to track the project's tasks forces developers to keep things up to date as they proceed and helps project managers prioritize features/bugs/chores etc.
posted by tjenks at 8:42 AM on July 22, 2010
Ah sorry, if you're beholden to the google doc, then my answer is irrelevant.
posted by tjenks at 8:43 AM on July 22, 2010
posted by tjenks at 8:43 AM on July 22, 2010
Not trying to sound dismissive, but how about holding people accountable for a) knowing what their tasks are, and b) being prepared for the meeting to provide them?
I mean, seriously, you're the project manager here. Why are people delegating work up to you? When a task gets assigned, you are not only assigning the task, you're also assigning responsibility for reporting on that task.
Step up and manage!
posted by bfranklin at 8:44 AM on July 22, 2010 [1 favorite]
I mean, seriously, you're the project manager here. Why are people delegating work up to you? When a task gets assigned, you are not only assigning the task, you're also assigning responsibility for reporting on that task.
Step up and manage!
posted by bfranklin at 8:44 AM on July 22, 2010 [1 favorite]
It adds an extra step to task creation, but where I work we use a hybrid of scrum and Kanban. Every task gets a card on the magnetic whiteboard. It starts out in the general bucket of "ready to be worked on", and everyone has a line on the board that their tasks move along from design to development, and so on thru release-ready.
At a glance, we can see how many tasks are waiting to be worked on, how quickly tasks are flowing thru everyone's worklist, and what tasks aren't moving. We use a webcam pointed at the whiteboard, and someone local will move along cards for our remote team member as needed.
posted by nomisxid at 8:48 AM on July 22, 2010
At a glance, we can see how many tasks are waiting to be worked on, how quickly tasks are flowing thru everyone's worklist, and what tasks aren't moving. We use a webcam pointed at the whiteboard, and someone local will move along cards for our remote team member as needed.
posted by nomisxid at 8:48 AM on July 22, 2010
Response by poster: no, bfranklin, that's exactly the kind of advice I'm looking for.
posted by sweetkid at 8:51 AM on July 22, 2010
posted by sweetkid at 8:51 AM on July 22, 2010
what do you do during scrum meetings to go through the project backlog?
Everything -- at least the user stories -- should be on physical cards pinned or taped to a giant board. The daily scrum meeting should occur standing in front of this board.
Moreover, the cards should be physically moved through the completion process on this board at this meeting -- which great for team morale ("Hey look, we're getting closer!") and overall buy-in of the process ("Aww yeah, look at me, moving my card to 'done.'")
posted by Cool Papa Bell at 8:52 AM on July 22, 2010
Everything -- at least the user stories -- should be on physical cards pinned or taped to a giant board. The daily scrum meeting should occur standing in front of this board.
Moreover, the cards should be physically moved through the completion process on this board at this meeting -- which great for team morale ("Hey look, we're getting closer!") and overall buy-in of the process ("Aww yeah, look at me, moving my card to 'done.'")
posted by Cool Papa Bell at 8:52 AM on July 22, 2010
Our team used to have this problem and meetings got much better when we stopped bringing up the computer at every Scrum. Ask people to take notes on what they did if they can't remember (I am often bad at remembering my tasks especially if I did a bunch of little things rather than one big thing). Have them print out the list of backlog items and bring it if they must. Also you don't need to update the backlog during the meeting; people can be responsible for updating the backlog on their own or you can do it after the meeting.
posted by phoenixy at 9:08 AM on July 22, 2010
posted by phoenixy at 9:08 AM on July 22, 2010
Seconding branklin and phoenixy. We had the same exact issue. We also had devs go "Durrrr without looking at it I don't know what I'm working on." This was solved by changing the scrum status meeting culture of "Look at the board and talk about what's next to your name" to "Talk specifically about what you have done yesterday, what you're going to do today, and what if anything blocking your progress."
It took some redundant reminders of the methodology -- to the point where the meeting request specifically had the standup instructions above -- but we got to the point where if people can't keep track of what they're doing, they need to write it down and look at their notepad before they speak. Some do that, some have gotten better at encapsulating their efforts into one minute highlights. :)
The converse of this is the PM now needs to keep their own notepad, and pretty much jot down/scribe notes. You could still do this with your laptop, I imagine, I don't know good you are at touch typing.
I am not a certified yada yada scrum master, but I've used agile for years, and the key to it I find is reinforcing the idea that the status meeting is not a "I'm good, this person sucks" meeting, it's all about communicating honestly and directly what the progress is on the project from every angle. It's not that often, but anytime I've had DB pipe up with "I can't do this item until so and so tells me foo" and then Web come back with "I thought I already gave you foo! Here is foo!", then everyone goes YAAAY Agile and we all have imaginary milkshakes to celebrate.
posted by cavalier at 9:20 AM on July 22, 2010
It took some redundant reminders of the methodology -- to the point where the meeting request specifically had the standup instructions above -- but we got to the point where if people can't keep track of what they're doing, they need to write it down and look at their notepad before they speak. Some do that, some have gotten better at encapsulating their efforts into one minute highlights. :)
The converse of this is the PM now needs to keep their own notepad, and pretty much jot down/scribe notes. You could still do this with your laptop, I imagine, I don't know good you are at touch typing.
I am not a certified yada yada scrum master, but I've used agile for years, and the key to it I find is reinforcing the idea that the status meeting is not a "I'm good, this person sucks" meeting, it's all about communicating honestly and directly what the progress is on the project from every angle. It's not that often, but anytime I've had DB pipe up with "I can't do this item until so and so tells me foo" and then Web come back with "I thought I already gave you foo! Here is foo!", then everyone goes YAAAY Agile and we all have imaginary milkshakes to celebrate.
posted by cavalier at 9:20 AM on July 22, 2010
Everything -- at least the user stories -- should be on physical cards pinned or taped to a giant board.
I admire this methodology, but I would have too many folks trying to set fire to the board. There's a real, um, novelty to the way our stakeholders treat the priority of the backlog system. Haha.
posted by cavalier at 9:21 AM on July 22, 2010
I admire this methodology, but I would have too many folks trying to set fire to the board. There's a real, um, novelty to the way our stakeholders treat the priority of the backlog system. Haha.
posted by cavalier at 9:21 AM on July 22, 2010
Are you having daily scrum meetings, or are you talking about sprint planning meetings or other types of status meetings?
I do think that one of the very few things about scrum that should never change is the DAILY scrum. If you're not doing it daily, I think this is the only place where you can safely say, you're doing it wrong. The daily scrums are the best thing about Agile Development. I'm not crazy about rigidity in production processes, but this is one thing that should never change. It needs to be at the same time every day and it needs to be short and sweet and focused. You should not even have it on a slightly different time of day. It's almost like conditioning. I use the analogy that it is the project team's version of "family dinner". It happens every day, damnit, no matter what, even if we're all pissed at eachother and nobody does much more than grunt.
Have you ever read this book? If not, do not do anything until you read this first. There are a lot of things about Agile and Scrum that I'm not really all that wild about, but I can safely say that unlike with some other production methodologies, if you biff one very major part of it, you really will have a hell of a time making it work. They suggest doing it by the book to start and only making tweaks to the process when you are really comfortable, and I do have to say, that's really important.
If you're using agile at your company, I would say, double check that you have the following completely down and in lock step.
Do you have daily scrums?
Do you know who your product owner is?
Do you know who the scrum master is?
Do you know who the customer is?
Are these three discreet people?
Do you know who owns the backlog?
If the answer to all of these are yes, you should not have the problem you're having in your scrum meetings.
Also, maybe look intoJira. It's a relatively low cost web-based solution to manage an agile project and I find it pretty useful to easily pull up for team meetings. Never in the daily scrum though. That's just a bunch of people with coffee standing up first thing in the morning.
posted by pazazygeek at 9:36 AM on July 22, 2010
I do think that one of the very few things about scrum that should never change is the DAILY scrum. If you're not doing it daily, I think this is the only place where you can safely say, you're doing it wrong. The daily scrums are the best thing about Agile Development. I'm not crazy about rigidity in production processes, but this is one thing that should never change. It needs to be at the same time every day and it needs to be short and sweet and focused. You should not even have it on a slightly different time of day. It's almost like conditioning. I use the analogy that it is the project team's version of "family dinner". It happens every day, damnit, no matter what, even if we're all pissed at eachother and nobody does much more than grunt.
Have you ever read this book? If not, do not do anything until you read this first. There are a lot of things about Agile and Scrum that I'm not really all that wild about, but I can safely say that unlike with some other production methodologies, if you biff one very major part of it, you really will have a hell of a time making it work. They suggest doing it by the book to start and only making tweaks to the process when you are really comfortable, and I do have to say, that's really important.
If you're using agile at your company, I would say, double check that you have the following completely down and in lock step.
Do you have daily scrums?
Do you know who your product owner is?
Do you know who the scrum master is?
Do you know who the customer is?
Are these three discreet people?
Do you know who owns the backlog?
If the answer to all of these are yes, you should not have the problem you're having in your scrum meetings.
Also, maybe look into
posted by pazazygeek at 9:36 AM on July 22, 2010
Best answer: Another Lady PM here.
At the risk of sounding like a real bitch, you are not their mom. Seriously. It is not your responsibility to show them the task list in the daily scrum. If they can't come to a meeting with their shit together then they need some kind of remedial help, in the form of their direct manager telling them to quit wasting people's time.
Forthwith, it is each team-member's responsibility to come to the meeting with adequate notes to get through the exercise. End of story.
posted by Medieval Maven at 9:41 AM on July 22, 2010
At the risk of sounding like a real bitch, you are not their mom. Seriously. It is not your responsibility to show them the task list in the daily scrum. If they can't come to a meeting with their shit together then they need some kind of remedial help, in the form of their direct manager telling them to quit wasting people's time.
Forthwith, it is each team-member's responsibility to come to the meeting with adequate notes to get through the exercise. End of story.
posted by Medieval Maven at 9:41 AM on July 22, 2010
Best answer: Sorry, I want to add here -- why are you reviewing the backlog in your daily stand up? The backlog should be reviewed only at sprint planning only. Are you working in sprints? Do you do group sprint plans, or are you asking the team to pull tasks directly out of the backlog every day when they're out of work?
It seems crazy to me that your team wouldn't be able to remember what they worked on yesterday and what they're working on today -- unless there is some form of confusion on the part of your team regarding what they've signed up for.
I do think you should be very careful not to hold your team accountable for "not knowing what their tasks are" if you're not making it very clear to them what their near-term tasks are. The sprint plan is an important buffer zone between your dev team and your backlog.
Jesus, listen to me, I sound like some sort of Agile dev kool-aid drinker. I should be writing this on stickies and posting them to the wall instead of here.
Again, to reiterate, I feel like agile development is really risky because people read a few books and web articles here and there, adapt it sorta, and then think they're working agile when in reality they're just only sort of planning in tiny increments day to day. That is not how it's supposed to work, and like I said before, you kind of do have to do it by the book so that everybody understands their roles and responsibilities and what they've committed to, otherwise, you get a frustrated team.
posted by pazazygeek at 9:45 AM on July 22, 2010
It seems crazy to me that your team wouldn't be able to remember what they worked on yesterday and what they're working on today -- unless there is some form of confusion on the part of your team regarding what they've signed up for.
I do think you should be very careful not to hold your team accountable for "not knowing what their tasks are" if you're not making it very clear to them what their near-term tasks are. The sprint plan is an important buffer zone between your dev team and your backlog.
Jesus, listen to me, I sound like some sort of Agile dev kool-aid drinker. I should be writing this on stickies and posting them to the wall instead of here.
Again, to reiterate, I feel like agile development is really risky because people read a few books and web articles here and there, adapt it sorta, and then think they're working agile when in reality they're just only sort of planning in tiny increments day to day. That is not how it's supposed to work, and like I said before, you kind of do have to do it by the book so that everybody understands their roles and responsibilities and what they've committed to, otherwise, you get a frustrated team.
posted by pazazygeek at 9:45 AM on July 22, 2010
I admire this methodology, but I would have too many folks trying to set fire to the board.
Well, we do have the "burn the cards" party when the sprint is done...
posted by Cool Papa Bell at 9:54 AM on July 22, 2010 [1 favorite]
Well, we do have the "burn the cards" party when the sprint is done...
posted by Cool Papa Bell at 9:54 AM on July 22, 2010 [1 favorite]
There are only 3 questions that everyone should answer at a daily scrum. The meeting should be as short as possible (but no shorter).
There is no time for updating spreadsheets, going through paperwork, shooting the breeze. On a simple day the meeting could last 2 minutes.
If ANYTHING comes up in the meeting that needs to be discussed or co-ordinated, immediate schedule time to deal with it after the scrum. Don't do it during the scrum. Let everyone answer the 3 questions, then anyone not required to be there can get back to work.
The reason scrums (or daily stand-ups, etc) fail is because it becomes a chance for people to sit around and chat, or have design discussions. You have to control that, but you also have to remember it's not YOUR meeting. You're only a facilitator. Every individual there is responsible for his or her own actions. They are reporting to the team, not to you.
posted by blue_beetle at 9:55 AM on July 22, 2010
There is no time for updating spreadsheets, going through paperwork, shooting the breeze. On a simple day the meeting could last 2 minutes.
If ANYTHING comes up in the meeting that needs to be discussed or co-ordinated, immediate schedule time to deal with it after the scrum. Don't do it during the scrum. Let everyone answer the 3 questions, then anyone not required to be there can get back to work.
The reason scrums (or daily stand-ups, etc) fail is because it becomes a chance for people to sit around and chat, or have design discussions. You have to control that, but you also have to remember it's not YOUR meeting. You're only a facilitator. Every individual there is responsible for his or her own actions. They are reporting to the team, not to you.
posted by blue_beetle at 9:55 AM on July 22, 2010
Oh, I should also add that if the team is setting the schedule, then the team is accountable to each other, and the team decides if each individual is pulling their weight. The backlog doesn't need to be managed. It only needs to be groomed in between sprints.
posted by blue_beetle at 9:57 AM on July 22, 2010
posted by blue_beetle at 9:57 AM on July 22, 2010
Well, we do have the "burn the cards" party when the sprint is done...
OOO! That sounds lovely actually. Will have to consider that the next time we get a project with clearly defined end goals at the start of the sprint. please gaia one sweet day all I ask.
posted by cavalier at 10:01 AM on July 22, 2010
OOO! That sounds lovely actually. Will have to consider that the next time we get a project with clearly defined end goals at the start of the sprint. please gaia one sweet day all I ask.
posted by cavalier at 10:01 AM on July 22, 2010
Response by poster: Wow, thanks so much for all these answers!! Yes, we are having daily scrum meetings. The main problem with them is all this staring at a spreadsheet -- I do agree that people should know their tasks, but I don't have a lot of experience running scrum meetings and a lot of experience with devs thinking PMs (especially women) should be their mom or should remind them of tasks, that I really appreciate the anecdotes of expecting them to be responsible for themselves, and all the other stories about how scrum works in other workplaces. So great!
posted by sweetkid at 11:05 AM on July 22, 2010 [1 favorite]
posted by sweetkid at 11:05 AM on July 22, 2010 [1 favorite]
Start with using a physical scrum board (cards/stickies, etc.). It really highlights the fact that so-and-so didn't move any cards today, or is adding cards to the board, or nothing is in the completed column and there are only two days left. It is an essential tool for doing scrum right. Whoever commits to a task puts their name on it. There is no forgetting, it's all on the board. Cards should be moving every day.
Second, if you decide you must have an electronic version (for backup, reporting, etc.), I would highly recommend using a scrum-specific software tool (Rally, Version One, Pivotal Tracker) in addition to the physical board. It may sound like duplication, but it is absolutely worth the small amount of extra effort.
> We also are a small company so people are on multiple scrum teams.
That is a major challenge. I think this is the key issue - you are failing to build a strong team that is accountable to each other. If you're acting as the scrum master, building that team is your job.
posted by nuffsaid at 1:03 PM on July 22, 2010
Second, if you decide you must have an electronic version (for backup, reporting, etc.), I would highly recommend using a scrum-specific software tool (Rally, Version One, Pivotal Tracker) in addition to the physical board. It may sound like duplication, but it is absolutely worth the small amount of extra effort.
> We also are a small company so people are on multiple scrum teams.
That is a major challenge. I think this is the key issue - you are failing to build a strong team that is accountable to each other. If you're acting as the scrum master, building that team is your job.
posted by nuffsaid at 1:03 PM on July 22, 2010
Response by poster: hey nuffsaid, I get your point -- but I can't do anything about the multiple scrum teams -- that's just our structure.. One challenge we face is that people will say a completely different project for a completely different client was what was holding them back.
posted by sweetkid at 2:05 PM on July 22, 2010
posted by sweetkid at 2:05 PM on July 22, 2010
Sweetkid: There is ScrumMaster training/certification available for pretty cheap near you. I'd highly recommend taking these courses.
posted by blue_beetle at 2:43 PM on July 22, 2010
posted by blue_beetle at 2:43 PM on July 22, 2010
Not directly related, but this is what I wanted to tell the PM during (awful) time I was on a scrum project: I would get a lot more done if you stopped coming up with silly little action items that I had to follow up on with pretty much everyone I knew. Yes, you just wanted to nail everything down and had good intentions, but I was a pig and you a chicken so you could at least have taken care of that stuff yourself.
posted by meepmeow at 6:10 PM on July 22, 2010
posted by meepmeow at 6:10 PM on July 22, 2010
The pig and chicken metaphor never ceases to make me hungry.
posted by cavalier at 3:46 AM on July 23, 2010
posted by cavalier at 3:46 AM on July 23, 2010
> One challenge we face is that people will say a completely different project for a completely different client was what was holding them back.
This is a symptom of the multiple scrum teams. This setup is allowing team members to determine the priority of the stories rather than the product owners working this out. Additionally, the complexity of working on multiple teams makes it very difficult for team members to accurately commit to the work in a sprint. It's also going to make it very, very hard to figure out a team's velocity and thereby establish a pattern of getting 'done'. What you're probably seeing is that various teams aren't getting done with the sprint and POs are getting annoyed that the stuff they expected to be completed isn't.
The ideal solution is to reorganize so that (as much as possible) team members are fully committed to only one team. Without this you are missing out on much of the value that scrum provides.
That said, I'm sympathetic to your situation and realize you probably don't have the ability to make that sort of sweeping change... here two things that might help: One would be to make sure attention is being paid to resource allocation across teams after planning and before the team commitments are made. One of the software solutions I mentioned before should be able to help with this process (tracking individual utilization/workload across multiple teams).
Second would be to institute a 'scrum of scrums' where representatives from each team meet for a stand-up on overall progress and to work out dependency/resource issues. This group should also conduct retrospectives and that may provide a forum to initiate broader changes.
Scrum master training may help (or just frustrate you in your current situation); coaching for the entire organization would be ideal. Hang in there!!
posted by nuffsaid at 8:00 AM on July 23, 2010
This is a symptom of the multiple scrum teams. This setup is allowing team members to determine the priority of the stories rather than the product owners working this out. Additionally, the complexity of working on multiple teams makes it very difficult for team members to accurately commit to the work in a sprint. It's also going to make it very, very hard to figure out a team's velocity and thereby establish a pattern of getting 'done'. What you're probably seeing is that various teams aren't getting done with the sprint and POs are getting annoyed that the stuff they expected to be completed isn't.
The ideal solution is to reorganize so that (as much as possible) team members are fully committed to only one team. Without this you are missing out on much of the value that scrum provides.
That said, I'm sympathetic to your situation and realize you probably don't have the ability to make that sort of sweeping change... here two things that might help: One would be to make sure attention is being paid to resource allocation across teams after planning and before the team commitments are made. One of the software solutions I mentioned before should be able to help with this process (tracking individual utilization/workload across multiple teams).
Second would be to institute a 'scrum of scrums' where representatives from each team meet for a stand-up on overall progress and to work out dependency/resource issues. This group should also conduct retrospectives and that may provide a forum to initiate broader changes.
Scrum master training may help (or just frustrate you in your current situation); coaching for the entire organization would be ideal. Hang in there!!
posted by nuffsaid at 8:00 AM on July 23, 2010
This thread is closed to new comments.
posted by TheBones at 8:29 AM on July 22, 2010