Thursday, July 21, 2011

Forced proximity and stand-up dynamics

I noticed something interesting when acting as Scrum Master for the Digital Archaeology Project. Our main meeting room is the Anthropology Department's conference room, which has tables set up in a U-shape.

While some of the students knew each other before the start of the project, many did not. When we started our first stand-up meeting, it was clear that the students wanted to stand around the outside of the tables, where they had sat down upon arrival. I shepherded the team towards the center of the tables in order to have their stand-up meeting.

There were three professors in the room, and we were all seated on the outside of the U during the stand-up meeting. I think this is significant, since from the very start of Sprint 1 to today, our last stand-up meeting, the students never turned and reported their progress to us, the Product Owners and Scrum Master. Every meeting, the team exemplified the agile best practice of reporting to their teammates. Even though there was clear line of sight among everyone in the room, the tables provided a psychological barrier that allowed the team to carve out its own private space in the middle of the room, without losing the benefit of having the Scrum Master listening in to determine how to remove impediments.

The cost of the room configuration was paid in Sprint Planning meetings. We used a portion of the wall for our task board, which comprised of colored index cards, tape, and yarn.

The cards are standard 3x5, and so to write user stories or tasks on them requires one to write relatively small, around 22 points. During the Sprint Planning meetings, however, the team would sit within the U in two rows. The close row, about eight feet from the wall, could see and read all the tasks, modulo handwriting issues. The next row, probably three times as far, could not make out a thing written on the cards. There wasn't really a way to get everyone close enough to read and still be comfortable, not without moving tables around. In retrospect, perhaps we should have just moved tables around for these meetings. Also, the complications of the space were exacerbated by the fact that we skipped the product planning meetings in which the team would discuss story points per user story: because of our very tight timeline, I assigned story points based on intuition.

There's not enough time in four one-week sprints to react to all the complications that can arise. It would have been nice to have more time in this space to see how to optimally use it. Next semester, I'll be back in my usual Computer Science classrooms, which come with their own issues.

No comments:

Post a Comment